Две световые шкалы с разными показаниями: лабораторный замер против полевого

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

PageSpeed показал 70, реальные пользователи — 84. Разбираем на живом проекте, почему лаборатория и поле расходятся вдвое, какому замеру верить и почему средний балл по сайту прячет именно ту страницу, которая приносит деньги.

Fedir AlpatovFedir Alpatov· Founder & Tech Lead31 авг 20268 мин чтения

Скорость загрузки сайта — та метрика, из-за которой спорят чаще всего. Подрядчик показывает зелёный отчёт, клиент открывает PageSpeed и видит семьдесят. Оба правы, и ниже — разбор на живом проекте, где разница между двумя замерами составила больше чем вдвое.

Два замера одного сайта, разница вдвое

Проект — сайт производителя сухого льда. Мы замерили его дважды: лабораторным прогоном PageSpeed Insights и полевыми данными Microsoft Clarity по 357 реальным просмотрам за 30 дней.

МетрикаЛаборатория (PageSpeed)Поле (реальные пользователи)
Общий балл7084
LCP (самый большой элемент)5,4 с2,5 с
CLS (сдвиг макета)00,001
INP (отклик на действие)TBT 410 мс250 мс
Распределениеодин прогон75,4% good · 23% needs · 1,7% poor

Разрыв в LCP — 5,4 против 2,5 секунды. Если бы мы принимали решения только по лаборатории, мы бы переписывали сайт, который в реальности почти укладывается в зелёную зону Google (порог «хорошо» для LCP — 2,5 с).

Почему лаборатория показывает хуже

PageSpeed Insights не меряет ваш сайт у вашей аудитории. Он прогоняет его в фиксированных условиях:

  • эмуляция сети Slow 4G с искусственной задержкой;
  • процессор, замедленный в четыре раза, — модель Moto G Power, а не тот телефон, с которого заходят ваши клиенты;
  • один холодный прогон без кеша, без повторных визитов;
  • сервер Google, а не украинская сеть, из которой идёт 89% трафика этого проекта.

Это не ошибка инструмента, а его назначение: лаборатория намеренно ставит жёсткие условия, чтобы проблемы было видно. Но «жёсткие условия» и «условия ваших клиентов» — разные вещи, и путать их дорого.

Самая дорогая ошибка: смотреть на средний балл

84 балла в среднем по сайту выглядят спокойно. Раскладка по страницам выглядит иначе — и именно там прячутся деньги.

СтраницаБаллLCPCLS
Товар «сухой лёд 3 мм, 50 кг»433,3 с0,6
Страница города (Запорожье)621,7 с0,035
Страница применения653,3 с0,6
Страница города (Днепр)950,82 с0
Доставка93

Страница с 43 баллами и сдвигом макета 0,6 — это самый популярный товар на сайте: 164 просмотра за месяц, первое место среди всех товаров. То есть худшая страница по скорости оказалась лучшей по спросу. Средний балл 84 эту проблему полностью прячет.

Правило простое: смотрите скорость на тех страницах, которые приносят деньги, а не в среднем по больнице. Что именно означают LCP, INP и CLS — разобрали отдельно в словаре Core Web Vitals.

Три попытки ускорить, которые сделали хуже

Самое полезное в этом проекте — не то, что сработало, а то, что не сработало. Все три случая откачены и зафиксированы в коммитах.

  1. `priority` на картинках первого экрана ухудшил LCP с 5,4 до 9,4 секунды. Атрибут `priority` в Next.js добавляет preload, и три декоративных изображения по 185 КБ забили канал раньше, чем загрузились CSS и шрифты. На быстром Wi-Fi разницы не видно, на медленном 4G — катастрофа.
  2. Снижение `quality` не сжало картинку. Вес держал альфа-канал, а не качество. Сработало другое: пересохранение с 1624 до 1012 пикселей (реальный размер отображения) и палитра на 128 цветов с дизерингом — 96 КБ стали 33 КБ.
  3. `preload: false` на шрифте дал регресс LCP и добавил сдвиг макета, которого до этого не было. Тоже откат.

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

Как мерить правильно

  1. Возьмите полевые данные. Google CrUX, если трафика достаточно; Microsoft Clarity — если нет. Clarity бесплатна и показывает CWV по каждому URL.
  2. Посмотрите раскладку по страницам, а не среднее. Худшая страница с высоким спросом — ваш приоритет номер один.
  3. Лабораторию используйте для диагностики. PageSpeed хорошо отвечает на вопрос «из-за чего именно медленно», и плохо — на вопрос «насколько медленно на самом деле».
  4. Смотрите на распределение, а не на балл. «75% good, 23% needs improvement, 2% poor» информативнее, чем «84 из 100».
  5. Мерьте до и после каждой правки. Три примера выше показывают, почему.

Сколько стоит ускорить сайт

Разбор скорости входит в аудит сайта за $150: мы смотрим полевые данные по каждой странице, находим, что именно держит LCP, и даём список правок с оценкой часов. Внедрение — $40/час или в рамках поддержки за $200/мес. Если сайт делаем мы, скорость закладывается в разработку: LCP до 2,5 с на мобильном — условие сдачи, а не пожелание.

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

Частые вопросы

Какая скорость загрузки сайта считается нормальной?
Ориентир Google — LCP до 2,5 секунды на мобильном: это порог «хорошо». До 4 секунд — «требует улучшения», дальше — «плохо». Но мерить надо на реальных пользователях: в примере выше лабораторный прогон давал 5,4 с, а живые люди видели 2,5 с на том же сайте.
Почему PageSpeed показывает 70, а на самом деле сайт быстрый?
Потому что PageSpeed намеренно тестирует в плохих условиях: эмуляция Slow 4G, процессор, замедленный вчетверо, холодный прогон без кеша. Это диагностический инструмент, а не измерительный. Реальную картину дают полевые данные — CrUX у Google или бесплатная Microsoft Clarity.
Что важнее — LCP или INP?
Зависит от типа сайта. Для страницы, которую читают (статья, лендинг, карточка товара), критичен LCP: человек ждёт, пока появится основной контент. Для интерфейса, с которым взаимодействуют (фильтры каталога, кабинет, корзина), критичен INP: человек нажимает и ждёт реакции. На сайте из примера INP 250 мс при норме 200 мс — это как раз фильтры каталога.
Сколько стоит ускорить сайт?
Разбор с перечнем правок — $150 в составе аудита. Внедрение — $40/час или в рамках поддержки $200/мес. Сколько часов уйдёт, зависит от платформы: на кастомном коде это обычно несколько часов, на WordPress с тяжёлой темой и плагинами — десятки, и потолок всё равно ниже.
Влияет ли скорость на позиции в Google?
Влияет, но слабее, чем принято думать. Core Web Vitals — фактор ранжирования, но один из многих, и релевантный контент на медленной странице обгонит быструю страницу не по теме. Реальная цена медленности — не позиции, а отказы: человек закрывает вкладку до того, как увидит ваш первый экран.

Обсудить свой проект?

Оставьте контакт — ответим в течение 4 рабочих часов. Без спама и скриптов продаж.