Geist и первый Layout: проверяем прогрев шрифта и карточки главной

1. Учитываем стоимость прогрева Geist, а не только дешёвый Layout после него

23 октября мы проверили главную в Chrome 153.0.8010.36 с фактическим замедлением CPU ×4. Отдельные серии холодных профилей проверяли раннюю подготовку шрифта и полную загрузку через локальный HTTPS/HTTP2-ретранслятор с фиксированным опубликованным HTML, исходным стартовым JavaScript и неизменёнными файлами шрифтов. В полных загрузках использовали экран 412×823, DPR 1,75, задержку сети 562,5 мс и пропускную способность 1474,56/675 Кибит/с на скачивание/отправку. Порядок вариантов чередовался; коллекторы аналитики подавлялись одинаково, скрипты сохранялись. Это прямые лабораторные измерения Chrome/CDP, а не новые отчёты Google PageSpeed или данные реальных посетителей. Более короткий следующий Layout сам по себе не доказывает ускорение первого экрана: в сравнении должна остаться длительность самого прогрева.

Сначала отдельный опыт проверил сам механизм на статическом HTML главной без стартовых скриптов. Одинаковые font-face перенесли в head; исходные Sans Latin/Cyrillic и Mono отдавали заранее, CSS — через 2 секунды, а корень одинаково скрывали до 2,5 секунды, чтобы исключить ранний Layout неоформленной страницы. Это искусственное окно — только контроль, а не предлагаемая стратегия загрузки. Мы измеряли короткий образец в 17 сочетаниях шрифта и стиля либо измеряли и рисовали 44 текстовых блока в отдельный canvas с чтением bitmap, чтобы учесть стоимость отрисовки. measureText также обрабатывает текст образца, а не просто читает метрики шрифта.

Прогрев сократил следующий Layout с 389 до 192 или 104 мс, но суммарная работа выросла с 391 до 485 или 606 мс. Последний столбец — медиана сумм внутри каждого запуска, а не сумма отдельно округлённых медиан. Следующий Layout во всех вариантах по-прежнему содержал 150 объектов и 35 вызовов shaping. Это эффект подготовленного состояния, а не установленный вклад одного конкретного кеша. В свободном окне прогрев мог бы перекрываться ожиданием сети, поэтому эти суммы — длительности работы, а не прогноз production-LCP.

В полной серии сохранили стартовый JavaScript и не задерживали ни CSS, ни показ страницы. Три экспериментальных варианта получили одинаковые ранние Sans font-face и load для двух уже preload-запрошенных подмножеств; различалась только работа Canvas. Во всех 10 загрузках с прогревом он начался после первого существенного Layout, в девяти — после paint H1, в семи — после LCP. Медианы около 2,9 секунды не доказывают устойчивый выигрыш или статистическую эквивалентность. Контроль с ранней загрузкой без Canvas оказался особенно нестабилен: результаты 8,004 и 9,748 секунды сохранены, а не приписаны отсутствию Canvas. Два таймаута Page.navigate повторили, не превращая ошибки в числовой LCP; успешные повторы вошли в выборки по пять запусков. Оборванная попытка Lighthouse не смешана с этой CDP-серией.

Ожидание только кириллицы с весом и размером заголовка, без Latin, тоже не создало раннего окна: все шесть прогревов начались после первого Layout. Короткий образец теперь занимал около 8 мс, три фрагмента только из кириллицы — около 85 мс, но страница к этому моменту уже использовала шрифт. Две загрузки короткого образца превысили 3,8 секунды; три наблюдения не устанавливают, что задержку вызвал именно этот API. Эти проверки не дают оснований добавлять проверенный прогрев или ожидание document.fonts.ready в старт сайта.

2. Проверяем, остаются ли отложенные карточки главной вне пути к LCP

В той же среде HTTP/2 и CPU ×4 сравнили 20 холодных загрузок, по пять на CSS-вариант, сохранив HTML главной, скрипты, байты шрифтов и порядок preload. Трём карточкам библиотек добавляли content-visibility: auto с оценкой intrinsic block size 400 px на мобильном и 240 px на широком экране. Первая карточка начинается примерно на 608 px в экране высотой 823 px и уже должна быть видна. Два контроля отделяли обычный layout/style/paint containment от постоянного исключения рендера двух нижних карточек. Auto может возвращать расчёт близкого невидимого содержимого ещё до прокрутки: это не обещание пропустить всё ниже края экрана.

Длительности — медианы; первый существенный Layout выполняет разный объём работы: обычно 150 объектов в исходном варианте и 67–97 с auto. В одной паре исходный первый проход занял 760 мс. Auto разбил работу на проходы 126, 245 и 361 мс до paint H1; вместе они выполнили те же 35 вызовов shaping. Первый paint H1 пришёлся на 2761 и 2780 мс, LCP — на 2872 и 2860 мс. Более ранний FCP auto в этом запуске относился лишь к маленькой ссылке EN, а не к заголовку. Во всех auto-загрузках уведомления в итоге показывали skipped:false для всех трёх карточек; сами эти асинхронные уведомления не устанавливают состав конкретного раннего Layout.

Уменьшение медианы LCP на 104 мс при принудительном исключении карточек 2 и 3 — лишь диагностический ориентир, а не строгая верхняя граница и не готовый ленивый рендер: содержимое оставалось невидимым и недоступным для обычного взаимодействия при прокрутке. Auto функционально работал: исходный и экспериментальный варианты совпали в RU/EN на ширинах 360, 412 и 1280 px; якорь библиотек устанавливался с отклонением до 0,4 px, высота при прокрутке сохранялась, три примера открывались с правильным фокусом, переполнения и JS-ошибок не было. CLS был нулевым во всех 20 замерах. Результаты не оправдывают добавление containment карточкам ради LCP на текущей короткой главной; нижние секции алгоритмов остаются отдельным ранее измеренным случаем.