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 wtyczki możesz znacznie poprawić wydajność swojej witryny lub aplikacji. Obejrzyj film, aby poznać szczegóły.

Jeśli chcesz przyspieszyć wczytywanie stron, jak sugeruje Jake, musisz zrozumieć, jak zasoby usługowe 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 przypadkiem użycia jest wykrywanie wstrzyknięcia 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 czasu ładowania zasobów i czasu użytkownika zostały utworzone i wdrożone, zanim usługa wątek została wprowadzona przez inżynierów. Kod powyżej nie jest w stanie określić, jak usługa wątek wpływa na działanie kodu.

Ostatnie zmiany w wersji Chrome 45 (beta z lipca 2015 r.) ułatwią Ci zarządzanie wydajnością sieci dla wszystkich użytkowników, ponieważ umożliwią wszystkim procesom typu worker (procesorom internetowym i usługowym) dostęp do interfejsów API Resource Timing i User Timing.

Uzyskiwanie dostępu do danych o wydajności z użyciem usługi pomocniczej

Największą zmianą jest dodanie obiektu performance do kontekstu Workera (Workera i usługa Workera), który pozwoli Ci teraz poznać czasy wykonania wszystkich żądań wysyłanych w kontekście Workera. Pozwoli Ci też ustawić własne punkty 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
  • fetch() żądania wysyłane podczas zapisywania danych w pamięci podręcznej w zdarzeniu onpush można teraz śledzić, aby poznać skuteczność działania dla użytkowników.
  • w końcu fetch() żądania, które są przechwytywane przez onfetch.

Ostatni punkt jest ważny. Usługę wątek pomocniczy można traktować jako serwer proxy, który znajduje się 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ługi 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