Как оптимизировать веб приложения
Интернет развивается с невероятной скоростью, как и разрабатываемая нами веб-платформа. Зачастую мы не задумываемся о том, как обстоит дело у наших клиентов. Лишь бегло взглянув на сегодняшнее состояние веба, можно заключить, что мы абсолютно забыли, насколько он изменчив.
Так что же есть современный интернет?
Только у 46% из 7.4-миллиардного населения Земли есть доступ в интернет. Средняя скорость соединения — 7Мб/с. Что более важно, 93% пользователей сидят в интернете с мобильных устройств, поэтому сегодня непростительно забывать о мобильных платформах.
Наши сайты не в лучшей форме - сегодня среднестатистический сайт весит столько же, сколько оригинальный Doom (порядка 3 Мб). Справедливости ради стоит заметить, что для статистики лучше использовать медианы (прочтите статью Ильи Григорика «Идеальная средняя статья — это миф»). Медианный сайт весит около 1.4Мб. Изображения занимают примерно 1.7Мб, JavaScript — 400Кб. Этой проблеме подвержены не только веб-платформы. Не лучше обстоит дело и с нативными приложениями.
Как люди, связанные с технологиями, мы чувствуем свое превосходство. С современными ноутбуками, телефонами последних моделей и быстрым интернетом просто забыть, что это есть не у каждого.
Как учесть эти нюансы в дизайне и разработке, не нанеся при этом ущерб представлению?
Один из наиболее эффективных, но редко используемых способов увеличения производительности состоит в том, чтобы понять, как браузер анализирует и хранит статику. Современные браузеры весьма успешно анализируют приоритет ресурсов прямо во время их парсинга. И именно здесь на сцене появляется критический запрос.
Запрос является критическим, если в нем содержится статика, необходимая для рендеринга контента в рамках пользовательского рабочего окна.
Для большинства сайтов это будет HTML, стили, логотип, шрифты и, возможно, изображения. Но на деле оказывается, что в это же время помимо них запрашиваются множество других, второстепенных вещей (JavaScript, трек-коды, реклама и т. д.). К счастью, мы можем контролировать это поведение, указывая приоритет подгрузки статики.
Благодаря <link rel="preload"> можно напрямую предписать высокий приоритет в очереди загрузки статический файлов, что может значительно оптимизировать UX.
Для многих критические реквесты до сих пор остаются черным ящиком, и на этом в большой степени сказывается недостаток в свободном доступе материалов на данную тему. Однако, недавно Бен Шварц (Ben Shwartz) опубликовал невероятно исчерпывающую и доступную статью по этому предмету. Также рекомендуется к прочтению материал Preload, Prefetch and Priorities in Chrome.
Для отслеживания приоритетов запросов можно использовать Lighthouse performance tool и Critical Request Chains audit, или следить за запросами во кладке Network в панели разработчика Chrome .
Картинки зачастую составляют львиную долю материалов веб-страницы, поэтому их оптимизация может в значительной степени повлиять на улучшение производительности пользовательского интерфейса. Существует множество стратегий и инструментов для устранения лишних байтов, но давайте зададим себе главный вопрос: «Существенна ли эта картинка для передачи идеи или достижения эффекта, которого я добиваюсь?» Если есть возможность обойтись без нее, вы сэкономите не только на пропускной способности, но и на запросах.
В некоторых случаях один и тот же результат достижим несколькими способами. CSS богат художественными инструментами: тени, градиенты, анимации, фигуры. Все это позволяет надлежащим образом стилизованным элементам DOM служить достойной заменой статическим изображениям.
Выбор правильного формата
Если избежать использования статики невозможно, важно правильно определить для нее наиболее подходящий формат. Первая ступень — выбор между векторной и растровой графикой:
- Вектор: не зависит от разрешения, как правило значительно компактнее. Идеально подходит для логотипов, иконок и простых изображений, основанных на геометрии.
- Растр: подходит для высоко детализированных изображений, например, фотографий.
После принятия этого решения, вам откроется широкий выбор: JPEG , GIF , PNG -8, PNG -24, или новейшие форматы, такие как WEBP или JPEG - XR . Как не ошибиться в выборе из такого широкого спектра?
- JPEG: для изображений с богатой цветовой палитрой (например, тех же фотографий)
- PNG-8: для изображений с малым количеством цветовой
- PNG-24: для изображений с прозрачными участками
- GIF: для анимаций
Экспериментальные форматы
В последнее время на арене появились несколько новых форматов: WebP , JPEG 2000 и JPEG - XR . Все они были созданы разработчиками браузеров.
WebP – самый популярный из них. Он поддерживает сжатие с потерями и без потерь, что делает его невероятно гибким. Сжатый без потерь WebP весит на 26% меньше PNG и на 25-34% легче JPG . Он поддерживается 74% браузеров, а Photoshop позволяет конвертировать в этот формат JPG и PNG .
Оптимизация инструментами и алгоритмами
Даже использование самых эффективных графических форматов не оправдывает игнорирования последующей оптимизации. Это — ключевая ступень.
Если вы выбрали SVG , который сам по себе относительно мало весит, он тоже должен быть сжат. Для этого существует ряд неплохих инструментов, таких как SVGO или SVGOMG. Также, поскольку SVG – формат, основанный на XML , его можно сжать с помощью GZIP на стороне сервера.
Для большинства других форматов прекрасным выбором будет ImageOptim. Еще в этом году Google представил Guetzli - открытый алгоритм, происходящий из прошлого опыта с WebP и Zopfi . Он позволяет добиться сжатия JPEG до 35%. Единственный его недостаток — низкая производительность: около минуты CPU на один мегапиксель.
Адаптивность
Десять лет назад можно было обойтись одним разрешением на все случаи жизни. Сегодня же, в эпоху адаптивного веба, оптимизация играет ключевую роль. Благодаря Responsive Images Community Group, веб-разработчики прекрасно подкованы и вооружены.
Возможность использования кастомных шрифтов — невероятно мощный дизайнерский инструмент. Но большая сила сопряжена с большой ответственностью. По статистике шрифты являются главными врагами производительности примерно на 68% сайтов.
Выбор правильного формата
Существует четыре веб-формата: EOT , TTF , WOFF и более новый WOFF 2. TTF и WOFF используются чаще всего и поддерживаются более чем 90% браузеров. В зависимости от поддержки браузерами, самым оптимальным считается WOFF 2, а для старых браузеров — WOFF . Достоинство WOFF 2 заключается в том, что он подразумевает ряд кастомных препроцессорных и сжимающих алгоритмов, что позволяет уменьшить итоговый вес файла на 30% и существенно повысить возможности парсинга.
Ограничьте количество шрифтов
Вне зависимости от того, где хостятся шрифты, их количество, разновидности и стили существенно влияют на ресурсы производительности.
В идеале можно было бы обойтись одним шрифтом с обычным и жирным начертаниями.
Обозначьте стратегию загрузки шрифтов
Сначала браузер строит DOM и CSSOM ; шрифты не будут подгружаться до тех пор, пока не встретятся в CSS -селекторе уже существующего узла DOM . Такое поведение ощутимо замедляет рендеринг текста, часто приводя к эффекту FOIT (Flash of Invisible Text).
Наиболее простым и эффективным решением может стать FOUT ( Flash of Unstyled Text ).
Font - display – новое свойство CSS , предоставляющее возможность решить проблему без использования JS . К сожалению, он поддерживается лишь частично (в Chrome и Opera ) и все еще находится в процессе разработки в Firefox и Webkit .
Оптимизировать получение JavaScript – это только полдела. После того, как код будет загружен, он будет подвергнут парсингу, скомпилирован и запущен в браузере. Беглого взгляда на несколько популярных сайтов достаточно, чтобы понять, что gzipped JS после распаковки становится как минимум в три раза больше.
Избавьтесь от лишних зависимостей
В современных менеджерах легко проследить количество и размер всех зависимостей. Хорошими инструментами являются webpack-bundle-analyzer и Bundle Buddy. Визуальные инструменты позволяют обнаружить дублирование кода, самые большие затраты производительности, ненужные зависимости.
В VS Code и Atom есть расширение Inport Cost , делающее вес импортируемого пакета более наглядным.
По возможности нужно всегда стремиться хранить и загружать только необходимое. Поэтому код должен быть максимально разделен и структурирован. Также стоит обратить внимание на динамический импорт и ленивую загрузку.
В данной статье были рассмотрены основные приемы оптимизации современных веб-приложений. Сегодня, в эпоху стремительного развития интернет-технологий, громоздкие веб-сайты прошлого уходят в небытие, и на смену им приходят новые принципы и парадигмы веб-разработки.
Ни для кого не секрет, что чем меньше/быстрее/отзывчивей ваше приложение, тем лучше для клиента и следовательно для бизнеса. Именно поэтому так часто поднимается вопрос об оптимизации.
В вебе существуют 3 основных “зла” замедляющих ваш сайт: JavaScript, Изображения и Шрифты.
Начнём с самого злого.
В javascript есть 2 основных параметра за которыми нужно следить:
- Размер (kb)
- Parse Time и Compile Time
На удивление, размер тут не самый приоритетный показатель. Как показывает статистика, на мобильных устройствах Parse и Compile Time могут занимать в 2–5 раз больше времени чем на декстопе.
Так что 200kb прише д шие на мобильный телефон будут ещё “белым экраном” когда на вашем ноутбуке приложение уже готово к работе.
Как измерить Parse и Compile Time ?
Вариантов существует много, самый доступный это — about:tracing. Chrome выпустил пошаговую инструкцию как получить эти данные.
Мониторинг производительности
Если вы не привыкли лазить в Developer Tools и считывать данные с Timeline, то всегда можно использовать готовое решение.
Google Lighthouse это Open Source проект по мониторингу производительности веб-приложений. Lighthouse можно использовать как расширение для Chrome, так и как отдельную вкладку в Developer Tools.
Lazy Load и Code-Splitting
Если вы разрабатывайте приложение с кучей дополнительных библиотек, задумайтесь, нужны ли они на каждой странице (к примеру на home page).
Отдавайте пользователю только тот код, который в данный момент ему нужен. Сегодня с этим прекрасно справляется webpack.
Лишние зависимости
Многие и не замечают, как несколько лишних зависимостей в package.json увеличивают размер приложения в несколько раз.
Когда вы используйте функциональность библиотеки на 5%, то вам стоит её заменить на что-то более “лёгкое”.
webpack-bundle-analyzer и Bundle Buddy помогут определить, кто же занимает столько места в bundle.js.
Также есть классные расширения для VS Code и Atom.
Как оптимизировать JavaScript ?
- Отправлять меньше кода.
- Использовать lazy load и code-splitting. То есть отдаём и показываем только то, что в данный момент нужно клиенту.
- Удалить/заменить зависимости. Проверьте нужны ли вам все ваши библиотеки или только небольшая их часть. Привет lodash 👋
Перед тем как использовать большие и красивые изображения спросите себя: “Эта картинка действительно передаёт тот эффект который я задумал ?”. Синк эбаут ит.
Если вы не смогли убрать картинку, то тогда стоит выбрать правильный вид изображения. Существуют два самых часто используемых:
- Вектор: независимый от разрешения, обычно маленький по размеру. Идеально подходит для логотипов и иконок.
- Растр: содержит больше разнообразия чем векторная графика. Идеально подходит для фотографий.
Теперь стоит выбрать правильный формат.
Для растровой графики есть четыре основных формата, которые используются часто и долго:
- JPEG: когда очень много цветов (например фото).
- PNG–8: когда мало цветов.
- PNG–24: когда есть полупрозрачные места на изображении.
- GIF: когда изображение анимированное.
Для векторной графики только один — SVG
Новые форматы
Мир графики тоже не стоит на месте и за последние пару лет появились новые форматы: WebP, JPEG 2000 и JPEG-XR. Все они делаются разработчиками браузеров: WebP от Google, JPEG 2000 от Apple и JPEG-XR от Microsoft.
WebP самый популярным из них. WebP на 26% меньше PNG и на 25–34% меньше, чем JPG.
74% браузеров поддерживают этот формат и его можно смело использовать с помощью fallbacks.
Уменьшение размера
Использование правильного формата это не последний шаг. Теперь нужно “ужать” изображение (скомпрессировать).
Для SVG:
-
: инструмент командной строки, который может быстро оптимизировать SVG путем удаления ненужных метаданных. : если вы предпочитаете веб-интерфейс или ограничены своей операционной системой.
Для всего остального есть Mastercard.
Также существует ImageOptim. Отличный выбор для большинства типов изображений. Он объединяет в себе множество известных алгоритмов (pngcrush, pngquant, MozJPEG, Google Zopfli) превращаясь в идеального помощника. Доступно как приложение для Mac OS, так и интерфейс командной строки (ещё как плагин для Sketch есть).
Атрибут srcset
Srcset лучше всего работает когда ваше приложение часто используется как на декстоп, так и на мобильных устройствах. Основываясь на наборе правил в атрибутах srcset и sizes, браузер будет выбирать наилучшее изображение для текущего экрана. Это отличный способ порадовать мобильную аудиторию.
Элемент picture
По функционалу похож на srcset + sizes, но имеет больше возможностей. Его стоит использовать только когда у вас стоит задача оптимизировать изображения под все виды экранов и связка srcset + sizes не справляется.
Подробное руководство”что, где и почему” лучше использовать.
Использование CDN
Все изображения можно доставлять на фронтенд с помощью CDN и специальных инструментов, предназначенных для изображений, таких как Cloudinary или imgx.
CDN решает большинство проблем с нагрузкой и оптимизацией изображений. Может изменять размер, обрезать и определять, какой формат лучше всего подходит вашим клиентам на основе устройств и браузеров. Более того — они могут сжимать изображения, ставить водяные знаки, и выполнять пост-обработку.
Как оптимизировать изображения ?
- Выбрать правильный формат.
- Использовать вектор где это возможно.
- Уменьшить качество, если изменения не заметны.
- Использовать новые форматы.
- “Посжимать” с помощью приложений.
- Попробывать srcset и picture.
- Использовать CDN.
Правильный формат
Существуют четыре формата шрифтов в вебе: EOT, TTF, WOFF и более поздний WOFF2. TTF и WOFF наиболее широко используются, имея более 90% поддержки браузеров.
Преимущество использования WOFF2 заключается в пользовательских алгоритмах предварительной обработки и сжатия, что приводит к 30% уменьшению размера шрифта.
Выбирайте только нужное
Если вам серьёзно нужен на проекте extra-supra-bold-italic-800, поговорите с вашим дизайнером.
Выкидывайте все не нужные шрифты.
Набор символов
Если вы не имеете дело со всеми языками мира, то следите за тем, чтобы ваш набор символов был минимален.
Font-display
Шрифты блокируют рендеринг. Такое поведение также значительно задерживает текстовый рендеринг и вызывает такое явление как Flash of Invisible Text (FOIT).
Тут на помощь приходит font-display. Это новое CSS свойство которое может:
- Показывать резервный шрифт пока ваш ещё загружается.
- Заменить резервный шрифт на загруженный.
Font-display имеет частичную поддержку (только Chrome и Opera) и в настоящее время находится в разработке в Firefox и WebKit.
Если вас очень волнует поддержка шрифтов, то используйте Web Font Loader. Библиотека имеет аналогичный принцип работ, что и font-display, только ещё и поддерживается всеми браузерами.
Как оптимизировать Шрифты ?
- Выбрать правильный формат.
- Выкинуть все не нужные стили.
- Использовать только необходимый набор стилей.
- Попробовать font-display или Web Font Loader.
Кроме всего перечисленного существует ещё и плохой код, который может тормозить ваше приложение, чтобы этого избежать советую прочитать — “Гайд как писать на React в 2017”.
От автора: разработчики обычно создают веб-приложения, имея в виду макет для стационарных ПК. Но сегодня люди используют мобильные устройства для просмотра контента и работы с веб-приложениями чаще чем компьютеры. И поскольку эти проекты в основном созданы для настольных устройств, они выглядят уродливо на мобильных устройствах. Вот почему так важно оптимизировать приложения именно для этой сферы.
Это простое приложение React, которое предоставляет список супергероев DC. Когда я попытался запустить его на мобильном устройстве, оно выглядело так:
Как вы можете видеть, оригинальный макет приложения полностью нарушен. В этой статье я покажу вам, как с использованием функций CSS оптимизировать веб-приложение для мобильных устройств и создать компоненты, которые будут отлично выглядеть и работать как на мобильных устройствах, так и на стационарных.
JavaScript. Быстрый старт
Изучите основы JavaScript на практическом примере по созданию веб-приложения
Настройка
Я создал Scope на Bit, в котором размещены компоненты вышеуказанного приложения.
Вы также можете клонировать это приложение в своей системе с GitHub:
Запустите это приложение в своей системе, используя yarn start или npm start, чтобы увидеть, как работает оно работает.
В инструментах для разработчиков Chrome есть много замечательных функций, которые не только позволяют разрабатывать веб-приложения, но и делать это с учетом в мобильных устройств.
Откройте инструменты для разработчиков Chrome и нажмите кнопку «Переключить панель инструментов устройства», которая находится в верхнем левом углу раздела «Инструменты для разработчиков» браузера. Теперь ваш браузер должен выглядеть примерно так:
Используя панель инструментов устройства, мы можем эмулировать мобильные устройства внутри браузера. Используйте эту панель инструментов для эмуляции iPhone X.
Правильно масштабируйте страницу для небольших окон просмотра с помощью тега meta
Здесь приложение работает на эмуляторе iPhone 5 / SE. Раньше четвертый столбец приложения «View» не был виден. Но теперь все столбцы хорошо видны, а макет дизайна приложения похож на то, что я намеревался сделать.
Представляем вам набор рекомендаций, следуя которым вы сможете с самого начала улучшить производительность вашего веб-приложения.
Фактически, разница между работой на локальном хосте и настоящем производственном сервере может быть настолько драматичной, что если вы не предпримете несколько мер предосторожности, то сразу после выпуска вашего приложения вы поймете, что у большинства пользователей ваш продукт работает крайне плохо и они, вероятно, ненавидят вас за это.
Чтобы это предотвратить, мы создали набор рекомендаций с наиболее эффективными мерами, которые вы можете предпринять чтобы изначально улучшить производительность вашего веб-приложения. Также эти шаги помогут вам предупредить падение производительности при появлении новых функций уже после выхода прекрасного первого релиза.
1. Установите бюджет производительности и придерживайтесь его
Бюджет производительности это четкая задача, выражающая, насколько быстрым должно быть ваше приложение. Цель — не дать вашей команде превратить продукт в беспорядок из слежавшихся функций, который требует вечности для загрузки, что в значительной степени неизбежно для долгосрочных проектов. Как вы можете предположить, в этой стратегии есть два главных компонента:
- установить бюджет производительности сам по себе;
- следовать ему в процессе работы (вот тут-то все и оступаются).
Лучший способ внедрить это — позволить собственнику продукта четко установить приоритет для производительности. Это заставить команду (дизайнеров и разработчиков) сфокусироваться на мобильной версии, для которой скорость является одной из самых важных черт.
Когда это сделано, следующим шагом будет вставить в ваш CI Pipeline правило, которое будет блокировать все запросы на принятие изменений, не отвечающих всем требованиям. И — нет, вы не можете делать исключений (в этом смысл правила CI).
Вот два главных правила, которые мы применяем в Aerolab. Можете их скопировать:
У вас есть не больше 1 секунды чтобы показать пользователю то, что он хочет увидеть.
(1 секунда времени для первого имеющего значение изображения при хорошем WiFi на нашем стандартном экземпляре Macbook Pros).
Через 1,5 секунды приложение должно стать интерактивным.
(1,5 секунды времени для интерактивности при хорошем WiFi на нашем стандартном экземпляре Macbook Pros).
Наличие четкой задачи по производительности затрагивает все в вашем стэке, от дизайна и выбранных вами Javascript-библиотек до того, как будут настроены ваши сервера.
Когда каждый поймет, как его работа влияет на этот параметр, вы сможете остановить снижение производительности, а это значит, что вы сможете сохранить отличную скорость от самого первоначального релиза и на протяжении всей жизни продукта.
2. Сохраняйте ваше ядро настолько легким, насколько это возможно
Одна из вещей, который вы должны иметь в виду, когда начинаете новый проект, следующая.
Основные фреймворки и библиотеки, которые вы выбираете для построения вашего продукта, обычно остаются в нем навсегда, что делает эти решения в достаточной мере необратимыми.
Поэтому, если вы выбрали невероятно большой промышленный фреймворк, который каким-либо образом нуждается в запуске виртуальной машины Linux в браузере, вы можете попрощаться с производительностью вашего продукта до следующего большого рефакторинга. Которого, конечно, никогда не будет, потому что удаление вещей обходится намного, намного, намного дороже, чем их добавление.
Здесь нужен ваш профессиональный взгляд. Если вы создаете продукт для миллионов мобильных пользователей, выбор ужасно тяжелого промышленного стека может быть катастрофическим как в отношении UX, так и с точки зрения доходов. Если вместо этого вы работаете над некоторым внутрикорпоративным приложением, которое несколько человек используют один раз в год (или если вы просто хотите опробовать новый фреймворк), – можете просто закинуть туда все, что хотите, потому что это никого не будет волновать.
Если вам нужны какие-то ссылки, наши готовые библиотеки для веб-разработки это Preact (полностью совместимый клон React в 3kb) и фреймворк Next.JS, который обеспечивает рендеринг на стороне сервера, офлайн-поддержку, предварительную выборку, отличную документацию и фантастическое сообщество.
Это попадание «в яблочко» для большинства проектов. К тому же поверх этой крошечной базы кода очень легко добавлять функции. Объединив этот подход со следующим советом, мы сможем загружать наши последние веб-приложения меньше чем за секунду, что является фантастическим с точки зрения UX.
3. Спроектируйте стратегию загрузки
Если вы работаете в этой сфере некоторое время, вы знаете, что со временем вам придется запихивать невероятно тяжелый компонент в ваш продукт, уничтожая все достижения в плане производительности, которые были в первом релизе. И что хуже, это будет демотивировать вашу команду, так как они почувствуют, что все их усилия сделать продукт быстрым были бессмысленны.
Но не отчаивайтесь! Когда такое случится, есть возможность сжульничать, и она называется «Проектированием загрузочной стратегии», что разделяет усилия между дизайнерами и разработчиками.
Главный принцип, стоящий за хорошей Загрузочной Стратегией, – никогда не позволять пользователям узнать, когда происходит загрузка приложения. А если этого нельзя избежать (например, при первоначальной загрузке), – сделать процесс настолько быстрым и приятным насколько возможно, загружая важные вещи в первую очередь, а все остальное – позже или никогда.
Лучший способ это испытать — выбрать самый тяжелый компонент в вашем приложении (вы знаете, тот, который требует тонну JS, хотя используется всего дважды на весь сайт) и разбить процесс загрузки на два субкомпонента:
- «Плейсхолдер»-версию компонента, которая требует самого минимального количества кода, однако прекрасно вписывается на странице и выглядит совсем как нечто настоящее. Например, если компонент это сложный видео плеер, который подгружает десятки дополнений, вам обычно нужно показать только миниатюру и кнопку «проигрывать». Это именно то, что вы покажете пользователю при первичной загрузке веб-приложения. Вы получите дополнительные «плюсики», если они будут выглядеть так, будто и правда работают.
- Настоящую версию компонента, которую вы загрузите сразу после того как будет должным образом загружено все самое важное на сайте. Лучший способ сделать это – отложить загрузку зависимостей этого компонента и все остальное до события загрузки окна, и когда вы наконец получите весь этот код, то сможете открыто заменить субкомпонент-«плейсхолдер» на настоящий, работающий.
Один из самых популярных примеров этой техники это эффект прогрессивной загрузки изображения, используемый Medium, Quartz и некоторыми другими, встраивающий картинку с очень низким разрешением с помощью HTML (в качестве плейсхолдера), а затем, после загрузки, переходящий к полному изображению:
Если вы выполнили оба шага правильно, этот новый тяжелый компонент не повлияет на ваше изначальное время загрузки (позволяя пользователям приступать к использованию продукта так же быстро как раньше). Все по-прежнему будет загружаться и правильно функционировать, а этот компонент загрузится на несколько десятых долей секунды позже всего остального веб-приложения. Если переход к рабочему компоненту правдоподобен, ваши пользователи вообще ничего не заметят, что является золотым стандартом для производительности.
Имейте в виду, что даже с продуманной загрузочной стратегией загрузка больших JS-библиотек все равно будет приводить к некоторым заметным заминкам на большинстве телефонов. Так что даже имея самую разумную загрузочную стратегию во всем мире стоит пытаться загружать как можно меньше кода.
4. Занимайтесь разработкой на среднем телефоне
Одна из лучших вещей, которые вы можете сделать как разработчик, – писать код на таком же устройстве, какое будет у большинства ваших пользователей.
Вы можете писать ваш код на топовой линейке Macbook Pro, но вам стоит приобрести дешевый б/у Nexus 5X или Moto G4 просто чтобы посмотреть как ваш код будет себя вести на девайсе средней руки. Если вы хотите действительно последовать этому совету, вы можете также ограничить соединение для этого телефона чтобы имитировать достаточно приличное 3G-соединение. Использование Chrome с удаленным дебаггингом сделает этот опыт почти таким же хорошим, как разработка на вашем компьютере.
Это откроет вам глаза на то, как на самом деле большинство людей используют ваше приложение в реальном мире, а также даст вам четкое понимание того насколько маленькие CPU и RAM доступны настоящим пользователям. В тот момент, когда вы начнете раздражаться из-за того что перезагрузка занимает слишком много времени на вашем телефоне, вы поймете, что поставляете гораздо больше кода, чем следует.
Различия между устройствами и платформами могут быть значительными. Для начала, согласно большинству тестов, айфоны обычно в два раза быстрее, чем лучшие Android-телефоны.
Просто, чтобы дать вам представление о том, насколько на самом деле медленны большинство телефонов, Эдди Османи написал отличную статью о JS Startup Performance. Один из наборов данных, которые он показывает, – это сколько времени требуется для анализа и выполнения 1 МВ Javascript на разных устройствах:
Согласно этим показателям, iPhone 7 примерно в 8 раз быстрее чем Nexus 5X (или в 14 раз быстрее чем более средний Moto G4). Так что, если вы разрабатываете веб-приложение, интенсивно использующее javascript, при помощи последнего iPhone или Macbook, у вас будет очень искаженное представление о производительности вашего кода на среднем телефоне.
Тестирование на разных устройствах нужно не только для исправления каких-то разночтений CSS. Это необходимость в силу того факта, что больше 60% веб-пользователей используют для этого мобильные устройства (а около 80% пользователей приходится на развивающиеся страны), и очень мало этих пользователей имеют супердорогие последние телефоны с неограниченным тарифным планом.
Если ваше приложение плохо работает на среднем телефоне с обычным соединением, оно будет плохо работать у подавляющего большинства ваших пользователей.
5. Используйте рендеринг на стороне сервера
Лучший способ убедиться, что весь JS, стоящий за вашим приложением, не затрагивает ваш продукт, это просто избавиться от него. Пуристы скажут вам писать только чистый HTML (что, кстати, является неплохой идеей). Однако работа с современными фреймворками, такими как React, принесет вам очень впечатляющую производительность, инструментарий и удобство командной работы, которых сложнее достичь с более старым стэком.
Простой способ сделать это — воспользоваться преимуществом рендеринга на стороне сервера, который будет рендерить ваш сайт на сервере (включая выполнение всех этих досадных сетевых запросов), так что вы сможете поставлять простой HTML как пользователям так и ботам. Большинство хороших микрофреймворков (Next.JS, Create React App, Preact CLI и несколько других) сделают это за вас, а в крайнем случае решение легко найти с помощью нескольких поисковых запросов Google.
Поскольку отображение HTML – основная функция браузера в последние несколько десятилетий, это поможет очень быстро отображать ваш важнейший контент, не заставляя ваших пользователей ожидать несколько лишних путешествий на сервер для доставки массивного груза Javascript и связки API-запросов. Более того, поскольку HTML очень легко кэшировать, вам не придется постоянно забивать фронтенд-серверы для рендеринга, и это может помочь выиграть несколько миллисекунд из вашего первоначального времени загрузки.
Вы также получите некоторые преимущества в SEO и распространении, поскольку простой HTML может быть проанализирован простым curl-запросом вместо необходимости запускать headless-браузер. Пока главные поисковики будут исполнять и индексировать отягощенные Javascript сайты, вы сможете воспользоваться дополнительными преимуществами. Вы получите лучшую совместимость с некоторыми другими сервисами (такими как Twitter, Linkedin, Pocket и многими другими), а еще эта часть продукта станет более предсказуемой и менее подверженной ошибкам.
6. Сначала подумайте про офлайн
У мобильных пользователей очень непредсказуемое сетевое соединение, разные скорости и уровни потерь пакетов. Мое любимое слово – Lie-Fi (Lie – «ложь»). Это когда ваш телефон говорит, что вы в сети, а на самом деле это не так или соединение ужасно медленное. В сочетании с тем фактом что большинство мобильных пользователей обычно спешат и очень нетерпеливы, это не добавит вашему продукту новых юзеров.
Самое лучшее в этом – наличие таких библиотек как Workbox, которые упрощают настройку Service Workers, так что вы можете легко добавить его в свой продукт и получить очень хорошую функцию, работающую без особых проблем.
Обеспечение хорошей работы вашего приложения в режиме офлайн является одной из ключевых особенностей построения продуктов в первую очередь для мобильных устройств. Делая ваш сайт более доступным при плохой связи (например, во время поездок в метро, если вы живете в большом городе) или просто пользуясь преимуществом кеша, благодаря чему все загружается почти мгновенно при повторных посещениях, это помогает вам сделать работу вашего сайта более сходной с работой приложений.
Заключительные слова
Я знаю, что фокусировка на производительности обычно не так привлекательна, как добавление связки новых функций, но делая ваш продукт быстрым вы получите совершенно потрясающие результаты когда дело дойдет до прибыли, просто потому что людям нравятся быстрые продукты, и статистика хороших PWA по большей части поддерживает этот вывод.
Если вы правда хотите построить впечатляющие продукты, каждый должен держать в уме производительность. Наличие целой команды, работающей над тем чтобы сделать приложение быстрым и легковесным, является одним из самых важных аспектов для построения продуктов, которые в самом деле понравятся людям.
На современном этапе развития World-wide-web, весьма важной является задача повышения скорости работы сайтов при фиксированной аппаратной составляющей хостинга. Это обусловлено как экономическими причинами, так и особенностями администрирования сетевых служб в конкретных организациях. В течение последних лет авторы статьи обслуживают хостинг сайтов на площадке Калужского филиала МГТУ им. Баумана. Опыт работы с сайтами, работающими на базе различных систем управления контентом (WordPress, Joomla и др.), а также с системами управления контентом собственной разработки позволил сформулировать набор универсальных рекомендаций для повышения скорости функционирования современных веб-сайтов.
В.Е. Драч, А.В. Родионов, И.В. Чухраев
Введение
Далее нужно провести стрессовый тест сайта, чтобы увидеть возможные причины появления узких мест. Ниже приведены несколько инструментов, которые могут помочь протестировать сайт. Они также могут быть полезными, если требуется масштабировать платформу.
Blitz : Тестирование производительности на веб-сайтах, веб-приложений и REST API.
Load Impact : Тестирование производительности на автомате и по запросу на DevOps. Сервис позволяет провести стресс-тест веб - сайта, веб - приложения, мобильного приложения или API для 1,2 млн одновременных пользователей.
WonderNetwork : Позволяет легко провести стресс-тест с точными результатами путем записи использования браузера, а затем его воспроизведения со своих серверов.
Loader : Сервис стрессового тестирования, который позволяет проводить проверку веб-приложения и API, с тысячами одновременных соединений.
BlazeMeter : Масштабируемый сервис для тестов производительности всех видов сайтов. Большинство функций доступны бесплатно. На рис. 2. показан пример выполнения стресс-теста для официального сайта Калужского филиала МГТУ им. Баумана.
На следующей странице можно настроить ползунки на основе использования CSS, JS, изображения, видео и шрифтов на сайте.
На последней странице даётся разбивка запаса производительности и предполагаемое время загрузки для различных типов соединений. Следует подчеркнуть, что речь идёт об оценках, но они могут быть полезны: эти оценки позволяют увидеть, насколько большой разрыв существует между скоростями подключения.
Оптимизация производительности веб-сайтов
После того, как сделаны несколько тестов сайта, выявивших задержки или перегрузки, следует начать оптимизацию,в соответствии с рекомендациями, сформулированными ниже.
Выбор ПО web-сервера
После тестирования сайта и определения задержек и/или перегрузок можно начинать его оптимизацию в соответствии со следующими рекомендациями.
Выбор программного обеспечения (ПО) веб-сервера. Последние результаты исследования применяемости различных веб-серверов с разбивкой по популярности веб-сайтов приведены на рис. 3 [9]. Как видно из рисунка, в настоящее время наибольшее применение находят веб-серверы Apache и nginx, на долю которых приходится обслуживание соответственно 50% и 33,3% всех веб-сайтов, просканированных в процессе исследования. При этом nginx обслуживает 54,1% всех веб-сайтов, входящих в тысячу самых популярных сайтов мира.
Веб-сервер nginx (на момент написания статьи – версия 1.11.X) является оптимальным решением для современных сайтов по стабильности, производительности и гибкости конфигурации 11. Он зародился в 2002 году благодаря усилиям Игоря Сысоева (выпускника МГТУ им. Баумана) по решению известной в то время проблемы C10K (одновременная обработка веб-сервером 10 тысяч запросов). Первая версия была выпущена в 2004 году и поставленная цель была достигнута благодаря асинхронной архитектуре event-driven. Веб-сервер nginx сразу начал набирать популярность благодаря своей нетребовательности к ресурсам и возможности легко масштабироваться на минимальном аппаратном обеспечении. Он уникален по скорости при отдаче статического контента и изначально нацелен на то, чтобы передавать динамические запросы другому ПО, специально предназначенному для их обработки. Администраторы часто выбирают nginx из-за его эффективного потребления ресурсов и отзывчивости под нагрузкой, а также из-за возможности использовать его одновременно и как веб-сервер, и как обратный прокси-сервер.
Распространенной альтернативой Nginx является популярный веб-сервер Apache[W],разработаный Робертом Маккулом в 1995 году, а с 1999 года разрабатывается под управлением Apache Software Foundation — организации развития программного обеспечения Apache. Веб-север Apache был самым популярным веб-сервером в интернете с 1996 года. Благодаря популярности, у Apache проработанная документация и продуманная интеграция со сторонними приложениями. Администраторы часто выбирают Apache из-за его гибкости, мощности и широкой распространенности. Он может быть расширен с помощью системы динамически-загружаемых модулей и исполнять программы на большом количестве интерпретируемых языков программирования без использования внешнего программного обеспечения.
На данный момент, используются несколько устоявшихся связок в веб-окружении:
• nginx + php-fpm (nginx обслуживает статический контент, а php-fpm интерпретирует РНР)
• nginx + Apache (nginx обслуживает статический контент, а Apache интерпретирует РНР)
• Apache + mod-php (Apache обслуживает статический контент, а mod-php интерпретирует РНР)
function disable_emojis_tinymce( $plugins ) if ( is_array( $plugins ) ) return array_diff( $plugins, array( 'wpemoji' ) );
> else return array();
>
>
В целом, можно рекомендовать не позволять сайту генерировать запросы, если они не используются.
Минимизация CSS и Javascript
На карте хорошо видно, что задержка возрастает по мере удаления геолокации от местоположения сервера, на котором размещён сайт.
Читайте также: