Pomiar wydajności skryptu service worker

Paul Kinlan

Jake Archibald martwi się, że jego umiejętności programisty przestaną się wyczerpywać, a Ty przedstawił solidny przykład, że dzięki inteligentnemu użyciu skryptu service worker można znacząco poprawić wydajność witryny lub aplikacji. Obejrzyj film, aby uzyskać ogólne informacje.

Jeśli zamierzasz przyspieszyć wczytywanie strony, jak sugeruje Jake, musisz naprawdę umieć zrozumieć, jak mechanizmy Service Worker wpływają na żądania strony.

Interfejs Resource Timing i User Timing API to kluczowe elementy infrastruktury RUM (Real User Monitoring) w wielu witrynach, ponieważ pozwalają w pełni zrozumieć, jak wszyscy użytkownicy postrzegają wydajność witryny (inny przypadek użycia wykrywa wstrzykiwanie treści). Krótko mówiąc, dzięki niemu możesz zrozumieć niemal każdy aspekt każdego żądania internetowego wysyłanego z Twojej witryny, chyba że w swojej witrynie masz skrypt service worker lub Web worker.

Oto krótki przykład wykorzystania tej funkcji do uzyskania listy wszystkich żądań wysłanych do domeny, która nie jest domeną bieżącą.

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;
};

Interfejsy API Resource Timing i User Timing zostały utworzone i wdrożone, zanim mechanizm Service Worker stał się błyskotką dla programistów, a powyższy kod nie był w stanie zrozumieć, jak mechanizmy Service Worker mają na niego wpływ.

Niedawny zestaw zmian w Chrome 45 (wersja beta w lipcu 2015 r.) ułatwi Ci umożliwienie wszystkim rodzajom instancji roboczych (skryptów internetowych i service worker) dostępu do interfejsów API Resource Timing i User Timing, co pozwoli wszystkim użytkownikom na bieżąco monitorować wydajność sieci.

Dostęp do wskaźników wydajności z poziomu skryptu service worker

Największą zmianą jest dodanie obiektu performance do kontekstu instancji roboczych (Web i ServiceWorkers), który pozwala teraz analizować czasy wydajności wszystkich żądań wysyłanych w kontekście instancji roboczej oraz ustalać własne znaczniki pomiaru wykonywania kodu JavaScript. Jeśli widzisz tylko to, co dzieje się w kontekście bieżącego okresu, stracisz najważniejsze informacje o czasie z tych źródeł:

  • Żądanie fetch() wysłane w zdarzeniu oninstall skryptu service worker
  • Żądania fetch() wysyłane podczas buforowania danych w zdarzeniu onpush można teraz śledzić, aby poznać wydajność widoczną dla użytkowników.
  • Na koniec żądanie fetch() wysłane i przechwycone przez moduł obsługi onfetch.

Ostatnia kwestia jest ważna. Skrypty service worker działają jak serwer proxy między interfejsem internetowym a siecią. Obiekt performance w window widzi tylko czasy i informacje dotyczące wywołanej części żądania. Nie ma informacji o tym, czy skrypt service worker znajduje się między klientem a siecią, dlatego nie może rozpoznać wpływu skryptu service worker.

Jak mogę tego użyć?

Typowy mechanizm Service Worker, który najpierw obsługuje tryb offline, ma fazę instalacji, podczas której pobiera i zapisze wszystkie zasoby do późniejszego wykorzystania.

Można to wykorzystać na przykład do rejestrowania i zapisywania danych dotyczących czasu instalacji, aby podejmować świadome decyzje o tym, jak poprawić wydajność instalacji na podstawie rzeczywistych zachowań użytkowników.

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;
        })
    );
});

Obecnie wiele witryn korzysta z RUM, aby dowiedzieć się, jak większość użytkowników korzysta z witryny. Narzędzia takie jak Google Analytics już raportują dane o szybkości witryny za pomocą interfejsu Navigation Timing API, ale trzeba je zaktualizować, aby uwzględnić analizę wydajności na podstawie kontekstu instancji roboczej.

Czy interfejs Navigation Timing API dotrze do procesów service worker?

W tej chwili nie planuje dodawać interfejsu Navigation Timing API do kontekstu skryptu service worker, ponieważ mechanizm Service Worker nie zawiera tradycyjnych nawigacji. Co ciekawe, dla każdego skryptu service worker każda nawigacja w kontrolowanym zestawie stron wygląda jak pobieranie zasobu. To sprawia, że mechanizmy Service Worker stanowią niezwykle atrakcyjną formę scentralizowania większości logiki wydajności w aplikacji internetowej.

Czy mogę zobaczyć, co się zmieniło?

Interesuje mnie dyskusja i dane techniczne