❗️ Начинаем сегодня и в течение недели будем публиковать методы улучшения показателей Core Web Vitals.

Google анонсировал Web Vitals в 2019 году, а уже в 2021 году показатели Core Web Vitals стали влиять на выдачу в Google. Основные метрики Core Web Vitals - это LCP, FID и CLS, именно про них гугл выдает предупреждения в Google Webmaster Console.

Данные Web Vitals - это живые данные, которые получены и агрегированы на серверах Google от браузеров реальных пользователей. Google Chrome в фоновом режиме передает в Google данные о скорости посещенных сайтов. Показатели метрик, адреса страниц, данные об устройстве и взаимодействии со страницей. Данные усредняются и выводятся по 75-ому процентилю (не путать с квантилем). Это когда вычисляется значение так, чтобы 75% общих данных находились ниже этого предела.

Все данные можно получить через коннектор Chrome UX Report. Переходим, вводим сайт (с www и https) и нажимаем связать. Далее давим создать отчет и получаем графический отчет с историей изменения всех показателей (если данных достаточно).

Кроме основных показателей, которые описаны выше, мы увидим еще и другие данные, некоторые из них могут быть вам знакомы по отчетам Lighthouse, а некоторые совсем непонятные, которые собирает гугл, а это FCP, INP, TTFB, FP, Notification Permissions, DCL, OL и параметры распределения устройств и скорости соединениям: Device Distribution и Connect Distribution. Подробно их все обязательно разберем в течение этой недели.

Данные в отчете Chrome UX Report обновляются раз в месяц, тоесть данные всегда с отставанием, примерно в один месяц. Более точные данные за последние 28 дней (что тоже не моментально) можно найти в Google Pagespeed Insights, и в Chrome UX Report API. Быстро данные из этого API можно увидеть на сайте webvitals.ru.

🗓 Завтра разберем LCP, как основной показатель, отвечающий за скорость загрузки.

💬 Делитесь своими показателями и задавайте вопросы в комментариях. Помните, не бывает глупых вопросов.

⚠️ Сегодня все внимание на LCP - продолжаем серию публикаций про Core Web Vitals.

🟢 Зеленая зона: до 2.5 секунд
🟡 Желтая зона: от 2.5 секунд до 4 секунд
🔴 Красная зона: более 4 секунд

LCP (Largest Contentful Paint) - Скорость загрузки основного контента, который занимает большую часть первого экрана страницы и является контрастным к фону. Так как мы говорим про Core Web Vitals, то следует учитывать какой элемент страницы является LCP-элементом, так как загрузка происходит с разных устройств с разным разрешением экрана, и где-то на первый экран может попадать больше контента и естественно, что элементы могут быть разными. Кроме того, для разных страниц LCP-элемент также может быть разным. Где-то вставлено небольшое изображение и LCP-элементом может являться большой заголовок, а где-то наоборот небольшой заголовок, но большое изображение, и уже изображение является LCP-элементом.

Большой показатель может свидетельствовать о том, что у пользователя есть проблема с отображением основного контента страницы, а это создает у пользователя иллюзию медленного интернета. Да, пользователь редко когда воспринимает медленным ваш сайт, чаще он будет думать, что тормозит интернет или устройство с которого он посетил ваш сайт. Так вот, если мы понимаем, что есть проблема с LCP, нам нужно в первую очередь понять, какой элемент является LCP-элементом. Для этого можно использовать отчеты Lighthouse, или Google Pagespeed Insights, который кстати тоже работает на Lighthouse. И уже после этого принимать решение, что делать.

🧩 Улучшаем LCP

Если LCP-элементом является изображение, то нужно проверить, не отложено ли оно. Изображения, которые могут являться LCP-элементом ни в коем случае не откладываем. Далее максимально сжимаем это изображение. Для быстрого сжатия воспользуйтесь приложением, о котором мы писали ранее. Обязательно проверьте разрешение изображения. Часто бывает, что на первом экране изображение с зеркалки размером 6000х4000 пикселей, а то и больше, с весом 18 мб. Если его просто сжать и перевести в webp и avif, мы все равно получим 2-4 мегабайта данных, что очень много. Сжимайте изображение так, чтобы оно весило не более 100 кб. Меньше - лучше. Для повышения приоритета загрузки, если на странице много запросов, можно добавить <link rel="preload" as="image" href="/lcp.jpg">.

