Чек-лист мероприятий по улучшению производительности сайта

Производительность должна постоянно измеряться, отслеживаться и оптимизироваться. Кроме этого развитие интернета создает новые проблемы, из-за которых становится сложно отслеживать показатели производительности.

Ниже приводится список мероприятий по оптимизации производительности 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 — это фантастический эмулятор, но проверяйте веб-сайт и на реальных устройствах.

Чек-лист мероприятий по улучшению производительности веб-сайта

k6 может писать тесты производительности наподобие модульных тестов.

Настроен ли у вас постоянный мониторинг?

Установить экземпляр WebPagetest полезно для выполнения быстрых и неограниченных тестов. Но инструмент непрерывного мониторинга с автоматическими предупреждениями обеспечит более подробное представление о работе веб-сайта или приложения.

Используйте RUM-решения для отслеживания изменений в производительности с течением времени. В виде автоматизированного инструмента для тестирования на основе модульных тестов можно использовать k6 с собственным API. Также обратите внимание на SpeedTracker , Lighthouse и Caliber .

Быстрые результаты

Десять рекомендаций, выполнив которые, вы получите наибольший эффект:

  1. Измерьте реальный опыт взаимодействия для различных точек, разбросанных по всему миру, и определите соответствующие цели.
  2. Подготовьте критический CSS для основных шаблонов и включите его в раздел <head> веб-страницы. (Ограничение по размеру составляет 14 КБ). Для CSS / JS, постарайтесь не выходить за ограничения по размеру файла — максимально 170Kb gzip (0,8-1 МБ, распакованного).
  3. Используйте отложенную загрузку для максимального числа скриптов. Особенно кнопок социальных сетей, видеоплееров и ресурсоемкого JavaScript.
  4. Добавьте подсказки ресурсов, чтобы ускорить доставку при помощи dns-lookup , preconnect , prefetch и preload .
  5. Подготовьте поднабор веб-шрифтов и загружайте его асинхронно (или просто переключитесь на системные шрифты).
  6. Оптимизируйте картинки и используйте WebP для критически важных страниц.
  7. Убедитесь, что заголовки кеша HTTP и заголовки безопасности установлены правильно.
  8. Включите на сервере сжатие Brotli или Zopfli.
  9. Если вы используете HTTP / 2, включите сжатие HPACK и начните мониторинг смешанного контента. Если используете TLS, также включите сшивание OCSP.
  10. Кэшируйте ресурсы, такие как шрифты, стили, JavaScript и картинки в кэше Service Worker.

Мы закончили!

Некоторые из перечисленных в руководстве мероприятий могут выходить за рамки работы или могут быть слишком сложными. Так что используйте этот чек-лист как общее руководство. На его основе создайте собственный список проблем. Но главное тестируйте ваши проекты для определения проблем оптимизации.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *