Lighthouse — Примеры

Пример 1 — Работа по отчёту сверху вниз

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

Performance 62          (лабораторный запуск, замедленно, пустой кэш)

Opportunities
  Properly size images             est. 480 KiB
  Reduce unused JavaScript         est. 210 KiB
  Eliminate render-blocking CSS    est. 120 ms

Diagnostics
  Largest Contentful Paint   4.1 s

Решение

чтение
оценка — это взвешенное резюме; список под ней — результат, с которым можно работать
"Properly size images" даёт самую крупную оценённую экономию, и диагностика LCP
соглашается: показатель, на котором оценка теряет очки, — это hero-изображение, а не стили

изменение: отдать hero корректного размера, затем повторить тот же самый аудит

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

Пример 2 — Один запуск, принятый за измерение

Оценка падает с 78 до 75 после изменения, которое должно было помочь, и изменение откатывают. Скажите, что здесь принимают за сигнал, а затем сделайте сравнение надёжным. Числа иллюстративны.

запуск 1: 78      (до добавления графика с ленивой загрузкой)
запуск 2: 75      (после)   -> откатили

Решение

протокол
- повторяйте аудит три раза и сравнивайте медианы, а не отдельные запуски
- считайте несколько пунктов шумом: аудит — одна замедленная симуляция, а не измерение
- меняйте по одной вещи на сравнение и сверяйтесь с полевыми данными рядом с лабораторной оценкой
- поставьте порог в конвейере: минимальная оценка accessibility, максимальный переданный объём

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