Скорость сайта: что реально влияет на заявки

Три метрики, а не «баллы Лайтхауса»

Общая оценка в инструментах проверки — производная величина. Смотреть нужно на Core Web Vitals: три показателя, которые описывают три разных ощущения пользователя. Долго ли ждать содержимого, отзывается ли страница на нажатие и не прыгает ли вёрстка под пальцем.

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

LCP: почему главный блок появляется поздно

LCP почти всегда упирается в одно из четырёх. Разбирать нужно именно в этом порядке — от самого частого к самому редкому.

• Тяжёлая картинка первого экрана: несжатая, без современного формата, без нужных размеров. Самая частая причина и самая дешёвая в исправлении.
• Шрифты: файл грузится, текст ждёт. Лечится подмножеством символов, предзагрузкой и корректным font-display.
• Блокирующие скрипты в head: аналитика, виджеты чатов, пиксели. Каждый из них задерживает отрисовку.
• Медленный ответ сервера. Если первый байт идёт дольше полусекунды, оптимизация картинок уже ничего не спасёт.

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

INP: «сайт тормозит, когда нажимаешь»

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

• Уберите со страницы всё, что вы не готовы защитить: чаты, попапы, счётчики, оставшиеся от прошлого подрядчика.
• Разгрузите обработчики: длинные вычисления разбиваются на части, слушатели прокрутки делаются пассивными.
• Анимируйте только transform и opacity: они не заставляют браузер пересчитывать раскладку.
• Проверяйте на слабом устройстве. Разница между флагманом и бюджетным телефоном — это разница между 90 мс и 400 мс.

CLS: прыгающая вёрстка

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

• У каждой картинки заданы ширина и высота либо явное соотношение сторон.
• Под баннеры, виджеты и рекламные блоки место зарезервировано до их загрузки.
• Шрифт-подмена подобрана так, чтобы запасное начертание занимало примерно ту же ширину.
• Ничего не вставляется над уже отрисованным содержимым после загрузки.

Порядок работ

Порядок важнее списка. Он устроен так, чтобы каждый следующий шаг был дешевле предыдущего по соотношению «эффект к трудозатратам».

• Снять полевые данные и понять, какая из трёх метрик действительно проседает.
• Починить картинки первого экрана: формат, сжатие, размеры, приоритет загрузки.
• Разобраться со сторонними скриптами: убрать лишние, остальные загрузить отложенно.
• Привести в порядок шрифты: подмножество символов, предзагрузка, корректная подмена.
• Заняться временем ответа сервера: кэш, серверный рендер, статическая генерация.
• Закрыть смещения: размеры изображений и зарезервированное место.
• Перемерить и остановиться, когда метрики в зелёной зоне. Дальше начинается вылизывание ради отчёта.

Чего скорость не чинит

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

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