Если LCP - это текстовый тег, например h1, или p, то здесь нужно проверить, что шрифты загружены, и для них используется font-display:swap. Без этого до момента загрузки шрифта будет просто белый экран. Если шрифты подключаются из Google Fonts, то перечитате наши посты (раз, два, три). Если шрифт грузится с вашего хоста, используйте формат woff2 и добавьте именно его в прелоад: <link rel="preload" as="font" href="font.woff2" crossorigin>.

Если же LCP-элементом является div, у которого есть фоновое изображение и текстовое содержимое, то тут возникает проблема с приоритетом загрузки, и для его отображения нужно загрузить картинку и загрузить шрифт. Лучше всего переверстать такой блок так, чтобы использовался тег img, а не фоновое изображение. Это поможет браузеру определить очередность загрузки и LCP улучшится. Далее определяем новый LCP-элемент и заново пробегаем по алгоритму.

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

Для улучшения показателя FID в первую очередь следует отложить загрузку контента, которого нет на первом экране. При использовании реактивных фреймворков можно откладывать гидрацию целых компонентов, чтобы максимально быстро отобразить контент первого экрана. Откладываем изображения при помощи кода, о котором мы писали ранее. Откладываем внешние скрипты до момента когда они будут необходимы, или до момента первого действия пользователя на странице (mousemove, click, touchstart, scroll, resize).

Далее разбиваем большие задачи в JavaScript на более мелкие. Например, если вы в большом цикле обрабатываете большое число задач, то стоит их вынести в отдельные функции и вызывать через setTimeout или requestIdleCallback для того, чтобы задачи вставали в очередь и не блокировали основной поток браузера.

Максимально уменьшаем число внешних соединений, так как установка соединения - самая ресурсоемкая операция. Минимизируйте число preconnect, dns-prefetch, prefetch и preload. Используйте их только для ресурсов которые есть на первом экране, но опять же помните, что лучше перенести или проксировать данные через свой домен.

💬 Если у вас есть проблемы с этим показателем - пишите в комментариях.

⚠️ Сегодня говорим про FID - продолжаем серию публикаций про Core Web Vitals.

🟢 Зеленая зона: до 100 мс
🟡 Желтая зона: от 100 до 300 мс
🔴 Красная зона: более 300 мс

FID (First Input Delay) - время между первым действием пользователя на сайте и реакцией на это действие браузера. Этот показатель в теории должен отвечать за отзывчивость сайта во время загрузку и сразу после нее. Чем показатель ниже, тем лучше. В теории должен показывать насколько отзывчив сайт, на практике практически всегда в зеленой зоне.

В первую очередь на этот показатель влияет время выполнения JavaScript кода на странице, и если показатель в желтой или тем более в красной зоне, то у сайта действительно серьезные проблемы с отзывчивостью. На мой взгляд, FID не отражает реальную отзывчивость сайта, и должен быть переработан. В этом направлении уже идут работы, потому что недавно был добавлен тестовый показатель INP (Interaction to Next Point), про который речь пойдет в другой день. INP гораздо лучше помогает оценить отзывчивость сайта, так как лишен минусов FID.

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

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

⚠️ Сегодня говорим про CLS - продолжаем серию публикаций про Core Web Vitals.

🟢 Зеленая зона: до 0.1
🟡 Желтая зона: от 0.1 до 0.25
🔴 Красная зона: более 0.25

Cumulative Layout Shift - это ключевой показатель Core Web Vitals, который отвечает за визуальную стабильность страницы во время загрузки и использования страницы. Вот это "во время использования" вызывает у людей больше всего вопросов. Вы можете замерить показатели всех страниц в Lighthouse и везде иметь CLS равный 0, но при этом по Core Web Vitals показатель будет далеко не идеальным, а возможно и вообще в красной зоне.

Все дело в том, что это динамический показатель, и снимается за все время посещения страницы, а не разово, как например LCP, или FID. Тоесть во время загрузки смещений может не быть, но при взаимодействии со страницей могут происходить смещения, которые будут зафиксированы и повлияют на показатель CLS в Core Web Vitals. Однако стоит оговориться, что смещения должны быть неожиданными, например, если происходит добавление элементов сразу после клика на кнопку, и при этом происходит смещение, то эти оно не будет являться неожиданным, так как перед ним следовал клик пользователя. Сразу договоримся, что далее мы говорим именно о неожиданных смещениях, и устранять мы будем не все смещения, а только неожиданные. Неожиданными являются те смещения, перед которыми в течение 500 миллисекунд не происходило взаимодействие пользователя с интерфейсом сайта.

