В рамках ежегодной конференции по интернет-маркетингу 8Р доклад Деми Мурыча, специалиста в реверс-инжиниринге и техническом SEO.
Из этого доклада вы узнаете, каким образом LightHouse оценивает производительность сайта, и что можно сделать для того, чтобы её улучшить и попасть в зелёную зону PageSpeed теста (90-100 баллов), не обладая серьёзными техническими квалификациями.
1. Что сейчас оценивает LightHouse
До 2018 все считали, насколько быстро сайт загружается (от начала до конца). Сейчас неважно, насколько быстро ваш сайт загружается. Сейчас интересует то, с какой скоростью первая область отображения формируется у пользователя на его устройстве.
Lighthouse не оценивает скорость загрузки сайта. Он оценивает возможности рендера отображения первой области. Если мы можем оценить время, за которое в первой области отображения экрана появляется что-то осмысленное, чего достаточно для взаимодействия пользователя с нашим сайтом, то это время может быть тем критерием, от которого мы отталкиваемся.
Lighthouse считывает с API браузера три важные временные метки в момент рендера:
- FCP (First Contentful Paint). Отображение чего-либо — некоторый текст, передний план, фоновые картинки, SVG, и т.д., но этого контента недостаточно для взаимодействия с пользователем.
- FMP (First Meaningful Paint). Отображение главного контента (hero elements), который может считаться ценным для пользователя.
- LCP (Largest Contetful Paint). В рамках области экрана достаточно сформировано контента для того, чтобы страница считалась законченной и сформированной.
Наша цель как оптимизаторов сделать так, чтобы все эти метки были ближе к началу момента, когда этот рендер начинается.
Таким образом, даже если сайт содержит тяжёлые картинки и может долго загружаться (3 секунды и больше), но он правильно оптимизирован с точки зрения производительности, он всё равно может попасть зелёную зону PageSpeed теста.
2. Какие метрики измеряют производительность сайта
Вот пример отчёта, который показывает, каким образом LightHouse действительно работает, а не то, что мы видим на сайте PageSpeed Insights.
Выделенные четыре области показывают, на какие моменты стоит обращать внимание в этом отчёте.
FP, FCP, FMP, LCP на шкале — это всего лишь временные метки, которые оценивают, когда что-то произошло. И чем раньше эти временные метки наступают относительно начала, тем лучше.
Все Web Vitals, о которых сейчас заявляет Google, включают те же метрики, которые существуют с 2018 года. Изменились только названия и способы их подсчёта.
Особняком стоит CLS (Cumulative Layout Shift) — эту метрику ввели совсем недавно, и самое интересное, что она не имеет никакого отношения к производительности.
CLS оценивает визуальную стабильность или то, насколько сильно «трясет» наш сайт во время загрузки его ресурсов. Например, когда у нас загружаются картинки, наш сайт начинает «прыгать» по мере загрузки изображений. Но если наш сайт свёрстан правильно, он «прыгать» не должен вообще.
Почему за эту характеристику нужно Google сказать большое спасибо? Теперь у всех людей, которые не являются техническими специалистами, есть возможность показать разработчику результат теста, где написано «плохой CLS», какая-то там страшная цифра, красный круг и «пожалуйста, исправьте». И он должен исправить, так как минимальный уровень качества вёрстки, который должен быть обеспечен, — это CLS = 0.
Подводя итог, все метрики, кроме CLS, действительно имеют некоторое отношение к производительности, а именно к тому, насколько быстро формируется первая область отображения вверху вашего сайта. А суть CLS только в том, чтобы подсчитать насколько сильно «трясет» сайт в момент загрузки его ресурсов.
3. Что снижает производительность сайта, и как это исправить?
3.1. JS, CSS, медиа
Очень простое правило для CSS: если объём вашей страницы в сжатом виде плюс объём вашего CSS-кода в сжатом виде составляет не больше 100 кБ, можно весь ваш CSS-код вставить инлайном в шапку HTML-странички. Так делать не совсем правильно, но по совокупности положительных и отрицательных факторов это решение будет самым идеальным.
Если вы переживаете, что страница увеличится ровно на объём этого CSS-кода, и что каждый раз при загрузке будет грузиться лишний код ➝ издержки на установку этого нового соединения для загрузки CSS-файла будут намного больше, чем загрузка этого лишнего кода в пределах 100 кБ сжатого вида.
Узнать объём страниц и CSS в сжатом виде можно во вкладке Network.
Медиа, аудио и звук должны загружаться отложено и только тогда, когда они действительно нужны.
JavaScript больше всего влияет на результаты. Вот основное правило, которое даст вам 100 баллов в Lighthouse:
- Всё, что загружается, не должно загружаться.
- Всё, что исполняется, не должно исполняться.
Всё, что загружается, не должно загружаться.
Одна из серьёзных проблем современного веба заключается в том, что нашим ресурсам необходимо постоянно устанавливать соединение между браузером и сервером. На эту задачу уходит очень много ресурсов.
Возьмём типичный пример: мы начинаем грузить Google Fonts стили и вставляем их себе, предполагая, что у них шикарный CDN, и они ближе всего расположены к клиенту. Но на самом деле это не так. Ваша задача: скачать шрифты локально на свой сервер, где у вас расположен проект, в CSS поменять адреса и подключить загрузку этих ресурсов локально.
Почему? Даже если у вас настроен HTTP2, запрос к локальному серверу будет намного быстрее осуществляться, чем к Google-серверу. Дело в том, что при первом запросе к вашему ресурсу фаза определения связей IP-адреса с именем вашего домена уже была пройдена. А все издержки, которые, кажется, значения не имеют, являются самыми основными издержками при загрузке какого-либо ресурса: на соединение, на резолвинг DNS, и т.д.
Всё, что исполняется, не должно исполняться.
Правило очень простое — чем меньше JavaScript-кода на момент формирования страницы выполняется, тем для вас лучше. Всё, что мы можем отложить в загрузке, должно быть отложено.
До 2014 года общий рецепт был таким: собирать все скрипты в один единственный файл. Сейчас концепция поменялась: чем больше дроблений скрипта вы можете себе позволить, тем быстрее наш проект будет загружаться. Пока один кусок скрипта будет загружаться, другой будет выполняться. Таким образом вы распределяете нагрузку между этими скриптами.
То есть если вы вдруг открываете сейчас свой проект и видите, что весь ваш JavaScript код грузится одним большим файлом, начинайте думать, как это изменить.
3.2. Iframe: YouTube, Vimeo
А вот эти вставки встречаются у всех на сайте и являются критичными для производительности вашего проекта.
Любой iframe (чаще всего это вставка YouTube плеера, Vimeo и т.д.) может просадить ваш сайт со 100 баллов до 0. Поэтому если на вашем проекте вы видите вставленный iframe, начинайте думать, как бы интегрировать и сделать то же самое, но без iframe.
В этом случае, вам поможет микроразметка Videoobject — Google её правильно понимает и правильно индексирует.
3.3. Google Tag Manager, Google Analytics и Yandex со всеми его сервисами
Этот код, который мы должны использовать на наших сайтах, написан совершенно не оптимальным образом.
Кстати, базовая точность в работе этих сервисов (Google Tag Manager, Google Analytics, Yandex) — плюс-минус 10%. Это можно заметить, если вы вставите код счётчика в начало вашей страницы, месяц покрутите, а потом вставите в конец и тоже месяц покрутите. Разница всего лишь внутри вашей страницы покажет вам плюс-минус 7% точности работы этой штуки.
Если для вас не принципиальна точность работы, а вам важно видеть только тенденцию, то задачу решить можно очень просто — поставить загрузку кода не в начало страницы. Если же вам важна точность, у вас другой путь — вам нужно отказаться от работы с подобными сервисами и формировать статистику на базе анализа своих собственных программ.
Вывод: Нужно оптимизировать и дифференцировать нагрузку, которую создают ваши скрипты, которые нагружают процессор и замедляют рендер начала первой области отображения.
4. Мифы об улучшении производительности
Часто рекомендуют: если у вас не внедрен протокол HTTP2, то для вашей производительности это нужно обязательно сделать, и будет вам счастье. Что когда вам тест пишет, что объём вашего DOM дерева превышает полторы тысячи узлов, то у вас очень большие проблемы. Что используйте векторную графику, и вы прозреете.
Давайте разберёмся, так ли это.
1. HTTP / HTTP2
HTTP2 действительно очень серьёзный прорыв по отношению к HTTP1. Когда появился HTTP2, его основным преимуществом перед HTTP1 было то, что ему для того, чтобы скачивать той или иной ресурс, не нужно было устанавливать массу соединений.
И, казалось бы, прекрасно! Давайте использовать HTTP2? Но если вы помните, как в каких-то 2000-х, мы качали фильмы, у нас были всякие download-менеджеры, которые писали нам про громаднейшее количество потоков, с которых они начинают скачивать файлы. Они устанавливали 5-10 соединений, чтобы этот файл скачать. И, казалось бы, как это может быть быстро, если у нас канал толще не стал от того, что мы 5 соединений установили. Ситуация достаточно банальная: когда у вас плохой канал, то одно подвисшее соединение не повлияет на 4 остальных соединений, которые установлены даже к тому же самому серверу.
Так вот почему HTTP2 не всегда хорош. Если ваша основная аудитория или значимая часть вашей аудитории это люди, которые загружают ваш ресурс с мобильного интернета, и качество этого интернета так себе, то скорее всего HTTP2 для вас враг, так как одно-единственное соединение, которое подвисает, приведёт к тому, что человек не увидит ваш сайт вообще. А если бы вы сидели на HTTP-соединении, то максимум, что грозило бы этому человеку — недогруз каких-то определенных ресурсов.
Сейчас традиционные рекомендации решения этих проблем заключаются в том, чтобы установить 4 HTTP2 соединения. Только разницы тогда между HTTP2 с 4 соединениями и HTTP с 4 соединениями нет никакой. Это касается именно случая оптимизации производительности.
2. Объём DOM дерева
Если вы открывали HTML-код вашего проекта, то видели, что он весь состоит из тегов. Каждый тег — это определённый узел дерева. Каждый такой узел занимает массу памяти. Чем больше таких узлов, тем больше памяти занимает ваш проект. Чем меньше памяти остаётся в устройстве, тем медленнее работает устройство.
Объём DOM дерева в 1500 узлов — это очень консервативная характеристика. Люди, которые занимаются оптимизацией всерьёз, могут сделать и на 3000, и на 5000 узлах проект, который будет работать очень быстро. Это скорее запугивание. Поэтому если вы услышите «у вас 2500 узлов, срочно сделайте так, чтобы у вас было меньше», и вы субъективно со своего телефона не испытываете с этим никаких проблем, значит, не волнуйтесь об этой цифре.
3. Векторная графика
Прекрасная штука, которая вне зависимости от разрешения демонстрирует одно и то же качество. Но у неё есть один единственный и очень большой недостаток. Для формирования этой графики используют центральный процессор. Очень часто графика подобного рода может очень сильно загрузить ваш процессор. Поэтому SVG-графика SVG-графике рознь.
Если вам кажется, что с вашей страницей стало происходить что-то неладное, что что-то подтормаживает, чаще всего тому виной самый маленький, самый примитивный на SVG файлик на 800 Байт. Казалось бы, как он может тормозить систему? А очень просто: внутри него используется определенный фильтр (а в внутри любого SVG-файла можно использовать массу фильтров от negative / positive до сглаживаний и т.д.). Так вот, единственный такой фильтр может привести к тому, что SVG-файл может тормозить всю вашу страницу.
Этот вопрос всегда нужно курировать, поскольку сейчас стало модно использовать векторную графику (и это правильно), но использовать бездумно (что неправильно).
Что почитать, чтобы правильно понять, как работает LightHouse, и сформировать достаточно квалифицированный технический анализ:
1. Особенности Google PageSpeed: улучшение оценки сайта и его рейтинга в поиске.
2. LightHouse.
Вывод
Производительность проекта не равняется скорости его загрузки. LightHouse вообще практически не интересует скорость вашей загрузки. Его интересует только временной отрезок, который проходит между началом и формированием первой области отображения.
Все метрики, которые используются LightHouse для оценки производительности сайта (кроме CLS) имеют некоторое отношение к производительности, а именно к тому, насколько быстро формируется первая область отображения вверху вашего сайта.