С 73 до 97: откладываем вёрстку невидимых секций с помощью CSS

1. Сначала проверяем достоверность замера

Локальный Lighthouse сначала показал 80 для главной и 45–49 для Quick sort. При этом инструмент предупреждал о CPU медленнее ожидаемого, а повторный запуск — о тайм-аутах очистки кеша. Обвинять скрипт на основании этих баллов было рано. PageSpeed Insights использовал Lighthouse 13.5.0 на инфраструктуре Google, локальный инструмент — 12.8.2. Сравнение до и после мы проводили внутри PageSpeed, не считая оценки разных сред и версий взаимозаменяемыми. Данных реальных посетителей в этих отчётах не было.

2. Находим работу перед первым показом текста

Вводный абзац уже рендерится на сервере, iframe видео загружаются только по нажатию. В диагностической трассировке без искусственного замедления CPU первая длинная задача заняла 304 мс, из них 281 мс пришлись на Layout. После неё появился вводный текст. Генерация начальных шагов сортировки в отдельном Node-бенчмарке занимала около 0,15–0,17 мс, а связанный с canvas перерасчёт в трассировке — около 1,4 мс. Это сузило поиск до первоначальной вёрстки. Но Node-бенчмарк не воспроизводит слабый телефон, а один короткий перерасчёт не доказывает дешевизну любой canvas-сцены.

3. Сравниваем CSS на одинаковом контенте

Мы зафиксировали отрисованный HTML, встроили одинаковые стили и шрифты, убрали JavaScript и проверили локальные копии. Отключение балансировки заголовков, кнопок, контейнерных запросов и внешнего flex-layout не дало сопоставимого устойчивого выигрыша. Исходные запуски тратили на Layout суммарно около 190–258 мс. Откладывание видео и секций статьи ниже плеера сократило это время до 94–108 мс в двух запусках. Откладывание только кода или только видео не воспроизвело тот же выигрыш. Это диагностический эксперимент: он изолировал работу CSS, но не измерял гидратацию и не предсказывал точный production-балл. Одного сломанного CSS-правила мы не обнаружили.

4. Откладываем нижние секции, а не плеер

content-visibility: auto позволяет браузеру при необходимости пропустить вёрстку и отрисовку невидимого содержимого. Свойство не удаляет серверный текст и не откладывает загрузку JavaScript. Мы применили его к нижним секциям, оставив заголовок, введение и плеер обычными. contain-intrinsic-block-size резервирует предполагаемую высоту, пока содержимое пропускается; auto позволяет повторно использовать размер уже показанного блока. Оценки различаются для мобильного и широкого экранов, длинного кода и вертикальных видео. В примере — общий CSS, а переменные высоты задаёт каждая секция. В браузерах без поддержки оптимизации остаётся обычная вёрстка.

.deferred {
    content-visibility: auto;
    contain-intrinsic-block-size: auto var(--estimated-height, 500px);
    scroll-margin-block-start: 24px;
}

@media (min-width: 768px) {
    .deferred {
        contain-intrinsic-block-size: auto var(--estimated-height-wide, 250px);
    }
}

@media print {
    .deferred {
        content-visibility: visible;
        contain-intrinsic-block-size: none;
    }
}

5. Проверяем прокрутку и прямые ссылки

Быстрый первый кадр бесполезен, если дальше статьёй неудобно пользоваться. Мы добавили стабильные ID секций, одинаковые в RU и EN, проверили прямой вход в нижнюю секцию трёхстороннего разбиения, якоря видео и кода, историю браузера, прокрутку вниз и обратно и отсутствие горизонтального переполнения. Проверенные якоря останавливались примерно в 24 px от верхнего края. После возврата работали шаги плеера, смена разбиения, запуск, пауза и сброс. Правило для печати возвращает обычную отрисовку, но это не заявление о полном аудите PDF и вспомогательных технологий. Резервные размеры остаются оценками: другие ширины и браузеры тоже требуют проверки.

6. Проверяем production и оговариваем ограничения

После публикации изменения Quick sort новый мобильный PageSpeed показал рост производительности с 73 до 97, снижение FCP примерно с 2,4 до 0,9 секунды, LCP с 5,2 до 2,6 секунды и TBT со 150 до 70 мс. CLS остался нулевым; доступность, рекомендации и SEO — по 100. Это два лабораторных запуска, не медианы и не гарантия для каждого посетителя. Направление совпадает с контролируемым экспериментом, но улучшение реального пользовательского опыта ещё нужно подтвердить полевыми данными.

7. Переносим подход только после проверки

Затем мы проверили оставшиеся страницы алгоритмов. Вставки и пузырьковая получили 77, выбор — 73, слияние — 77, с LCP около пяти секунд. После публикации аналогичной оптимизации нижних секций новые мобильные замеры показали соответственно 77, 80, 99 и 77. У выбора LCP снизился с 5,2 до 2,0 секунды, у пузырьковой — с 5,2 до 4,8 секунды. У вставок и слияния он остался около пяти секунд. TBT у вставок снизился примерно со 130 до 0 мс, у пузырьковой — со 110 до 10 мс, а у слияния изменился со 170 до 180 мс. CLS у выбора составил 0,001, у остальных новых замеров — 0. Heap sort в предыдущей проверке получил 99, бинарный поиск — 98, поэтому их не меняли. В таблице сохранены оба замера и ссылки на отчёты: большой прирост Quick sort не повторился на каждой странице. Каждая пара до и после — сравнение одиночных запусков, а не доказательство устойчивого эффекта. Общий серверный компонент позволяет не копировать поведение, сохранив отдельные оценки высот.