⚠️ Отмечу, что CLS - это самая частая проблема по метрикам Core Web Vitals, и встречается даже у очень быстрых сайтов.

🧩 Давайте рассмотрим основные проблемные моменты, почему они происходят и как их устранить.

Возможно смещение контента при загрузке отложенных изображений. До момента загрузки, в src изображения находится заглушка, а после грузится изображение большего формата, и как следствие сдвигает весь контент ниже этого элемента. Для того, что исправить это, просто укажите у изображений width и height. Если изображения масштабируются уже в браузере, нужно указать ширину и высоту оригинальной картинки, для определения aspect-ratio, далее меняете размер уже через стили.

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

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

Бесконечная прокрутка - еще один частый кейс когда происходит CLS. Здесь все просто: если используете бесконечную прокрутку уберите футер, потому что до него, во-первых, никогда не доскроллят, во-вторых, он постоянно будет сдвигаться и приводить к увеличению cls. Можно показывать футер только когда пользователи доскроллят до конца. Главное сделать так, чтобы ниже подгружаемого контента ничего небыло, что могло бы смещаться.

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

💬 Пишите, если у вас есть затруднения в решении проблемы с CLS.

🥳 Вот и заключительный день нашей недели Core Web Vitals. Напомню, мы рассмотрели LCP, FID, и CLS. Даже в рамках двух постов в день получилось очень поверхностно, потому что когда писали статью, она не влезала даже в 3 поста Telegram.

Давайте кратко пробежимся по оставшимся трем, которые собирает Google и выводит в Google Pagespeed Insights. Это FCP, INP и TTFB. На самом деле это большая тема, и про улучшения каждого из показателей мы сделаем еще не один пост, так как и методы меняются и поведения браузеров и новые метрики также появляются.

FCP - отрисовка первого контента, это время между событием TTFB и началом отрисовки контента на странице.

🟢 до 1.8 секунд
🟡 от 1.8 до 3 секунд
🔴 более 3 секунд

Для улучшения показателя нужно снижать блокировку отрисовки. Стили делим на Critical и обычные, и inline грузим только критические, остальные подключаем асинхронно, js откладываем при помощи defer или другими методами.

INP - новый показатель, работает по тому же принципу, что и CLS, и считает данные за все время проведенное пользователем на странице, а не только при загрузке.

🟢 до 200 мс
🟡 от 200 до 300 мс
🔴 более 500 мс

Для улучшения показателя добавляем стильные скелетоны при клике на кнопку без ожидания ответа сервера. И оптимизируем сам Javscript. Разбиваем задачи на более мелкие и упрощаем. Отказываемся от поддержки устаревших браузеров.

TTFB - Время до получения первого байта от сервера. Зависит от времени выполнения скриптов, сети и нагрузки магистралей. Больше всего зависимость от времени выполнения скриптов на сервере. Чем проще задачи - тем быстрее.

🟢 до 500 мс
🟡 от 500 до 1000 мс
🔴 более 1000 мс

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

На следующей неделе рассмотрим несколько практических методов для улучшения показателей производительности. Хороших выходных!

💬 Пишите, была ли вам полезна информация этой недели?

❗️ Я много раз писал, что самая ресурсоемкая операция - это установка нового соединения. Сегодня мы обсудим отложенную загрузку внешних скриптов. В отличии от отложенной загрузки изображений, внешние скрипты откладывают по первому действию пользователя, например движению мыши, клику, ресайзу, скроллу, и тд. Это повышает оценку Google PageSpeed Insights. Получаем значительное улучшения показателей, но давайте рассмотрим, что же произойдет, когда пользователь пошевелит мышкой или сделает клик.

Обычная реализация: задается функция, которая создает элемент <script> со стороннего домена, или выполняет код. Далее эта функция вызывается на действие пользователя. Самые частые ошибки здесь:

1. Функция выполняется на каждое действие пользователя. Каждое смещение мыши или клик добавляют на страницу элемент, что неправильно, так как это нужно сделать всего один раз.
2. Элемент добавляется один раз, но прослушиватели остаются. Это лучше, чем предыдущий пункт, но также влияет на быстродействие. Удаляем события после срабатывания.
3. Все скрипты выполняются на одно и то же действие и буквально одной кучей. Системы синтетических замеров не увидят, но у пользователя основной поток будет заблокирован при первом же действии. Нужно разносить по времени, и постоянно смотреть во вкладку Performance в Google Chrome.
4. Загружается слишком много скриптов, что приводит к блокировке основного потока при загрузке с медленных устройств. Избавляемся от ненужных скриптов.

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

