Скорость сайта и PageSpeed: что измеряют и как ускорить страницы

Что такое скорость сайта и почему это не одна цифра?

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

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

PageSpeed Insights показывает оба. Как объясняет справка сервиса, лабораторные данные собирают в контролируемой среде, поэтому по ним удобно искать причины, но реальные узкие места они могут пропустить. Полевые данные берутся из отчёта Chrome User Experience Report за предыдущие 28 дней и описывают настоящих посетителей. Если у страницы мало визитов, сервис покажет данные по всему сайту, а иногда не покажет их совсем.

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

Три показателя, по которым Google оценивает страницу

Из десятков метрик Google выбрал три и назвал их Core Web Vitals. Каждая отвечает на вопрос, который задал бы посетитель. LCP: когда я увижу главное? CLS: перестанет ли страница прыгать под пальцем? INP: отреагирует ли она, когда я нажму? Остальные показатели, вроде FCP и TTFB, помогают найти причину, но оценку страницы определяют эти три.

LCP считают от начала загрузки до момента, когда в видимой области появился наибольший блок: картинка или заголовок. В руководстве web.dev норма сформулирована для реальных посетителей: 2,5 секунды или быстрее как минимум для 75% визитов. Одна медленная загрузка на ноутбуке разработчика картины не меняет.

Сдвиги макета раздражают сильнее, чем кажется. Команда новостей Yahoo! JAPAN заметила, что на странице статьи текст уезжает вниз, когда догружается главное изображение. Инженеры зарезервировали под картинку место заранее, взяв соотношение сторон из внутреннего API. CLS упал примерно с 0,2 почти до нуля, число проблемных адресов в Search Console сократилось на 98%, а просмотров страниц за сеанс стало на 15% больше.

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

Оценку «пройдена» страница получает по строгому правилу. Согласно справке PageSpeed Insights, нужно, чтобы 75-й процентиль всех трёх метрик попал в зелёную зону. Это значит, что четверть визитов может быть хуже, а один красный показатель перечёркивает два зелёных. Смотрите на медленный хвост посетителей, а не на среднее, которое всегда выглядит лучше.

Сколько стоит медленная страница в деньгах?

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

Vodafone провёл именно такой эксперимент: одну посадочную страницу показывали двум половинам платного трафика, и в версии A оптимизировали LCP. Виджет стали отрисовывать на сервере, главное изображение уменьшили, блокирующий JavaScript убрали. LCP улучшился на 31%, и продажи выросли на 8%, переходы от лидов к посещениям на 15%, а из корзины на 11%.

Renault выбрал наблюдение вместо теста. Команда отправляла веб-метрики в Google Analytics и за четыре месяца собрала более 10 миллионов визитов в 33 странах. В разборе Renault видно: чем ниже LCP, тем меньше отказов и больше заполненных форм, а улучшение LCP на секунду соответствовало снижению отказов на 14 процентных пунктов и росту конверсий на 13%.

Для поискового трафика пример есть тоже. Магазин Nykaa улучшил LCP на 40%, и органический трафик из городов второго и третьего эшелона вырос на 28%. Это не доказывает, что скорость двигает позиции сама по себе, но показывает, что быстрая страница удерживает людей, пришедших из поиска.

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

Как читать отчёт PageSpeed Insights

Начинайте с блока реальных пользователей, круг с баллом оставьте на потом. Руководство web.dev советует: если для сайта есть данные CrUX, всегда в первую очередь смотрите на них, а лабораторный отчёт берите для поиска причин.

Балл от 0 до 100 считает Lighthouse: от 90 хорошо, от 50 до 89 есть что улучшать, ниже 50 плохо. Мобильный балл почти всегда ниже настольного, и важнее именно он: по данным, которые приводит Ingate, больше 60% трафика в России идёт с мобильных устройств. Сам балл не цель: сайт с 72 баллами и зелёными LCP и CLS может работать лучше, чем сайт с 85 баллами и красным INP.

Агентство Ingate приводит пример интернет-магазина бытовой техники на популярной CMS. Мобильный балл 38 и LCP 6,8 секунды после трёх итераций (WebP, отложенная загрузка картинок, минификация JS и сжатие Gzip) превратились в 74 балла и LCP 2,3 секунды. За три месяца органический трафик вырос на 22%, а конверсия из мобильного поиска на 11%. Это рассказ агентства о своём клиенте, поэтому вклад скорости отдельно от других работ он не доказывает.

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

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

