Помимо беспокойства Джейка Арчибальда о том, что его навыки разработчика увядают и падают, он привел веские доводы в пользу того, что при разумном использовании Service Worker вы можете радикально улучшить производительность своего сайта или приложения. Посмотрите видео для обзора.
Если вы собираетесь максимально ускорить загрузку страницы, как предлагает Джейк, вам действительно нужно понимать, как сервис-воркеры влияют на запросы вашей страницы.
API Resource Timing и User Timing являются критически важными компонентами во многих инфраструктурах RUM (Real User Monitoring), поскольку они позволяют вам целостно понять, как все ваши пользователи видят производительность вашего сайта ( еще один вариант использования — обнаружение внедрения контента ). Короче говоря, они позволяют вам понять практически каждый аспект каждого веб-запроса, сделанного с вашего сайта, ну, если только у вас нет service worker или web worker.
Вот краткий пример того, как его можно использовать для получения списка всех запросов, которые были сделаны к домену, который не является текущим доменом.
var getThirdPartyRequests = function() {
var thirdPartyRequests = [];
var requests = window.performance.getEntriesByType("resource");
var currentHost = window.location.host
for(var requestIdx = 0; requestIdx < requests.length; requestIdx++) {
var request = requests[requestIdx];
var url = new URL(request.name);
var host = url.host;
if(host != currentHost) {
thirdPartyRequests.push(request);
}
}
return thirdPartyRequests;
};
API-интерфейсы Resource Timing и User Timing были созданы и реализованы еще до того, как Service Worker появился в глазах инженеров, и приведенный выше код не смог бы понять, как Service Worker на него повлиял.
Недавний набор изменений в Chrome 45 (бета-версия в июле 2015 г.) поможет вам, предоставив возможность всем видам работников (веб- и сервис-работников) иметь доступ к API синхронизации ресурсов и синхронизации пользователей, что позволит вам контролировать производительность сети для всех ваших пользователей.
Доступ к показателям производительности из Service Worker
Самым большим изменением является добавление объекта performance в контекст Workers (Web и ServiceWorkers), что теперь позволит вам понять время выполнения всех запросов, которые сделаны в контексте Worker, а также позволит вам устанавливать собственные отметки для измерения выполнения JS. Если вы можете видеть только то, что происходит в контексте текущего окна, вы упустите важную информацию о времени из:
- Запросы
fetch()сделанные внутри событияoninstallсервисного работника - Запросы
fetch(), выполненные при кэшировании данных в событииonpushтеперь можно отслеживать, чтобы оценить производительность, которую видят ваши пользователи. - наконец, запросы
fetch(), которые создаются и перехватываются обработчикомonfetch.
Последний пункт важен. Один из способов думать о service worker — это как о прокси, который находится между веб-интерфейсом и сетью. Объект performance в window видит только время и информацию для той части запроса, которую он вызывает, он не знает о service worker, который находится между клиентом и сетью, поэтому он не может понять влияние service worker.
Как это использовать?
Типичный сервисный работник, который сначала поддерживает офлайн, будет иметь шаг установки, на котором он загрузит и сохранит все ресурсы для последующего использования.
Примером использования этого метода является запись и регистрация данных о времени выполнения этапа установки, что позволит вам принимать обоснованные решения о том, как улучшить производительность установки на основе данных о реальном использовании системы пользователями.
self.addEventListener("install", function() {
var urls = [
'/',
'/images/chrome-touch-icon-192x192.png',
'/images/ic_add_24px.svg',
'/images/side-nav-bg@2x.jpg',
'/images/superfail.svg',
'/scripts/voicememo-core.js',
'/styles/voicememo-core.css',
'/third_party/Recorderjs/recorder.js',
'/third_party/Recorderjs/recorderWorker.js',
'/third_party/Recorderjs/wavepcm.js',
'/third_party/moment.min.js',
'/favicon.ico',
'/manifest.json'
];
urls = urls.map(function(url) {
return new Request(url, {credentials: 'include'});
});
event.waitUntil(
caches
.open(CACHE_NAME + '-v' + CACHE_VERSION)
.then(function(cache) {
// Fetch all the URL's and store in the cache
return cache.addAll(urls);
})
.then(function () {
// Analyze all the requests
var requests = self.performance.getEntriesByType("resource");
// Loop across all the requests and save the timing data.
return;
})
);
});
Сегодня многие сайты используют RUM для понимания того, как большинство их пользователей взаимодействуют с их сайтом. Такие инструменты, как Google Analytics, уже сообщают данные о скорости сайта с помощью Navigation Timing API, но их необходимо обновить, чтобы включить анализ производительности из контекста Worker.
Будет ли API навигационного времени доступен Service Workers?
На данный момент нет планов по добавлению Navigation Timing API в контекст service worker, поскольку в service worker нет традиционных навигаций. Интересно то, что для service worker каждая навигация в контролируемом наборе страниц service worker выглядит как выборка ресурсов. Это само по себе делает service worker невероятно убедительным способом централизации большей части вашей логики производительности в вашем веб-приложении.