Интернет-магазины
Сайты
Дизайн
Поддержка
Продвижение
ИнтеграцииМедленный сайт: как читать PageSpeed Insights и выбирать исправления
Медленный первый экран, зависающий фильтр и прыгающая кнопка — три разные проблемы. Их нельзя исправить одним обещанием «довести PageSpeed до 100». Разберём два слоя отчёта, три основные метрики и заполненный план работ. Числа в учебных таблицах ниже не являются измерением activelab.by и не показывают результаты клиентов.
1. Выберите страницы и действия, которые действительно важны
Проверять только главную страницу недостаточно. В интернет-магазине основная нагрузка может приходиться на категорию с фильтром, карточку и оформление заказа. На сайте услуг — на посадочную страницу и форму расчёта. Составьте короткий список разных шаблонов, затем добавьте наиболее посещаемые и проблемные адреса по данным своего проекта.
Для каждого теста запишите точный URL, тип устройства, дату, состояние авторизации и действие. Не сравнивайте страницу без виджетов на тестовом сервере с боевой страницей, где работают аналитика, чат и реальные данные. Закрытые страницы и оформление заказа не нужно открывать поисковым роботам ради PSI: их проверяют подходящими локальными инструментами и сценариями.
| Страница | Что делает посетитель | Как проверяем |
|---|---|---|
| Категория /catalog/stoly/ | Открывает список и выбирает ширину | PSI для загрузки; ручной сценарий фильтра на телефоне |
| Карточка /catalog/stol-nord-120/ | Смотрит фото, меняет цвет, добавляет товар | PSI и последовательная проверка выбора варианта |
| Корзина и оформление | Меняет количество, выбирает доставку | Тестовая корзина и запись взаимодействий; без реальной оплаты |
Если таблица не помещается на экране, прокрутите её по горизонтали.
Два адреса одного шаблона могут вести себя по-разному из-за фотографий и объёма данных. Выборку расширяют при обнаружении такого различия, а не проверяют случайные URL ради количества отчётов.
2. Отделите данные посетителей от лабораторного запуска
В PageSpeed Insights сначала выясните, относится ли блок опыта пользователей к конкретному URL или ко всему источнику — origin. Полевые данные берутся из Chrome UX Report и отражают предшествующий 28-дневный период. При недостатке данных страницы сервис может показать уровень сайта; если данных мало и там, полевой оценки не будет. Это не означает ни хорошую, ни плохую скорость.
Лабораторный блок создаёт Lighthouse: он загружает страницу в заданных условиях и помогает искать причины. Это отдельный эксперимент, а не средняя скорость ваших клиентов. После исправления лабораторный результат может измениться сразу, а полевые показатели обновляются постепенно вместе с окном наблюдения. Точное совпадение двух блоков не ожидается.
- Выбор страницыURL, устройство и важное действие посетителя
- Два слоя данныхCrUX за период отдельно от одного запуска Lighthouse
- Причина и задачаКонкретный ресурс или обработчик, а не только общий балл
- Повторная проверкаТот же сценарий, сохранённые отчёты и контроль функций
Полевые данные показывают опыт, лабораторный тест помогает найти причину. Оба нужны в своих границах.
| Блок | Что прочитать | Как использовать |
|---|---|---|
| Опыт реальных пользователей | Устройство, URL или origin, период, доступность данных | Понять масштаб проблемы; не приписывать всему сайту результат одного URL |
| Core Web Vitals | LCP, INP, CLS и распределение наблюдений | Выбрать: загрузка, реакция или стабильность |
| Лабораторная производительность | Условия запуска, метрики, снимок загруженной страницы | Проверить воспроизводимый сценарий и отсутствие иной версии страницы |
| Диагностика и рекомендации | Конкретные ресурсы, длинные задачи и причинные связи | Сформировать гипотезу исправления, затем проверить её |
Если таблица не помещается на экране, прокрутите её по горизонтали.
Документация: Google: устройство отчёта PageSpeed Insights; web.dev: почему лабораторные и полевые данные отличаются;
3. Разберите два фрагмента настоящего интерфейса
На первом скриншоте из документации Google показан LCP 2 секунды на 75-м процентиле. Доли рядом описывают распределение наблюдений: 81% хороших, 9% требующих улучшения и 11% плохих. Из-за округления сумма подписанных долей здесь составляет 101%; это не повод складывать проценты и вычислять собственную «среднюю скорость». Даже хороший 75-й процентиль не означает, что у всех посетителей загрузка быстрая.
Второй скриншот показывает условия конкретного лабораторного запуска: моделируемую медленную сеть 4G, задержку 150 мс, скорость 1638,4 Кбит/с и расположение центра обработки в Северной Америке. Это иллюстрация из документации, не измерение activelab.by и не неизменные условия каждого теста. При сравнении собственных запусков раскрывайте этот блок и фиксируйте его актуальные значения вместе с датой и URL.
Документация: Google: устройство отчёта PageSpeed Insights;
4. Переведите LCP, INP и CLS на язык задачи посетителя
LCP характеризует появление крупнейшего видимого элемента содержимого, INP — отзывчивость при взаимодействиях, CLS — визуальные сдвиги. Для хорошего опыта ориентиры Core Web Vitals: LCP не более 2,5 секунды, INP не более 200 миллисекунд, CLS не более 0,1. Их оценивают по 75-му процентилю отдельно для мобильных и настольных устройств: это не среднее арифметическое и не время самого быстрого открытия.
Обычный запуск Lighthouse без пользовательских действий не измеряет INP. Показатель TBT помогает искать блокирующий код, но не равен INP и не подставляется вместо него в отчёт о реальных посетителях. Общий балл производительности также не является отдельным доказательством удобной покупки.
| Показатель и условное значение | Что испытывает посетитель | Что исследовать |
|---|---|---|
| LCP 3,6 с | Главное фото или крупный текст появляется поздно | Ответ сервера, момент обнаружения главного ресурса, загрузку и отрисовку |
| INP 310 мс | Выбор варианта или фильтра ощущается заторможенным | Действия с задержкой и выполняющийся в это время JavaScript |
| CLS 0,18 | Элементы меняют положение после появления страницы | Размеры фото, вставку баннера, шрифты и поздние блоки |
Если таблица не помещается на экране, прокрутите её по горизонтали.
По этим цифрам нельзя назначить конкретное лекарство без диагностики. Например, большой LCP иногда связан с ожиданием сервера, а не с весом фотографии. Перевод всех картинок в другой формат не исправит задержку, если нужный ресурс начинает загружаться слишком поздно.
Документация: web.dev: Core Web Vitals, пороги и измерение; web.dev: поиск причин и оптимизация LCP;
5. Составьте очередь работ с критериями результата
Приоритет определяют сочетанием масштаба, влияния на важное действие и подтверждённой причины. Поломка оформления важнее косметического предупреждения. Затем берут проблему, затрагивающую много важных страниц. Список ниже — учебный пример после диагностики: это не универсальный набор изменений для каждого сайта.
| Приоритет и наблюдение | Изменение | Приёмка | Ответственный |
|---|---|---|---|
| 1. Главное фото загружается только после запуска галереи | Сделать исходное главное изображение доступным браузеру раньше; не откладывать его lazy loading | В записи загрузки запрос начинается раньше; правильное фото и выбор варианта сохранены | Разработчик интерфейса |
| 2. Фильтр блокируется пересчётом всего каталога | Сократить и разделить тяжёлую обработку; проверять только нужные данные | Запись взаимодействия показывает снижение задержки; результаты фильтра верны | Разработчик каталога |
| 3. Баннер доставки сдвигает кнопку покупки | Предусмотреть место или изменить размещение без внезапного сдвига | При первом и повторном открытии кнопка не уезжает во время действия | Разработчик интерфейса |
| 4. Чат загружает тяжёлый код до основного содержимого | Проверить безопасную отложенную загрузку с учётом работы чата | Основной сценарий быстрее; чат по-прежнему открывается и доставляет сообщение | Разработчик и владелец сервиса |
Если таблица не помещается на экране, прокрутите её по горизонтали.
Не удаляйте счётчик, защиту, обязательную информацию или функцию только ради зелёного балла. Если отключение виджета используется для поиска причины, это эксперимент с последующим решением, а не автоматически готовая оптимизация. Попросите оценить трудоёмкость после подтверждения причины, а не обещать одинаковый срок для всех пунктов.
Документация: web.dev: поиск причин и оптимизация LCP; web.dev: оптимизация отзывчивости INP;
6. Сравните версии в одинаковых условиях
Сохраните исходный отчёт, затем повторите несколько запусков для той же страницы и устройства. В учебном протоколе ниже выбраны три запуска и медиана: это удобный способ не делать вывод по одному удачному тесту, а не обязательный стандарт Google. Не смешивайте результаты разных адресов или версии с пустым и заполненным каталогом.
Отдельно запишите, какие данные пока отсутствуют. Если после изменения ещё нет достаточного полевого окна, так и укажите. Нельзя представлять лабораторное улучшение как доказанный рост продаж или как уже улучшившийся опыт всех посетителей.
| Проверка | До изменения | После изменения | Вывод |
|---|---|---|---|
| Лабораторный LCP, три запуска | 4,1 / 4,4 / 4,2 с; медиана 4,2 | 2,8 / 2,6 / 2,7 с; медиана 2,7 | В контрольном сценарии загрузка ускорилась; полевой статус Core Web Vitals этой серией не определяется |
| Выбор синего варианта | Меняет фото, цену и SKU | Меняет фото, цену и SKU | Функция сохранена |
| Добавление в корзину | Правильный SKU, одна позиция | Правильный SKU, одна позиция | Ошибки покупки не обнаружены в этом сценарии |
| Полевые Core Web Vitals | Сохранён отчёт за исходный период | Нового сопоставимого окна ещё нет | Не заявляем подтверждённое полевое улучшение |
Если таблица не помещается на экране, прокрутите её по горизонтали.
Если цифры скачут, исследуйте ответ сервера, внешние сервисы и условия запуска. Не выбирайте лучший результат из серии для отчёта. Сохраняйте всю серию и выводите заранее выбранный способ сравнения — медиану, диапазон или другую обоснованную характеристику.
Документация: Google: устройство отчёта PageSpeed Insights; web.dev: почему лабораторные и полевые данные отличаются;
7. Принимайте улучшение вместе с рабочими функциями
Хорошая приёмка соединяет технический результат и сценарий человека. Откройте страницу с телефона, смените вариант, примените фильтр, добавьте товар и начните оформление. Проверьте форму при ошибке, работу клавиатуры и видимость фокуса. Если оптимизация меняла кэширование, дополнительно проверьте персональные данные, корзину, цены и авторизацию: чужое содержимое не должно попадать другому посетителю.
Закройте задачу только с понятной записью: какие адреса проверены, что изменено, какие замеры приложены, какие функции прошли проверку и какие риски остались. Например: «Раннее обнаружение главного фото внедрено на шаблоне карточки; проверены два варианта и корзина; медиана лабораторного LCP снизилась в контрольной серии; полевой эффект ещё наблюдаем». Это полезнее отчёта из одного зелёного кружка.
Контроль скорости стоит повторять после изменения шаблона, установки нового виджета и существенного обновления каталога. Привяжите его к релизам, а для важных сценариев выберите собственные допустимые границы. Универсального обещания «100 баллов навсегда» нет: содержимое, устройства, сторонние сервисы и инструменты измерения меняются.
Частые вопросы
Сколько баллов PageSpeed достаточно?
Баллы полезны как диагностический ориентир одного запуска. Для решения о качестве смотрите реальные LCP, INP и CLS при наличии данных, условия теста и рабочие сценарии. Высокий балл не компенсирует неработающую форму или корзину.
Почему на компьютере всё хорошо, а на телефоне плохо?
Это разные условия: вычислительные возможности, сеть, экран, иногда состав страницы. Сначала сравните одинаковый URL и убедитесь, что отчёт относится к нужному устройству. Причину определяют по ресурсам и действиям, а не по разнице баллов как таковой.
Почему после ускорения полевые данные не изменились сразу?
PSI использует накопленные данные за предшествующий 28-дневный период. В нём ещё присутствуют посещения старой версии. Лабораторный повтор показывает текущую проверку, но не заменяет последующее наблюдение за реальными пользователями.
Если нет данных CrUX, сайт не проходит Core Web Vitals?
Недостаток данных означает отсутствие оценки, а не автоматически плохой результат. Используйте лабораторную диагностику и, при необходимости, собственный сбор разрешённых технических измерений реального опыта, не приписывая ему статус данных CrUX.
Источники и документация
Материал подготовлен для владельцев бизнеса на основе официальной документации. Примеры и планы работ в тексте — учебные: состав решений зависит от конкретного сайта.
Если нужна помощь с описанной задачей, посмотрите состав услуги Поддержка и оптимизация сайта. Объём работ, сроки и стоимость согласуются после изучения вашего проекта.