⚠️ Чтобы полностью избавиться от негативного влияния внешних скриптов, нужно ПОЛНОСТЬЮ убрать их с сайта. Любой сторонний скрипт нужно добавлять, предварительно замерив как это влияет на быстродействие сайта. Если не сильно, то можно откладывать по предложенному ниже примеру.

✅ Пример на CodePen

А что если отложить весь JS?

Привет 👋. В прошлой статье я писал о том, как отложить внешние скрипты. И кто-то мог задаться вопросом: а что если отложить вообще весь JS? Да, мы встречали такие проекты при работе. Сразу скажу, что от проекта к проекту отличались методы отложенной загрузки и выполнения скриптов. Однако мы немного подумали, и вообще сделали конфиг для nginx, который откладывает выполнение всех js на странице в автоматическом режиме. Что-то похожее делает Rocket-loader у Cloudflare, но грузятся и выполняются скрипты только при первом действии пользователя.

Как это работает, nginx на своей стороне дописывает к скриптам type="text/psscript" и скрипт перестает выполняться браузером. Далее при помощи JS создаются новые элементы script, которые загружаются в нужном порядке, и загрузка начинается после срабатывания события.

⚠️ Важно: для того, чтобы скрипт работал правильно, нужно сделать так, чтобы первый экран отображался одинаково как с включенным так и с выключенным JS. Особенно это касается слайдеров, попапов и тд. И этот может существенно испортить другие показатели по Core Web Vitals, а относительно полезно только для синтетических тестов. Однако кому-то может помочь решить "нерешаемую" задачу.

🧩 Конфиг nginx
✅ JS-файл

Как заставить это работать: Конфиг в секцию server, js в корень сайта с тем же именем.

💬 Пишите ваши мнения в комментариях

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

Проксирование метрики через свой домен позволяет снизить число установленных соединений, и как следствие ускорить инициализацию при первом запуске проекта. Для корректной работы nginx дожен быть собран с поддержкой sub_filter. В коде метрики нужно заменить https://mc.yandex.ru/ на /proxy-yandex/

Для того, чтобы все заработало, добавляем содержимое файла в секцию server в конфиге nginx нужного хоста. В конфиг внесено два хоста mc.yandex.ru и mc.yandex.com, однако в разных странах подключение может производиться с региональных доменов, например mc.yandex.md, поэтому проверяйте и вносите необходимые домены в конфиг по такому же шаблону. Например: sub_filter 'mc.yandex.md' "$host/proxy-yandex";

🧩 Конфиг nginx

⚠️ По этой же схеме можно проксировать и другие внешние скрипты через свой домен для ускорения их загрузки и инициализации.

💬 Если есть вопросы или идеи по улучшению - пишите в комментарии.

🙈 Я продолжаю каждый день сталкиваться с сайтами, где стандартный функционал браузера реализуют на JavaScript. Наверное можно даже рубрику #nojs сделать. Сегодня рассмотрим возможность закрепления блоков при скролле на чистом css.

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

В CSS уже достаточно давно появилось свойство position: sticky. Указываете его для элемента и позиционируете при помощи inset (top right bottom left) для закрепления. Закреплять можно сверху, снизу, слева и справа. Можно даже по двум осям.

Если вы сомневаетесь, можно ли использовать это решение - смотрите поддержку. На момент написания 96,58%.

✅ Пример на Codepen

💬 Знали вы о таком свойстве? Используете в работе? Пишите в комментарии.

Ворчанье деда

Нас больше 1000. Спасибо вам!

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

Почему все острее стоит проблема быстродействия сайтов и веб-приложений? Потому что все меньше внимания уделяется этому вопросу. Быстрый интернет и быстрые процессоры позволяют совсем расслабиться. Но проблема ещё и в самих разработчиках: уже изначально, при входе в профессию, учат не языки, а фреймворки: react, vue, angular. Это крутые инструменты, против них ничего не имею, но если человек не знает как работает JavaScript, то и использовать фреймворки он будет так же.

Я много общаюсь и знаю, что многие разработчики понимают важность быстродействия, но часто проблема системная, и в одиночку с ней не справиться. Например, маркетологи ставят задачу ускорить сайт и одновременно подключить 4 сторонних сервиса для "увеличения конверсии", которые наглухо блокируют основной поток на 4-6 секунд. 🤦‍♂️

Непонимание языка или лень?

