Разговор о скорости чаще всего начинается со скриншота PageSpeed Insights: красный балл, список рекомендаций на три экрана, подрядчик предлагает «оптимизацию» по фиксированной цене. При этом никто не проверил, теряет ли сайт заявки из-за скорости. Ниже — как мы отделяем реальные проблемы от косметики: какие данные брать, с какими порогами сравнивать и в каком порядке чинить.
Откуда брать данные: лаборатория и реальные пользователи
Инструменты измерения скорости делятся на два класса. Лабораторные (Lighthouse внутри PageSpeed Insights, вкладка Performance в браузере) загружают страницу в эмуляции и дают воспроизводимый результат, но на условном устройстве и условной сети. Полевые данные собираются с реальных посетителей: у Google это отчёт Chrome UX Report, который показывается в верхней части PageSpeed Insights, у Яндекса — отчёт о времени загрузки страниц в Метрике.
Решения принимаем по полевым данным: именно на них опирается Google при оценке страницы, и именно они описывают опыт вашего посетителя, а не тестового робота. Лабораторный отчёт нужен для диагностики: он показывает, что именно грузится долго и почему.
Google оценивает три показателя Core Web Vitals, и для каждого есть опубликованные пороги. Оценка ставится по 75-му процентилю: сайт считается быстрым, если у трёх четвертей посещений показатель в зелёной зоне.
| Метрика | Что измеряет | Хорошо | Плохо |
|---|---|---|---|
| LCP (Largest Contentful Paint) | Когда отрисовался самый крупный элемент первого экрана | до 2,5 с | более 4 с |
| INP (Interaction to Next Paint) | Задержка реакции на клики и ввод за весь визит | до 200 мс | более 500 мс |
| CLS (Cumulative Layout Shift) | Насколько «прыгает» вёрстка во время загрузки | до 0,1 | более 0,25 |
Яндекс порогов в духе Core Web Vitals не публикует, но логика та же: оценка строится на данных реальных посетителей, а не на балле синтетического теста. В Яндекс Метрике отчёт о времени загрузки можно разрезать по типу устройства, браузеру и странице — это первый инструмент, в который мы заходим, когда клиент говорит, что сайт медленный.
Честные пороги: когда скорость действительно мешает заявкам
Балл PageSpeed — не бизнес-метрика. Сайт с баллом 45 на мобильных может стабильно приносить заявки, а сайт с баллом 95 — не приносить ничего. Поэтому вопрос «проблема или нет» мы проверяем по трём признакам, и нужно, чтобы совпали хотя бы два.
- Полевые данные по мобильным в красной или жёлтой зоне по LCP или INP. Десктоп смотрим отдельно: в большинстве ниш основной трафик мобильный, и именно там сайт медленнее.
- В Метрике посещения с долгой загрузкой конвертируются заметно хуже остальных. Сравниваем CR по сегментам «время загрузки до 3 секунд» и «более 5 секунд» на одних и тех же страницах; если разницы нет, скорость вряд ли главная причина потерь.
- Доля отказов на посадочных страницах рекламы выше, чем на тех же страницах из органического трафика. Рекламный посетитель менее терпелив и быстрее уходит, пока страница грузится.
Отдельно смотрим на разброс. Если средний LCP приличный, а на пятой части посещений страница грузится по 8–10 секунд, проблема в конкретном сегменте: старые Android-устройства, определённый регион, одна тяжёлая страница каталога. Чинить нужно его, а не весь сайт.
Правильный вопрос не «насколько быстрый у нас сайт», а «сколько заявок мы теряем из-за того, что он медленный». Если ответ — «неизвестно», сначала нужны данные, а не подрядчик по ускорению.
Условный пример: посадочная страница получает 3 000 посещений в месяц с рекламы, конверсия в заявку у посетителей с быстрой загрузкой — 4 %, у посетителей с медленной — 2 %, медленных посещений треть. Потери — около 20 заявок в месяц. Теперь у задачи есть цена, и её можно сравнить со стоимостью работ.
Что реально ускоряет сайт: порядок правок
Правки ниже выстроены по соотношению эффекта к трудозатратам. В большинстве проектов первые четыре пункта дают основной прирост, остальные — доводка.
- Ответ сервера. Если время до первого байта (TTFB) стабильно больше 0,6–0,8 секунды, никакая оптимизация фронтенда не спасёт. Причины обычно в отсутствии кэширования страниц на CMS, перегруженном общем хостинге или тяжёлых запросах к базе. Включение серверного кэша — самая дешёвая правка с самым заметным эффектом.
- Изображения. Фото в исходном разрешении 4 000 пикселей, вставленное в блок шириной 400, — типичная причина плохого LCP. Нужны современные форматы (WebP или AVIF), размеры под реальные блоки, отложенная загрузка всего, что ниже первого экрана, и приоритетная загрузка главного изображения первого экрана.
- Сторонние скрипты. Чат, виджет обратного звонка, пиксели рекламных систем, карты, видео с хостинга, несколько систем аналитики — каждый добавляет сотни миллисекунд и часто блокирует взаимодействие. Проводим ревизию: что действительно используется, что можно загружать после первого действия пользователя, что убрать совсем.
- Шрифты. Пять начертаний с внешнего сервиса, загружаемых до отрисовки текста, дают и задержку, и скачок вёрстки. Оставляем два-три начертания, размещаем файлы на своём домене, разрешаем показывать системный шрифт, пока грузится основной.
- Критический CSS и порядок загрузки. Стили первого экрана — встроенные в страницу, остальное — отложенно. Скрипты — в конец документа или с атрибутами отложенного выполнения.
- CDN и сжатие. Для сайтов с аудиторией по всей России раздача статики через сеть доставки сокращает задержку для удалённых регионов. Сжатие текстовых ресурсов на сервере проверяем отдельно: удивительно часто оно просто выключено.
- Вёрстка без скачков. Явные размеры для изображений, видео и рекламных блоков, чтобы контент не сдвигался при их загрузке. Это почти весь CLS.
Отдельный класс проблем — INP на сайтах с тяжёлым фронтендом: интернет-магазины с фильтрами, калькуляторы, конфигураторы. Здесь задержка возникает не при загрузке, а при каждом клике, и правится оптимизацией кода, а не картинок. Такую работу оцениваем только после профилирования конкретных взаимодействий.
Мобильные: где скорость теряется чаще всего
Почти все «быстрые» сайты, которые нам показывают, быстрые на ноутбуке разработчика по офисному Wi-Fi. Полевые данные с телефонов в мобильной сети рисуют другую картину, и причины обычно одни и те же.
- Слайдер на первом экране с пятью полноразмерными фотографиями, из которых посетитель увидит одну. Главное изображение должно быть одно, лёгкое и загружаться первым.
- Всплывающие окна и баннеры, которые появляются через секунду после загрузки и сдвигают контент. Это и CLS, и отказы: на маленьком экране окно закрывает всю страницу.
- Автоматически запускаемое видео в шапке. На десктопе выглядит эффектно, на телефоне съедает трафик и задерживает отрисовку всего остального.
- Чат и виджет обратного звонка, которые грузят свои скрипты до того, как посетитель увидел заголовок. Их можно загружать с задержкой или после первой прокрутки без потерь в обращениях.
- Десктопная вёрстка, «ужатая» под мобильный: те же тяжёлые изображения, скрытые через стили, продолжают скачиваться.
- Кнопки и формы, которые реагируют с задержкой из-за тяжёлых скриптов: посетитель нажимает дважды, отправляет две заявки или уходит.
Проверка простая и обязательная: открыть главные посадочные страницы на обычном телефоне средней ценовой категории в мобильной сети, а не на флагмане по Wi-Fi. Если за три секунды не виден заголовок и предложение, диагностика нужна независимо от того, что показывает отчёт.
Отдельно смотрим на страницы, куда ведёт реклама: в Яндекс Директе посетитель платный, и каждая секунда ожидания оплачена из бюджета. Для них порог жёстче, чем для информационных страниц, и именно с них начинается любая работа по ускорению.
Косметика: что меняет балл, но не результат
Часть рекомендаций из отчётов улучшает цифру, но ничего не меняет для посетителя и заявок. Их стоит делать, если они бесплатны, и не стоит оплачивать как отдельный проект.
- Минификация CSS и JavaScript там, где файлы и так небольшие: экономия измеряется килобайтами и миллисекундами.
- Погоня за баллом 90+ на мобильных для сайта, у которого полевые метрики уже в зелёной зоне. Дальше — убывающая отдача.
- Плагины «ускорения» для CMS, которые включают всё сразу: нередко ломают формы и скрипты аналитики, а выигрыш даёт только одна их функция — кэш.
- Переезд на другую платформу «потому что она быстрее». Медленный сайт можно собрать на любой платформе; проблема почти всегда в содержимом страниц и настройке сервера, а не в движке.
- Удаление аналитики и коллтрекинга ради скорости. Выигрыш в десятки миллисекунд против потери данных о заявках — плохой обмен.
- Оптимизация страниц, на которые нет трафика. Сначала — посадочные страницы рекламы, главная и страницы, по которым сайт находят в поиске.
Если подрядчик предлагает «комплексное ускорение» без замеров до и без прогноза эффекта на заявки, это продажа балла, а не результата.
Чек-лист перед тем, как платить за ускорение
| Симптом | Как проверить | Что делать |
|---|---|---|
| Красный балл PageSpeed, полевые данные зелёные | Сравнить блок с данными реальных пользователей и лабораторный отчёт | Ничего срочного. Правки — в фоновом режиме, без отдельного бюджета |
| Плохой LCP на мобильных | Отчёт о времени загрузки в Метрике по типу устройства, PageSpeed для главных посадочных | Сервер, изображения первого экрана, сторонние скрипты — в этом порядке |
| Долгий ответ сервера | TTFB в лабораторном отчёте и в панели разработчика браузера | Кэширование, проверка хостинга, тяжёлые запросы к базе |
| Контент прыгает при загрузке | CLS в полевых данных, визуальная проверка на телефоне | Размеры медиаблоков, шрифты, баннеры с фиксированной высотой |
| Сайт «виснет» при кликах | INP в полевых данных, профилирование взаимодействий | Оптимизация скриптов интерфейса, отказ от лишних библиотек |
| Одна страница медленнее остальных | Разрез по страницам в Метрике | Чинить конкретную страницу, не трогая остальные |
После правок обязательно сверяем полевые данные через 3–4 недели: столько накапливается статистика по реальным посещениям. Лабораторный отчёт изменится сразу, полевой — с задержкой, и только по нему можно судить об итоге. Если параллельно меняли содержимое страницы, честнее провести A/B-тест по заявкам, чем приписывать весь прирост скорости.
Как сформулировать задачу подрядчику
Если решено, что ускорять нужно, задача в договоре должна звучать как целевые полевые метрики, а не как «оптимизировать сайт». Минимальный набор пунктов:
- Исходные замеры: LCP, INP, CLS по мобильным и десктопу для списка конкретных страниц, TTFB по серверу, дата снятия.
- Целевые значения: например, LCP на посадочных страницах рекламы в зелёной зоне по полевым данным через месяц после сдачи.
- Перечень работ с приоритетами и оценкой эффекта каждой, а не общий список из автоматического отчёта.
- Что нельзя ломать: формы, цели аналитики, коллтрекинг, интеграции с CRM — проверяются после каждой итерации.
- Контроль через 3–4 недели по полевым данным как условие закрытия работ.
Такая постановка защищает обе стороны: подрядчик не отвечает за балл, на который влияют сторонние сервисы клиента, а клиент платит за измеримый результат, а не за список выполненных рекомендаций.
Коротко
- Решения принимаем по полевым данным, а не по баллу синтетического теста.
- Скорость — проблема, когда это подтверждается цифрами по заявкам, а не ощущением.
- Основной эффект дают сервер, изображения, сторонние скрипты и шрифты; остальное — доводка.
- Чиним в первую очередь посадочные страницы рекламы и страницы с поисковым трафиком.
- Результат проверяем по полевым метрикам через месяц, а не по отчёту на следующий день.
Не уверены, стоит ли платить за ускорение? В рамках аудита мы смотрим полевые метрики и конверсию по сегментам и говорим прямо, где скорость действительно мешает заявкам, а где нет.
