Представим владельца интернет-магазина, который в субботу утром решил наконец проверить скорость сайта. Открыл PageSpeed Insights, вставил адрес, получил оранжевую цифру. Расстроился, нажал «Анализировать» еще раз и получил другую цифру. На сайте за эту минуту не поменялось ничего. Тут любой засомневается: то ли сайт капризный, то ли инструмент.
На самом деле ни то, ни другое. Балл действительно может меняться от запуска к запуску. В справке PageSpeed Insights этому посвящен отдельный вопрос, и звучит он почти как мысль нашего владельца: почему балл меняется, если я ничего не менял. Любопытнее другое: даже стабильная сотня не означает, что сайт быстрый для всех, кто на него приходит. Чтобы понять, почему, полезно разобраться, что именно стоит за этой цифрой.
Из чего складывается балл PageSpeed
Лабораторную часть PageSpeed Insights считает Lighthouse. По документации Chrome, это взвешенное среднее нескольких метрик, измеренных в лабораторных условиях. В Lighthouse 10 больше всего весит Total Blocking Time — 30%, по 25% у Largest Contentful Paint и Cumulative Layout Shift, по 10% у First Contentful Paint и Speed Index. Веса со временем меняются: команда Lighthouse пересматривает их по мере исследований.
Там же есть фраза, которую я бы показывала каждому, кто гонится за сотней. Идеальный балл 100 назван чрезвычайно трудным и не ожидаемым, а подъем с 99 до 100 требует примерно столько же улучшений метрик, сколько подъем с 90 до 94. Зеленая зона начинается с 90. Последние баллы стоят непропорционально дорого и мало что меняют для живого человека.
Почему же цифра прыгает? Документация перечисляет причины, к сайту почти не относящиеся: A/B-тесты и смена рекламы, изменения маршрутов интернет-трафика, разные устройства, расширения браузера, которые добавляют свой JavaScript, и даже антивирус. Поэтому документация Lighthouse советует думать о производительности как о распределении результатов, а не об одной цифре. Наш субботний владелец, получается, увидел нормальное поведение инструмента, никакого каприза тут нет. К тому же, по справке PageSpeed Insights, тест запускается в дата-центре Google в Северной Америке, Европе или Азии, а мобильная проверка имитирует телефон среднего уровня в мобильной сети. Для сайта, чьи покупатели сидят в Перми или Казани, это тоже условность.
Лабораторный тест и реальные посетители
Lighthouse запускает страницу в смоделированной среде: одно устройство, одна сеть, один заход. Это удобно, чтобы ловить проблемы до того, как их увидят люди. Но в обзоре Web Vitals на web.dev прямо сказано, что лабораторное измерение не заменяет полевое. Скорость сайта зависит от возможностей устройства, сети, других процессов на телефоне и того, как человек взаимодействует со страницей. Полную картину дают только данные реальных посетителей.
Такие данные Google собирает в Chrome User Experience Report, и именно они показываются в PageSpeed Insights в блоке о реальных пользователях: за последние 28 дней и только если по странице или сайту набралось достаточно данных. У свежей или малопосещаемой страницы этого блока может не быть вовсе. Получается, что на одной странице отчета соседствуют два разных ответа: как сайт повел себя в лаборатории и как он ведет себя у людей. Они могут не совпадать, и это нормально.
Есть и деталь, которую легко пропустить. Lighthouse загружает страницу без пользователя, поэтому не может измерить отклик на действия, то есть Interaction to Next Paint. Вместо него в лаборатории используют Total Blocking Time как косвенный показатель. Улучшение TBT может улучшить реальный отклик, а может и не сказаться на нем заметно. Кнопка «В корзину», которая задумывается на телефоне покупателя, в лабораторном балле видна только косвенно.
Загрузка, отклик и стабильность: что измеряют Core Web Vitals
Core Web Vitals — набор метрик, который Google выделил как основной для оценки впечатления от страницы. Сейчас в него входят три метрики, у каждой свой рекомендуемый порог. Largest Contentful Paint отвечает за загрузку: главный контент должен появиться в пределах 2,5 секунды. Interaction to Next Paint отвечает за отклик: хорошим считается значение до 200 миллисекунд. Cumulative Layout Shift отвечает за визуальную стабильность, то есть за то, не прыгает ли страница под пальцем, и должен быть не выше 0,1.
Оценивают их по 75-му процентилю загрузок, отдельно для мобильных и компьютеров, одиночный заход тут ничего не решает. На простом языке: хорошим результат считается, если порог выдерживают как минимум три четверти визитов. Это гораздо ближе к жизни, чем одиночный прогон, потому что учитывает и новый флагман, и старенький телефон в метро.
Важная оговорка: это методика Google. У Яндекса свои инструменты и свои рекомендации, и правила Google на него напрямую переносить не стоит. Но сама логика, когда кроме лаборатории смотрят еще и на реальных людей, полезна независимо от поисковика.
Когда цифра в отчете не совпадает с ощущениями
Если сайт в тестах выглядит неплохо, а покупатели жалуются, что на телефоне все тормозит и прыгает, начать стоит с того, что мешает людям: тяжелого первого экрана, прыгающих баннеров, медленных кнопок. А балл после этого удобно использовать как проверку, что ничего не сломалось.
Как выбирать улучшения, не гоняясь за цифрой
Мне ближе начинать с вопроса, что именно чувствует человек, а потом уже смотреть, какая метрика это описывает. Долго появляется главная картинка на первом экране — это про загрузку. Текст съезжает вниз, когда сверху догружается баннер или уведомление о cookie, и человек промахивается мимо кнопки — это про стабильность. Фильтр каталога после нажатия думает так долго, что кажется сломанным, — это про отклик. У каждой такой проблемы своя причина и своя цена исправления.
Дальше разумно смотреть на мобильную версию отдельно. На компьютере тяжелый дизайн часто прощается, на телефоне в слабой сети — нет. И тут полезно помнить, что многие тяжелые вещи на сайте добавлены сознательно: видео на первом экране, анимации, сторонние виджеты, счетчики. Убрать их ради балла можно, но иногда они нужны бизнесу больше, чем пара лишних баллов. Решение становится компромиссом, и принимать его лучше с открытыми глазами.
О сайтах на Тильде я подробнее писала в статье о SEO на Тильде, там есть раздел о скорости и Core Web Vitals. Здесь повторю только главную мысль оттуда: идеальный балл любой ценой не цель, цель — чтобы сайтом было комфортно пользоваться.
Когда балл все-таки полезен
Было бы нечестно сказать, что лабораторный балл бесполезен. Он хорошо работает как сигнализация: если после очередной доработки цифра резко упала, стоит выяснить почему, пока проблему не заметили посетители. Он удобен для сравнения версий одной страницы в одинаковых условиях. И он подсказывает направления, куда смотреть, в разделах с возможностями и диагностикой.
Плохо он работает как цель сам по себе и как аргумент в споре, чей сайт лучше. Сотня у конкурента означает, что его страница хорошо прошла один лабораторный тест. Как она ведет себя у его покупателей, по этой цифре не скажешь.
Наш субботний владелец мог бы сэкономить себе утро. Вместо того чтобы нажимать «Анализировать» до победного, достаточно было пролистать отчет ниже — к данным реальных посетителей, если они есть, — и открыть свой сайт на собственном телефоне. Иногда это самый честный тест из всех.