Фраза «наш сайт медленный» — обычно не чувство, а измеримое состояние. Что означают три метрики, на которые смотрит Google, и какая из них действительно влияет на продажи?
О скорости сайта обычно говорят в двух крайностях: либо о ней вовсе не заботятся, либо считают причиной каждой проблемы. Истина посередине. Скорость сама по себе не приносит продаж; но медлительность теряет уже пришедшего клиента. В этой статье мы объясняем метрики, на которые смотрит Google, не топя вас в куче технических терминов.
Три метрики, на которые смотрит Google
Вместе их называют Core Web Vitals. Все три измеряют реальный опыт пользователя, а не мощность сервера.
LCP — страница выглядит «наполненной»
Когда посетитель открывает страницу, за сколько на экране появляется самое большое изображение или заголовок? Человеческий глаз именно в этот момент решает, что страница «загрузилась». Порог, считающийся хорошим, — менее 2,5 секунды.
Самая частая причина: огромное изображение вверху страницы не сжато. Обложка в 4 МБ на мобильном соединении может сама по себе удвоить это время.
INP — отклик на клик
Когда вы нажимаете кнопку, за сколько страница реагирует? Открывается ли меню, или две секунды ничего не происходит? Порог, считающийся хорошим, — менее 200 миллисекунд. Эта метрика в 2024 году заменила старую метрику FID.
Самая частая причина: множество кодов отслеживания, чат-инструментов и внешних плагинов, добавленных на страницу. Каждый сам по себе мал; их сумма занимает браузер.
CLS — страница прыгает
Съезжает ли вниз текст, который вы начали читать, из-за поздно загружающейся вверху рекламы? Смещается ли кнопка как раз когда вы собираетесь кликнуть? Это мера того самого раздражающего поведения; менее 0,1 считается хорошим.
Самая частая причина: изображениям не заданы ширина и высота. Поскольку браузер не знает, сколько места займёт изображение, он сначала не оставляет промежутка, а когда изображение приходит — сдвигает всё вниз.
Какая из них действительно влияет на продажи?
Все три влияют на пользовательский опыт, но их влияние неодинаково. На практике самая решающая — LCP: если страница открывается поздно, посетитель не остаётся достаточно, чтобы проверить две другие метрики. Затем идёт INP; отсутствие отклика, особенно на шагах корзины и формы, — прямая причина отказа. А CLS вредит чувству доверия больше, чем продажам.
Вытекающий порядок приоритетов ясен: сначала время открытия, затем взаимодействие, в последнюю очередь сдвиг.
Не начинайте исправлять, не измерив
Самая дорогая ошибка в работе над скоростью — делать случайные улучшения по ощущению «медленно». Есть два отдельных типа измерения, и их нельзя путать:
- Лабораторное измерение: оценка, которую дают инструменты вроде PageSpeed Insights, имитируя стандартное устройство и соединение. Оно показывает, где проблема.
- Полевые данные: данные с устройств реальных посетителей. Google учитывает это в ранжировании. Вы видите их в разделе «Core Web Vitals» Search Console.
Лабораторная оценка может быть 95, а полевые данные — плохими: если ваши посетители приходят со старыми телефонами и слабым соединением, это нормально. Принимая решение, смотрите на полевые данные.
Первые пять шагов, работающих на большинстве сайтов
- Преобразуйте изображения в современный формат и задайте размер. Переход на WebP и отдача фото шириной 3000 пикселей в том размере, в каком оно видно на экране, часто даёт самый большой выигрыш сама по себе.
- Задайте изображениям ширину и высоту. Бо́льшая часть проблемы CLS на этом заканчивается.
- Загружайте отложенно изображения вне экрана. Но обложку вверху страницы держите вне этого; её задержка напрямую ухудшает LCP.
- Уберите плагины, которые не используете. Когда-то опробованные и брошенные инструменты аналитики продолжают оставаться на странице.
- Отдавайте шрифты локально и ограничьте их число. Три отдельных семейства шрифтов и восемь начертаний и замедляют, и рассеивают дизайн.
Когда «достаточно быстро»?
Сделать оценку 100 — не цель. Если метрики в зелёной зоне и в потоке посетителя нет заминок, дальше обычно не стоит усилий. Потратить эти усилия на контент и поток конверсии приносит больше.
Как проверить скорость сайта в Google?
Бесплатный тест скорости сайта от Google — PageSpeed Insights: вы вводите адрес страницы на pagespeed.web.dev и запускаете анализ, результат приходит отдельно для мобильных и для десктопа. В верхней части отчёта показаны данные реальных пользователей, в нижней — лабораторный тест.
Чтобы правильно прочитать результат, действуйте в таком порядке:
- Измеряйте не только главную, но и страницы, которые приносят деньги. Страницу товара, страницу услуги и лендинг, на который ведёт реклама, нужно проверять по отдельности.
- Сначала смотрите вкладку для мобильных. Если большинство посетителей приходит с телефонов, решение принимается по этому результату.
- Проверьте, есть ли в верхней части полевые данные. Для страниц с недостаточным числом посетителей этот блок остаётся пустым; в таком случае смотрят общий отчёт по сайту в Search Console.
- В нижней части прочитайте разделы «Возможности» и «Диагностика». Здесь по пунктам перечислены крупные изображения, блокирующие скрипты и неиспользуемый код.
- Повторите тест несколько раз. Лабораторная оценка немного меняется при каждом запуске; не принимайте решение по одному результату.
Отчёт Core Web Vitals в Search Console классифицирует страницы не по отдельности, а группами похожих адресов: хорошие, требующие улучшения и плохие. Это самый удобный экран, чтобы увидеть, какой шаблон проблемный.
Например, если в интернет-магазине все страницы товаров отмечены как плохие, а статьи блога как хорошие, проблема не в отдельных страницах, а в шаблоне товара. Исправление шаблона улучшает сотни страниц одновременно. После исправления в отчёте можно запустить проверку; Google подтвердит устранение проблемы по мере накопления полевых данных.
Ускорение сайта на WordPress и готовых платформах
На сайтах на готовых платформах источник медлительности чаще всего не сервер, а нагромождение темы, конструктора страниц и плагинов. Поэтому ускорение начинается с упрощения и только потом дополняется такими инструментами, как кеширование.
- Проведите инвентаризацию плагинов. Запишите, для чего нужен каждый плагин; неиспользуемые не отключайте, а удаляйте.
- Поставьте под вопрос конструктор страниц. Визуальные drag-and-drop-конструкторы генерируют много лишнего кода. Если планируется новый дизайн, можно выбрать более лёгкую структуру.
- Настройте кеширование, но не считайте его единственным решением. Кеш ускоряет ответ сервера, но не исправляет тяжёлые изображения и внешние скрипты.
- Используйте актуальную версию PHP и подходящий хостинг. Старые версии и медленнее, и несут риски безопасности.
- Пересмотрите внешние сервисы. Онлайн-чат, карты, видео и ленты соцсетей не должны загружаться, пока посетитель не начал с ними взаимодействовать.
После каждого изменения заново тестируйте те же страницы и записывайте результаты. Если вносить несколько улучшений одновременно, невозможно понять, какое из них сработало или какое что-то сломало. Настройки кеширования и минификации кода особенно часто ломают формы, корзину и шаги оплаты, поэтому эти страницы нужно дополнительно проверять вручную.
От чего зависит стоимость ускорения сайта?
Бюджет работ по скорости определяется не столько количеством страниц, сколько источником проблемы. Проблемы, вызванные изображениями и плагинами, решаются несколькими исправлениями, а проблемы темы или платформы могут потребовать частичной переделки.
При запросе предложения обсуждаются такие факторы:
- Платформа сайта и степень доработки темы
- Количество изображений и возможность пакетно изменить их размер
- Внешние сервисы, которые нельзя убрать (оплата, онлайн-запись, чаты)
- Собраны ли коды аналитики и рекламы в менеджере тегов
- Будут ли работы вестись на рабочем сайте или в тестовой среде
Иногда экономичнее не латать старую тему, а пересобрать страницы на лёгкой структуре. Для этого решения мы начинаем с замеров текущего сайта; подробности — на странице услуги веб-дизайн.
Оценивая предложения, с осторожностью относитесь к обещаниям, привязанным к одному числу, вроде «поднимем оценку выше такого-то значения». Настоящая цель — чтобы полевые данные на страницах, приносящих продажи, вошли в хороший диапазон и это улучшение не было снова испорчено последующими доработками. Для этого полезно попросить по итогам работ короткую записку о том, почему выбраны те или иные плагины, код и правила для изображений: это упростит работу всем, кто будет обновлять сайт потом.
Частые вопросы
Мой балл PageSpeed 60. Накажет ли меня Google?
Нет, такого понятия, как наказание, нет. Скорость — один из многих сигналов ранжирования и обычно далеко позади релевантности контента. Однако если два сайта равны по контенту, ожидается, что более быстрый выйдет вперёд.
Если усилить сервер, решится ли проблема скорости?
Отчасти. Сервер ускоряет первый ответ страницы; но размер изображений, шрифты и внешние коды — проблемы на стороне браузера, и более мощный сервер их не исправит.
Почему мобильный и десктопный баллы так различаются?
Мобильное измерение намеренно предполагает более слабое устройство и соединение. Если большинство ваших посетителей приходят с телефонов, учитывать нужно мобильный балл.
Почему тест скорости каждый раз показывает разный результат?
На лабораторный тест при каждом запуске влияют текущий ответ сервера, сетевые условия и скорость внешних сервисов. Поэтому оценка может колебаться на несколько пунктов. Принимая решения, ориентируйтесь на среднее по нескольким замерам и прежде всего на полевые данные.
Когда Search Console обновится после исправления скорости?
Полевые данные основаны на замерах реальных пользователей за последние 28 дней. Поэтому сделанное улучшение появится в отчёте не сразу, а постепенно, в течение нескольких недель. Кнопка проверки в Search Console всё это время ведёт мониторинг.
Может ли плагин кеширования сам по себе ускорить сайт?
Частично. Кеш позволяет быстрее отдавать страницу с сервера, но крупные изображения, избыток шрифтов и внешние скрипты продолжают замедлять сайт на стороне браузера. Лучший результат даёт сочетание кеширования с упрощением.
