Производительность должна постоянно измеряться, отслеживаться и оптимизироваться. Кроме этого развитие интернета создает новые проблемы, из-за которых становится сложно отслеживать показатели производительности.
Ниже приводится список мероприятий по оптимизации производительности front-end . Обзор проблем, которые нужно решить, чтобы обеспечить быстрое время отклика, хороший опыт взаимодействия пользователя и оптимальное использование имеющихся ресурсов.
Подготовка: планирование и показатели
Четко определенные цели влияют на любые решения, принимаемые на протяжении всего процесса. Убедитесь, что вы установили собственные приоритеты.
Сформируйте культуру производительности.
Изучите жалобы, поступающие от клиентов. Посмотрите, как улучшение производительности сможет устранить некоторые из этих проблем.
Запускайте тесты и анализируйте результаты на мобильных и на десктопных устройствах. Это поможет создать пример с реальными данными.
Кроме этого использование данных из статистических отчетов WPO поможет узнать, как производительность влияет на пользовательский опыт и показатели бизнеса. При этом важно установить измеримые цели и отслеживать их.
Цель: будьте на 20% быстрее, чем ваш самый быстрый конкурент.
Чтобы пользователи поняли, что ваш сайт работает лучше, чем конкурирующий, он должен быть на 20% быстрее его. Изучайте своих основных конкурентов, собирайте показатели работы их сайтов на мобильных и десктопных устройствах.
Изучите свою аналитику, чтобы узнать, как себя ведут ваши пользователи. Соберите данные, сгруппируйте их в электронную таблицу, задайте прирост в 20%. Затем, исходя из этого, установите собственные цели.
Установите допустимые пороговые значения времени для критических действий пользователей. Убедитесь, что дополнительные затраты на добавление новых ресурсов и функций можно подсчитать.
Кроме этого стоит запланировать последовательность загрузки компонентов. В идеале этот порядок должен отражать последовательность импорта CSS и JavaScript. Тогда их обработка во время процесса сборки будет проще.
Выберите правильные показатели.
Установите, какие показатели важны для вашего приложения или сайта. Это даст понимание того, что нужно оптимизировать.
Вместо того чтобы сосредоточиться на полном времени загрузки страницы (например, с помощью onLoad и DOMContentLoaded timings), расставьте приоритеты этапов загрузки страниц. При этом учитывая то, как это воспримут ваши клиенты. Для этого необходимо сосредоточиться на нескольких разных наборах показателей.
Ниже приведены некоторые из показателей, которые стоит учитывать:
- Первое отображение (FMP, когда на странице отображается основной контент),
- Hero Rendering Times (когда полностью будет отображен важный контент),
- Время до первого взаимодействия (TTI, точка, в которой макет стабилизирован, ключевые веб-шрифты загружены, а основной поток доступен для обработки данных, вводимых пользователем)
- First Input Delay (сколько времени требуется, чтобы интерфейс начал реагировать на действия пользователя),
- Speed Index (измеряет, насколько быстро или медленно загружается визуальный контент).
- Индивидуальные показатели, определяемые потребностями вашего бизнеса и опытом работы с клиентами.
Собирайте данные об устройствах, используемых вашей аудиторией.
Необходимо тщательно выбрать устройства для тестирования. Если у вас нет подходящего устройства, эмулируйте его на стационарном компьютере в дросселированной сети. В конечном итоге переходите к обычным 3G, 4G и Wi-Fi.
Есть много отличных вариантов, которые позволяют автоматизировать сбор данных и оценить, как ваш сайт работает в разных условиях:
- Пассивные инструменты мониторинга — имитируют взаимодействие пользователя по запросу (искусственное тестирование, например Lighthouse, WebPageTest).
- Активные инструменты мониторинга — непрерывно фиксируют и оценивают взаимодействие пользователей. Например, SpeedCurve, New Relic. Оба этих инструмента также обеспечивают искусственное тестирование.
Первый тип инструментов полезен во время разработки. Второй тип применяется для долгосрочного обслуживания. Они помогают выявить проблемные места производительности. Тестирование происходит в реальных условиях, когда пользователи получают доступ к сайту.
Например, можно использовать PWMetrics, Calibre, SpeedCurve, mPulse, Boomerang, которые являются отличными инструментами для мониторинга производительности.
Примечание. Используйте эмуляторы на уровне сети. Так как у DevTools есть проблемы с взаимодействием с HTTP / 2.
Lighthouse, инструмент аудита производительности, интегрированный в DevTools.
Ознакомьте с контрольным списком своих коллег.
Убедитесь, что каждый участник вашей команды ознакомлен с контрольным списком. В нем должны быть указаны план решений по разработке, лимиты показателей производительности и приоритеты.
Определение реалистичных целей
Время отклика — 100 миллисекунд, 60 кадров в секунду.
Чтобы взаимодействие было оптимальным, интерфейс должен откликаться на действия пользователя за100 мс. Если это время больше, пользователь воспринимает приложение как тормозящее. RAIL, ориентированная на пользователя модель производительности, дает вам оптимальные цели.
Чтобы обеспечить время отклика меньше100 миллисекунд, страница должна возвращать управление в основной поток не позднее, чем через каждые 50 миллисекунд. Если учитывать Estimated Input Latency, то в идеале это время должно быть меньше 50 мс.
RAIL, ориентированная на пользователя модель производительности.
Кроме этого каждый кадр анимации должен быть завершен менее чем за 16 миллисекунд, тем самым обеспечивая частоту 60 кадров в секунду. Поскольку браузеру требуется некоторое время на отрисовку нового кадра на экране, код должен заканчивать выполнение, еще до истечения 16 миллисекунды.
SpeedIndex <1250, TTI <5 с на 3G, критическое ограничение на размер файла <170 Кб.
Правильной целью является FMP менее 1 секунды и значение SpeedIndex ниже 1250. Базовый уровень круговой задержки Android-смартфона в сети 3G составляет RTT — 400 мс, а скорость передачи — 400 кбит/с. Поэтому стоит ориентироваться на показатель TTI до 5 секунд для первого посещения и менее 2 секунд для повторных.
Первые 14 ~ 15Kb HTML — это единственная часть контента, которая может быть доставлена на первом этапе. Это все, что получает пользователь за 1 секунду при RTM 400 мс.
Чтобы достичь поставленных выше целей, необходимо соблюдать ограничения по размеру архивированных файлов в 170Kb gzip (0,8-1 МБ в распакованном состоянии). Это уже потребует до 1 секунды времени на синтаксический анализ и компиляцию на смартфоне среднего уровня. Поэтому старайтесь свести эти показатели к возможному минимуму.
Но при определенных условиях вы можете выйти за пределы этих ограничений. Например, для оценки производительности можно ориентироваться на основной поток браузера. То есть, время до начала визуализации. Такие инструменты, как Caliber, SpeedCurve и Bundlesizeпозволят контролировать соответствие лимитам и могут быть интегрированы в процесс разработки.
Определение среды
Выберите и настройте инструменты сборки.
Используйте удобную для вас среду разработки, будь то Grunt, Gulp, Webpack, Parcel или сочетание различных инструментов. До тех пор, пока не возникает проблем с процессом сборки, все в порядке.
Прогрессивное улучшение.
Сначала создайте основное ядро пользовательского опыта, а затем приступайте к расширению функций для новейших браузеров. Если ваш сайт работает быстро на медленном компьютере с плохим монитором в плохом браузере на низкой скорости соединения, то он будет работать еще быстрее на современном компьютере с хорошим браузером и качественным интернет-соединением.
Выберите базовую линию производительности.
Существует огромное количество неизвестных, влияющих на загрузку сайта. Проблемные места есть как на сервере, так и в клиенте. Рассмотрим эти факторы более подробно.
Рекомендуемый лимит в 170 КБ уже включает в себя расходы на передачу HTML / CSS / JavaScript, маршрутизаторов, управление состояниями, утилиты, фреймворк и загрузку логики приложения. Исходя из этого, следует подробно изучить используемый фреймворк.
Чтобы измерить затраты времени на запуск для фреймворков, сначала визуализируйте представление, затем удалите и снова отобразите. Это позволит оценить, как масштабируется сам фреймворк.
При первой визуализации много времени уходит на обработку отложено скомпилированного кода. Вторая визуализация — это эмуляция того, как повторное использование кода на странице влияет на характеристики производительности.
При выборе фреймворка обратите внимание время на загрузку общего размера + начальное время парсинга. Компактные инструменты, такие как Preact, Inferno, Vue, Svelte или Polymer, прекрасно справляются с большинством задач.
Имейте в виду, что на мобильном устройстве быстродействие сайта замедляется в 4-5 раз по сравнению со стационарными компьютерами. Время парсинга на мобильных устройствах на 36% дольше, чем на ПК. Поэтому всегда проводите замеры на устройстве, которое чаще всего использует ваша аудитория.
Различные фреймворки по-разному влияют на производительность и требуют применения различных стратегий оптимизации. При создании веб-приложения ознакомьтесь с PRPL-шаблонами и архитектурой оболочки приложения.
PRPL означает «отправить критический ресурс, визуализировать исходный маршрут, предварительно кэшировать остальные маршруты, и отложено загрузить маршруты по требованию.
Оболочка приложения — это код HTML, CSS и JavaScript, управляющий пользовательским интерфейсом.
Будете ли вы использовать AMP или Instant Articles?
Для улучшения производительности можно использовать AMP от Google, Instant Articles от Facebook или Apple News от Apple.
Основным преимуществом этих технологий для пользователей является гарантированная производительность. Для сайтов с большими объемами контента, которые используют множество сторонних ресурсов, эти технологии могут ускорить процесс рендеринга.
Выгода для владельца сайта очевидна: открытость этих форматов на соответствующих платформах и повышенная видимость в поисковых системах.
Выбирайте правильную CDN.
CDN могут обслуживать (и разгружать) динамический контент. Поэтому не обязательно обслуживать через CDN только статические ресурсы. Проверьте, выполняет ли CDN сжатие и преобразование (например, оптимизацию изображений, сжатие и изменение их размеров до минимума), интеллектуальную доставку HTTP / 2, сборку статических и динамических частей страниц CDN на ближайшем к пользователю сервере и другие важные задачи.
Оптимизация сборки
Определите свои приоритеты.
Проведите инвентаризацию всех ресурсов (JavaScript, изображений, шрифтов, сторонних скриптов) и разбейте их по группам.
Создайте таблицу. Определите базовый функционал для устаревших браузеров (доступный основной контент), расширенный для совместимых браузеров (полный опыт взаимодействия) и дополнительные сервисы (веб-шрифты, скрипты каруселей, видеоплееры, кнопки социальных сетей, большие изображения).
Используйте минимальные объемы JavaScript.
Ищите модули и методы для ускорения начального рендеринга. Большинство проблем с производительностью связано с начальным этапом синтаксического анализа.
Время парсинга и выполнения зависит от аппаратного обеспечения пользовательского устройства. На смартфоне среднего уровня (Moto G4) время парсинга 1 МБ (несжатого) JavaScript будет составлять 1,3-1,4 секунды. Из них всего 15-20% времени тратится непосредственно на парсинг.
При компиляции игры только подготовительная работа с JavaScript занимает в среднем 4 секунды. Поэтому время парсинга и исполнения может быть в 2-5 раз больше на мобильных устройствах низшего класса.
Вот почему важно анализировать каждую зависимость JavaScript. Такие инструменты, как webpack-bundle-analyzer, Source Map Explorer и Bundle Buddy, могут помочь вам измерить время парсинга и компиляции JavaScript.
Вы используете ahead-of-time компилятор?
Используйте ahead-of-time компилятор, чтобы переложить часть рендеринга со стороны клиента на сервер. Рассмотрите возможность использования Optimize.js для более быстрой начальной загрузки путем обертывания срочно вызываемых функций.
Используете ли вы tree-shaking и разделение кода?
Tree-shaking — это способ очистки сборки. В результате остается в только код, который фактически используется в работе.
Webpack 3 и Rollup предоставляют метод, который определяет, где цепочка import может быть сжата и преобразована в одну встроенную функцию без ущерба для кода.
С Webpack 4 также можно использовать JSON Tree Shaking, UnCSS или Helium, которые могут помочь удалить из CSS неиспользуемые стили.
Вы также можете использовать Webpack, чтобы сокращать имена классов и использовать изоляцию диапазонов для динамического переименования классов CSS во время компиляции.
Не все скрипты JavaScript нужно загружать, парсировать и компилировать сразу. После того, как вы определите точки разделения в коде, Webpack может позаботиться о зависимостях и выводимых файлах. Это позволит сохранить малый размер начальной загрузки и запрашивать код по требованию приложения.
Также используйте preload-webpack-plugin. Он принимает маршруты, на которые разбит код, используя <link rel="preload"> или <link rel = "prefetch">.
Обратите внимание, что Rollup демонстрирует значительно лучшие результаты, чем экспорт Browserify. Вы можете попробовать Rollupify, который преобразует модули ECMAScript 2015 в один большой модуль CommonJS.
Воспользуйтесь оптимизацией для целевого движка JavaScript.
Узнайте, какие движки JavaScript доминируют среди ваших пользователей, а затем изучите способы их оптимизации. Например, при оптимизации для V8, который используется в Blink-браузерах, в среде выполнения Node.js и в Electron, применяется потоковая передача скриптов для монолитных скриптов. Это позволяет парсировать асинхронные или отложенные скрипты в отдельном фоновом потоке после начала загрузки. В некоторых случаях уменьшение времени загрузки страницы составляет до 10%. Используйте <script defer> в <head>, чтобы браузеры могли сначала обнаружить ресурс, а затем парсировать его в фоновом потоке.
Предостережение: Opera Mini не поддерживает отсрочку выполнения скриптов, поэтому, если вы разрабатываете для Индии или Африки, отсрочка будет проигнорирована, что приведет к блокировке рендеринга до тех пор, пока скрипт не будет оценен.
Прогрессивная загрузка означает использование рендеринга на стороне сервера, чтобы получить быстрое первое значимое отображение. Она также включает в себя минимальный JavaScript, чтобы приблизить время до первого взаимодействия к времени до первого отображения.
Рендеринг на стороне клиента или на стороне сервера?
В обоих сценариях цель должна состоять в том, чтобы настроить прогрессивную загрузку. Если JavaScript загружается слишком поздно после первого значимого отображения, браузер может блокировать основной поток при парсинге, компиляции и выполнении давно обнаруженного JavaScript. Из-за этого нарушается интерактивность сайта или приложения.
Поэтому назначайте выполнение функций на отдельные, асинхронные задачи и по возможности используйте requestIdleCallback. Применяйте отложено загружаемые части пользовательского интерфейса с помощью динамической поддержки оператора import() из WebPack. Это позволит не загружать и не компилировать код, пока он не понадобится пользователям.
Ограничьте влияние сторонних скриптов
Зачастую мы не можем контролировать сторонние скрипты. На их показатели не влияет опыт конечных пользователей. Поэтому часто такой скрипт вызывает длинный хвост других сторонних скриптов. Что сводит на нет все усилия, направленные на повышение производительности.
Во многих случаях эти скрипты загружают динамические ресурсы. Ресурсы меняются при загрузке различных страниц. Поэтому мы не всегда знаем, с каких хостов будут загружены ресурсы и какие.
Чтобы решить эту проблему, можно регистрировать или блокировать сторонние запросы, которые не были успешными или не соответствуют определенным критериям.
Еще один вариант — установить политику защиты контента (CSP), чтобы ограничить влияние сторонних скриптов. Например, запрещая загрузку аудио или видео.
Лучший вариант — встраивать скрипты с помощью <iframe>, чтобы они не имели доступа к DOM страницы и не могли запускать произвольный код в домене.
Iframe можно дополнительно ограничить с помощью атрибута sandbox. А также отключить любой функционал, который может выполнять iframe, Например, запуск скриптов, оповещения, отправку формы, запуск плагинов, доступ к панели навигации и т. д.
Например, можно сделать так чтобы скрипты запускались с помощью <iframe sandbox = "allow-scripts">. Каждое ограничение можно снять с помощью различных значений allowв атрибуте sandbox (поддерживается почти во всех браузерах).
Рассмотрите возможность использования Safeframe и Intersection Observer; это позволит вложить рекламные объявления в iframe. Параллельно будет осуществляться отправка событий или получение информации из DOM, которая им необходима.
Чтобы провести стресс-тестирование сторонних ресурсов, просмотрите общий отчет всех показателей на странице профиля производительности в DevTools. Проверьте, что произойдет при блокировке или задержке выполнения запроса.
Правильно ли настроены заголовки кеша HTTP?
Проверьте, правильно ли настроены expires, cache-control, max-age и другие заголовки кеша HTTP. Отключите заголовок Last-Modified, так как любой ресурс с этим заголовком создаст условный запрос с заголовком If-Modified-Since, даже если ресурс находится в кеше. То же самое касается Etag.
Используйте Cache-control: immutable, предназначенный для статичных ресурсов, введенных вручную. Он позволит избежать повторной валидации.
Оптимизация ресурсов
Используете ли вы сжатие простого текста с помощью Brotli или Zopfli?
В 2015 году Google представил Brotli. Это новый формат данных без потерь, который поддерживается во всех современных браузерах.
На практике Brotli более эффективен, чем Gzip и Deflate. В зависимости от настроек он может очень медленно сжиматься. Но в конечном итоге это дает более высокий коэффициент сжатия. В то же время, распаковывается он быстро.
Браузеры принимают его только в том случае, если пользователь посещает сайт через HTTPS. В чем подвох? На сегодняшний день Brotli все еще не установлен на некоторых серверах, и его не просто настроить без самокомпилирующихся NGINX или Ubuntu.
При самом высоком уровне сжатия Brotli очень медленный. Тем не менее, при статическом сжатии рекомендуется использовать более высокие настройки сжатия.
Также можно использовать алгоритм сжатия Zopfli, который сохраняет данные в форматы Deflate, Gzip и Zlib. Любой ресурс, сжатый с помощью Gzip, получает за счет использования кодировки Deflate. Она позволяет получить файлы, которые на 3-8% меньше, чем те, которые получаются с помощью Zlib. Подвох заключается в том, что файлы будут сжиматься примерно в 80 раз дольше. Поэтому лучше использовать Zopfli для ресурсов, которые изменяются не часто. А также файлов, которые сжимаются и затем загружаются много раз.
Оптимизируйте статические ресурсы с помощью Brotli + Gzip при самом высоком уровне сжатия. Динамически сжимайте HTML на лету с помощью Brotli на уровне 1-4.
Правильно ли оптимизированы изображения?
По возможности используйте адаптивные изображения с элементами srcset, sizes
и <picture>. А также формат WebP, отображая WebP-изображения с помощью элемента <picture> и с резервным вариантом в формате JPEG.
Графический редактор Sketch изначально поддерживает WebP. Изображения в формате WebP также можно экспортировать из Photoshop с помощью плагина WebP для Photoshop.
Для WordPress или Joomla, существуют расширения, которые помогут вам добавить поддержку WebP. Например, Optimus и Cache Enabler для WordPress.
Для автоматизации оптимизации изображений используйте Responsive Image Breakpoints Generator или такой сервис, как CloudMan. Также можно использоватьsrcset и sizes.
Responsive Image Breakpoints Generatorавтоматизирует генерацию изображений и разметки.
Выведите оптимизацию изображения на новый уровень.
Чтобы изображение загружалось быстро, обеспечьте, сжимайте JPEG-файлы с помощью Adept, mozJPEG. А также с помощью Guetzli – нового инструмента от Google, использующего алгоритмы Zopfli и WebP.
Для оптимизации формата PNG используйте Pingo, а для SVG — SVGO или SVGOMG. Также можно размыть ненужные части изображения (применяя к ним фильтр «Размытие по Гауссу»), чтобы уменьшить размер файла.
Вместо тяжелой GIF-анимации лучше использовать циклические HTML5-видео. А также сжатие GIF с помощью Lossy GIF, gifsicle или giflossy.
Оптимизируете ли вы веб-шрифты?
Есть вероятность, что веб-шрифты, которые вы используете, включают в себя глифы и дополнительные функции. А это значит лишние байты, которые не используются. Вы можете попросить автора веб-шрифта создать поднабор или создать его самостоятельно.
Если вы не можете использовать шрифты с вашего сервера и полагаетесь на сторонние хосты, обязательно используйте Font Load Events (или Web Font Loader для браузеров, которые его не поддерживают).
Сразу начните отображение текста с резервного варианта и параллельно асинхронно загружайте шрифты. Для этого можно использовать loadCSS. Вы также можете обойтись установленными в операционной системе шрифтами. А также использовать вариативные шрифты.
Оптимизация доставки
Вы ограничиваете влияние библиотек JavaScript и загружаете их асинхронно?
Когда пользователь запрашивает страницу, браузер извлекает HTML и создает DOM. Затем извлекает CSS и строит CSSOM. После чего генерирует дерево рендеринга, сопоставляя DOM и CSSOM.
Если необходимо обработать код JavaScript, браузер не начнет рендеринг страницы до тех пор, пока это не будет сделано. Поэтому нужно явно указать браузеру начинать рендеринг страницы без задержки. Это делается в HTML с помощью атрибутов defer и async.
Предпочтительнее использовать-defer, а неasync (особенно в Internet Explorer до версии 9). Также ограничьте влияние сторонних библиотек и скриптов.
Size Limit помогает предотвратить «раздувание» библиотек JavaScript. Если вы случайно добавите большую зависимость, инструмент сообщит об этом и выдаст ошибку.
Отложенная загрузка объемных скриптов с помощью Intersection Observer
Для отложенной загрузки изображений, видео, скриптов рекламы, скриптов A / B тестирования можно использовать новый API-интерфейс Intersection Observer. Для этого нужно создать новый объект IntersectionObserver, который принимает функцию обратного вызова и набор параметров. Затем добавить цель для наблюдения.
Также можно добавить прогрессивную загрузку изображений на свои страницы. При этом сначала загружаются изображения низкого качества, а затем заменить их на полные версии. Этот подход уменьшает время до первого значимого отображения.
Мы также можем автоматизировать его, используя SQIP. Инструмент создает низкокачественную версию изображения для SVG- заполнителя. Подобные заполнители могут быть встроены в HTML, поскольку они хорошо сжимаются.
В целом, рекомендуется отложено загружать все емкие компоненты, такие как шрифты, JavaScript, карусели, видео и фреймы. Кроме того можно адаптировать контент, исходя из оптимальных параметров сети. Network Information API и, в частности,navigator.connection.effectiveType (Chrome 62+) используют значения RTT и скорости скачивания, чтобы предоставить более точное представление о соединении и данных, которые могут обрабатывать пользователи. Вы можете использовать его для автоматического удаления видео, фоновых изображений или веб-шрифтов для слишком медленных соединений.
Вы быстро вводите критический CSS?
Чтобы ускорить рендеринг в браузере, все стили CSS, необходимые для начала отображения первой видимой части страницы (критический CSS), встраиваются в раздел<head>.
Из-за фиксированного размера пакетов, передаваемых в фазе медленного запуска, ограничение для объема критического CSS составляет около 14 КБ.
Если выйти за эти пределы, браузеру потребуются дополнительные обращения, чтобы получить больше стилей. CriticalCSS и Critical позволяют сделать именно это.
С помощью HTTP / 2 критический CSS может храниться в отдельном файле и доставляться через server push, не раздувая HTML. Сложность заключается в том, что данная технология не поддерживается в достаточной степени и имеет некоторые проблемы с кешированием.
Но даже при использовании HTTP / 1, выделение критического CSS в отдельный файл, расположенный в корневом каталоге домена дает определенные преимущества.
Браузер Google Chrome при запросе страницы виртуально открывает второе HTTP-соединение с корневым доменом, что устраняет необходимость TCP- подключения для получения этого CSS.
На данный момент не существует простого способа уведомить сервер о том, что передаваемые ресурсы находятся в одном из кэшей пользователя. Поэтому ресурсы будут постоянно передаваться при каждом пользовательском посещении. Из-за этого требуется механизм cache -aware HTTP/2 server push.
Вы стримите ответы?
Часто забытые и игнорируемые потоки предоставляют интерфейс для чтения или записи асинхронных фрагментов данных. Это позволяет странице, которая выполнила исходный запрос, начать работу с ответом при получении первого фрагмента данных. А также использовать парсеры, оптимизированные для потоковой передачи, чтобы прогрессивно отображать контент.
Можно создать один поток из нескольких источников. Например, вместо того, чтобы обслуживать пустую оболочку пользовательского интерфейса, и заполнять ее с помощью JavaScript, можно позволить Service Worker построить поток. Через него оболочка поступает из кеша, но тело добавляется из сети.
Преимуществом такого подхода является то, что HTML, отображаемый во время первоначального запроса, может в полной мере обрабатываться потоковым HTML-парсером браузера. Куски HTML, вставленные в документ после загрузки страницы (как это обычно бывает с содержимым, заполняемым с помощью JavaScript), не могут быть оптимизированы с помощью данной функции.
Сохраняете ли вы данные с помощью Save-Data?
Заголовок запроса подсказки клиента Save-Data позволяет настраивать приложение и полезную нагрузку для пользователей, у которых имеются ограничения по объему и производительности. Например, переписывать запросы на изображения с высоким разрешением на изображения с низким разрешением, удалять веб-шрифты и сложные эффекты параллакса, отключать автоматическое воспроизведение видео, server push или даже изменять способ доставки разметки.
Этот HTTP-заголовок в настоящее время поддерживается только в Chromium, в Android-версии браузера Google Chrome через расширение Data Saver, установленное на стационарном устройстве.
Вы разогреваете соединение, чтобы ускорить доставку?
Используйте подсказки ресурсов, чтобы сэкономить время на dns-prefetch (который выполняет поиск DNS в фоновом режиме), preconnect (просит браузер начать квитирование соединения в фоновом режиме), prefetch (просит браузер запросить ресурс) и preload(предварительно извлекает ресурсы, но не выполняет их).
Чаще всего мы используем минимум preconnect и dns-prefetch. Но должны быть осторожны с использованием prefetch и preload. Первый должен применяться только в том случае, если знаете, какие ресурсы потребуются пользователю в будущем (например, в воронке продаж). Обратите внимание на то, чтоprerender устарел и больше не поддерживается.
Также имейте в виду, что даже при использовании preconnect и dns-prefetch браузер ограничен числом хостов, на которых он будет искать / подключать параллельно. Поэтому наиболее оптимальная стратегия — задать для них порядок, исходя из приоритетов.
Когда решите, какие ресурсы важны для рендеринга, вы можете присвоить им высокий приоритет. Чтобы узнать, как расставляются приоритеты для ваших запросов, активируйте включить столбец «Приоритет» в таблице сетевых запросов Chrome DevTools.
Столбец «Приоритет» в DevTools.
Например, шрифты являются важными ресурсами страницы. Поэтому рекомендуется указывать браузеру загружать шрифты с помощью preload.
Поскольку <link rel = "preload"> принимает атрибут media, вы можете использовать выборочное распределение приоритетов для ресурсов на основе правил @media-запроса.
Но предварительно загруженные ресурсы помещаются в кеш памяти, который привязан к странице, выполняющей запрос. Это означает, что предварительно загружаемые запросы не могут быть разделены между страницами.
Также preload хорошо работает с HTTP-кешем: сетевой запрос никогда не отправляется, если элемент уже присутствует в HTTP- кеше.
Предварительная загрузка через HTTP-заголовок немного быстрее, так как мы не ждем, когда браузер парсирует HTML-код для начала запроса.
Early Hints позволяет начать предварительную загрузку еще до того, как будут отправлены заголовки ответов для HTML.
Вы оптимизируете производительность рендеринга?
Свойство CSS Containment позволяет ограничить область действия стилей браузера, макет и работу с отображением скрытых элементов навигации или сторонних виджетов. Удостоверьтесь, что при прокрутке страницы или при воспроизведении анимации элемента ничего не тормозит и содержимое стабильно отображается с частотой 60 кадров в секунду.
Если это невозможно, то обеспечьте частоту не ниже 15 кадров в секунду. Используйте CSS-свойство will-change, чтобы сообщить браузеру, какие элементы и свойства будут изменяться.
Вы оптимизировали опыт визуализации?
При загрузке ресурсов нужно всегда быть на шаг впереди клиента, чтобы опыт взаимодействия воспринимался пользователями как очень быстрый. В это же время на заднем плане будет происходить довольно много вещей. Чтобы поддерживать клиента, можно использовать вместо индикаторов загрузки скелетные экраны, добавлять переходы / анимацию.
HTTP / 2
Перейдите на HTTPS, затем подключите HTTP / 2.
Перевод сайта на HTTPS позволит добиться значительного повышения производительности от использования Service Worker и server push.
Google помечает все HTTP-страниц как небезопасные.
Трудность перехода на HTTPS зависит от того, насколько велика ваша пользовательская база HTTP / 1.1. То есть, количество пользователей с устаревшими операционными системами или устаревшими браузерами.
Правильное развертывание HTTP / 2.
Обслуживание ресурсов по протоколу HTTP / 2 требует частичного изменения. Можно вообще не объединять ресурсы. Вместо этого разбить весь интерфейс на множество небольших модулей, сжимая их при сборке и загружая их параллельно.
Изменение одного файла не потребует повторной загрузки всей таблицы стилей или JavaScript. Это также минимизирует время синтаксического анализа и снижает нагрузку на отдельные страницы.
С другой стороны, упаковка все еще важна. Во-первых, пострадает сжатие. Сжатие большого пакета дает выигрыш при повторном использовании большого словаря. Для небольших отдельных пакетов это не имеет серьезного влияния.
Существует стандартная процедура для решения этого вопроса, но пока она далека от совершенства. Во-вторых, браузеры еще не оптимизированы для таких рабочих процессов. Например, браузер Google Chrome запускает межпроцессные коммуникации (IPC) в линейной пропорции к количеству ресурсов. Поэтому использование сотен ресурсов приведет к увеличению времени на выполнение.
Можно попытаться загрузить CSS прогрессивно. Но при этом придется пренебречь пользователями HTTP / 1.1. Поэтому придется генерировать и обслуживать сборки для разных браузеров в рамках процесса развертывания, а это значит, что ситуация становится немного сложнее.
Что делать? Если вы используете HTTP / 2, отправка по 6-10 пакетов выглядит как достойный компромисс. Поэкспериментируйте и проведите замеры, чтобы найти правильный баланс для своего сайта.
Поддерживают ли ваши серверы и CDN HTTP / 2?
Различные серверы и CDN будут поддерживать HTTP / 2 по-разному. Используйте Is TLS Fast Yet?, что проверить параметры или быстро просмотреть, как работают ваши серверы.
Is TLS Fast Yet? позволяет проверять параметры для серверов и CDN при переключении на HTTP / 2.
Включено ли у вас OCSP Stapling (сшивание OCSP)?
Включив на сервере OCSP Stapling, вы можете ускорить рукопожатия TLS. Данная технология была создана в качестве альтернативы протоколу Certificate Revocation List (CRL).
Оба протокола используются для проверки того, был ли вызван сертификат SSL. Тем не менее, OCSP не требует, чтобы браузер тратил время на загрузку и просмотр информации о сертификате. Это сокращает время, необходимое для установления связи.
Вы уже применяете IPv6?
Рекомендуется обновить DNS до IPv6, чтобы гарантировать стабильную работу в будущем. Убедитесь, что по всей сети предоставляется поддержка по двум стекам. Это позволяет IPv6 и IPv4 работать одновременно.
Исследования показывают, что IPv6 сделал сайты на 10-15% быстрее благодаря обнаружению соседей (NDP) и оптимизации маршрутов.
Используете ли вы компрессию HPACK?
Если вы используете HTTP / 2, проверьте, чтобы ваши серверы применяли сжатие HPACK для заголовков ответов HTTP. Это позволит уменьшить потребление ресурсов.
Поскольку серверы HTTP / 2 относительно новы. Поэтому они могут не полностью поддерживать спецификацию. Примером чего является HPACK. H2spec — отличный инструмент, который позволяет проверить это.
Проверьте безопасность своего сервера.
Все браузерные реализации HTTP / 2 выполняются через TLS. Проверьте правильность установки заголовков безопасности, устраните известные уязвимости и проверьте свой сертификат.
Убедитесь, что все внешние плагины и скрипты отслеживания загружаются через HTTPS. А также что межсайтовый скриптинг невозможен и что HTTP-заголовки Strict Transport Security и Content Security Policy установлены правильно.
Используются ли Service Worker для кэширования и резервных вариантов?
Оптимизация производительности в сети не может дать больший результат, чем локально сохраненный на компьютере пользователя кэш.
Как уже говорилось ранее, они поддерживается отлично (Chrome, Firefox, Safari TP, Samsung Internet, Edge 17+).
Тестирование и мониторинг
Проводите ли вы тестирование устаревших браузеров?
Тестирования в Google Chrome и Firefox недостаточно. Посмотрите, как работает ваш сайт в устаревших браузерах с помощью дросселирования сети и эмуляции устройства с высоким разрешением. BrowserStack — это фантастический эмулятор, но проверяйте сайт и на реальных устройствах.
Настроен ли у вас постоянный мониторинг?
Установить экземпляр WebPagetest всегда полезно для выполнения быстрых и неограниченных тестов. Но инструмент непрерывного мониторинга с автоматическими предупреждениями обеспечит более подробное представление о работе сайта или приложения.
Используйте RUM-решения для отслеживания изменений в производительности с течением времени. В качестве автоматизированного инструмента для тестирования на основе модульных тестов можно использовать k6 с собственным API. Также обратите внимание на SpeedTracker, Lighthouse и Caliber.
Быстрые результаты
Десять рекомендаций, выполнив которые, вы получите наибольший эффект:
- Измерьте реальный опыт взаимодействия для разных точек, разбросанных по всему миру, и определите соответствующие цели.
- Подготовьте критический CSS для основных шаблонов и включите его в раздел <head> веб-страницы. (Ограничение по размеру составляет 14 КБ). Для CSS / JS, постарайтесь не выходить за ограничения по размеру файла — максимально 170Kb gzip (0,8-1 МБ, распакованного).
- Используйте отложенную загрузку для максимального количества скриптов. Особенно кнопок социальных сетей, видеоплееров и ресурсоемкого JavaScript.
- Добавьте подсказки ресурсов, чтобы ускорить доставку с помощью
dns-lookup,preconnect,prefetchиpreload. - Подготовьте поднабор веб-шрифтов и загружайте его асинхронно (или просто переключитесь на системные шрифты).
- Оптимизируйте изображения и используйте WebP для критически важных страниц.
- Убедитесь, что заголовки кеша HTTP и заголовки безопасности установлены правильно.
- Включите на сервере сжатие Brotli или Zopfli.
- Если вы используете HTTP / 2, включите сжатие HPACK и начните мониторинг смешанного контента. Если используете TLS, также включите сшивание OCSP.
- Кэшируйте ресурсы, такие как шрифты, стили, JavaScript и изображения в кэше Service Worker.
Мы закончили!
Некоторые из перечисленных в руководстве мероприятий могут выходить за рамки вашей работы или могут быть слишком сложными. Поэтому используйте этот чек-лист как общее руководство. На его основе создайте свой собственный список проблем. Но главное тестируйте свои проекты для определения проблем оптимизации.
http://vanar.md/ro/oferte-si-reduceri