Библиотека для вычисления разницы между двумя датами. Серьезно? Это одна функция с совсем простой математикой. Зачем подключать библиотеку на 200 кб? Просто потому что торопился. Да, эта библиотека решает необходимую задачу, и еще 400 других, которые не нужны. Отсюда мы и получаем предупреждение Lighthouse о неиспользуемом коде. Хорошо еще, если используется система сборки и импорт происходит не всей библиотеки, а только необходимой части. Но это скорее исключение из правил. Ведь в Examples этой библиотеки был пример только с полным импортом, так ведь?

Непонимание проблемы производительности.

"8 мегабайт картинка? Ну, у меня за секунду загрузилась на моем гигабитном интернете по проводу, если у вас медленно, значит проблема на вашей стороне." Нет. Картинку можно и нужно сжимать, готовить к публикации. Если с сайтом работают неподготовленные люди, то это должно происходить без их вмешательства. Тоже касается и 8 мб js на странице. Четыре разных слайдера на разных библиотеках, только потому что в примерах один свайпится тачем, а второй по таймеру. Так и хочется процитировать классика "Астанавитесь!". Не у всех такой компьютер как у разработчика. У большинства пользователей будут устройства медленнее чем у разработчика. Это нормально. И даже рост вычислительной мощности процессоров не должен позволять забывать об оптимизации. Даже если это временное решение, то техдолг растёт и со временем становится неуправляемым.

Сложность алгоритмов.

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

‼️ Важно: Я НЕ призываю отказываться от готовых библиотек - это нерационально писать велосипеды. Я призываю вдумчиво анализировать что подключается и используется на сайте.

💬 У меня все. Пишите, что думаете по этому поводу в комменты.

❗️ Сегодня рассмотрим еще одно интересное #nojs решение.

Все видели в интернет-магазинах переключение превью изображений при движении курсором мыши по фотографии товара влево и вправо? Интересный и уже достаточно привычный функционал. Но как его реализуют? На JS вычисляют положение мыши и выполняют переключение активного изображения в зависимости от ее координат. В результате на странице списка товаров стоит несколько десятков таких прослушивателей. Далее математика для вычисления того, какую картинку показать и в конце-концов действие с добавлением класса, которое вызывает перерисовку.

Сейчас мы сделаем на чистом CSS без полной перерисовки DOM. Думаю смысла нет рассказывать как стилизуем карточку, расскажу лишь про механизм работы. Все изображения в нашем случае это div с классом thumb спозиционированы относительно родителя и находятся друг под другом. Перед ними находятся пустые элементы с классом place, при наведении на которые мы меняем opacity следющего за ним элемента.

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

✅ Пример на Codepen

💬 Если есть идеи по улучшению - пишите в комментарии.

