Front-End Performance Checklist 2021 (Part 1)
Diana KucherenkoПроизводительность веб-сайтов - сложный процесс; это не только техническая проблема: она влияет на все - от доступности до удобства использования и оптимизации поисковых систем, поэтому ее необходимо постоянно измерять, отслеживать и совершенствовать.
Для того, чтобы это сделать, мы рекомендуем воспользоваться максимально полным контрольным списком производительности внешнего интерфейса на 2021 год, который подготовил дизайнер и разработчик Виталий Фридман vitalyf в своём онлайн-журнале Smashing Magazine. Кстати, этот список создан в 2016 году и обновляется ежегодно:
1) Getting Ready: Planning And Metrics
Performance culture, Core Web Vitals, performance profiles, CrUX, Lighthouse, FID, TTI, CLS, devices.
2) Setting Realistic Goals
Performance budgets, performance goals, RAIL framework, 170KB/30KB budgets.
3) Defining The Environment
Choosing a framework, baseline performance cost, Webpack, dependencies, CDN, front-end architecture, CSR, SSR, CSR + SSR, static rendering, prerendering, PRPL pattern.
4) Assets Optimizations
Brotli, AVIF, WebP, responsive images, AV1, adaptive media loading, video compression, web fonts, Google fonts.
5) Build Optimizations
JavaScript modules, module/nomodule pattern, tree-shaking, code-splitting, scope-hoisting, Webpack, differential serving, web worker, WebAssembly, JavaScript bundles, React, SPA, partial hydration, import on interaction, 3rd-parties, cache.
6) Delivery Optimizations
Lazy loading, intersection observer, defer rendering and decoding, critical CSS, streaming, resource hints, layout shifts, service worker.
7) Networking, HTTP/2, HTTP/3
OCSP stapling, EV/DV certificates, packaging, IPv6, QUIC, HTTP/3.
8) Testing And Monitoring
Auditing workflow, proxy browsers, 404 page, GDPR cookie consent prompts, performance diagnostics CSS, accessibility.
10) Quick Wins
В данной статье мы остановимся подробнее на первом пункте под названием «Подготовка: Планирование и метрики»
Культура производительности, Core Web Vitals, профили производительности, CrUX, Lighthouse, FID, TTI, CLS, устройства.
Микрооптимизация отлично подходит для поддержания производительности, но очень важно иметь в голове четко определенные цели - измеримые цели, которые будут влиять на любые решения, принимаемые в ходе процесса. Существует несколько различных моделей, и те, что обсуждаются ниже, имеют свои мнения - просто убедитесь, что вы определили свои собственные приоритеты на раннем этапе.
- Создайте культуру производительности.
Во многих организациях front-end разработчики точно знают, каковы общие базовые проблемы и какие стратегии следует использовать для их устранения. Однако до тех пор, пока нет установленного одобрения культуры производительности, каждое решение будет превращаться в поле битвы отделов, разбивая организацию на группы. Вам нужна поддержка заинтересованных сторон, и чтобы получить ее, вам необходимо провести тематическое исследование или доказать концепцию того, как скорость - особенно Core Web Vitals, которую мы подробно рассмотрим позже - приносит пользу метрикам и ключевым показателям эффективности (KPI), о которых они заботятся.
Например, чтобы сделать производительность более осязаемой, можно раскрыть влияние производительности на доходы, показав корреляцию между коэффициентом конверсии и временем загрузки приложения, а также производительностью рендеринга. Или показатель заполняемости сайта поисковыми ботами (PDF, стр. 27-50).
Без сильного согласования между командами разработчиков/дизайнеров и бизнесменов/маркетологов производительность не будет устойчивой в долгосрочной перспективе. Изучите распространенные жалобы, поступающие в службу поддержки клиентов и отдел продаж, изучите аналитику на предмет высоких показателей отказов и падения конверсии. Изучите, как повышение производительности может помочь решить некоторые из этих распространенных проблем. Корректируйте аргументы в зависимости от группы заинтересованных лиц, к которым вы обращаетесь.
Проведите эксперименты с производительностью и измерьте результаты - как на мобильных, так и на настольных компьютерах (например, с помощью Google Analytics). Это поможет вам создать индивидуальный пример с реальными данными. Более того, использование данных из тематических исследований и экспериментов, опубликованных на WPO Stats, поможет повысить осведомленность бизнеса о том, почему производительность имеет значение, и какое влияние она оказывает на пользовательский опыт и бизнес-показатели. Однако одного утверждения, что производительность имеет значение, недостаточно - необходимо также установить некоторые измеримые и отслеживаемые цели и наблюдать за ними в течение определенного времени.
Как этого добиться? В своем выступлении на тему "Создание производительности в долгосрочной перспективе" Эллисон Макнайт делится подробным примером того, как она помогла создать культуру производительности в компании Etsy (слайды). Совсем недавно Тэмми Эвертс рассказывала о привычках высокоэффективных команд по повышению производительности как в малых, так и в больших организациях.
Проводя такие беседы в организациях, важно помнить, что так же, как UX - это спектр впечатлений, веб-производительность - это распределение. Как отметила Каролина Щур, "ожидание того, что одно число сможет обеспечить оценку, к которой нужно стремиться, является ошибочным предположением". Следовательно, цели производительности должны быть гранулированными, отслеживаемыми и осязаемыми.
Например, на мобильных устройствах за сеанс пользователи, которые быстро загружали сайт, приносят на 17% больше дохода, чем в среднем. Источник - Addy Osmani.
2. Цель: быть по крайней мере на 20% быстрее, чем ваш самый быстрый конкурент.
Согласно психологическим исследованиям, если вы хотите, чтобы пользователи чувствовали, что ваш сайт быстрее, чем сайт конкурента, вам нужно быть как минимум на 20% быстрее. Изучите своих основных конкурентов, соберите метрики о том, как они работают на мобильных и настольных компьютерах, и установите пороговые значения, которые помогут вам обогнать их. Чтобы получить точные результаты и цели, сначала изучите аналитику и получите полное представление об опыте ваших пользователей. Затем вы можете имитировать опыт 90-го процентиля для тестирования.
Чтобы получить первое впечатление о работе ваших конкурентов, вы можете использовать Chrome UX Report (CrUX, готовый набор данных RUM, видео введение Ильи Григорика и подробное руководство Рика Вискоми) или Treo, инструмент мониторинга RUM, который работает на базе Chrome UX Report. Данные собираются от пользователей браузера Chrome, поэтому отчеты будут специфичны для Chrome, но они дадут вам достаточно подробное распределение производительности, что особенно важно для оценок Core Web Vitals, по широкому кругу ваших посетителей. Обратите внимание, что новые наборы данных CrUX публикуются во второй вторник каждого месяца.
В качестве альтернативы вы также можете использовать:
1) Инструмент сравнения отчетов Chrome UX Report от Addy Osmani,
2) Speed Scorecard (также предоставляет оценку влияния на доход),
3) Сравнение тестов реального пользовательского опыта или
4) SiteSpeed CI (основан на синтетическом тестировании).
Примечание: Если вы используете Page Speed Insights или Page Speed Insights API (нет, он не устарел!), вы можете получить данные о производительности CrUX для конкретных страниц, а не только агрегированные. Эти данные могут быть гораздо полезнее для установления целевых показателей производительности для таких активов, как "целевая страница" или "листинг продукта". И если вы используете CI для тестирования бюджетов, вам нужно убедиться, что ваше тестируемое окружение соответствует CrUX, если вы использовали CrUX для установки цели (спасибо Патрику Минану!).
Если вам нужна помощь, чтобы показать обоснование приоритетности скорости, или вы хотите наглядно продемонстрировать снижение конверсии или увеличение показателя отказов при более медленной производительности, или, возможно, вам нужно пропагандировать RUM-решение в вашей организации, Сергей Чернышев создал UX Speed Calculator - инструмент с открытым исходным кодом, который помогает моделировать данные и визуализировать их, чтобы донести свою точку зрения.
Если вы хотите изучить немного глубже, объединив данные, полученные с помощью CrUX, с любыми другими данными, которые у вас уже есть, чтобы быстро определить, где замедления, "мертвые зоны" и неэффективность - у ваших конкурентов или в вашем проекте. В своей работе Гарри Робертс использует таблицу Site-Speed Topography Spreadsheet, которую он использует для разбивки производительности по ключевым типам страниц и отслеживания различных ключевых показателей по ним. Вы можете загрузить таблицу в формате Google Sheets, Excel, OpenOffice или CSV:
А если вы хотите пойти до конца, вы можете запустить аудит производительности Lighthouse на каждой странице сайта (через Lightouse Parade) с сохранением результатов в формате CSV. Это поможет вам определить, какие конкретные страницы (или типы страниц) ваших конкурентов работают хуже или лучше, и на чем вы, возможно, захотите сосредоточить свои усилия. (Для собственного сайта, вероятно, лучше отправлять данные в конечную точку аналитики!).
Соберите данные, создайте электронную таблицу, отбросьте 20% и таким образом установите свои цели (бюджеты производительности). Теперь у вас есть что-то измеримое для тестирования. Если вы не забываете о бюджете и пытаетесь отправить только минимальную полезную нагрузку, чтобы получить быстрое время перехода к интерактивности, то вы на разумном пути.
Нужны ресурсы для начала работы?
- Адди Османи написал очень подробную статью о том, как начать бюджетирование производительности, как количественно оценить влияние новых функций и с чего начать, если вы превысили бюджет.
- Руководство Лары Хоган о том, как подходить к разработке дизайна с бюджетом производительности, может дать полезные указания дизайнерам.
- Гарри Робертс опубликовал руководство по настройке Google Sheet для отображения влияния сторонних скриптов на производительность, используя Request Map.
- Калькулятор бюджета производительности Джонатана Филдинга, perf-budget-calculator Кэти Хемпениус и Browser Calories могут помочь в создании бюджетов (спасибо Каролине Щур за информацию).
- Во многих компаниях бюджеты производительности должны быть не желаемыми, а скорее прагматичными, служащими в качестве удерживающего знака, чтобы не проскользнуть мимо определенной точки. В этом случае, вы можете выбрать худшую точку данных за последние две недели в качестве порогового значения и двигаться дальше. В книге "Бюджеты эффективности, прагматично" показана стратегия достижения этой цели.
- Кроме того, сделайте бюджет производительности и текущую производительность видимыми, установив приборные панели с графиками, сообщающими о размерах сборки. Существует множество инструментов, позволяющих добиться этого: SiteSpeed.io dashboard (с открытым исходным кодом), SpeedCurve и Calibre - это лишь некоторые из них, и вы можете найти больше инструментов на perf.rocks.
Как только вы установили бюджеты, включите их в процесс сборки с помощью Webpack Performance Hints и Bundlesize, Lighthouse CI, PWMetrics или Sitespeed CI, чтобы обеспечить соблюдение бюджетов в запросах на поставку и предоставить историю оценок в комментариях PR.
Чтобы открыть бюджеты производительности для всей команды, интегрируйте бюджеты производительности в Lighthouse через Lightwallet или используйте LHCI Action для быстрой интеграции Github Actions. А если вам нужно что-то индивидуальное, вы можете использовать webpagetest-charts-api, API конечных точек для построения графиков из результатов WebPagetest.
Однако осведомленность о производительности не должна исходить только из бюджетов производительности. Подобно Pinterest, вы можете создать пользовательское правило eslint, запрещающее импорт из файлов и каталогов, которые, как известно, имеют много зависимостей и раздувают пакет. Создайте список "безопасных" пакетов, который может быть распространен среди всей команды.
Кроме того, подумайте о критических задачах клиента, которые наиболее полезны для вашего бизнеса. Изучите, обсудите и определите приемлемые временные пороги для критически важных действий и установите "готовые UX" временные отметки пользователей, которые одобрила вся организация. Во многих случаях путешествия пользователей затрагивают работу многих различных отделов, поэтому согласование приемлемых сроков поможет поддержать или предотвратить дискуссии о производительности в дальнейшем. Убедитесь, что дополнительные затраты на дополнительные ресурсы и функции видны и понятны.
Согласовывайте усилия по повышению производительности с другими техническими инициативами, начиная от новых функций создаваемого продукта, рефакторинга и заканчивая выходом на новую глобальную аудиторию. Поэтому каждый раз, когда идет разговор о дальнейшем развитии, производительность также является частью этого разговора. Гораздо легче достичь целей по производительности, когда кодовая база свежая или только что отрефакторенная.
Кроме того, как предложил Патрик Минан, стоит планировать последовательность загрузки и компромиссы в процессе проектирования. Если вы заранее определите приоритеты, какие части являются более важными, и определите порядок их появления, вы также будете знать, что можно отложить. В идеале этот порядок будет также отражать последовательность импорта CSS и JavaScript, что облегчит работу с ними в процессе сборки. Также подумайте о том, каким должно быть визуальное восприятие в "промежуточных" состояниях, когда страница находится в процессе загрузки (например, когда веб-шрифты еще не загружены).
Как только вы установите в своей организации сильную культуру производительности, стремитесь быть на 20% быстрее, чем раньше, чтобы сохранить приоритеты с течением времени. Но учитывайте различные типы и модели поведения ваших клиентов (которые Тобиас Балдауф назвал cadence и cohorts), а также трафик ботов и влияние сезонности.
Планирование, планирование, планирование. Может быть заманчиво заняться быстрой оптимизацией "низко висящих фруктов" на ранних этапах - и это может быть хорошей стратегией для быстрых побед - но будет очень трудно сохранить производительность в качестве приоритета без планирования и постановки реалистичных целей производительности с учетом специфики компании.
3) Выберите правильные метрики.
Не все метрики одинаково важны. Изучите, какие метрики наиболее важны для вашего приложения: обычно они определяются тем, как быстро вы можете начать рендеринг наиболее важных пикселей вашего интерфейса и как быстро вы можете обеспечить отзывчивость ввода для этих рендеринговых пикселей. Эти знания дадут вам наилучшую цель оптимизации для дальнейших усилий. В конечном счете, не события загрузки или время отклика сервера определяют опыт, а восприятие того, насколько быстро работает интерфейс.
Что это значит? Вместо того чтобы фокусироваться на полном времени загрузки страницы (например, через тайминги onLoad и DOMContentLoaded), отдайте предпочтение загрузке страницы в том виде, в котором ее воспринимают ваши клиенты. Это означает, что нужно сосредоточиться на несколько ином наборе метрик. На самом деле, выбор правильной метрики - это процесс без очевидных победителей.
Основываясь на исследованиях Тима Кадлека и заметках Маркоса Иглесиаса в его докладе, традиционные метрики можно сгруппировать в несколько наборов.
Обычно нам нужны все из них, чтобы получить полную картину производительности, и в вашем конкретном случае некоторые из них будут важнее других.
- Метрики, основанные на количестве, измеряют количество запросов, вес и оценку производительности. Хороши для поднятия тревоги и мониторинга изменений во времени, но не так хороши для понимания пользовательского опыта.
- Метрики по вехам используют состояния во время процесса загрузки, например, Time To First Byte и Time To Interactive. Хороши для описания пользовательского опыта и мониторинга, но не очень хороши для понимания того, что происходит между вехами.
- Метрики рендеринга дают оценку скорости рендеринга контента (например, время начала рендеринга, индекс скорости). Хороши для измерения и настройки производительности рендеринга, но не очень хороши для определения времени появления важного контента и возможности взаимодействия с ним.
- Пользовательские метрики измеряют конкретное событие для пользователя, например, время до первого твита в Twitter и время ожидания PinnerWaitTime в Pinterest. Эти показатели хороши для точного описания пользовательского опыта, но не очень хороши для масштабирования показателей и сравнения с конкурентами.
Для полноты картины мы обычно ищем полезные метрики среди всех этих групп.
Обычно наиболее конкретными и релевантными являются:
Точка, в которой макет стабилизировался, ключевые веб-шрифты видны, а основной поток достаточно доступен для обработки пользовательского ввода - по сути, отметка времени, когда пользователь может взаимодействовать с пользовательским интерфейсом. Ключевая метрика для понимания того, сколько ожиданий должен испытать пользователь, чтобы пользоваться сайтом без задержек. Борис Шапира написал подробный пост о том, как надежно измерить TTI.
Время с момента первого взаимодействия пользователя с вашим сайтом до момента, когда браузер фактически способен ответить на это взаимодействие. Очень хорошо дополняет TTI, поскольку описывает недостающую часть картины: что происходит, когда пользователь фактически взаимодействует с сайтом. Предназначен только как метрика RUM. Существует библиотека JavaScript для измерения FID в браузере.
Отмечает точку во временной шкале загрузки страницы, когда, скорее всего, загрузилось самое важное содержимое страницы. Предполагается, что наиболее важным элементом страницы является самый большой элемент, видимый в области просмотра пользователя. Если элементы отображаются как выше, так и ниже сгиба, релевантной считается только видимая часть.
Метрика, которая помогает количественно оценить степень неинтерактивности страницы до того, как она станет надежно интерактивной (то есть, основной поток был свободен от любых задач, выполняющихся более 50 мс (длинные задачи) в течение как минимум 5 с). Метрика измеряет общее количество времени между первой закраской и временем до интерактивности (TTI), когда основной поток был заблокирован достаточно долго, чтобы не реагировать на ввод. Неудивительно, что низкий показатель TBT является хорошим индикатором хорошей производительности.
Эта метрика показывает, как часто пользователи сталкиваются с неожиданными сдвигами макета (перетеканиями) при посещении сайта. Она изучает нестабильные элементы и их влияние на общее впечатление. Чем ниже показатель, тем лучше.
Измеряет, насколько быстро визуально отображается содержимое страницы; чем ниже показатель, тем лучше. Показатель индекса скорости рассчитывается на основе скорости визуального продвижения, но это всего лишь расчетное значение. Он также чувствителен к размеру области просмотра, поэтому вам необходимо определить диапазон конфигураций тестирования, соответствующий вашей целевой аудитории. Обратите внимание, что он становится менее важным, поскольку LCP становится более значимой метрикой.
- Затраченное процессорное время
Метрика, показывающая, как часто и как долго основной поток блокируется, работая над рисованием, рендерингом, сценариями и загрузкой. Высокое время процессора является явным показателем нестабильной работы, т.е. когда пользователь ощущает заметную задержку между своим действием и ответом. В WebPageTest вы можете выбрать "Capture Dev Tools Timeline" на вкладке "Chrome", чтобы просмотреть разбивку главного потока в процессе его работы на любом устройстве, использующем WebPageTest.
Как и в случае с затратами процессорного времени, эта метрика, предложенная Стояном Стефановым, исследует влияние JavaScript на процессор. Идея заключается в том, чтобы использовать количество инструкций CPU для каждого компонента, чтобы понять его влияние на общий опыт, в отдельности. Может быть реализована с помощью Puppeteer и Chrome.
В то время как многие метрики, представленные выше, объясняют, когда происходит то или иное событие, FrustrationIndex Тима Верееке рассматривает промежутки между метриками, а не рассматривает их по отдельности. Он рассматривает основные этапы, воспринимаемые конечным пользователем, такие как "Заголовок виден", "Первый контент виден", "Визуально готов" и "Страница выглядит готовой", и рассчитывает балл, указывающий на уровень разочарования при загрузке страницы. Чем больше разрыв, тем больше вероятность того, что пользователь будет расстроен. Потенциально это хороший KPI для пользовательского опыта. Тим опубликовал подробный пост о FrustrationIndex и о том, как он работает.
Если ваш сайт зависит от доходов, получаемых от рекламы, полезно отслеживать вес кода, связанного с рекламой. Скрипт Пэдди Ганти создает два URL (один обычный и один блокирующий рекламу), предлагает сгенерировать видеосравнение через WebPageTest и сообщает о дельте.
Как отмечают инженеры Википедии, данные о том, насколько велика дисперсия в ваших результатах, могут сообщить вам, насколько надежны ваши инструменты, и сколько внимания вам следует уделять отклонениям и аутлерам. Большая дисперсия является показателем того, что необходимо внести коррективы в настройку. Это также помогает понять, труднее ли надежно измерить определенные страницы, например, из-за сторонних скриптов, вызывающих значительные отклонения. Нелишним будет также отслеживание версии браузера, чтобы понять, какие скачки в производительности происходят при выпуске новой версии браузера.
Пользовательские метрики определяются вашими бизнес-потребностями и клиентским опытом. Они требуют определения важных пикселей, критических скриптов, необходимых CSS и соответствующих активов и измерения того, как быстро они доставляются пользователю. Для этого вы можете отслеживать Hero Rendering Times. Кроме того, вы можете собирать пользовательские метрики с помощью WebPagetest, выполняя произвольный JavaScript в конце теста.
Обратите внимание, что в приведенном выше обзоре отсутствует показатель First Meaningful Paint (FMP). Раньше он давал представление о том, как быстро сервер выводит какие-либо данные. Длинный FMP обычно указывал на блокировку JavaScript основного потока, но также мог быть связан с проблемами бэкенда/сервера. Однако в последнее время эта метрика была упразднена, так как она оказалась неточной примерно в 20% случаев. Она была фактически заменена на LCP, которая является более надежной и более простой для рассуждений. Она больше не поддерживается в Lighthouse. Дважды проверьте последние метрики производительности и рекомендации, ориентированные на пользователя, чтобы убедиться, что вы находитесь на безопасной странице.
Стив Соудерс подробно объясняет многие из этих показателей. Важно отметить, что в то время как Time-To-Interactive измеряется путем проведения автоматизированного аудита в так называемой лабораторной среде, First Input Delay отражает реальный пользовательский опыт, причем реальные пользователи испытывают заметную задержку. В целом, вероятно, хорошей идеей будет всегда измерять и отслеживать оба показателя.
В зависимости от контекста вашего приложения, предпочтительные метрики могут отличаться: например, для пользовательского интерфейса Netflix TV более важны скорость отклика на ввод, использование памяти и TTI, а для Wikipedia более важны метрики первого/последнего визуального изменения и затраченного процессорного времени.
Примечание: FID и TTI не учитывают поведение скроллинга; скроллинг может происходить независимо, поскольку он не является основным потоком, поэтому для многих сайтов, потребляющих контент, эти метрики могут быть гораздо менее важны.