Куда уходят секунды и что исправлять первым

Частая ошибка: сразу сжимать картинки. Время LCP складывается из четырёх частей: ожидание ответа сервера, задержка до начала загрузки главного ресурса, сама загрузка и задержка до отрисовки. Оптимизировать нужно все четыре, иначе выигрыш просто переедет из одной части в другую.

Руководство web.dev показывает это на примере: файл изображения сжали сильнее и перевели в WebP, загрузка ресурса сократилась, но LCP не улучшился. Элемент оставался скрыт, пока не загрузится JavaScript, и время перешло в задержку отрисовки. Две части из четырёх называются задержками, и их нужно сводить к нулю.

Из этого следует порядок работ. Сначала выясняют, какой элемент считается LCP, и только потом лечат именно его. Если это картинка, она не должна грузиться лениво: отложенная загрузка откладывает и главное изображение. Правильнее указать браузеру высокий приоритет для одного-двух ключевых ресурсов: если выделить все подряд, выделение перестаёт работать.

1. Найдите элемент LCP в отчёте и посмотрите, на какую из четырёх частей уходит больше всего времени.
2. Дайте главному изображению нужный размер и высокий приоритет, а все картинки ниже первого экрана загружайте лениво.
3. Укажите ширину и высоту у картинок и видео: так браузер резервирует место и CLS не растёт.
4. Отложите чаты, пиксели и виджеты: сторонние скрипты не нужны до первого действия посетителя, и их можно грузить асинхронно.
5. Если ответ сервера дольше 800 мс, смотрите на хостинг, кэш и CDN, а не на код страницы.

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

Пример из маркетплейсов. Маркетплейс Tokopedia улучшил LCP на 55% и увеличил среднюю длительность сеанса на 23%. Команда отрисовывала элемент LCP на сервере, загружала его заранее и оптимизировала изображения: сжатие, WebP, отложенная загрузка неважных картинок. Попутно она собрала панель мониторинга, чтобы видеть влияние работ разных команд.

Как удержать результат после ускорения

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

Сервис Redbus сначала исправил слоты для компонентов страницы и убрал неоптимизированные скрипты вставки тегов: CLS снизился с 1,65 до нуля. Затем оптимизировали сторонние скрипты, и время до интерактивности сократилось с 8 до 4 секунд. По итогам мобильная конверсия выросла на 80-100 процентов, а команда закрепила культуру производительности, чтобы предотвратить откаты.

Сервис iCook решал похожую задачу для рекламы: сделал размеры рекламных блоков фиксированными и отложил некритичный JavaScript. CLS улучшился на 15%, и рекламный доход вырос на 10%, хотя заполняемость блоков могла снизиться, ведь реклама стала лучше видна.

Технический руководитель Renault Седрик Базюро формулирует правило коротко:

Производительность требует постоянного мониторинга

Седрик Базюро, технический руководитель Renault, в разборе на web.dev

На практике это три привычки. Измеряйте реальных пользователей постоянно, раз после релиза мало. Проверяйте крупные правки на половине трафика, как это сделал Vodafone: подробнее о такой механике в разборе A/B-тестов. Перед каждым новым скриптом через тег-менеджер спрашивайте, что он стоит в миллисекундах.

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

Чем измерять скорость в России?

Одного инструмента мало. Эксперты Ingate советуют минимум два: PageSpeed Insights, чтобы увидеть картину глазами Google, и Яндекс Вебмастер, чтобы узнать, что думает Яндекс. WebPageTest подключают, когда нужен диагноз: его водопад запросов находит конкретный ресурс, который блокирует отрисовку.

Для реальных посетителей есть отчёт Метрики. По инструкции Skobeeff, он лежит в разделе «Мониторинг» и называется «Время загрузки страниц». Он полезен тем, что показывает неровности: главная может открываться быстро, а каталог или карточка товара тормозить только у части аудитории.

• PageSpeed Insights: бесплатный отчёт с реальными данными и рекомендациями, регистрация не нужна.
• Lighthouse в Chrome DevTools: локальная проверка, подходит для страниц на тестовом стенде.
• Метрика и Вебмастер: поведение реальных посетителей и взгляд Яндекса.
• WebPageTest и Ping-Admin: диагностика загрузки и замеры из российских городов.

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

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