Первое, не значительное но интересное - это время работы Service Worker.
Как я понимаю, разница между точками workerStart и fetchStart с предыдущей диаграммы - это время на инициализацию спящего SW + время которое он потратил на "fetch" обработчик перед запросом текущей страницы.
Ночью и рано утром событий мало и шум сильный, а днем видно что в среднем оверхед небольшой - 10-20мс даже на мобилках, на десктопе еще меньше.
Но тем не менее, эти расходы есть, а высокие перцентили и пики в ночные часы показывают, что на небольшое количество пользователей оверхэд в разы сильнее.
Тут нам стоит провести эксперимент с Navigation Preload API, что бы делать запрос за страницей параллельно активации SW - https://web.dev/blog/navigation-preload
А в будущем возможно поможет Static Routing API - https://developer.chrome.com/blog/service-worker-static-routing
Как я понимаю, разница между точками workerStart и fetchStart с предыдущей диаграммы - это время на инициализацию спящего SW + время которое он потратил на "fetch" обработчик перед запросом текущей страницы.
Ночью и рано утром событий мало и шум сильный, а днем видно что в среднем оверхед небольшой - 10-20мс даже на мобилках, на десктопе еще меньше.
Но тем не менее, эти расходы есть, а высокие перцентили и пики в ночные часы показывают, что на небольшое количество пользователей оверхэд в разы сильнее.
Тут нам стоит провести эксперимент с Navigation Preload API, что бы делать запрос за страницей параллельно активации SW - https://web.dev/blog/navigation-preload
А в будущем возможно поможет Static Routing API - https://developer.chrome.com/blog/service-worker-static-routing
👍2
tgoop.com/super_oleg_dev/172
Create:
Last Update:
Last Update:
Первое, не значительное но интересное - это время работы Service Worker.
Как я понимаю, разница между точками workerStart и fetchStart с предыдущей диаграммы - это время на инициализацию спящего SW + время которое он потратил на "fetch" обработчик перед запросом текущей страницы.
Ночью и рано утром событий мало и шум сильный, а днем видно что в среднем оверхед небольшой - 10-20мс даже на мобилках, на десктопе еще меньше.
Но тем не менее, эти расходы есть, а высокие перцентили и пики в ночные часы показывают, что на небольшое количество пользователей оверхэд в разы сильнее.
Тут нам стоит провести эксперимент с Navigation Preload API, что бы делать запрос за страницей параллельно активации SW - https://web.dev/blog/navigation-preload
А в будущем возможно поможет Static Routing API - https://developer.chrome.com/blog/service-worker-static-routing
Как я понимаю, разница между точками workerStart и fetchStart с предыдущей диаграммы - это время на инициализацию спящего SW + время которое он потратил на "fetch" обработчик перед запросом текущей страницы.
Ночью и рано утром событий мало и шум сильный, а днем видно что в среднем оверхед небольшой - 10-20мс даже на мобилках, на десктопе еще меньше.
Но тем не менее, эти расходы есть, а высокие перцентили и пики в ночные часы показывают, что на небольшое количество пользователей оверхэд в разы сильнее.
Тут нам стоит провести эксперимент с Navigation Preload API, что бы делать запрос за страницей параллельно активации SW - https://web.dev/blog/navigation-preload
А в будущем возможно поможет Static Routing API - https://developer.chrome.com/blog/service-worker-static-routing
BY SuperOleg dev notes
Share with your friend now:
tgoop.com/super_oleg_dev/172