Front-End Performance Checklist 2021 (Part 2)

Front-End Performance Checklist 2021 (Part 2)


Продолжаем серию статей про Front-End Performance Checklist 2021

«Подготовка: Планирование и метрики»

  1. Создайте культуру производительности.
  2. Цель: быть по крайней мере на 20% быстрее, чем ваш самый быстрый конкурент.
  3. Выберите правильные метрики.
  4. Измеряйте и оптимизируйте основные показатели Web:

В течение долгого времени показатели производительности были довольно техническими, сосредоточенными на инженерном представлении того, насколько быстро реагируют серверы и насколько быстро загружаются браузеры. С течением времени метрики менялись, пытаясь найти способ отразить реальный пользовательский опыт, а не временные показатели сервера.

В мае 2020 года Google анонсировал Core Web Vitals - набор новых показателей производительности, ориентированных на пользователя, каждый из которых представляет собой отдельную грань пользовательского опыта.

Для каждого из них Google рекомендует диапазон приемлемых показателей скорости. По крайней мере, 75% всех просмотров страниц должны превышать "хороший" диапазон, чтобы пройти эту оценку. Эти показатели быстро набрали популярность, а после того, как в мае 2021 года Core Web Vitals стали сигналами ранжирования для Google Search (обновление алгоритма ранжирования Page Experience), многие компании обратили свое внимание на их показатели.

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

Измеряет загрузку страницы и сообщает время рендеринга самого большого изображения или текстового блока, который виден в области просмотра. Таким образом, на LCP влияет все, что откладывает отрисовку важной информации - будь то медленное время отклика сервера, блокировка CSS, неработающий JavaScript (сторонний или сторонний), загрузка веб-шрифта, дорогостоящие операции рендеринга или рисования, лениво загруженные изображения, скелетные экраны или рендеринг на стороне клиента.

Для хорошего восприятия LCP должен происходить в течение 2,5 с после начала загрузки страницы. Это означает, что нам нужно как можно раньше отрисовать первую видимую часть страницы. Это потребует адаптации критических CSS для каждого шаблона, организации <head>-порядка и предварительной выборки критических активов.

Основной причиной низкого показателя LCP обычно являются изображения. Чтобы получить LCP за <2,5 с на Fast 3G - размещенном на хорошо оптимизированном сервере, статичном без рендеринга на стороне клиента и с изображением, поступающим из специализированной сети CDN - это означает, что максимальный теоретический размер изображения составляет всего около 144 КБ. Вот почему важны отзывчивые изображения, а также предварительная загрузка критически важных изображений (с предварительной загрузкой).

Быстрый совет: чтобы узнать, что считается LCP на странице, в DevTools вы можете навести курсор на значок LCP под "Timings" в панели Performance Panel.

Измеряет отзывчивость пользовательского интерфейса, т.е. как долго браузер был занят другими задачами, прежде чем он смог отреагировать на дискретное событие пользовательского ввода, такое как нажатие или клик. Он предназначен для учета задержек, возникающих в результате занятости основного потока, особенно во время загрузки страницы.

Цель - не превышать 50-100 мс для каждого взаимодействия. Чтобы достичь этой цели, нам нужно выявлять длинные задачи (блокирующие основной поток на >50 мс) и разбивать их на части, разделять код пакета на несколько частей, сокращать время выполнения JavaScript, оптимизировать выборку данных, откладывать выполнение скриптов третьих сторон, перемещать JavaScript в фоновый поток с помощью Web workers и использовать прогрессивную гидратацию для сокращения затрат на регидратацию в SPA.

Небольшой совет: в целом, надежная стратегия для получения лучшего показателя FID заключается в минимизации работы основного потока путем разбиения больших пакетов на более мелкие и предоставления того, что нужно пользователю, тогда, когда это нужно, чтобы не задерживать взаимодействие пользователя. Подробнее об этом мы расскажем ниже.

Измеряет визуальную стабильность пользовательского интерфейса для обеспечения плавного и естественного взаимодействия, то есть суммирует все индивидуальные оценки сдвига макета для каждого неожиданного сдвига макета, который происходит в течение жизни страницы. Индивидуальный сдвиг макета происходит каждый раз, когда элемент, который уже был виден, меняет свое положение на странице. Он оценивается на основе размера содержимого и расстояния, на которое оно переместилось.

Стоит отметить, что Core Web Vitals должны развиваться со временем, с предсказуемым годовым циклом. В первом годовом обновлении мы можем ожидать повышения First Contentful Paint до уровня Core Web Vitals, снижения порога FID и улучшения поддержки одностраничных приложений. Мы также можем увидеть, что реакция на пользовательский ввод после загрузки приобретет больший вес, наряду с соображениями безопасности, конфиденциальности и доступности (!).

