FMP — от него хотим следующего: понимание нашего critical path, количества времени которое уходит на него. Дальше будет очень большой тред с большим количеством графиков и сравнений:
TL;DR: мы пришли к такому решению: gist.github.com/xnimorz/8ec4fc…
Это позволяет нам трекать critical path, понимать, когда render tree "доходит" до нужного места. Это не самый "честный" FMP, но это наиболее репрезентативный вариант до которого мы смогли дойти.
Дальше история того, как мы к этому шли и графики, графики!)
С одной стороны, FMP говорит о том, что нужно трекать, когда контент отобразился. И тогда код будет что-то вроде такого:
gist.github.com/xnimorz/6b939a… Этот код приходится вставлять inline или блокирующим вызовом (чтобы cache работал).
Offtop, но если вы сделаете блокирующий вызов для того, чтобы кеш сработал, я вас удивлю: кеш может не сработать так, как вы ожидаете! Почему так расскажу чуть позже сегодня
Если затрекать такое время от gist.github.com/xnimorz/6b939a… и выводить на график, получим вот такую чушь:
Почему чушь?
99 перцентиль составляет больше 100 секунд. Представьте людей, которые настолько терпеливы? :)
Если копать на меньшие перцентили (95, 75) там значения будут около 20-30 секунд.
Вспоминаем вчерашнюю историю про "сайт грузится и не работает 30 секунд". Понимаем, что если пользователям приходилось бы столько ждать, то обращения в сапорт были бы.
Почему так происходит? Если пользователь переключит вкладку, то raf не будет исполняться, пока вкладка не станет активной. Вот наглядное видео: youtu.be/jmvzULtV7Q8
Какое может быть решение? Трекать активность страницы!
В коде это будет так: gist.github.com/xnimorz/917a57… здесь скрипт, который трекает видимость страницы должен располагаться до fmp.
Насколько отличается первый и второй вариант? Вот графики:
Первый вариант 95-я перцентиль (без трека visibility page api).
Вот вариант, когда убираем значения, если пользователь уходил со страницы, или открывал фоновую вкладку:
Здесь уже видим, что значения похожи на правду: 1 секунда загрузка резюме, самая тяжелая страница: 2.6 секунды.
У второго варианта есть проблема. Он не трекает многих пользователей, так как один из популярных паттернов у пользователей хх: открыть вакансии в новых вкладках и потом идти по ним.
Здесь может прийти идея трекать новые DOM метрики, которые уже есть в браузерах, но они также плохо учитывают неактивные страницы и мы получим те же проблемы, о которых говорили вначале.
Как научиться трекать остальных пользователей? Исполнять скрипт, который не зависит от raf 🙂
Это можем сделать, просто снимая timestamp, при исполнении инлайн скрипта.
Это позволяет нам делать аналитику, потому что у нас уже есть renderTree.
Делаем это вот так: gist.github.com/xnimorz/8ec4fc…
Если сравнить со вторым вариантом, разница оказывается не такой большой, как можно было предположить 100-300мс. А охват пользователей полноценный. По эксперименту в неделю, поняли, что разница между вариантами незначительна и остановились на вариантом с полным покрытием кода.
На график выводим 95-ю перцентиль. Т.е. у 95% пользователей страница отображается не дольше, чем за это время на графике и только у 5% пользователей — хуже.
95" график важного контента (+/- первый экран):
95" то же время, но с засечкой body:
Для сравнения вот 50 перцентиль за тоже время у body:
Эти графики не отображают мобилка \ десктоп. Но если это сделать, будет очень необычно.
Вот мобилки:
Десктоп:
