Посетитель открывает услугу, сравнивает варианты и отправляет заявку. На каждом шаге сайт может мешать: долго показывать главный экран, задерживать ответ кнопки или сдвигать форму во время ввода. Задача диагностики — найти помеху и проверить, что исправление помогает пройти сценарий.
Один балл в отчёте не объясняет, почему посетитель ушёл. Нужны технические измерения, проверка интерфейса и данные о достижении цели. Ни ускорение, ни высокий Lighthouse сами по себе не позволяют обещать определённый рост выручки.
Сначала выберите страницы и действия
Проверять только главную недостаточно. Выберите разные шаблоны: главная, услуга, кейс, статья и форма обращения. Для магазина добавьте каталог, карточку и оформление заказа.
Для каждого URL запишите действие: прочитать предложение, открыть меню, применить фильтр, перейти к брифу, исправить ошибку и отправить форму. Отдельно отметьте мобильный сценарий. Статья, на которую приходят из поиска, заслуживает проверки не меньше главной.
Лабораторные и полевые данные
| Данные | Для чего использовать | Чего они не доказывают |
|---|---|---|
| Lighthouse в заданных условиях | Найти техническую причину и сравнить изменения | Что все посетители получают такой же результат |
| Полевые данные CrUX в PageSpeed Insights | Оценить накопленный опыт пользователей | Что сегодняшнее исправление изменило весь период |
| Проверка действий в браузере | Найти сбой конкретного сценария | Частоту проблемы среди всей аудитории |
| Аналитика обращений | Наблюдать движение к заявке | Что изменение конверсии вызвано только скоростью |
PageSpeed Insights показывает полевые данные за предшествующие 28 дней. Проверяйте, относятся ли они к точному URL или ко всему origin. При недостатке наблюдений данных может не быть: это неизвестный результат, а не успешная проверка. Описание PageSpeed Insights.
Какие метрики читать
| Метрика | Что замечает пользователь | Ориентир хорошего результата |
|---|---|---|
| LCP | Когда появляется крупнейший видимый элемент контента | Не более 2,5 секунды |
| INP | Насколько быстро интерфейс реагирует на взаимодействие | Не более 200 мс |
| CLS | Насколько неожиданно сдвигаются элементы | Не более 0,1 |
Это пороги Core Web Vitals для 75-го процентиля, с отдельной оценкой мобильных и настольных устройств. Они не являются результатами измерения CoreWeb. Обычный Lighthouse-тест загрузки не измеряет INP реальных посетителей; TBT помогает диагностировать блокировку, но не заменяет INP. Web Vitals: метрики и методы измерения.
Почему одного числа 90+ недостаточно
Баллы Lighthouse рассчитываются из нескольких показателей. Условия запуска влияют на результат, а одинаковая сумма может скрывать разные проблемы. Сохраняйте отчёт вместе с версией инструмента, устройством, ограничениями сети и датой. Как рассчитывается оценка Lighthouse.
Для приёмки согласуйте конкретные URL и сценарии, окружение, режим кэша, включённые сторонние сервисы и критерии. Повторите измерение несколько раз в одинаковых условиях; зафиксируйте разброс, а не только лучший запуск. Затем проверьте форму, навигацию и содержимое. Выключение нужного клиенту виджета ради красивого отчёта требует отдельного продуктового решения.
Учебный отчёт LAB-01: от числа к проверяемой задаче
Ниже вымышленный разбор, а не замер CoreWeb, результат клиента или обещание скорости. Страница https://example.test/services/pumps описывает услугу и ведёт к форме запроса. Заказчик получил лабораторный отчёт с LCP 4,2 секунды. Из одного числа ещё нельзя заключить, что нужен другой хостинг или что все посетители ждут столько же.
Сначала прочитайте паспорт запуска
| Поле учебного отчёта | Что записано | Зачем это нужно для сравнения |
|---|---|---|
| Страница и версия | /services/pumps, сборка LAB-A, без авторизации | Иначе можно сравнить разные страницы или содержимое |
| Инструмент | Lighthouse в Chrome; точные версии обоих сохранены в исходном JSON отчёта | Названия «мобильный тест» недостаточно; версии берут из реального отчёта, не угадывают |
| Устройство | Эмуляция мобильного viewport 390 × 844, замедление CPU ×4 | Это заданная лабораторная модель, а не измерение каждого телефона |
| Сеть | Учебная настройка: 150 мс задержки, загрузка 1,6 Мбит/с; метод throttling указан в отчёте | Симуляцию и фактическое ограничение запросов нельзя молча считать одинаковыми |
| Состояние | Холодный кэш, первый визит; одинаковый набор разрешённых сторонних сервисов | Повторный визит и другой набор сервисов — отдельные условия |
| Место и время | Один тестовый компьютер и сеть; время каждого запуска записано | Фоновая нагрузка и сеть могут добавить разброс |
Значения выше придуманы для задания и не являются рекомендуемым SLA или стандартным профилем любой версии Lighthouse. В рабочей карточке приложите настоящий HTML/JSON отчёт, дату, точные версии и настройки. Если этих данных нет, сначала запросите их; красивый скриншот балла не делает измерение воспроизводимым.
Найдите элемент, которому относится LCP
В LAB-01 крупнейшим элементом стало главное изображение оборудования. В записи загрузки видно: запрос изображения начинается поздно, хотя оно находится на первом экране. Это наблюдение. Возможная причина — изображение обнаруживается только после выполнения скрипта; это гипотеза, которую разработчик проверяет по разметке и цепочке запросов.
Не назначайте сразу сжатие всех картинок: если задерживается начало запроса, уменьшение файла может не убрать основную задержку. Сначала сопоставьте LCP-элемент, момент его обнаружения, загрузку и появление на экране. Элементом LCP может быть и текст; на другом размере экрана или с другим содержимым он может измениться. Почему лабораторные и полевые данные различаются.
Учебная задача исполнителю: «Проверить причину позднего запроса главного изображения в LAB-A. Если гипотеза подтвердится, сделать его доступным загрузчику раньше, сохранить правильное изображение и размеры, затем повторить ту же серию». Это постановка проверки, а не универсальная инструкция добавлять preload ко всем изображениям.
Повторите серию и покажите разброс
В условной версии LAB-B изменили обнаружение главного изображения. Остальные условия сохранили. Все значения таблицы учебные; пять запусков — выбранный размер этого упражнения, а не универсальная гарантия достаточности выборки.
| Показатель | LAB-A, до | LAB-B, после | Что допустимо заключить |
|---|---|---|---|
| LCP пяти запусков, с | 4,2; 4,0; 4,4; 4,1; 4,3 | 2,8; 2,7; 2,9; 2,8; 3,0 | В этой серии и этих условиях значения уменьшились |
| Медиана и диапазон, с | 4,2; от 4,0 до 4,4 | 2,8; от 2,7 до 3,0 | Есть устойчивое различие между этими сериями; это не полевой 75-й процентиль |
| LCP-элемент | Главное изображение | То же изображение | Сравнение не объясняется удалением важного содержимого |
| Форма и меню | Проверены отдельным сценарием | Сценарий повторён | Ускорение не принято за счёт сломанного действия |
Lighthouse может давать разные результаты даже без изменения кода. Сохраняйте все прогоны и объясняйте исключения, если запуск испорчен известным сбоем; не оставляйте только лучший. Если диапазоны сильно перекрываются, выполните дополнительные сопоставимые измерения и проверьте помехи, прежде чем объявлять эффект. О вариативности Lighthouse.
Для LAB-B вывод ограничен лабораторией. Медиана 2,8 секунды не доказывает прохождение полевого порога LCP, не измеряет INP посетителей и ничего сама по себе не говорит о числе обращений. CrUX за накопленный период и проверка конкретного запуска отвечают на разные вопросы. Отсутствие CrUX для учебного URL нельзя заменить придуманным зелёным результатом.
Что передать заказчику после исправления
Приложите исходные отчёты обеих серий, условия, идентификаторы версий, подтверждение LCP-элемента и объяснение изменения. Отдельно запишите проверку меню, формы и ошибок; отправку тестовых данных выполняйте только в согласованной среде. Если задача требовала иной порог или устройство, LAB-B нельзя принять по чужому критерию.
В протоколе приёмки сайта зафиксируйте собственный критерий, ссылки на доказательства и оставшиеся ограничения. Для обсуждения с исполнителем достаточно этой цепочки: наблюдение → проверенная причина → изменение → сопоставимый повтор → проверка пользовательского действия.
Как выбирать работы по диагностике
| Наблюдение | Что проверить | Как подтвердить исправление |
|---|---|---|
| Главное изображение появляется поздно | Размер файла, размер на экране и момент запроса | Сравнить загрузку этого элемента до и после |
| Кнопка отвечает с задержкой | Длительные задачи JavaScript и обработчик действия | Повторить действие на том же устройстве |
| Текст или форма сдвигаются | Место под изображения, шрифты и баннеры | Проверить момент смещения в записи сценария |
| Повторный визит остаётся тяжёлым | Заголовки кэша и повторные запросы ресурсов | Раздельно сравнить холодный и повторный визит |
| После подключения сервиса стало медленнее | Работу чата, аналитики или другого виджета | Сравнить согласованные варианты с сервисом и без него |
Начните с проблемы, мешающей важному действию на посещаемом шаблоне. Для задачи укажите наблюдение, предполагаемую причину и способ проверки. Не заказывайте смену CMS только по красному кругу отчёта: сначала установите причину. Для обсуждения архитектуры пригодится сравнение Nuxt и WordPress.
Карточка проверки для подрядчика
Скопируйте этот список в задачу:
- URL и сценарий посетителя.
- Дата, версия сайта и окружение проверки.
- Устройство, браузер, сеть и режим кэша.
- Источник: лаборатория, полевые данные или ручная проверка.
- Для полевых данных: период и область — URL либо origin.
- Проблема, исходные показатели и ссылка на отчёт.
- Изменение, повторные показатели в сопоставимых условиях и оставшиеся ограничения.
- Результат проверки формы, меню и важных действий после изменения.
Карточка делает обсуждение предметным: понятно, что было плохо, что изменили и каким наблюдением это подтверждается.
Как оценить эффект для бизнеса
Сначала убедитесь, что обращения учитываются корректно. Сравнивайте сопоставимые периоды и источники трафика, отмечая изменения рекламы, предложения и формы. Несколько заявок на малой выборке не позволяют уверенно приписать эффект ускорению.
Старые отраслевые исследования скорости могут подсказать гипотезу, но их проценты нельзя переносить на выручку конкретного корпоративного сайта. Для поиска хороших Core Web Vitals тоже недостаточно: они не гарантируют верхние позиции. Core Web Vitals и результаты поиска.
Если вы планируете новый сайт или переработку существующего, включите страницы, сценарии и условия проверки в исходный объём работ. Посмотрите, как устроена разработка сайта под ключ, и приложите URL и заполненную карточку к описанию проекта.
Краткую расшифровку показателей и различий источников данных можно открыть в термине Core Web Vitals.