В связи с Core Web Vitals существует множество полезных ресурсов и статей, на которые стоит обратить внимание:

  • Web Vitals Leaderboard позволяет сравнивать ваши показатели с конкурентами на мобильных, планшетных и настольных компьютерах, а также в сетях 3G и 4G.
  • Core SERP Vitals, расширение для Chrome, которое показывает основные веб-показатели от CrUX в результатах поиска Google.
  • Layout Shift GIF Generator, который визуализирует CLS с помощью простого GIF (также доступен из командной строки).
  • Библиотека web-vitals позволяет собирать и отправлять основные веб-показатели в Google Analytics, Google Tag Manager или любую другую аналитическую конечную точку.
  • Analyzing Web Vitals with WebPageTest, в котором Патрик Минан (Patrick Meenan) исследует, как WebPageTest раскрывает данные о Core Web Vitals.
  • Оптимизация с помощью Core Web Vitals - 50-минутное видео с Адди Османи, в котором он рассказывает о том, как улучшить Core Web Vitals на примере электронной коммерции.
  • Cumulative Layout Shift in Practice и Cumulative Layout Shift in the Real World - исчерпывающие статьи Ника Янсмы, в которых рассказывается практически обо всем, что касается CLS, и как она коррелирует с ключевыми показателями, такими как Bounce Rate, Session Time или Rage Clicks.
  • What Forces Reflow - обзор свойств или методов, при запросе/вызове которых в JavaScript браузер будет синхронно рассчитывать стиль и макет.
  • CSS Triggers показывает, какие свойства CSS вызывают Layout, Paint и Composite.
  • Устранение нестабильности макета - это подробное описание использования WebPageTest для выявления и устранения проблем нестабильности макета.
  • Cumulative Layout Shift, The Layout Instability Metric - еще одно очень подробное руководство Бориса Шапиры по CLS, как она рассчитывается, как измерять и как оптимизировать ее.
  • How To Improve Core Web Vitals, подробное руководство Саймона Хирна по каждой из метрик (включая другие Web Vitals, такие как FCP, TTI, TBT), когда они возникают и как их измерять.

Однако, как объясняет Кэти Сайлор-Миллер, основными проблемами Core Web Vitals являются отсутствие кроссбраузерной поддержки, мы не можем измерить полный жизненный цикл пользовательского опыта, а также трудно соотнести изменения в FID и CLS с бизнес-результатами.

Поскольку мы должны ожидать развития Core Web Vitals, кажется вполне разумным всегда сочетать Web Vitals с вашими индивидуальными метриками, чтобы получить лучшее понимание того, где вы находитесь с точки зрения производительности.

5. Соберите данные на устройстве, представляющем вашу аудиторию:

Чтобы собрать точные данные, необходимо тщательно выбрать устройства, на которых будет проводиться тестирование. В большинстве компаний это означает обращение к аналитике и создание профилей пользователей на основе наиболее распространенных типов устройств. Однако зачастую одна лишь аналитика не дает полной картины. Значительная часть целевой аудитории может покинуть сайт (и не вернуться) только потому, что их работа слишком медленная, и их устройства вряд ли будут отображаться в аналитике как наиболее популярные по этой причине. Поэтому дополнительное исследование распространенных устройств в вашей целевой группе может быть хорошей идеей.

По данным IDC, в 2020 году в мире 84,8% всех поставляемых мобильных телефонов будут устройства на базе Android. Средний потребитель обновляет свой телефон каждые 2 года. Средние телефоны-бестселлеры по всему миру будут стоить менее 200 долларов.

Таким образом, репрезентативное устройство - это устройство Android, которому не менее 24 месяцев, стоимостью 200 долларов или меньше, работающее на медленном 3G, 400 мс RTT и 400 кбит/с передачи данных, просто чтобы быть немного более пессимистичным. Конечно, для вашей компании это может быть совсем не так, но это достаточно близкое приближение к большинству клиентов. На самом деле, было бы неплохо изучить текущих бестселлеров Amazon для вашего целевого рынка.

Какие тестовые устройства выбрать? Те, которые хорошо подходят под профиль, описанный выше. Хороший вариант - выбрать немного устаревший Moto G4/G5 Plus, устройство Samsung среднего уровня (Galaxy A50, S8), хорошее устройство среднего уровня, например Nexus 5X, Xiaomi Mi A3 или Xiaomi Redmi Note 7, и медленное устройство, например Alcatel 1X или Cubot X19, возможно, в открытой лаборатории устройств. Для тестирования на более медленных устройствах с тепловым дросселированием можно также приобрести Nexus 4, который стоит всего около 100 долларов.

