Pomiar wydajności skryptu service worker

Paul Kinlan

Jake Archibald nie tylko wyraził obawy, że jego umiejętności programistyczne słabną i zanikają, ale też przekonująco wykazał, że dzięki inteligentnemu korzystaniu z usług w tle można znacznie poprawić wydajność witryny lub aplikacji. Obejrzyj film, aby poznać szczegóły.

Jeśli chcesz przyspieszyć wczytywanie stron, jak sugeruje Jake, musisz zrozumieć, jak moduły usług wpływają na żądania stron.

Interfejsy Resource Timing i User Timing API są kluczowymi komponentami infrastruktury RUM (monitorowanie prawdziwych użytkowników) w wielu witrynach, ponieważ pozwalają kompleksowo analizować wydajność witryny z perspektywy wszystkich użytkowników (innym zastosowaniem jest wykrywanie wstrzykiwania treści). Krótko mówiąc, pozwala ona zrozumieć niemal każdy aspekt każdej żądania sieci wysłanego z Twojej witryny, chyba że masz usługę lub element sieci.

Oto krótki przykład użycia tego polecenia do uzyskania listy wszystkich żądań wysłanych do domeny, która nie jest bieżącą domeną.

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 dotyczące pomiaru czasu ładowania zasobów i czasu użytkownika zostały utworzone i wdrożone, zanim usługa wtyczki została wprowadzona przez inżynierów. Z tego powodu kod powyżej nie jest w stanie określić, jak usługa wtyczki wpłynęła na pomiar.

Niedawno wprowadzone zmiany w Chrome 45 (w wersji beta w lipcu 2015 r.) ułatwią Ci kontrolowanie wydajności sieci u wszystkich użytkowników, ponieważ umożliwią wszystkim procesom (procesom internetowym i usługowym) dostęp do interfejsów API Resource Timing i User Timing.

Dostęp do danych o wydajności z pośrednictwem usługi pomocniczej

Największą zmianą jest dodanie obiektu performance do kontekstu Worker (Web i ServiceWorker), który pozwoli Ci teraz poznać czasy wykonywania wszystkich żądań wysyłanych w kontekście workera. Pozwoli Ci też ustawić własne punkty kontrolne do pomiaru wykonania kodu JS. Jeśli widzisz tylko to, co dzieje się w ramach bieżącego okna, nie zobaczysz ważnych informacji o czasie z tych źródeł:

  • fetch() żądań wysłanych w ramach zdarzenia oninstall w usługowym workerze
  • Aby poznać skuteczność działania usługi dla użytkowników, możesz teraz śledzić fetch() żądania wysyłane podczas zapisywania danych w pamięci podręcznej w zdarzeniu onpush.
  • Na koniec fetch() żądania, które są przechwytywane przez onfetch przetwarzacz.

Ostatni punkt jest ważny. Usługę można traktować jako pośrednika między interfejsem internetowym a siecią. Obiekt performance w komponencie window widzi tylko czasy i informacje dotyczące części żądania, którą wywołuje. Nie ma on wiedzy o usługach workera znajdujących się między klientem a siecią, więc nie może zrozumieć wpływu usług workera.

Jak mogę z niego korzystać?

Typowy serwis worker, który obsługuje tryb offline, ma etap instalacji, na którym pobiera i zapisuje wszystkie zasoby na potrzeby późniejszego użycia.

Można go na przykład użyć do rejestrowania danych o czasie trwania instalacji, aby podejmować świadome decyzje dotyczące poprawy wydajności instalacji na podstawie rzeczywistego użytkowania przez 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 ich witryny. Narzędzia takie jak Google Analytics już teraz generują raporty z danymi o szybkości witryny za pomocą interfejsu API do pomiaru czasu trwania nawigacji, ale trzeba je zaktualizować, aby uwzględniały analizę wydajności z kontekstu Workera.

Czy interfejs Navigation Timing API trafi do usług pracujących w tle

Obecnie nie planujemy dodawać interfejsu Navigation Timing API do kontekstu usługi, ponieważ w usługach nie ma tradycyjnej nawigacji. Ciekawostką jest to, że dla skryptu service worker każda nawigacja w ramach kontrolowanego przez niego zbioru stron wygląda jak pobieranie zasobu. To samo czyni skrypty service worker niezwykle atrakcyjnym sposobem na scentralizowanie większości logiki działania w aplikacji internetowej.

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

Interesują mnie dyskusje i specyfikacje