Что обозначает каждое событие вкладки TimeLine из данного примера?

Привет.
У меня есть документ HTML, документ начинает анализироваться и начинает строиться дерево синтаксического разбора DOM - выводится один параграф с текстом (этот параграф я сделал блочно-строчным, чтобы все события поместились на экран), потом скрипт попадается, анализ документа стопорится (так как в данном случае скрипт обычный - синхронный), отрабатывает скрипт, который выводит строку с указанием, что скрипт синхронный (можно сделать и асинхронный – комментарии убрать), потом продолжается анализ документа и построение дерева синтаксического разбора DOM, - выводится второй параграф текста (этот параграф я сделал блочно-строчным, чтобы все события поместились на экран).
`

Paragraph 1

Paragraph 2

`

С этим документом HTML ссылками связаны внешние таблицы стилей CSS (файл 7style.css):

p{color:red;display:inline-block;}
`P:last-Child{color:green;display:inline-block;}

и код JavaScript (файл 7script.async.js)`:

if (document.getElementById(123).async==true){ window.document.write('Hallo from async script!'); } else{ window.document.write('Hallo from sync script!'); }

Если сделать запись во вкладке TimeLine, то получу следующее:


ВОПРОС: ЧТО ЗНАЧИТ КАЖДОЕ СОБЫТИЕ ? ПОЧЕМУ СОБЫТИЯ ГРУППИРУЮТСЯ?
Я пронумеровал все события, обвел те, которые сгруппированы.
1 - что это за событие?
2 - браузер отправил запрос “пришли мне файл 7.html”. ожидание около 300 миллисекунд.
3 - сервер говорит “я услышал тебя”.
4 - 7 - начинается загрузка файла 7.html (4- начало загрузки файла 7.html, 5,6 - ЧТО ЭТО ЗА ПЕРЕСЧЕТ СТИЛЕЙ??? ВЕДЬ ДО ЭЛЕМЕНТА link браузер еще не дошел???, 7 - парсинг, начинает строиться дерево DOM).
8 - закончилась загрузка файла 7.html.
9 - 12 - начало загрузки файла стилей 7style.css, загрузка, браузер строит дерево CSSOM и окончание загрузки.
13 - 16 - браузер увидел скрипт, постройка DOM останавливается, начало загрузки файла скриптов 7scriptasync.js, загрузка и окончание загрузки. Дерево CSSOM еще не готово, скрипт ждет его постройки.
17 - Это анализ стилей моего файла стилей 7style.css???
18 - ЧТО ЭТО ЗА СОБЫТИЕ EVALUATE SCRIPT?
19 - парсинг моего файла со скриптами 7scriptasync.js и отработка скрипта. С построения DOM снимается блокировка.
20 - 21 - браузер парсит оставшуюся часть моего документа 7.html.
22 - ЧТО ЭТО ЗА ПЕРЕСЧЕТ СТИЛЕЙ?
23 - Что это за событие Stamp???
24 - к этому времени render tree готово, создание макета - расчет положения всех блоков и их размеров под данное разрешение экрана…
25 - 29 - вывод на экран. ПОЧЕМУ ВЫВОД НА ЭКРАН - ЭТО 5 СОБЫТИЙ С ОДНИМ НАЗВАНИЕМ, А НЕ ОДНО???

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

Второе - этапы рендеринга (подгрузка стилей, парсинг html, repaint, reflow, парсинг html при вставке его скриптом через innerHTML) в современных браузерах мало чем отличаются от представителя к представителю.

Третье - я сейчас буду спекулировать (не зная точно что происходит, придумывать какое может быть объяснение происходящему исходя из доступных мне знаний).

Предполагаю что что действия браузерами будут выполнены примерно одинаковые, а последовательность может варьироваться (особенно на старте страницы так как старт все стремятся оптимизировать).

Похоже на изначальное применение браузерных стилей к документу. У каждого браузера есть стили по умолчанию.

Этот двойной просчет, который я вижу и в хроме

и в фаерфоксе. Почему, откуда - не могу сказать.

Скорее всего да. В скриншоте выше хром делает recalculate style прямо во время парсинга html.

Это самое простое. Время, необходимое браузеру для выполнения скрипта. В скриншоте хрома выше этому событию соответствует желтая полоса левее от голубой.

Это парсинг html-я, который вставляется в скрипте в DOM. Отладчик подсказывает причиу (8 строка скрипт файла).

Старые отладчики не делали разницы между relflow и repaint, помечая их одинаково как пересчет стилей. В твоем случае причиной пересчета стилей стало изменение DOM-а скриптом. Это reflow

По логике похоже на событие или load или domReady.

Неоптимальный код браузера. Или инкрементальный рендер.

Это как-бы связанные действия, отдельные шаги которых не могут существовать сами по себе. На самом деле интерпретация очень условная, и особого смысла я бы в группах не искал.

4-7 похоже применение браузерных стилей к странице.
9-12 прогрузка внешних стилей.
13-16 подгрузка скрипта
18-19 выполнение скрипта + парсинг html-я, вставленного скриптом. Объединено потому как синхронная операция.

Спасибо за развернутый вопрос.

Самая лучшая ссылка про внутренности работы браузера на английском: طريقة عمل المتصفِّحات  |  Articles  |  web.dev

1 лайк

Спасибо за ответ)

Вы мне кинули ссылку в конце, я ее уже читал. Эта статья сжатая, есть ее переведенный и более объемный вариант, вот ссылка - http://webknowledge.ru/kak-rabotaet-brauzer-chto-proishodit-za-kulisami-sovremennyh-brauzerov/#parsing-general. Но даже тут нет описания принципов работы с таймлайном.
Вообще, я не нашел развернутого описания работы вкладки таймлайн инструментов разработчика хрома. Даже, если почитать стать на сайте google.developers.com (от первоисточника) про таймлайн, то там только краткое описание, Вот ссылка - https://developer.chrome.com/devtools/docs/timeline.
Про оптимизацию критического пути неплохо рассказывает Илья Григорик (гугловский спец- оптимизатор быстродействия). Но про сам таймлайн у него всего пару слов. Вот ссылка на курс Григорика - https://www.udacity.com/course/viewer#!/c-ud884/l-1464158642/m-1529098548.
Я этот вопрос задал на форуме также на форуме Григорековского сайта Udacity. Интересно, ответит ли кто-нибудь там. Вот ссылка - https://discussions.udacity.com/t/what-does-each-timeline-event-mean-in-this-example/171951.
Я себе поставил неплохой браузер - Chrome Canary. Как написано, это экспериментальный браузер для разработчиков. Его можно поставить параллельно с обычным браузером хром. Написано было, что он выдает больше информации, что инструменты разработчика в нем более продвинутые. У canary панель devtools усовершенствованная - появляется намного больше спрятанных событий во вкладке таймлайн, кучу дополнительной информации дает . На некоторые мои вопросы он дал ответ. Например, мне было непонятно, как прорисовка идет. Браузер подтвердил (я событие посмотрел, их список стал намного больше, чем 29 на моем рисунке), что прорисовка (paint) идет не в самом конце документа, а отрисовывается постепенно (после появления каждого нового элемента дерева render tree запускается макетирование и отрисовка). На данный момент мне этот браузер нравится из-за панели таймлайн. Но браузер глючный, об даже на сайте гугл пишут. Трудно было найти работающий у меня вариант., пришлось ходить по разным ссылкам, много раз ставить и удалять.

Я разбирался с таймлайном по этому документу. Лучше документов по таймлайну не видел. Конечно у меня были некоторые знания о том как работают браузеры. А дальше - метод проб и ошибок и практика.

Это альфа версия хрома. Я бы советовал использовать хром для работы с таймлайном. Были в моей практике неприятные баги с canary. Единственный случай когда я пользуюсь canary - это когда есть баг в инструменте разработчиков в хроме.