Недавно на сайте web.dev появился раздел, посвящённый метрикам производительности. Насколько я понял, этот раздел собран из новых статей и из уже существовавших с небольшими правками.

Сейчас там можно найти описание всех пользовательских метрик. Каждой метрике посвящена отдельная статья: First Contentful Paint (FCP), Largest Contentful Paint (LCP), First Input Delay (FID), Time to Interactive (TTI) и т.п. Есть практические советы по улучшению этих метрик. Появилась статья про Custom Metrics — в ней рассказывается про использование User Timing API (позволяет замерять временные метрики), Long Tasks API (для выявления проблем с блокированием главного потока JS), Element Timing API (используется для определения времени появления на странице конкретных элементов).

Если вы занимаетесь производительностью, то вам точно пригодится эта подборка статей.

#performance #metrics

https://web.dev/metrics/

На CSS-Tricks Артём Денисов написал про производительность JAM-сайтов — "A Look at JAMstack’s Speed, By the Numbers".

Под понятием JAMstack (JavaScript, APIs, Markdown) понимаются статически генерируемые сайты. В отличие от традиционных сайтов, построенных с помощью CMS, все страницы JAMstack-сайтов генерируются на этапе сборки чаще всего из Markdown-файлов. Этот подход в последнее время набирает большую популярность. В статье сравниваются метрики TTFB, FCP и FID для среднестатистических сайтов, CMS- и JAMstack-сайтов. Последние (при условии использования CDN) показывают наибольшую производительность.

В статье есть хорошая мысль по поводу производительности: "Мне встречались клиенты, которые требовали поддержку IE10 и IE11, потому что этими браузерами пользовался один процент пользователей, что эквивалентно миллионам долларов выручки. Пожалуйста, подсчитайте свои потери, когда один процент пользователей уходит с сайта и никогда не возвращается из-за плохой производительности. Если пользователи страдают, будет страдать и бизнес".

#performance #metrics #jamstack

https://css-tricks.com/a-look-at-jamstacks-speed-by-the-numbers/

Петер Хеденског рассказал, как на Wikipedia измеряется отзывчивость сайта — "Measuring Long Tasks and First Input Delay".

Для измерения отзывчивости в Wikipedia используют Long Tasks API и метрику First Input Delay (доступны только в Chrome). Long Tasks API позволяет найти задачи, выполнение которых занимает более 50 мс в основном потоке. В собираемых данных нет информации о том, какая именно задача забивала поток, поэтому в синтетическом окружении дополнительно собираются логи производительности, это помогает в поиске конкретных задач. First Input Delay показывает, сколько времени занимает отклик после первого взаимодействия со страницей. Эту метрику сложно измерить адекватно в синтетическом окружении, но её можно аппроксимировать с помощью max potential first input delay.

Статья хорошая. Рекомендую почитать, если интересно узнать, какие есть грабли при сборе метрик.

#performance #metrics #wikipedia

https://calendar.perfplanet.com/2019/measuring-long-tasks-and-first-input-delay/

Гарри Робертс поделился своими мыслями о бюджете на производительность — "Performance Budgets, Pragmatically".

Гарри пишет, что не стоит рассматривать бюджет как цель — большинство организаций не готовы брать на себя вызовы по экстренной оптимизации проекта. В статье предлагается более прагматичный подход, который рассматривает бюджет как подушку безопасности. Сначала нужно посмотреть на метрики за последние две недели и выбрать наихудший показатель, который будет верхним порогом в бюджете. Затем каждые две недели делать анализ: если нет проблем, то снижать порог далее, если проблема появилась, то нужно заняться её исправлением.

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

#performance #metrics

https://csswizardry.com/2020/01/performance-budgets-pragmatically/

В блоге Chromium была опубликована статья про исследования, которыми подкреплялись пороговые значения недавно анонсированных Web Vitals — "The Science Behind Web Vitals ".

Web Vitals состоит из трёх метрик — Largest Contentful Paint (LCP), Cumulative Layout Shift (CLS) и First Input Delay (FID). Пороговые значения для них были выбраны с учётом поведения реальных пользователей. Например, одно из исследований говорит о том, что пользователи мобильных устройств обычно сохраняют внимание около 4-8 секунд. Если за это время страница не загрузилась, это означает, что для них общее время загрузки будет состоять из актуального времени загрузки плюс количество времени, в течении которого они не смотрели на устройство, после того как страница была загружена. Ещё одно исследование говорит о том, что пользователи замечают проблемы с отзывчивостью интерфейса, если время задержки до визуального фидбека находится в районе 150 миллисекунд.

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

#performance #metrics

https://blog.chromium.org/2020/05/the-science-behind-web-vitals.html

Хочу продолжить вчерашнюю тему. Эдди Османи написал пост про решение проблем сдвига контента — "Optimize Cumulative Layout Shift".

Cumulative Layout Shift (CLS) — это метрика Web Vitals, которая измеряет нестабильность контента, складывая смещение всех элементов, которое происходит независимо от действий пользователя. То есть если на странице происходит сдвиг после пользовательского ввода, например, пользователь открыл список-аккордеон после загрузки страницы, то такое смещение не будет влиять на CLS.

Самые распространённые причины нежелательных смещений:
— изображения без заданных размеров (можно исправить добавлением атрибутов width и height );
— реклама, iframe, встраиваемый контент (можно исправить, предварительно выделив необходимое место);
— динамически добавляемые блоки — GDPR-сообщения, похожие товары и т.п. (вместо них можно использовать временные заглушки);
— web-шрифты, вызывающие FOIT/FOUT (такое смещение можно устранить с помощью font-display: optional и <link rel="preload"> ).

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

