Почему LCP скачет: повторные замеры и трассировка Chrome

1. Измеряем разброс вместо отбора лучшего запуска

Следующая проверка вставок показала 81: прежние 100 не воспроизводились в каждом запуске. Затем мы провели по пять мобильных проверок шести страниц сортировок примерно за десять минут — с 17:30 до 17:40 по Москве 21 октября. Все 30 отчётов использовали Lighthouse 13.5.0, одну опубликованную версию сайта и обычные URL без диагностических параметров. В каждой серии запускали шесть проверок; на графике указано время начала отчётов. График показывает баллы, LCP и TBT, таблица — медиану и полный диапазон пяти запусков каждой страницы. Это отдельные замеры, а не непрерывный мониторинг.

Ни одна страница не получила 99–100 во всех пяти запусках. У вставок, слияния и пирамидальной медиана LCP превысила четыре секунды. Наблюдения не устанавливают причину разброса и не доказывают регрессию: параллельной контрольной версии не было, полевых данных в отчётах нет. Пять запусков описывают это короткое окно, а не долгосрочную стабильность. CLS был нулевым во всех 30 запусках.

2. Повторяем проверку вставок после откладывания палитры и подвала

Затем изменили общую оболочку сайта: закрытая цветовая полоска показывает градиенты, создаёт ползунки только при раскрытии и удаляет их при закрытии. Для подвала добавили content-visibility: auto с резервом высоты. После публикации повторно проверили обычный URL сортировки вставками 22 октября с 05:53 до 05:56 по Москве. Три независимых мобильных отчёта PageSpeed показали 100, 81 и 79 баллов, LCP — 1,368, 4,500 и 4,853 секунды. LCP-элементом остался вводный абзац. В разбивке медленных отчётов задержка его отрисовки составила 1,40–1,51 секунды; эти значения из разбивки не равны полному моделируемому LCP. Новая медиана LCP — 4,50 секунды против 4,70 в прежней серии из пяти запусков, медиана балла осталась 81. Медиана TBT снизилась со 100 до 0 мс, CLS остался нулевым. Устойчивое улучшение LCP эта проверка не подтвердила: быстрые и медленные запуски сохранились, выборки малы, а две версии не проверялись одновременно. Одного снижения TBT недостаточно, чтобы считать задержку показа кадра устранённой.

Lighthouse 13.5.0, эмуляция Moto G Power и медленной сети 4G, HeadlessChromium 153.0.8010.36. Во всех трёх отчётах доступность, рекомендации и SEO получили 100; полевых данных нет. Один дополнительный отчёт повторил время захвата и точные метрики предыдущего; его исключили как возможный дубликат. В таблице FCP и LCP округлены до двух знаков.

3. Воспроизводим задержку без приложения и Lighthouse

Собрали отдельный пример: 109 220 байт статического HTML и таблица стилей на 555 байт, без фреймворка, прикладных скриптов, canvas, изображений, веб-шрифтов и анимации. Сборщик добавляет через CDP пассивные наблюдатели времени; ответ со стилями намеренно задержан на 200 мс. На Windows x64, Chrome 155.0.8059.80 и chrome-launcher 1.2.2 сравнили прямую навигацию, переход через about:blank в сохраняемой вкладке и новую вкладку. В обеих группах оставили все стандартные флаги launcher; в сравнительной группе только убрали RenderDocument из списка отключённых возможностей и явно включили его. Всего выполнили 48 загрузок без трассировки: по два изолированных процесса Chrome на группу и по четыре загрузки каждого сценария в процессе. Повторные загрузки внутри процесса не являются независимыми наблюдениями. Здесь измеряется нативный интервал между paintTime и presentationTime, а не балл PageSpeed или моделируемый LCP.

4. Находим ожидание между активацией слоёв и отправкой кадра

В отдельной серии сырых потоковых трасс связали показанный кадр с renderer, его деревом слоёв и приёмником кадров Viz. В одном медленном запуске новое дерево активировалось на 1172,167 мс, но кадр отправился только на 2137,322 мс. Этап от активации до отправки занял 965,154 мс; после отправки до показа прошло всего 15,093 мс. Второй медленный запуск потратил на тот же этап 972,751 мс, а контрольные запуски с RenderDocument — около 0,5–1,4 мс. Отдельная трасса с явными областями задач повторила ожидания 971,0 и 968,1 мс. Целевой renderer получал BeginFrame на 135,855, 1135,854 и 2135,918 мс. При этом браузер запрашивал поверхность 5, а renderer продолжал отправлять поверхность 3; поверхность 5 попала в сборку кадра вскоре после получения. Это локализует измеренное ожидание до отправки кадра, а не в финальном обмене буферов или показе после отправки.

Метки показа из Paint Timing API и PipelineReporter — разные наблюдения; в таблице сохранены обе. Серия трассировки выполнена отдельно от сравнения 48 загрузок выше. Опубликованный отчёт, воспроизводитель и трассы в Lighthouse #17148.

5. Передаём результаты разработчикам, не выдавая гипотезу за исправление

Во время ожидания Viz записывает ThrottleUndrawnFrames, что согласуется с интервалом BeginFrame около секунды. Но в записях отказа нет идентификатора приёмника кадров: близость по времени не доказывает, что каждый отказ относится к нашей поверхности. В первом интервале длиной 965 мс захваченные области задач занимают около 1,65 мс на основном потоке renderer и 0,75 мс на потоке компоновки; это не CPU-время и не доказательство простоя всех потоков. Признак потери данных при завершении исторических трасс не был сохранён. Одного повторного использования RenderFrameHost тоже недостаточно: прямой повторный переход может сохранить его и остаться быстрым. В Lighthouse #17148 мы опубликовали воспроизводитель, три полные очищенные трассы, скрипты сопоставления и контрольные суммы, попросив разработчиков уточнить зависимость поверхностей и BeginFrame и проверить отключение RenderDocument. Полной трассы медленного запуска Google PSI у нас нет, поэтому его точная причина и внутренние флаги пока не подтверждены. Это не исправленный баг Chromium, не обходное решение для сайта и не доказательство единой причины всего оставшегося разброса LCP.