Измерение производительности сервисного работника

Пол Кинлан

Помимо Джейка Арчибальда, беспокоящегося о том, что его навыки разработчика загнивают и теряются, он привел веские аргументы в пользу того, что, разумно используя сервис-воркера, вы можете значительно улучшить производительность своего сайта или приложения. Посмотрите видео для обзора.

Если вы собираетесь увеличить время загрузки своей страницы, как предлагает Джейк, вам действительно нужно понимать, как работники службы влияют на запросы вашей страницы.

Resource Timing и User Timing API являются важнейшими компонентами инфраструктуры RUM (Real User Monitoring) многих сайтов, поскольку они позволяют вам целостно понять, как все ваши пользователи видят производительность вашего сайта ( еще один вариант использования — обнаружение внедрения контента ). Короче говоря, он позволяет вам понять почти каждый аспект каждого веб-запроса, сделанного с вашего сайта, если только у вас нет сервис-воркера или веб-работника.

Вот краткий пример того, как его можно использовать для получения списка всех запросов, которые были сделаны к домену, который не является текущим доменом.

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-интерфейсам Resource Timing и User Timing и, таким образом, иметь возможность позволить вам следите за производительностью сети для всех своих пользователей.

Доступ к показателям производительности от Service Worker

Самым большим изменением является добавление объекта performance в контекст Workers (Web и ServiceWorkers), который теперь позволит вам понять время выполнения всех запросов, сделанных в контексте Workers, а также позволит вам устанавливать свои собственные оценки. для измерения выполнения JS. Если вы можете видеть, что происходит только из контекста текущего окна, вы пропустите важную информацию о времени:

  • Запросы fetch() сделанные внутри события oninstall сервисного работника
  • Запросы fetch() выполняемые при кэшировании данных в событии onpush , теперь можно отслеживать, чтобы понять производительность, которую видят ваши пользователи.
  • наконец, запрос fetch() , который создается и перехватывается обработчиком onfetch .

Последний пункт важен. Сервис-воркера можно рассматривать как прокси-сервер, который находится между веб-интерфейсом и сетью. Объект performance в window видит только время и информацию для той части запроса, которую он вызывает, он не знает о сервисном работнике, находящемся между клиентом и сетью, поэтому он не может понять влияние сервисного работника. .

Как я могу это использовать?

Типичный сервисный работник, который сначала поддерживает автономный режим, должен выполнить этап установки, на котором он загрузит и сохранит все ресурсы для последующего использования.

Примером того, где это можно использовать, является запись и протоколирование данных о времени этапа установки, чтобы вы могли принять некоторые взвешенные решения о том, как вы можете улучшить производительность вашей установки на основе реального использования пользователями.

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, уже сообщают данные о скорости сайта с помощью API синхронизации навигации, но их необходимо обновить, чтобы включить анализ производительности из контекста Worker.

Будет ли API синхронизации навигации доступен для сервисных работников?

На данный момент не планируется добавлять API синхронизации навигации в контекст сервис-воркера, поскольку в сервис-воркере нет традиционной навигации. Интересно то, что для сервис-воркера каждая навигация по контролируемому им набору страниц выглядит как выборка ресурса. Уже одно это делает сервис-воркеров невероятно привлекательным способом централизации большей части вашей логики производительности в вашем веб-приложении.

Могу ли я посмотреть, что изменилось?

Меня интересует обсуждение и характеристики.