Historia dostawy, sposobu pomiaru wpływu i powiązanych kompromisów.
Wprowadzenie
Wystarczy wyszukać w Google dowolny temat. Wyświetli się łatwo rozpoznawalna strona z istotnymi, trafnymi wynikami. Prawdopodobnie nie zdajesz sobie sprawy, że ta strona wyników wyszukiwania jest w określonych sytuacjach obsługiwana przez zaawansowane narzędzie internetowe nazywane skryptem service worker.
Wprowadzenie obsługi mechanizmów Service Worker w wyszukiwarce Google bez negatywnego wpływu na wydajność wymagało pracy wielu inżynierów w różnych zespołach. Znajdziesz tu informacje o tym, co zostało wysłane, jak mierzono skuteczność i jakie udało się osiągnąć.
Najważniejsze powody, dla których warto poznać mechanizmy Service Worker
Dodanie skryptu service worker do aplikacji internetowej, tak jak wprowadzanie zmian w architekturze witryny, powinno odbywać się z uwzględnieniem jasno określonych celów. Zespół wyszukiwarki Google stworzył kilka kluczowych powodów, dla których warto było zastanowić się nad dodaniem skryptu service worker.
Ograniczone zapisywanie wyników wyszukiwania w pamięci podręcznej
Zespół wyszukiwarki Google odkrył, że użytkownicy często wyszukują te same hasła w krótkim czasie więcej niż raz. Zamiast uruchamiać nowe żądanie backendu w celu uzyskania prawdopodobnie takich samych wyników, zespół wyszukiwarki chciał wykorzystać buforowanie i lokalnie zrealizować te żądania.
Nie można pomijać aktualności, a czasem użytkownicy wielokrotnie wyszukują te same hasła, ponieważ jest to temat ewoluujący i oczekują nowych wyników. Skrypt service worker pozwala zespołowi wyszukiwania wdrożyć szczegółową logikę, by kontrolować okres przechowywania wyników wyszukiwania lokalnie zapisanych w pamięci podręcznej. Dzięki temu może uzyskać dokładną równowagę między szybkością a aktualnością treści, która według nich jest korzystna dla użytkowników.
Znaczące działanie offline
Zespół wyszukiwarki Google chciał też, by użytkownicy mogli w łatwy sposób tworzyć treści offline. Gdy użytkownik chce dowiedzieć się czegoś na dany temat, powinien od razu przejść do strony wyszukiwarki Google i zacząć wyszukiwać informacje, nie martwiąc się o aktywne połączenie internetowe.
Gdyby nie skrypt service worker, odwiedzenie strony wyszukiwania Google w trybie offline prowadziłoby po prostu do standardowej strony z błędami sieciowymi w przeglądarce, a użytkownicy musieliby pamiętać o odzyskaniu połączenia i spróbowaniu jeszcze raz po zwróceniu połączenia. Skrypt service worker pozwala wysłać niestandardową odpowiedź HTML offline i umożliwić użytkownikom natychmiastowe wpisywanie zapytań.
Wyniki będą dostępne dopiero po nawiązaniu połączenia z internetem, ale skrypt service worker pozwala odroczyć i wysłać wyszukiwanie na serwery Google zaraz po powrocie urządzenia do trybu online za pomocą interfejsu API synchronizacji w tle.
Inteligentniejsze buforowanie i wyświetlanie JavaScriptu
Kolejną motywacją była optymalizacja buforowania i wczytywania zmodularyzowanego kodu JavaScript, który obsługuje różne typy funkcji na stronie wyników wyszukiwania. Grupowanie skryptów JavaScript ma wiele zalet, które sprawiają, że korzystanie z pakietów nie wymaga zaangażowania ze strony mechanizmów Service Worker. Dlatego zespół ds. wyszukiwarki nie chciał po prostu całkowicie zrezygnować z grupowania.
Wykorzystując możliwość tworzenia wersji i przechowywania w pamięci podręcznej szczegółowych fragmentów kodu JavaScript w czasie działania przez mechanizm Service Worker, zespół wyszukiwarki podejrzewał, że może zmniejszyć liczbę rezygnacji z pamięci podręcznej i zadbać o odpowiednie buforowanie JavaScriptu. Mechanizm działania mechanizmu Service Worker pozwala analizować wychodzące żądania HTTP pakietów, które zawierają wiele modułów JavaScript, i wypełniać je, łącząc kilka modułów z pamięci lokalnej w miarę możliwości. Zmniejsza to obciążenie przepustowości sieci i poprawę ogólnej reakcji.
Korzystanie z kodu JavaScript w pamięci podręcznej wywoływanego przez mechanizm Service Worker w Chrome ma również zalety w zakresie wydajności: w Chrome przetworzona reprezentacja kodu JavaScriptu jest przechowywana i używana ponownie, co ogranicza ilość pracy wykonywanej w czasie działania w celu wykonania kodu JavaScript na stronie.
Wyzwania i rozwiązania
Oto kilka przeszkód, które trzeba było pokonać, aby osiągnąć określone cele zespołu. Choć niektóre z nich dotyczą tylko wyszukiwarki Google, wiele z nich dotyczy również witryn, które rozważają wdrożenie takich mechanizmów.
Problem: narzut skryptu service worker
Największym wyzwaniem i jedną przeszkodą dla uruchomienia mechanizmu Service Worker w wyszukiwarce Google było sprawdzenie, czy nie wykonuje on niczego, co mogłoby zwiększyć opóźnienia widoczne dla użytkowników. Wyszukiwarka Google traktuje wydajność bardzo poważnie i w przeszłości blokowała wprowadzanie nowych funkcji, jeśli w przypadku danej populacji wyświetlane były nawet dziesiątki milisekund dodatkowego czasu oczekiwania.
Gdy zespół zaczął zbierać dane o skuteczności już w trakcie swoich najwcześniejszych eksperymentów, stało się oczywiste, że jest jakiś problem. Kod HTML zwracany w odpowiedzi na żądania nawigacji na stronie wyników wyszukiwania jest dynamiczny i różni się w znacznym stopniu w zależności od logiki, która musi działać na serwerach WWW wyszukiwarki. Obecnie nie ma możliwości, aby skrypt service worker zreplikował tę logikę i od razu zwrócił kod HTML zapisany w pamięci podręcznej. Najlepsze rozwiązanie to przekazywanie żądań nawigacji do serwerów WWW backendu, co wymaga żądania sieciowego.
Bez skryptu service worker żądanie sieciowe jest wykonywane natychmiast po nawigacji użytkownika. Gdy skrypt service worker jest zarejestrowany, zawsze musi być uruchomiony i dać mu szansę na wykonanie modułów obsługi zdarzeń fetch, nawet jeśli nie jest możliwe, że będą one wykonywać inne działania poza przejściem do sieci. Czas potrzebny na uruchomienie i uruchomienie kodu skryptu service worker to absolutny narzut, dodawany do każdej nawigacji:
Sprawia to, że implementacja mechanizmów Service Worker jest zbyt mała, by uzasadniać inne korzyści. Poza tym zespół odkrył, że na podstawie pomiaru czasu uruchamiania mechanizmów Service Worker na prawdziwych urządzeniach występuje szeroki rozkład czasu uruchamiania, przy czym w przypadku niektórych mniej zaawansowanych urządzeń mobilnych uruchomienie skryptu service worker zajmuje tyle czasu, ile potrzeba na przesłanie żądania sieciowego kodu HTML strony wyników.
Rozwiązanie: użyj wstępnego wczytywania nawigacji
Najważniejszą, podstawową funkcją, która pozwoliła zespołowi wyszukiwarki Google zrobić krok do przodu po uruchomieniu skryptu service worker, jest wstępne wczytywanie nawigacji. Korzystanie z wstępnego wczytywania nawigacji ma kluczowe znaczenie dla wydajności wszystkich mechanizmów Service Worker, które muszą korzystać z odpowiedzi z sieci, aby zrealizować żądania nawigacji. Informuje on przeglądarkę, aby rozpocząć wysyłanie żądania nawigacji zaraz po uruchomieniu skryptu service worker:
O ile czas potrzebny na uruchomienie skryptu service worker jest krótszy niż czas potrzebny na otrzymanie odpowiedzi z sieci, nie powinno to powodować naliczania dodatkowych opóźnień w czasie oczekiwania.
Zespół wyszukiwarki chciał też unikać korzystania z skryptów service worker na słabszych urządzeniach mobilnych, w których czas uruchamiania skryptu może być dłuższy niż czas potrzebny na nawigację. Nie ma stałej i szybkiej reguły określania urządzeń niskobudżetowych, dlatego firma postanowiła sprawdzić całkowitą ilość pamięci RAM zainstalowanej na urządzeniu. Urządzenia mniejsze niż 2 GB pamięci należały do kategorii urządzeń niskiej jakości, w przypadku których czas uruchamiania skryptu service worker byłby niedopuszczalny.
Warto rozważyć dostępne miejsce na dane, ponieważ pełny zbiór zasobów do buforowania do wykorzystania w przyszłości może zajmować kilka megabajtów. Interfejs navigator.storage pozwala stronie wyszukiwarki Google z wyprzedzeniem sprawdzić, czy jej próby zapisu danych w pamięci podręcznej mogą się nie udać z powodu przekroczenia limitu miejsca na dane.
Z tego powodu zespół wyszukiwarki kierował się wieloma kryteriami, których chciał użyć, aby określić, czy chce użyć skryptu service worker. Jeśli użytkownik otwiera stronę wyszukiwarki Google w przeglądarce, która obsługuje wstępne wczytywanie nawigacji, ma co najmniej 2 GB pamięci RAM i wystarczającą ilość wolnego miejsca, rejestrowany jest skrypt service worker. Przeglądarki i urządzenia, które nie spełniają tych kryteriów, nie są powiązane z mechanizmem service worker, ale wyszukiwarka Google działa tak samo jak dotychczas.
Jedną z zalet tej selektywnej rejestracji jest możliwość wysyłania mniejszych i wydajniejszych pracowników usługowych. Kierowanie kodu skryptu service worker na stosunkowo nowoczesne przeglądarki eliminuje konieczność transpilacji i kodu polyfill w starszych przeglądarkach. W efekcie wycięto około 8 kilobajtów nieskompresowanego kodu JavaScript z całkowitego rozmiaru implementacji skryptu service worker.
Problem: zakresy mechanizmu Service Worker
Gdy zespół wyszukiwarki przeprowadził wystarczająco dużo eksperymentów dotyczących czasu oczekiwania i uzyskał pewność, że użycie wstępnego wczytywania nawigacji oferuje realną, neutralną ścieżkę do korzystania z skryptu service worker, na pierwszym planie zajęły się pewne praktyczne problemy. Jeden z tych problemów jest związany z regułami określania zakresu skryptu service worker. Zakres skryptu service worker określa, nad którymi stronami może przejąć kontrolę.
Określanie zakresu działa na podstawie prefiksu ścieżki adresu URL. W przypadku domen, w których znajduje się pojedyncza aplikacja internetowa, nie stanowi to problemu, ponieważ zwykle używa się skryptu service worker o maksymalnym zakresie /, który może przejąć kontrolę nad dowolną stroną w domenie.
Jednak struktura adresów URL w wyszukiwarce Google jest nieco bardziej złożona.
Gdyby skrypt service worker otrzymał maksymalny zakres /, mógłby przejąć kontrolę nad każdą stroną hostowaną w domenie www.google.com (lub odpowiedniku regionalnym), a w tej domenie znajdują się adresy URL, które nie mają nic wspólnego z wyszukiwarką Google. Bardziej uzasadnionym i ograniczonym zakresem jest zakres /search, który przynajmniej eliminuje adresy URL zupełnie niezwiązane z wynikami wyszukiwania.
Niestety nawet ta ścieżka adresu URL /search jest niepowtarzalna wśród różnych rodzajów wyników wyszukiwania Google, a parametry zapytania z adresu URL określają, jaki konkretnie rodzaj wyniku wyszukiwania zostanie wyświetlony. Niektóre z nich wykorzystują zupełnie inne
bazy kodów niż tradycyjna strona wyników wyszukiwania w internecie. Na przykład wyszukiwarka grafiki i wyszukiwarka Zakupów wyświetlają się w ścieżce adresu URL /search z innymi parametrami zapytania, ale żaden z tych interfejsów nie był jeszcze gotowy do udostępnienia własnych narzędzi service worker.
Rozwiązanie: utwórz platformę wysyłania i routingu
Chociaż istnieją pewne propozycje, które pozwalają na zastosowanie czegoś bardziej zaawansowanego niż prefiksy ścieżek adresów URL do określania zakresów instancji roboczych, zespół wyszukiwarki Google utknął przy wdrażaniu skryptu service worker, który nie wykonał żadnego działania na podzbiorze kontrolowanych stron.
Aby obejść ten problem, zespół wyszukiwarki Google stworzył dostosowaną platformę wysyłania i kierowania, którą można skonfigurować tak, aby sprawdzała takie kryteria jak parametry zapytania na stronie klienta i używała ich do określania ścieżki kodu do odwoływania się. Zamiast reguł kodowania, system został stworzony w taki sposób, aby był elastyczny i umożliwiał zespołom, które korzystają z tej samej przestrzeni adresów URL, np. wyszukiwarce grafiki i wyszukiwarki produktowej, stosować własną logikę service worker, jeśli zdecydują się ją wdrożyć.
Problem: spersonalizowane wyniki i dane
Użytkownicy mogą logować się w wyszukiwarce Google za pomocą swoich kont Google, a wyniki wyszukiwania mogą być dostosowywane na podstawie danych z ich kont. Zalogowani użytkownicy są rozpoznawani za pomocą określonych plików cookie przeglądarki, czyli cenionego i powszechnie obsługiwanego standardu.
Wadą plików cookie w przeglądarce jest jednak to, że nie są one ujawniane przez mechanizm service worker i nie ma możliwości automatycznego sprawdzenia ich wartości ani sprawdzenia, czy nie zmieniły się w wyniku wylogowania się użytkownika lub przełączenia konta. Pracujemy nad umożliwieniem zapewnienia dostępu do plików cookie pracownikom service worker, ale na razie jest to eksperymentalne rozwiązanie, które nie jest powszechnie obsługiwane.
Niezgodność między widokiem aktualnie zalogowanego użytkownika a rzeczywistym zalogowanym użytkownikiem w interfejsie wyszukiwarki Google może skutkować nieprawidłowo spersonalizowanymi wynikami wyszukiwania lub niewłaściwie przypisanymi danymi i logowaniem. Każdy z tych scenariuszy niepowodzenia byłby poważnym problemem dla zespołu wyszukiwarki Google.
Rozwiązanie: wysyłanie plików cookie za pomocą metody postMessage
Zamiast czekać na uruchomienie eksperymentalnych interfejsów API i bezpośredni dostęp do plików cookie przeglądarki w skrypcie service worker, zespół wyszukiwarki Google zastosował rozwiązanie tymczasowe: za każdym razem, gdy wczytuje się strona kontrolowana przez ten mechanizm, strona odczytuje odpowiednie pliki cookie i używa postMessage(), aby wysyłać je do skryptu service worker.
Skrypt service worker porównuje następnie wartość pliku cookie z oczekiwaną wartością. Jeśli coś się nie zgadza, usuwa z pamięci dane dotyczące konkretnego użytkownika i ponownie wczytuje stronę wyników wyszukiwania bez jakiejkolwiek nieprawidłowej personalizacji.
Konkretne czynności wykonywane przez mechanizm Service Worker w celu przywrócenia ustawień do wartości bazowej są specyficzne dla wyszukiwarki Google, ale to samo ogólne podejście może być przydatne dla innych deweloperów, którzy zajmują się spersonalizowanymi danymi odczytywanymi z plików cookie przeglądarek.
Zadanie: eksperymenty i dynamika
Jak już wspomnieliśmy, zespół wyszukiwarki Google w dużej mierze polega na przeprowadzaniu eksperymentów w środowisku produkcyjnym oraz testowania efektów nowego kodu i funkcji w świecie rzeczywistym przed ich domyślnym włączeniem. Może to stanowić spore wyzwanie w przypadku statycznego skryptu service worker, który w dużym stopniu opiera się na danych zapisanych w pamięci podręcznej, ponieważ włączanie i wyłączanie eksperymentów przez użytkowników często wymaga komunikacji z serwerem backendu.
Rozwiązanie: dynamicznie generowany skrypt skryptu service worker
Rozwiązanie, które wybrał zespół, polegało na użyciu dynamicznie generowanego skryptu skryptu service worker, który jest dostosowywany przez serwer WWW dla każdego użytkownika, zamiast pojedynczego, statycznego skryptu skryptu service worker generowanego z wyprzedzeniem. Informacje o eksperymentach, które mogą wpływać na zachowanie skryptu service worker lub ogólnie na żądania sieciowe, są zawarte bezpośrednio w tym niestandardowym skrypcie skryptu service worker. Zmiana zestawów aktywnych doświadczeń dla użytkownika odbywa się przez połączenie tradycyjnych metod, takich jak pliki cookie przeglądarki, a także udostępnianie zaktualizowanego kodu w zarejestrowanym adresie URL skryptu service worker.
Zastosowanie dynamicznie generowanego skryptu skryptu service worker ułatwia także zapewnienie wyjścia awaryjnego w sytuacji, gdy w implementacji skryptu service worker występuje błąd krytyczny, którego należy unikać. Dynamiczna odpowiedź instancji roboczej serwera może mieć postać implementacji braku operacji, która powoduje wyłączenie skryptu service worker u niektórych lub wszystkich bieżących użytkowników.
Problem: koordynowanie aktualizacji
Jednym z najtrudniejszych wyzwań, z jakimi spotykają się rzeczywiste mechanizmy Service Worker, jest znalezienie rozsądnego kompromisu między unikaniem sieci na rzecz pamięci podręcznej, a jednocześnie zapewnieniem istniejących użytkownikom dostępu do krytycznych aktualizacji i zmian zaraz po wdrożeniu ich w środowisku produkcyjnym. Odpowiednia równowaga zależy od wielu czynników:
- Czy Twoja aplikacja internetowa to działająca od dawna aplikacja z jedną stroną, która jest otwarta bez otwierania nowych stron.
- Częstotliwość wdrażania w przypadku aktualizacji serwera WWW backendu.
- To, czy przeciętny użytkownik toleruje używanie nieco nieaktualnej wersji Twojej aplikacji internetowej, czy też dostępność jest najwyższym priorytetem.
Eksperymentując z mechanizmami Service Worker, zespół wyszukiwarki Google zadbał o to, aby eksperymenty były prowadzone w ramach szeregu zaplanowanych aktualizacji backendu, aby zapewnić, że wskaźniki i wrażenia użytkowników będą bardziej zgodne z rzeczywistością.
Rozwiązanie: zrównoważenie aktualności wyników i wykorzystania pamięci podręcznej
Po przetestowaniu różnych opcji konfiguracyjnych zespół wyszukiwarki Google odkrył, że opisana konfiguracja zapewnia odpowiednią równowagę między aktualnością danych a wykorzystaniem pamięci podręcznej.
Adres URL skryptu skryptu service worker jest wyświetlany z nagłówkiem odpowiedzi Cache-Control: private, max-age=1500 (1500 sekund lub 25 minut) i jest rejestrowany z aktualizacją updateViaCache z wartością „all”. Dzięki temu nagłówek jest przestrzegany. Backend wyszukiwarki Google to duży, rozproszony globalnie zbiór serwerów, który wymaga maksymalnie 100% czasu działania. Wdrażanie zmiany, która wpływa na zawartość skryptu skryptu service worker, odbywa się w sposób kroczący.
Jeśli użytkownik korzysta z backendu, który został zaktualizowany, a następnie szybko przejdzie na inną stronę, która trafi na backend, który nie otrzymał jeszcze zaktualizowanego skryptu service worker, użytkownik będzie wielokrotnie przełączać się między wersjami. Dlatego polecenie przeglądarki, by sprawdzała dostępność zaktualizowanego skryptu tylko wtedy, gdy od ostatniego sprawdzenia minęło 25 minut, nie ma znaczącej wady. Zaletą tej opcji jest znaczne zmniejszenie ruchu odbieranego przez punkt końcowy, który dynamicznie generuje skrypt skryptu service worker.
Dodatkowo w odpowiedzi HTTP skryptu skryptu service worker jest ustawiany nagłówek ETag, dzięki czemu po 25 minutach sprawdzania aktualizacji serwer może skutecznie odpowiedzieć, wysyłając odpowiedź HTTP 304, jeśli w międzyczasie nie były wdrażane żadne aktualizacje w tym mechanizmie.
Niektóre interakcje w aplikacji internetowej wyszukiwarki Google wykorzystują nawigację w aplikacji na jednej stronie (tj. za pomocą interfejsu History API), ale przeważnie wyszukiwarka Google to tradycyjna aplikacja internetowa, która używa „prawdziwej” nawigacji. Ta wiedza przychodzi, gdy zespół uznał, że korzystne będzie skorzystanie z 2 opcji, które przyspieszają cykl życia aktualizacji mechanizmów Service Worker: clients.claim() i skipWaiting().
Kliknięcie interfejsu wyszukiwarki Google zwykle powoduje przejście do nowych dokumentów HTML. Wywołanie skipWaiting sprawia, że zaktualizowany skrypt service worker może obsłużyć nowe żądania nawigacji natychmiast po instalacji. Podobnie wywołanie clients.claim() oznacza, że zaktualizowany skrypt service worker może kontrolować wszystkie otwarte strony wyszukiwarki Google, które nie są kontrolowane, po aktywacji skryptu service worker.
Podejście zastosowane w wyszukiwarce Google nie musi sprawdzić się w każdym przypadku. Było to wynikiem skrupulatnych testów A/B różnych kombinacji opcji wyświetlania, aż do momentu znalezienia tej, która sprawdza się najlepiej w ich przypadku.
Deweloperzy, których infrastruktura backendu umożliwia szybsze wdrażanie aktualizacji, mogą preferować wyszukiwanie zaktualizowanego skryptu skryptu service worker tak często, jak to możliwe, zawsze ignorując pamięć podręczną HTTP.
Jeśli tworzysz aplikację jednostronicową, która może pozostawać otwarta przez dłuższy czas, korzystanie z skipWaiting() prawdopodobnie nie jest odpowiednim rozwiązaniem, ponieważ zezwalasz na aktywowanie nowego skryptu service worker w czasie długotrwałych klientów i ryzyko wystąpienia niespójności pamięci podręcznej.
Podsumowanie
Domyślnie mechanizmy Service Worker nie są neutralne pod względem wydajności
Dodanie skryptu service worker do aplikacji internetowej oznacza wstawienie dodatkowego fragmentu kodu JavaScript, który musi być wczytywany i wykonywany, zanim aplikacja zacznie odpowiadać na żądania. Jeśli te odpowiedzi pochodzą z lokalnej pamięci podręcznej, a nie z sieci, nakład pracy związany z uruchamianiem skryptu service worker jest zwykle minimalny w porównaniu z wydajnością, która wynika z opracowania głównie pamięci podręcznej. Jeśli jednak wiesz, że mechanizm Service Worker zawsze musi konsultować się z siecią podczas obsługi żądań nawigacji, korzystanie z wstępnego wczytywania nawigacji ma kluczowe znaczenie dla wydajności.
Skrypty service worker stanowią (nadal!) udoskonalenie
Historia pomocy mechanizmów Service Worker jest dziś znacznie ciekawsza niż rok temu. Wszystkie nowoczesne przeglądarki oferują teraz przynajmniej pewną obsługę mechanizmów Service Worker, ale niestety niektóre zaawansowane funkcje, takie jak synchronizacja w tle i wstępne wczytywanie nawigacji, nie są powszechnie stosowane. Warto sprawdzać funkcje w przypadku tylko tych konkretnych podzbiorów funkcji, których potrzebujesz, i rejestrować mechanizmy Service Worker tylko wtedy, gdy są dostępne.
Podobnie jeśli przeprowadzasz eksperymenty w terenie i wiesz, że urządzenia niskiej jakości mają złą wydajność z powodu dodatkowych obciążeń wywołanych przez mechanizm service worker, w takich sytuacjach możesz też zrezygnować z rejestrowania mechanizmów Service Worker.
Skrypty service worker powinny być nadal traktowane jako ulepszenia progresywne dodawane do aplikacji internetowej po spełnieniu wszystkich wymagań wstępnych, a skrypty service worker wnosi pozytywne korzyści dla użytkowników i ogólną wydajność wczytywania.
Mierz wszystko
Jedynym sposobem na określenie, czy dostawa zasobu service worker ma pozytywny czy negatywny wpływ na wrażenia użytkowników, jest eksperymentowanie i mierzenie wyników.
Szczegóły konfiguracji przydatnych pomiarów zależą od tego, z usług którego dostawcy usług analitycznych korzystasz, i od tego, jak zwykle przeprowadzasz eksperymenty w konfiguracji wdrożenia. Jedna z metod, obejmująca zbieranie danych za pomocą Google Analytics, została szczegółowo omówiona w tym studium przypadku opartym na doświadczeniach związanych z używaniem mechanizmów Service Worker w aplikacji internetowej Google I/O.
Inne niż cele
Chociaż wielu członków społeczności programistów stron internetowych łączy pracowników usług z progresywnymi aplikacjami internetowymi, utworzenie „PWA dla wyszukiwarki Google” nie było na początku celem zespołu. Obecnie aplikacja internetowa Wyszukiwarka Google nie udostępnia metadanych w pliku manifestu aplikacji internetowej ani nie zachęca użytkowników do wykonania opcji dodawania do ekranu głównego. Zespół ds. wyszukiwarki jest obecnie zadowolony z tego, że użytkownicy trafiają do swojej aplikacji internetowej przez tradycyjne punkty wejścia w wyszukiwarce Google.
Zamiast przekształcać działanie wyszukiwarki Google w odpowiadający temu, co można spodziewać się po zainstalowanej aplikacji, skoncentrowaliśmy się na początkowym ulepszeniu istniejącej witryny.
Podziękowania
Dziękujemy całemu zespołowi ds. tworzenia stron internetowych wyszukiwarki Google za jego pracę nad wdrożeniem skryptów service worker i podzielenie się podstawowymi materiałami powstałymi w tym artykule. Szczególnie dziękujemy Philippe Golle, Rajeshowi Jagannathan, R. Samuel Klatchko, Andy Martone, Leonardo Peña, Rachel Shearer, Greg Terrono i Clay Woolam.
Aktualizacja (październik 2021 r.): od momentu opublikowania tego artykułu zespół wyszukiwarki Google ponownie przeanalizował zalety i wady obecnej architektury service worker. Opisany powyżej skrypt service worker jest wycofywany. W miarę ewoluowania infrastruktury wyszukiwarki Google zespół może zmieniać projekt mechanizmu Service Worker.