Также проверьте чипсеты, используемые в каждом устройстве, и не переборщите с одним чипсетом: нескольких поколений Snapdragon и Apple, а также low-end Rockchip, Mediatek будет достаточно.

Имейте в виду, что на мобильных устройствах следует ожидать замедления на 4×-5× по сравнению с настольными машинами. Мобильные устройства имеют разные GPU, CPU, память и разные характеристики батареи. Вот почему важно иметь хороший профиль среднего устройства и всегда проводить тестирование на таком устройстве.

К счастью, существует множество отличных вариантов, которые помогут вам автоматизировать сбор данных и измерить, как ваш сайт работает с течением времени в соответствии с этими метриками. Помните, что хорошая картина производительности охватывает набор метрик производительности, лабораторных данных и полевых данных:

  • Инструменты синтетического тестирования собирают лабораторные данные в воспроизводимой среде с заранее заданными настройками устройства и сети (например, Lighthouse, Calibre, WebPageTest) и
  • Инструменты мониторинга реальных пользователей (RUM) оценивают взаимодействие пользователей в непрерывном режиме и собирают полевые данные (например, SpeedCurve, New Relic - эти инструменты также обеспечивают синтетическое тестирование).

Первые особенно полезны во время разработки, так как они помогут вам выявить, изолировать и устранить проблемы производительности во время работы над продуктом. Второй полезен для долгосрочного обслуживания, так как он поможет вам понять узкие места в производительности, когда они возникают в реальном времени - когда пользователи действительно заходят на сайт.

Используя встроенные API RUM, такие как  Navigation Timing, Resource Timing, Paint Timing, Long Tasks, инструменты синтетического тестирования и RUM вместе дают полную картину производительности вашего приложения. Вы можете использовать Calibre, Treo, SpeedCurve, mPulse и Boomerang, Sitespeed.io, которые все являются отличными вариантами для мониторинга производительности. Более того, с помощью заголовка Server Timing вы можете даже контролировать производительность back-end и front-end в одном месте.

Примечание: Всегда безопаснее выбирать дроссели сетевого уровня, внешние по отношению к браузеру, так как, например, DevTools имеет проблемы с взаимодействием с HTTP/2 push, из-за того, как он реализован (спасибо, Йоав, Патрик!). Для Mac OS мы можем использовать Network Link Conditioner, для Windows Windows Traffic Shaper, для Linux netem, а для FreeBSD dummynet.

Поскольку, скорее всего, вы будете тестировать в Lighthouse, имейте в виду, что вы можете:


6. Настройте "чистый" и "клиентский" профили для тестирования.

При проведении тестов в инструментах пассивного мониторинга обычно отключают антивирус и фоновые задачи ЦП, удаляют фоновую передачу полосы пропускания и проводят тестирование с чистым профилем пользователя без расширений браузера, чтобы избежать искажения результатов (в Firefox и в Chrome).

На этом графике показаны 20 самых медленных расширений из 100 наиболее используемых расширений Chrome. Все остальные 80 добавляют менее 100 мс дополнительного процессорного времени на страницу:

В отчете DebugBear выделены 20 самых медленных расширений, включая менеджеры паролей, блокировщики рекламы и такие популярные приложения, как Evernote и Grammarly.

Однако нелишним будет также изучить, какие расширения для браузеров часто используют ваши клиенты, и провести тестирование с помощью специальных профилей "клиентов". На самом деле, некоторые расширения могут оказывать значительное влияние на производительность (2020 Chrome Extension Performance Report) вашего приложения, и если ваши пользователи часто их используют, вы, возможно, захотите учесть это заранее. Таким образом, "чистые" результаты профиля сами по себе являются чрезмерно оптимистичными и могут быть разрушены в реальных сценариях.

7. Поделитесь целями производительности со своими коллегами.

Убедитесь, что цели эффективности знакомы каждому члену вашей команды, чтобы избежать недоразумений в дальнейшем. Каждое решение - будь то дизайн, маркетинг или что-то между ними - имеет последствия для производительности, и распределение ответственности и ответственности между всей командой позволит в дальнейшем упростить принятие решений, ориентированных на производительность. Сопоставьте проектные решения с бюджетом производительности и приоритетами, определенными на раннем этапе.

Источник: Vitaly Friedman “Front-End Performance 2021”

Report content on this page

Report Page

Please submit your DMCA takedown request to dmca@telegram.org