#performance #metrics

https://web.dev/optimize-cls/

Андрэа Верличчи написал статью про опыт оптимизации метрик LCP и CLS e-commerce проекта — "Optimizing for web vitals on chloe.com".

С помощью Lighthouse можно найти DOM-узел, который генерирует LCP (Largest Contentful Paint). На chloe таким узлом был блок с изображениями товаров. Для того чтобы изображения загрузились раньше, был понижен приоритет второстепенных асинхронных запросов. У самих изображений была ограничена плотность пикселей до 2x, что позволило уменьшить размер изображений на 50%. На современных смартфонах с плотностью пикселей 3x пользователи не замечают такое уменьшение плотности изображений. Для ускорения времени отрисовки критический CSS инлайнят в html. Для этого на этапе сборки используется скрипт, который ищет все критичные CSS-блоки, содержащие специальное свойство critical: this;.

Для оптимизации CLS (Cumulative Layout Shift) было зарезервировано место для тех виджетов, которые рендерятся на клиенте. Был подобран такой дефолтный шрифт, который после замены, не вызывал сдвига контента.

Хорошая статья. Стоит заглянуть, если интересуетесь темой производительности.

#performance #metrics

https://medium.com/ynap-tech/optimizing-cls-and-lcp-on-chloe-com-8280a036122a

Скотт Джел написал пост про необходимость сбора метрик сайтов, учитывающих средства доступности, — "We need more inclusive web performance metrics".

Метрики FCP и LCP, которые предоставляют браузеры, — отличные средства для анализа скорости появления контента на странице. Но эти метрики отражают опыт работы с сайтами не всех пользователей. Для кого-то контент может быть недоступен, пока страница не станет полностью интерактивна, так как многие web-приложения добавляют интерактивность для средств доступности с помощью загружаемого JavaScript. То есть если пользователь использует скринридер, то он не сможет получить доступ к странице, пока на ней не будет выполнен необходимый JavaScript-код.

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

#a11y #metrics #performance

https://www.filamentgroup.com/lab/a11y-ready/

Эдди Османи рассказал о том, как ускорить загрузку hero-изображений — "Preload late-discovered Hero images faster".

Hero image — это термин, которым в дизайне называют главное изображение статьи. Оно обычно располагается на самом видном месте страницы. С точки зрения производительности скорость загрузки такого изображения влияет на метрику Largest Contentful Paint (LCP).

Проблема может возникнуть тогда, когда загрузка изображения происходит на позднем этапе, например, после инициализации js или после загрузки другого ресурса, в котором находится url изображения. Для улучшения LCP можно использовать preconnect или preload. Preload можно использовать с отзывчивыми изображениями:

<link rel="preload" as="image" 
     href="poster.jpg" 
     imagesrcset="
        poster_400px.jpg 400w, 
        poster_800px.jpg 800w, 
        poster_1600px.jpg 1600w" 
    imagesizes="50vw">

Рекомендую почитать статью, если в вашем проекте используются hero-изображения.

#performance #metrics

https://addyosmani.com/blog/preload-hero-images/

Ник Джансма из Akamai написал большую статью про метрику CLS — "Cumulative Layout Shift in Practice".

Метрика CLS (Cumulative Layout Shift) показывает, насколько контент страницы стабилен. Большой показатель CLS обычно говорит о том, что у страницы плохой пользовательский опыт. Например, когда сдвигается текст из-за загрузки изображения или рекламных виджетов.

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

— CLS на мобильных устройствах выше, потому что контент на мобильных сайтах располагается вертикально, поэтому при анализе проблем CLS рекомендуется разделять статистику для десктопов и мобильных;
— момент времени, когда останавливается сбор метрики CLS, для разных инструментов разный;
— в инструментах разработчика есть баги при измерении сдвига контента внутри iframe'ов, также есть несоответствия в инструментах для сбора синтетической статистики и статистики с устройств реальных пользователей;
— в некоторых случаях страницы с высоким CLS могут предоставлять хороший пользовательский опыт;
— CLS не учитывает элементы, которые ничего не рендерят.

Очень большая и хорошая статья. Рекомендую почитать всем, кто интересуется темой производительности.

#performance #metrics

https://nicj.net/cumulative-layout-shift-in-practice/

Новые метрики для измерения отзывчивости сайтов

Разработчики Chrome уже более полугода работают над добавлением новых метрик, отвечающих за измерение отзывчивости сайтов. Хонгбо Санг рассказывает, как их можно подсчитать — "Hands On with the new Responsiveness Metrics".

В Core Web Vitals за отзывчивость страницы отвечает метрика First Input Delay. FID показывает величину задержки между пользовательским событием и временем, когда это событие начинает обрабатываться. У этой метрики много ограничений: оно показывает время задержки только первого события, оно не включает в себя время обработки события, с её помощью нельзя понять, лагает ли страница.

В новых экспериментальных метриках измеряется время обработки взаимодействий пользователя (interactions) на протяжении всей жизни страницы. Взаимодействие — это комбинация логически связанных DOM-событий. Например, для нажатия кнопки на клавиатуре такими событиями будут keydown, keypress и keyup.

На данный момент ещё нет окончательного списка метрик отзывчивости, так как у разных вариантов есть свои плюсы и минусы. В статье есть ссылка на код, который можно запустить в DevTools, чтобы получить все метрики, которые находятся на рассмотрении. Также есть экспериментальный плагин для Lighthouse для получения этих метрик.

Разработчики просят посмотреть результаты метрик на своих сайтах и оставить фидбек.

#performance #metrics

https://calendar.perfplanet.com/2021/hands-on-with-the-new-responsiveness-metrics/