От полученного документа к показанному кадру
Сетевой водопад показывает, когда браузер получил документ и ресурсы. Но читатель видит кадр, а не окончание HTTP-запроса. Между этими событиями выполняется работа: разбор документа, вычисление оформления, размещение элементов и подготовка изображения экрана. В этом уроке свяжем доставку speed-lab с реальным показом его содержимого.
Практическая задача — объяснить ситуацию, в которой ресурсы уже загружены, а основной текст или изображение появляются позднее. Подготовленные исходники не запускались автором; предполагаемые наблюдения читатель проверяет вручную. Здесь не утверждается, что такая задержка была измерена у ProfessorWeb. Мы изучаем механизм на отдельной учебной странице.
Структура, оформление и размещение
HTML задаёт элементы и их связи. Браузер строит представление документа, применяет CSS и определяет размеры с положением видимого содержимого. Затем подготавливаются операции рисования и окончательный кадр. Это упрощённая модель, но она уже помогает разделить три факта: ресурс получен, элемент существует и элемент показан человеку. Как браузер заполняет страницу.
В Console можно найти img, который ещё не доставлен, или абзац с оформлением, делающим его невидимым. Поэтому наличие узла в DOM не доказывает готовность результата. В Network завершённый запрос также не означает, что браузер уже декодировал изображение и включил его в кадр. Для объяснения задержки нужны наблюдения из нескольких представлений.
У speed-lab стили подключены в head, а JavaScript оформлен как модуль. Текст статьи находится в HTML. Это позволяет отличить доставку основного документа от поведения фильтра. Не переносим все абзацы в скрипт ради эксперимента: тогда изменятся и путь обнаружения содержимого, и его доступность, а расследование станет сложнее.
<link rel="stylesheet" href="../assets/style.v1.css">
<script type="module" src="app.js"></script>Это фрагмент head, а не целый документ. Модульный скрипт без async по умолчанию имеет отложенное исполнение относительно разбора HTML. Но его дальнейшая работа всё равно может занимать основной поток. Свойство подключения решает вопрос планирования загрузки и исполнения; оно не делает тяжёлую функцию бесплатной. Семантика script.
Зависимости показа
Обычный подключённый stylesheet может задерживать первое отображение, пока браузер не имеет необходимых стилей. Это объясняет, почему небольшой файл иногда влияет сильнее большой картинки ниже статьи. Для нашего документа оформление текста и контейнеров нужно до устойчивого показа. Перенос CSS в поздний скрипт может создать ранний неоформленный кадр, но сам по себе не улучшит чтение.
Представим изменение: стили загружаются после появления статьи. Сначала строки имеют одну ширину, затем получают новые размеры и отступы. Человек видит материал раньше, но его положение меняется. Следует оценить и загрузку, и устойчивость. Нельзя признавать решение успешным только по раннему появлению любого текста, если читатель затем теряет место.
У готовой библиотеки часто есть общий стиль и особенности материалов. Уменьшать файл можно, удаляя действительно неиспользуемые правила, но вывод должен опираться на представительные страницы. Правило, не применённое на главной, может быть нужно старому уроку с таблицей или примером. В нашем исследовании сохраняем функции содержания; устройство общего оформления уже рассмотрено в курсе дизайна.
Разделение CSS также имеет цену. Отдельный критический набор усложняет согласованность и может дублировать правила. До такого решения полезно проверить, является ли доставка стилей реальным ограничением. Если документ задержан до первого ответа или основной поток занят большой задачей, перестановка CSS не обязательно устранит главную причину.
Чтение записи Performance
Откройте Performance до воспроизведения сценария, запишите загрузку и найдите кадр появления содержимого. Затем сопоставьте его с событиями Main: выполнением скрипта, пересчётом стилей, layout и paint. Названия и расположение областей могут различаться по версии DevTools; ориентируйтесь на смысл операций, а не на координату кнопки. Работа с Performance.
Нам нужна связь во времени. Допустим, после завершения изображения основная область ещё выполняет JavaScript, а показ начинается позже. Это предполагает ограничение исполнения или отображения, а не доставки самой картинки. Однако совпадение полос не является окончательным доказательством. Найдите стек или событие, объясняющее работу, и проверьте его независимым изменением.
В baseline фильтр вычисляет синтетическую сумму по карточкам целиком. Такая работа намеренно введена в стенд. Если она попадёт рядом с ранним отображением, вы можете увидеть конкуренцию за основной поток. Измерение на собственном устройстве покажет фактический эффект; учебное число элементов не обещает определённую задержку на каждом компьютере.
Измеряйте один и тот же сценарий. Если в одной записи вы набрали запрос во время загрузки, а в другой дождались её завершения, сравниваются разные условия. Позднее исследуем взаимодействие отдельно. Сейчас важна загрузочная цепочка: какие операции предшествовали кадру, в котором читатель получил основное содержание?
Повторный layout и чередование операций
Размещение зависит от текущих размеров. Если программа пишет стиль, а затем немедленно запрашивает геометрию, браузеру может понадобиться актуализировать её. Многократное чередование чтения и записи способно создавать лишнюю работу. Следующий фрагмент показывает учебную антиструктуру; он не включён в рабочий стенд и не должен добавляться для ускорения:
for (const card of document.querySelectorAll(".card")) {
card.style.padding = "20px";
console.log(card.getBoundingClientRect().width);
}Здесь каждое изменение сопровождается запросом вычисленной геометрии. Если значение действительно нужно, сначала определите зависимость и постарайтесь сгруппировать необходимые чтения и записи. Но нельзя механически переставить операции, когда каждое следующее измерение должно учитывать предыдущее изменение. Правильность алгоритма остаётся условием оптимизации.
Для фильтра speed-lab геометрия карточек вообще не нужна. Создаём элементы в DocumentFragment, затем заменяем набор одной операцией. Это сокращает число промежуточных изменений документа, но не даёт фиксированной гарантии скорости: итоговое размещение и рисование всё равно выполняются. Кроме того, огромный набор видимых элементов может оставаться дорогим после такой группировки.
Проверка выбранной границы
Событие DOMContentLoaded связано с готовностью разбора и соответствующими зависимостями, а load — с другим состоянием доставки. Ни одно имя не означает автоматически момент, когда читатель получил главный абзац. Если вы используете событие как контрольную точку, сначала объясните его роль в вашем сценарии. Затем проверьте кадры: иногда нужный текст появляется до этой точки, иногда ожидает дальнейшей динамической работы.
Для статической статьи полезно сохранять основное содержание в исходном документе и исследовать дополнительные функции отдельно. Это делает цепочку понятнее: браузер получает текст независимо от работы фильтра. Но сама статичность не гарантирует мгновенный кадр; общий CSS, шрифт и занятый основной поток всё ещё имеют значение. Доступность HTML — исходное условие исследования, а не готовое доказательство скорости.
Завершите исследование временной цепочкой из двух границ: «ресурс получен» и «результат показан». Между ними укажите конкретные операции из собственной записи. Если большой промежуток не объясняется изображением, не продолжайте сжимать его наугад. Следующий урок использует эту модель для LCP: найдём крупнейший подходящий элемент и определим, какая часть пути задерживает его появление.