Сайт грузится медленно: как это проверить и что даёт ускорение

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

Именно эти три момента и описывают Core Web Vitals — набор показателей, по которым Google и, косвенно, Яндекс оценивают, комфортно ли людям на странице. Ценность этой группы метрик не в самих аббревиатурах, а в том, что каждая из них соответствует конкретной претензии живого человека. Поэтому дальше мы разбираем их именно так: что за ощущение стоит за каждой цифрой.

LCP (Largest Contentful Paint) — момент, когда в видимой части экрана отрисовался самый крупный элемент: обычно это фотография первого экрана или крупный заголовок. Для посетителя это ответ на вопрос «я уже понял, куда попал?». Хороший ориентир — до 2,5 секунды на мобильном. Чаще всего LCP портят два виновника: тяжёлое изображение первого экрана и медленный ответ сервера.

INP (Interaction to Next Paint) — время от нажатия до видимой реакции интерфейса. Это ровно то, что люди называют «сайт тупит»: тапнул по пункту меню, ничего не произошло, тапнул ещё раз, открылось два раза. Причина почти всегда одна — браузер занят выполнением JavaScript и физически не успевает перерисовать экран. Порог комфорта — 200 миллисекунд.

CLS (Cumulative Layout Shift) — насколько содержимое прыгает во время загрузки. Самая обидная метрика: человек уже собрался нажать «Оставить заявку», в этот момент подгрузился шрифт или виджет обратного звонка, блок сместился, и палец попал не туда. Показатель выше 0,1 — это не эстетическая придирка, а прямая потеря нажатий на кнопку.

Отдельно стоит TTFB — время до первого байта от сервера. Формально он не входит в Core Web Vitals, но проверять его надо первым: если сервер отвечает дольше 0,8 секунды, оптимизировать картинки бессмысленно, вы просто уменьшите вторую половину проблемы, не тронув первую.

Главная путаница в измерениях: одни инструменты дают лабораторные данные, другие — полевые. Лабораторные — это когда сервис запускает страницу у себя на смоделированном мобильном устройстве и медленном канале. Такой прогон удобен для поиска причины, но результат скачет от запуска к запуску. Полевые данные собираются из браузеров реальных посетителей, они инертнее и обновляются неделями, зато отвечают на вопрос «а как у моих людей».

Практический минимум для владельца сайта выглядит так. PageSpeed Insights — вбить адрес, обязательно смотреть вкладку мобильной версии и читать не общий балл, а конкретные строки с LCP, INP, CLS. Яндекс.Метрика, отчёт «Время загрузки страниц» — здесь видно распределение по вашей реальной аудитории и, что важнее, по конкретным страницам: часто выясняется, что главная быстрая, а тормозит именно каталог или страница услуги, куда идёт реклама. Яндекс.Вебмастер в разделе диагностики отдельно сообщает о проблемах с мобильной адаптацией и о медленном ответе сервера.

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

Когда мы открываем чужой сайт на диагностику, набор причин повторяется из проекта в проект. Первое место с большим отрывом — изображения. Фотография работ, выгруженная с телефона или из фотостока как есть, весит несколько мегабайт и отдаётся в исходном разрешении, хотя на экране занимает четверть ширины. Перевод в WebP и отдача под нужный размер решают это без единой правки дизайна.

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

Третье — шрифты. Два-три подключённых начертания с внешнего домена дают заметную задержку и тот самый прыжок текста, когда системный шрифт сменяется фирменным. Четвёртое — хостинг и отсутствие кеширования: сайт на самом дешёвом тарифе с непустой базой отвечает по секунде и больше, а любое обращение к странице каждый раз пересобирается заново вместо того, чтобы отдаваться из кеша.

Отдельная категория — сайты на конструкторах и коробочных CMS, куда за годы поставили полтора десятка плагинов. Каждый тянет свои стили и скрипты на всех страницах, включая те, где он не используется. Здесь ускорение — это чаще ревизия и удаление, чем добавление новых оптимизаций.

Ускорение почти никогда не требует переделки сайта. Мы начинаем с того, что даёт максимальный эффект при минимальном вмешательстве в вёрстку, и только потом обсуждаем архитектурные вещи. Первым делом — изображения и явные размеры под них: это одновременно и LCP, и CLS. Дальше ревизия сторонних скриптов: что удаляем совсем, что переносим на отложенную загрузку, что оставляем только на нужных страницах.

Следующий слой — сервер: включение сжатия и кеширования, при необходимости смена тарифа хостинга. Это единственный пункт, где иногда приходится тратить деньги ежемесячно, зато он лечит TTFB, а с ним и часть LCP. И только в конце имеет смысл заниматься тонкой работой с CSS и JavaScript — она даёт меньше всего выигрыша на рубль и требует участия разработчика.

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

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

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

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

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

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