❗️ Сегодня речь пойдет о так называемом Critical CSS - небольшой хитрости для ускорения первой отрисовки (#fcp, #lcp) страницы и устранению её блокировки файлами стилей. Если у вас FCP больше 1.5 сек, то определенно стоит озадачиться.

Как обычно выглядит проект в конечном виде - HTML, в котором подключаются файлы стилей. Так вот, отрисовка страницы не начнется, пока все файлы стилей не будут загружены и прочитаны. Находятся умельцы, которые файлы стилей переносят из head куда-нибудь перед </body> и первая отрисовка становится почти мгновенной, но сначала мы видим страницу без стилей, а затем перерисовка и огромный CLS.

Чтобы этого избежать, стили, необходимые для отрисовки первого экрана нужно поместить в код страницы в тег <style>. Тогда прыгать контент не будет, и эти стили применятся к странице сразу же. Остальные стили при таком формате нужно подключать в <head> сайта, но чтобы они загрузились как можно быстрее и не блокировали отрисовку. Для этого отлично подходит небольшой лайфхак:

<link rel="preload" as="style" href="style.css" onload="this.onload=null;this.rel='stylesheet'">

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

Чтобы выделить Critical-CSS, лучше выполнять верстку покомпонентно, как в современных фреймворках, и управлять вручную теми стилями, которые попадут inline, или использовать инструменты для выделения критических стилей для текущей страницы, например плагин для вебпака, и отдельные приложения для экстракции стилей с готовой верстки critical.

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

💬 А вы используете Critical-CSS?

❗️ При загрузке контента одна из важных метрик - это #fcp - первая отрисовка контента. Это чаще всего элементы интерфейса, или текст. Для пользователя комфортнее, если отрисовка начнется раньше.

Как оценивается показатель FCP:

🟢 Зеленая зона: до 1.8 секунды
🟡 Желтая зона: от 1.8 секунд до 3 секунд
🔴 Красная зона: более 3 секунд

Давайте разбираться, как улучшить этот показатель и какие частые ошибки можно встретить.

1. В <head> загружается слишком много стилей или js файлов. Помните, что стили и скрипты без async и defer блокируют первую отрисовку до момент пока не будут загружены и выполнены подключаемые файлы. Оставляйте там только то, что необходимо для первой отрисовки

2. Нет критических стилей, о которых мы писали вчера. Используйте их, это хорошо для первой отрисовки.

3. Шрифты используются без font-display:swap|optional или того хуже с Google Fonts. Не используйте Google Fonts. Такую ошибку можно часто встретить там, где первый экран на белом фоне, и нет основных элементов интерфейса. Пока шрифты не загрузятся у пользователя будет просто белый экран, хотя началась отрисовка уже второго и третьего блоков.

4. В <head> подключаются стили или скрипты со сторонних доменов, что может съедать 500-600 миллисекунд на установку соединения. Если подключений больше, то задержка может стать еще больше. Если нельзя перенести стили или скрипты на свой домен, проксируйте тем же способом, как мы предлагали проксировать яндекс-метрику.

⚠️ В Lighthouse есть аудит "Старайтесь не допускать создания цепочек критических запросов". Как раз тут нужно следить, чтобы цепочка была как можно короче, и там ни в коем случае не было внешних сервисов и поддоменов. Отличный аудит - один из самых полезных при отладке FCP.

💬 А как у вас дела с первой отрисовкой?

❗️ Сегодня расскажу об интересной технологии, которую можно использовать вместо безвременно почивших HTTP/2 Server Push. Напомню, раньше была возможность при помощи веб-сервера вместе со страницей отправить сразу нужные ресурсы, которые подгружаются на этой странице, но Google удалил поддержку из Google Chrome. А как же хорошо они работали вместе HTTP 103 Early Hints!

HTTP 103 Early Hints - это другая и тоже интересная на мой взгляд технология. Вместо проталкивания указанных ресурсов, как это делал Push, сервер отдает два ответа. Первый моментально 103 Early Hints с HTTP заголовками, например preconnect или preload, и затем второй как обычно 200. Это позволяет начать загрузку ресурсов еще до момента, когда поступит настоящий полный ответ сервера с содержимым. В отличии от Server Push здесь не будет передачи лишних байт, если стили были закэшированы, браузер возьмет их из кэша. Во-вторых, пока происходит генерация даже какой-то тяжелой страницы, браузер может уже начать загрузку критичной статики.

🧩 Как использовать: Поддержки в ядре nginx пока нет, поэтому только собирать сторонние модули к нему. Поддержка apache2 есть, но при проксировании через nginx может не работать. Опробовать как это работает можно через CloudFlare, включив нужную галочку. Попробовать точно стоит, если ttfb больше 200 мс, ускорение может быть очень заметным. Для того, чтобы заработало, передавайте заголовки серверу из своего приложения. Браузерная поддержка есть пока только в свежем Google Chrome, но думаю, другие браузеры быстро подтянуться.

Например в php <?php header('Link: </style.css>; rel=preload; as=style');?>

💬 А вы слышали про 103 Early Hints?

❗️ Необычный #lifehack позволит ускорить постраничную навигацию, например в большом интернет магазине. На странице 20 товаров. Показ следующей страницы происходит после нажатия на кнопку "показать еще". Ответ от сервера приходит за 300 миллисекунд, значит до времени показа следующей страницы будет задержка не меньше этой цифры. Показатель INP на этой странице вырастет, и сайт станет менее отзывчивым.

Давайте для начала поймем, что мы хотим получить? Ускорить ответ сервера, используя кэш? А зачем? Нам нужно только показать следующую страницу быстрее. Давайте разбираться, какие еще есть варианты.

Можно загрузить следующую страницу в фоне, когда пользователь проскроллит например 50% от всех вариантов, и скрыть их до момента нажатия кнопки "показать еще". После нажатия кнопки показываем скрытые элементы и выполняем следующий запрос. После нажатия мгновенно отображается следующая страница, пока изучаем варианты грузится следующая. Быстрее приложение по факту не стало, но мы отдаем результат с точки зрения пользователей мгновенно. Задача решена.

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

💬 Что вы думаете о таком подходе? Использовали когда-то подобные фишки? Пишите свои варианты подобных механик.