Comments 22
1) Есть ли у вас какой-то бюджет на загрузку страниц. Ну например вы такие собрались подумали и решили что главная страница почты должна открываться за 2 секунды по 75-ой перцентили. И если есть то как и исходя из чего вы его определяете?
2) Мериете ли вы отдельно кешированный/некешированный флоу ( ну типа пользователь зашел первый раз/ и последующие )?
3) Что таки используется для подсчета перцентилей ( я думаю что вряд ли гугл аналитика )? есть ли оно в опенсорсе?
4) Мониторите ли вы что-то постоянно? или просто после релизов смотрите не просели ли где-то?
5) Есть ли аномали детекшн может какой
Бюджет понятие очень размытое, у каждого проекта он свой, конечно мы стремимся к максимальной скорости, например Главная не просто быстро должна быстро отдаётся, она изначально сконструирована особым способом, чтобы по мере загрузки пользователь увидел сначала самые важные блоки, а потом уже остальные. В то же время для Почты, первая загрузка важна, но всё же это тяжелый SPA, тут другие правила.
Кроме этого, проекту много лет, поэтому нам немного проще, запуская новую Главную или Почту, нам однозначно нельзя сделать хуже ;] Кроме этого, периодически мы запускаем хакатон по оптимизации первой загрузки Почты.
Ну и на остальные вопрос:
- Да, меряем и не только кеширование, но ещё и делим метрики на какой интет у юзера
- Для процентилей использует внутренний инструмент и он не в опенсорсе и вряд ли будет
- Мониторим постоянно, рядом с рабочими местами всят с мониторы с графиками, а так же есть SMS-алертинг, если что-то пошло не так
Хороший вопрос, сделайте пример на каком-нибудь jsfiddle/jsbin, подумаю как это решить. Но на первый взгляд, можно добавить методы для ручного делегирования событий scroll и/или scrollStart/scrollEnd.
at new FPSMeterPugin. Я попытался исправить своими силами, однако не вышло.
Упс, это я случайно, вот правильная ссылка https://jsfiddle.net/RubaXa/uhtecoas/3/
Спасибо, было интересно.
Можно ещё добавить что-нибудь про lazy hydration, метрики TTI этот приём улучшает на порядок.
Хм, звучит интересно. Но, у нас нет SSR (почти нет), а в тех местах где есть наоборот хотим провести обратный эксперимент с его отключением, чтобы мгновенно отдавать крохотный HTML и потом быстро рендерить приложение.
TTI интересная метрика, но я больше доверяю когда само приложение говорит Ready и обычно оно это делает заметно раньше ;], а лонг таски, лонг тасками, это ещё не значит, что интерфейс залип.
Поэтому в планах сделать непрерывный мониторинг интерактивности, но пока не очень вижу, как именно снимать сконструировать такую метрика (одно понятно, что она точно должна быть комплексной).
А почему SSR не используете? Быстрее работает же, апишка дёргается на сервере, первичный html отдаётся гидрированным, ну и для ботов хорошо. Вообще, по-моему круто для более-менее статичных страниц (типа лендинга) использовать пререндеринг на уровне CI/CD, для динамических — первые несколько блоков кидать на SSR, а дальнейшие блоки внизу страницы грузить и гидрировать лениво и асинхронно, отдавая скелетоны на время загрузки чанка с ними. Ну и выбросить все блоки, которые доступны после логина в отдельный чанк, который тоже загрузится после логина. Можно ещё обмазать это каким-нибудь smart prefetch-ингом, чтобы совсем всё отлично было.
У нас нет задачи угодить ботам, а поддержка SSR это время, кроме этого, мы же Приложение (с большой буквы), тут SSR полноценный не выйдет, не всеми данными обладает сервер. Если брать туже Главную, то там и гидриротировать нечего, там вся страница отдаётся маленькими независимыми блоками (html + js + css).
Привет! Классная статья, у вас все очень круто устроено. Если не сложно, то ответьте на пару вопрос:
- http2/brotli вы используете их везде и всегда? Проводили ли вы сравнение по скорости загрузки и использованию cpu? Можно где-нибудь почитать про это, если да?
- Вы вручную разбиваете по бандлам? Используете ли three-shaking? Как решаете проблему дублирования модулей?
HTTP/2 везде, но опять же, есть мониторинг трафика, поэтому если откуда-то выползает HTTP/1, разбираемся.
Brotli стоит в планах, готовить его будем при сборке, а то никакого железа не хватит, но это только после запуска так называемых HTTP2-бадлов, на которые у нас большие надежды.
Смысл в том, что в HTTP2-бандл, это не сборка исходников в один файл, а только файл декларация, в которой объявлены все зависимости в порядке их использования, т.е.
В итоге при загрузке такого бандла сразу запрашиваются все файлы из него и т.к. у нас HTTP/2 всё должно пройти как нельзя лучше ;] Но самый профит, что при изменении любого файла сборки, юзеру не нужно будет выкачивать весь мегабайтный бандл (что сейчас происходит абсолютно у всех), а только обновленную декларацию и низменные файлы у которого изменился checksum (такой подход называется дедубликация).
Про бандлы. Где webpack, там кто-во что горазд, но больше руками, на Почте своя система сборки на основе r.js и там тоже руками, но c с хитростью, бандлы объявляются в виде массива и каждый следующим бандл становиться зависимым от предыдущего, поэтому и не включает в себя его зависимости, даже если из явно указать. В самом конце этого массива есть rest-bundle, в который попадают все файлы, которые не вошли ни в одну из сборок.
Насчет brotli — у нас получилось так, что дополнительное время на декомпрессию клиентом примерно равнялось разнице в скорости загрузки. В итоге не выйграли ничего.
Конечно, в независимости от результата напишем.
А вот про brotli интересно (все же пишут только про размер, а не реальный профит ;]), вы это по каким метрикам увидели?
Мы измеряем примерно те же метрики что и вы. После запуска brotli не увидели значительного профита на метриках usable (когда мы считаем, что страница готова к использованию), но время загрузки бандлов упало. Стали профилировать, обнаружили, что CPU гораздо сильнее нагружается и решили не углубляться дальше. Возможно закопавшись в это можно было бы подобрать наиболее оптимальный brotli_comp_level и получить значимый профит.
Производительность фронтенда: разбираем важные метрики