Речь тогда про вложенные requestAnimationFrame. Они ведь будут где-то вызываться? Сами таймарки ок, а вот значения которые лягут в window.globalVars.performance.fmp могут зависеть от тех искажений о которых писал выше.
Вычисление метрики fmp, не учитывает ещё одну вещь – Браузер, который во время работы
занимается парсингом и отрисовкой и выполнением джс (ну и борьбой за ресурсы). Такой код:
requestAnimationFrame(function() {
var renderTreeFormed = performance.now(); // начало
requestAnimationFrame(function() {
var fmp = performance.now(); // окончание
// видимость && отправка(окончание - начало)
});
});
Будет работать верно в случае, когда страница распарсилась и всё происходит не во время загрузки страницы. Иначе с точки зрения работы браузера тут есть 2 ошибки:
— у браузерного парсера нет обязательств, движок в любой момент может прервать парсинг и отрисовать картинку (причем в хромиумы нацелены чаще рисовать, а не быстрее парсить большие документы – это хорошо видно на открытии github, когда огромная простыня кода отрисовывается долго, а вот firefox наоборот).
— ваш xxx рядом с которым стоит метка точно не распарсится, если он еще не загрузился ¯\_(ツ)_/¯ т.е. браузер может распарсить открывающий тег следующего div, а потом приходит очередной BeginFrame, и парсить больше нечего — тогда точно (ну почти) нарисуется еще один белый кадр, и второй rAF засечет время перед ним.
Т.е. фундаментально метрика показывает правду исключая влияние парсинга страницы. Но если вдруг у вас страница состоит больше, чем из примеров HelloWorld, то скорее всего тут будет ошибка. Проверить её можно достаточно просто:
<script>window.performance.mark('fmp_body')</script>
<div class="body" data-test="вот тут очень много ненужных символов, которые будут влиять на парсинг">
<!-- или вот сюда можно наставить -->
xxx
</div>
Могу сказать результат: метрика будет улучшаться, но это false-positive улучшение, т.к. пользователю не стало лучше) В итоге контент xxx не нарисуется, а метрика будет отправляться и стремиться к 0, тк белый экран отрисовывать достаточно дёшево.
Ну или посмотреть и поподбирать параметры страницы и посмотреть внутри Rendering chrome://tracing как и что происходит.
Распечатаю комментарий и повешу на стену. Ожидал притензии по коду питона. Я новичок в этом деле и этот код в первой десятке написанного. Думаю, теперь все будет лучше.
занимается парсингом и отрисовкой и выполнением джс (ну и борьбой за ресурсы). Такой код:
Будет работать верно в случае, когда страница распарсилась и всё происходит не во время загрузки страницы. Иначе с точки зрения работы браузера тут есть 2 ошибки:
— у браузерного парсера нет обязательств, движок в любой момент может прервать парсинг и отрисовать картинку (причем в хромиумы нацелены чаще рисовать, а не быстрее парсить большие документы – это хорошо видно на открытии github, когда огромная простыня кода отрисовывается долго, а вот firefox наоборот).
— ваш xxx рядом с которым стоит метка точно не распарсится, если он еще не загрузился ¯\_(ツ)_/¯ т.е. браузер может распарсить открывающий тег следующего div, а потом приходит очередной BeginFrame, и парсить больше нечего — тогда точно (ну почти) нарисуется еще один белый кадр, и второй rAF засечет время перед ним.
Т.е. фундаментально метрика показывает правду исключая влияние парсинга страницы. Но если вдруг у вас страница состоит больше, чем из примеров HelloWorld, то скорее всего тут будет ошибка. Проверить её можно достаточно просто:
Пример было:
Попробуйте сделать так:
Могу сказать результат: метрика будет улучшаться, но это false-positive улучшение, т.к. пользователю не стало лучше) В итоге контент xxx не нарисуется, а метрика будет отправляться и стремиться к 0, тк белый экран отрисовывать достаточно дёшево.
Ну или посмотреть и поподбирать параметры страницы и посмотреть внутри Rendering chrome://tracing как и что происходит.
Если списки/словари вложены, то копировать можно через deepcopy:
Например, WWDC