Opis tego, co zostało wdrożone, jak mierzono wpływ i jakie kompromisy zostały poczynione.
Data publikacji: 20 czerwca 2019 r.
Wyszukaj w Google dowolny temat, a zobaczysz od razu rozpoznawalną stronę z trafnymi i przydatnymi wynikami. Prawdopodobnie nie zdajesz sobie sprawy, że w określonych sytuacjach ta strona wyników wyszukiwania jest obsługiwana przez zaawansowaną technologię internetową zwaną service workerem.
Wprowadzenie obsługi service workerów w wyszukiwarce Google bez negatywnego wpływu na wydajność wymagało pracy dziesiątek inżynierów z różnych zespołów. Opisuje ona, co zostało wdrożone, jak mierzono wydajność i jakie kompromisy zostały poczynione.
Główne powody, dla których warto poznać service workerów
Dodanie do aplikacji internetowej elementu service worker, podobnie jak wprowadzenie w witrynie jakichkolwiek zmian w architekturze, powinno być poprzedzone określeniem jasnych celów. Zespół wyszukiwarki Google miał kilka kluczowych powodów, dla których warto było rozważyć dodanie komponentu Service Worker.
Ograniczone buforowanie wyników wyszukiwania
Zespół wyszukiwarki Google zauważył, że użytkownicy często wyszukują te same hasła więcej niż raz w krótkim czasie. Zespół wyszukiwarki chciał wykorzystać pamięć podręczną i realizować powtarzające się żądania lokalnie, zamiast wywoływać nowe żądanie backendu tylko po to, aby uzyskać prawdopodobnie te same wyniki.
Świeżość informacji jest bardzo ważna. Czasami użytkownicy wielokrotnie wyszukują te same hasła, ponieważ temat się rozwija i oczekują świeżych wyników. Użycie service workera pozwala zespołowi wyszukiwarki wdrożyć szczegółową logikę kontrolującą czas życia lokalnie buforowanych wyników wyszukiwania i osiągnąć dokładną równowagę między szybkością a aktualnością, która jego zdaniem najlepiej służy użytkownikom.
Wartościowe doświadczenia offline
Dodatkowo zespół wyszukiwarki Google chciał zapewnić użytkownikom przydatne funkcje offline. Gdy użytkownik chce dowiedzieć się czegoś na dany temat, chce przejść bezpośrednio do strony wyszukiwarki Google i zacząć wyszukiwać, nie martwiąc się o aktywne połączenie z internetem.
Bez service workera odwiedzenie strony wyszukiwarki Google w trybie offline spowodowałoby wyświetlenie standardowej strony błędu sieciowego przeglądarki, a użytkownicy musieliby pamiętać, aby wrócić i spróbować ponownie po przywróceniu połączenia. Dzięki mechanizmowi Service Worker można wyświetlać niestandardową odpowiedź HTML w trybie offline i umożliwiać użytkownikom natychmiastowe wpisywanie zapytań.
Wyniki będą dostępne dopiero po nawiązaniu połączenia z internetem, ale service worker umożliwia odroczenie wyszukiwania i przesłanie go na serwery Google, gdy tylko urządzenie ponownie połączy się z internetem za pomocą interfejsu Background Sync API.
Inteligentniejsze buforowanie i przesyłanie JavaScriptu
Kolejną motywacją była optymalizacja buforowania i wczytywania modułowego kodu JavaScript, który obsługuje różne typy funkcji na stronie wyników wyszukiwania. Bundling JavaScriptu ma wiele zalet, które są przydatne, gdy nie ma zaangażowania service workera, więc zespół wyszukiwarki nie chciał całkowicie zrezygnować z bundlingu.
Zespół wyszukiwarki podejrzewał, że dzięki wykorzystaniu możliwości wersji i pamięci podręcznej drobnych fragmentów JavaScriptu w czasie działania usługi można zmniejszyć ilość zmian w pamięci podręcznej i zapewnić efektywne przechowywanie w niej kodu JavaScript, który będzie używany w przyszłości. Logika w usłudze Service Worker może analizować wychodzące żądanie HTTP dotyczące pakietu zawierającego wiele modułów JavaScript i realizować je, łącząc wiele lokalnie buforowanych modułów, co w miarę możliwości powoduje „rozpakowywanie”. Pozwala to zaoszczędzić przepustowość użytkownika i zwiększyć ogólną responsywność.
Korzystanie z pamięci podręcznej JavaScriptu obsługiwanej przez service worker ma też zalety związane z wydajnością: w Chrome przeanalizowana reprezentacja kodu bajtowego JavaScriptu jest przechowywana i ponownie wykorzystywana, co zmniejsza ilość pracy, jaką należy wykonać w czasie działania, aby uruchomić JavaScript na stronie.
Wyzwania i rozwiązania
Oto kilka przeszkód, które trzeba było pokonać, aby osiągnąć założone cele zespołu. Niektóre z tych wyzwań są specyficzne dla wyszukiwarki Google, ale wiele z nich dotyczy szerokiego zakresu witryn, które mogą rozważać wdrożenie service workerów.
Problem: narzut skryptu service worker
Największym wyzwaniem i jedyną prawdziwą przeszkodą w uruchomieniu komponentu Service Worker w wyszukiwarce Google było zapewnienie, że nie będzie on wykonywać żadnych działań, które mogłyby zwiększyć opóźnienia odczuwane przez użytkowników. Wyszukiwarka Google bardzo poważnie traktuje wydajność i w przeszłości blokowała wprowadzanie nowych funkcji, jeśli powodowały one nawet kilkadziesiąt milisekund dodatkowego opóźnienia w przypadku danej grupy użytkowników.
Gdy zespół zaczął zbierać dane o skuteczności podczas pierwszych eksperymentów, stało się jasne, że pojawi się problem. Kod HTML zwracany w odpowiedzi na żądania nawigacyjne dotyczące strony wyników wyszukiwania jest dynamiczny i znacznie się różni w zależności od logiki, która musi być uruchomiona na serwerach WWW wyszukiwarki. Obecnie nie ma możliwości, aby service worker powielił tę logikę i natychmiast zwrócił HTML z pamięci podręcznej. Najlepsze, co może zrobić, to przekazać żądania nawigacji do serwerów backendu, co wymaga żądania sieciowego.
Bez komponentu Service Worker to żądanie sieciowe jest wysyłane natychmiast po przejściu użytkownika do innej strony. Gdy usługa Service Worker jest zarejestrowana, zawsze musi zostać uruchomiona i mieć możliwość wykonania fetchprocedur obsługi zdarzeń, nawet jeśli nie ma szansy, aby te procedury obsługi pobierania zrobiły coś innego niż przejście do sieci. Czas potrzebny na uruchomienie i wykonanie kodu usługi Service Worker to czysty narzut dodawany do każdej nawigacji:
W takim przypadku implementacja service workera jest zbyt wolna, aby uzasadnić inne korzyści. Zespół odkrył też, że na podstawie pomiarów czasu uruchamiania service workerów na rzeczywistych urządzeniach mobilnych występuje szeroki zakres czasów uruchamiania. W przypadku niektórych urządzeń mobilnych z niższej półki uruchomienie service workera zajmuje prawie tyle samo czasu, co wysłanie żądania sieciowego dotyczącego kodu HTML strony z wynikami.
Rozwiązanie: użyj wstępnego wczytywania nawigacji
Najważniejszą funkcją, która umożliwiła zespołowi wyszukiwarki Google wprowadzenie usługi Service Worker, jest wstępne wczytywanie nawigacji. Wstępne wczytywanie nawigacji to kluczowa korzyść dla każdego modułu Service Worker, który musi używać odpowiedzi z sieci, aby spełniać żądania nawigacji. Podpowiada przeglądarce, aby natychmiast rozpoczęła wysyłanie żądania nawigacji, w tym samym czasie, w którym uruchamia się usługa Service Worker:
Dopóki czas uruchamiania service workera jest krótszy niż czas potrzebny na uzyskanie odpowiedzi z sieci, service worker nie powinien powodować żadnych opóźnień.
Zespół wyszukiwarki musiał też unikać używania usługi Service Worker na urządzeniach mobilnych z niższej półki, na których czas uruchamiania usługi Service Worker mógł przekraczać czas żądania nawigacji. Nie ma ścisłej definicji „urządzenia z niższej półki”, więc zespół opracował heurystykę polegającą na sprawdzaniu całkowitej ilości pamięci RAM zainstalowanej na urządzeniu. Wszystkie urządzenia z pamięcią mniejszą niż 2 GB należały do kategorii urządzeń z niższej półki, w których czas uruchamiania instancji roboczej usługi byłby nie do zaakceptowania.
Kolejną kwestią jest dostępna ilość miejsca na dane, ponieważ pełny zestaw zasobów do zapisania w pamięci podręcznej na potrzeby przyszłego wykorzystania może zajmować kilka megabajtów. navigator.storageInterfejs umożliwia stronie wyszukiwarki Google z wyprzedzeniem określenie, czy próby buforowania danych mogą się nie powieść z powodu przekroczenia limitu miejsca na dane.
Zespół wyszukiwarki miał więc do dyspozycji kilka kryteriów, które mógł wykorzystać do określenia, czy używać service workera: jeśli użytkownik wchodzi na stronę wyszukiwarki Google za pomocą przeglądarki obsługującej wstępne wczytywanie nawigacji i ma co najmniej 2 GB pamięci RAM oraz wystarczającą ilość wolnego miejsca na dane, rejestrowany jest service worker. Przeglądarki i urządzenia, które nie spełniają tych kryteriów, nie będą miały service workera, ale nadal będą korzystać z wyszukiwarki Google w taki sam sposób jak dotychczas.
Jedną z zalet selektywnej rejestracji jest możliwość dostarczania mniejszego i wydajniejszego komponentu service worker. Kierowanie na dość nowoczesne przeglądarki w celu uruchamiania kodu service worker eliminuje narzut związany z transpilacją i polyfillami w przypadku starszych przeglądarek. Dzięki temu udało się zmniejszyć rozmiar kodu JavaScript bez kompresji o około 8 kilobajtów.
Problem: zakresy skryptu service worker
Gdy zespół wyszukiwarki przeprowadził wystarczającą liczbę eksperymentów dotyczących opóźnień i zyskał pewność, że korzystanie z wstępnego wczytywania nawigacji zapewnia mu opłacalną, neutralną pod względem opóźnień ścieżkę korzystania z service workera, na pierwszy plan zaczęły wysuwać się pewne praktyczne problemy. Jeden z tych problemów dotyczy reguł zakresu skryptu service worker. Zakres skryptu service worker określa, nad którymi stronami może on potencjalnie przejąć kontrolę.
Określanie zakresu działa na podstawie prefiksu ścieżki adresu URL. W przypadku domen, które hostują jedną aplikację internetową, 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.
Struktura adresów URL wyszukiwarki Google jest jednak nieco bardziej skomplikowana.
Gdyby skrypt service worker miał maksymalny zakres /, mógłby przejąć kontrolę nad każdą stroną hostowaną w domenie / (lub jej regionalnym odpowiedniku), a w tej domenie znajdują się adresy URL, które nie mają nic wspólnego z wyszukiwarką Google.www.google.com Bardziej rozsądny, ograniczony zakres to /search, który przynajmniej wyeliminuje adresy URL całkowicie niezwiązane z wynikami wyszukiwania.
Niestety ten /search ścieżka URL jest wspólna dla różnych rodzajów wyników wyszukiwania Google, a parametry zapytania URL określają, który konkretny typ wyniku wyszukiwania jest wyświetlany. Niektóre z nich korzystają z całkowicie innych baz kodu niż tradycyjna strona wyników wyszukiwania. Na przykład wyszukiwarka grafiki i wyszukiwarka produktów są obsługiwane w ścieżce URL /search z różnymi parametrami zapytania, ale żaden z tych interfejsów nie był jeszcze gotowy do udostępnienia własnego mechanizmu Service Worker.
Rozwiązanie: utworzenie platformy wysyłkowej i routingowej
Istnieją pewne propozycje, które pozwalają na używanie czegoś bardziej zaawansowanego niż prefiksy ścieżki URL do określania zakresów skryptu service worker, ale zespół wyszukiwarki Google musiał wdrożyć skrypt service worker, który nie robił nic w przypadku podzbioru kontrolowanych przez niego stron.
Aby to obejść, zespół wyszukiwarki Google stworzył specjalną platformę wysyłania i kierowania, którą można było skonfigurować tak, aby sprawdzała kryteria takie jak parametry zapytania na stronie klienta i na ich podstawie określała, którą ścieżkę kodu należy wybrać. Zamiast zakodowanych na stałe reguł system został zaprojektowany tak, aby był elastyczny i umożliwiał zespołom korzystającym z tej samej przestrzeni adresów URL, takim jak wyszukiwarka grafiki i wyszukiwarka produktów, w przyszłości dodawanie własnej logiki 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 do danych konkretnego konta. Zalogowani użytkownicy są identyfikowani za pomocą konkretnych plików cookie przeglądarki, które są sprawdzonym i powszechnie obsługiwanym standardem.
Jednak minusem korzystania z plików cookie przeglądarki jest to, że nie są one widoczne w skrypcie service worker i nie można automatycznie sprawdzać ich wartości ani upewniać się, że nie uległy zmianie w wyniku wylogowania się użytkownika lub przełączenia konta. (Trwają prace nad umożliwieniem dostępu do plików cookie w przypadku skryptów service worker, ale w momencie pisania tego artykułu to podejście ma charakter eksperymentalny i nie jest powszechnie obsługiwane).
Niezgodność między widokiem bieżącego zalogowanego użytkownika w usłudze service worker a rzeczywistym użytkownikiem zalogowanym w interfejsie internetowym wyszukiwarki Google może prowadzić do nieprawidłowo spersonalizowanych wyników wyszukiwania lub błędnie przypisanych danych i logów. 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ą funkcji postMessage
Zamiast czekać na wprowadzenie eksperymentalnych interfejsów API, które zapewnią bezpośredni dostęp do plików cookie przeglądarki w usłudze Service Worker, zespół wyszukiwarki Google zdecydował się na rozwiązanie tymczasowe: za każdym razem, gdy wczytywana jest strona kontrolowana przez usługę Service Worker, odczytuje ona odpowiednie pliki cookie i używa funkcji postMessage(), aby wysłać je do usługi Service Worker.
Następnie sprawdza on, czy bieżąca wartość pliku cookie jest zgodna z oczekiwaną wartością. Jeśli nie, podejmuje działania mające na celu usunięcie z pamięci wszystkich danych dotyczących użytkownika i ponowne wczytanie strony wyników wyszukiwania bez nieprawidłowej personalizacji.
Konkretne kroki, które wykonuje service worker, aby przywrócić stan początkowy, są dostosowane do wymagań wyszukiwarki Google, ale to samo ogólne podejście może być przydatne dla innych deweloperów, którzy mają do czynienia ze spersonalizowanymi danymi powiązanymi z plikami cookie przeglądarki.
Problem: eksperymenty i dynamiczność
Jak już wspomnieliśmy, zespół wyszukiwarki Google w dużym stopniu opiera się na przeprowadzaniu eksperymentów w środowisku produkcyjnym i testowaniu wpływu nowego kodu oraz funkcji w rzeczywistych warunkach, zanim włączy je domyślnie. W przypadku statycznego modułu service worker, który w dużej mierze opiera się na danych z pamięci podręcznej, może to być nieco trudne, ponieważ włączanie i wyłączanie użytkowników z eksperymentów często wymaga komunikacji z serwerem backendu.
Rozwiązanie: dynamicznie generowany skrypt service worker
Zespół zdecydował się na użycie generowanego dynamicznie skryptu service worker, dostosowywanego przez serwer internetowy do każdego użytkownika, zamiast jednego statycznego skryptu service worker, który jest generowany z wyprzedzeniem. Informacje o eksperymentach, które mogą wpływać na działanie komponentu Service Worker lub ogólnie na żądania sieciowe, są uwzględniane bezpośrednio w tych dostosowanych skryptach komponentu Service Worker. Zmiana zestawów aktywnych eksperymentów dla użytkownika odbywa się za pomocą kombinacji tradycyjnych technik, takich jak pliki cookie przeglądarki, a także przez udostępnianie zaktualizowanego kodu w zarejestrowanym adresie URL service workera.
Używanie dynamicznie generowanego skryptu service workera ułatwia też zapewnienie mechanizmu awaryjnego w mało prawdopodobnym przypadku, gdy implementacja service workera zawiera poważny błąd, którego należy unikać. Dynamiczna odpowiedź serwera może być implementacją bez działania, co spowoduje wyłączenie usługi Service Worker dla niektórych lub wszystkich obecnych użytkowników.
Problem: koordynowanie aktualizacji
Jednym z najtrudniejszych wyzwań, przed jakimi staje każde wdrożenie usługi Service Worker w rzeczywistym świecie, jest znalezienie rozsądnego kompromisu między unikaniem sieci na rzecz pamięci podręcznej a zapewnieniem, że obecni użytkownicy otrzymają krytyczne aktualizacje i zmiany wkrótce po ich wdrożeniu w środowisku produkcyjnym. Odpowiednie saldo zależy od wielu czynników:
- Czy Twoja aplikacja internetowa to długotrwała aplikacja jednostronicowa, którą użytkownik może mieć otwartą bezterminowo, bez przechodzenia do nowych stron.
- Jak często wdrażane są aktualizacje serwera WWW backendu.
- Czy przeciętny użytkownik zaakceptuje korzystanie z nieco starszej wersji aplikacji internetowej, czy też świeżość jest dla niego najważniejsza.
Podczas eksperymentowania z usługami Google Search zespół zadbał o to, aby eksperymenty były przeprowadzane w ramach wielu zaplanowanych aktualizacji backendu. Dzięki temu dane i wrażenia użytkowników były bardziej zbliżone do tego, co użytkownicy powracający widzieli w rzeczywistości.
Rozwiązanie: zachowanie równowagi między świeżością a wykorzystaniem pamięci podręcznej
Po przetestowaniu wielu różnych opcji konfiguracji zespół wyszukiwarki Google stwierdził, że poniższa konfiguracja zapewnia odpowiednią równowagę między aktualnością a wykorzystaniem pamięci podręcznej.
Adres URL skryptu service workera jest wyświetlany z nagłówkiem odpowiedzi Cache-Control: private, max-age=1500 (1500 sekund, czyli 25 minut) i rejestrowany z ustawieniem updateViaCache na „all”, aby zapewnić, że nagłówek jest uwzględniany. Backend wyszukiwarki Google to, jak można sobie wyobrazić, duży, globalnie rozproszony zbiór serwerów, który wymaga jak najbliższej 100% dostępności. Wdrażanie zmian, które wpłyną na zawartość skryptu service worker, odbywa się stopniowo.
Jeśli użytkownik trafi na backend, który został zaktualizowany, a następnie szybko przejdzie na inną stronę, która trafi na backend, który nie otrzymał jeszcze zaktualizowanego service workera, będzie wielokrotnie przełączać się między wersjami. Dlatego poinformowanie przeglądarki, aby sprawdzała, czy skrypt został zaktualizowany, tylko wtedy, gdy od ostatniego sprawdzenia minęło 25 minut, nie ma większych wad. Zaletą wyrażenia zgody na takie działanie jest znaczne ograniczenie ruchu otrzymywanego przez punkt końcowy, który dynamicznie generuje skrypt service worker.
Dodatkowo w odpowiedzi HTTP skryptu service workera ustawiany jest nagłówek ETag, co zapewnia, że gdy po upływie 25 minut zostanie przeprowadzona kontrola aktualizacji, serwer może skutecznie odpowiedzieć odpowiedzią HTTP 304, jeśli w międzyczasie nie wprowadzono żadnych aktualizacji wdrożonego service workera.
Niektóre interakcje w aplikacji internetowej wyszukiwarki Google korzystają z nawigacji w stylu aplikacji na jednej stronie (np. za pomocą History API), ale w większości przypadków wyszukiwarka Google jest tradycyjną aplikacją internetową, która korzysta z „prawdziwej” nawigacji. Ma to znaczenie, gdy zespół uzna, że warto użyć 2 opcji, które przyspieszają cykl życia aktualizacji service workera: clients.claim() i skipWaiting().
Klikanie elementów interfejsu wyszukiwarki Google zwykle powoduje przejście do nowych dokumentów HTML. Wywołanie skipWaiting zapewnia, że zaktualizowany service worker będzie mógł obsługiwać nowe żądania nawigacji natychmiast po instalacji. Podobnie wywołanie clients.claim() oznacza, że po aktywacji service workera zaktualizowany service worker może zacząć kontrolować wszystkie otwarte strony wyszukiwarki Google, które nie są kontrolowane.
Podejście, które zastosowała wyszukiwarka Google, niekoniecznie jest rozwiązaniem odpowiednim dla wszystkich. Jest ono wynikiem starannego testowania A/B różnych kombinacji opcji wyświetlania, aż znaleziono tę, która najlepiej się sprawdza.
Deweloperzy, których infrastruktura backendu umożliwia szybsze wdrażanie aktualizacji, mogą preferować, aby przeglądarka jak najczęściej sprawdzała zaktualizowany skrypt service worker, zawsze ignorując pamięć podręczną HTTP.
Jeśli tworzysz aplikację jednostronicową, którą użytkownicy mogą pozostawiać otwartą przez dłuższy czas, używanie skipWaiting() prawdopodobnie nie jest dobrym rozwiązaniem. Jeśli zezwolisz na aktywację nowego modułu service worker, gdy istnieją długotrwałe klienty, ryzykujesz wystąpienie niespójności w pamięci podręcznej.
Podsumowanie
Domyślnie skrypty service worker nie mają neutralnego wpływu na wydajność
Dodanie do aplikacji internetowej komponentu service worker oznacza wstawienie dodatkowego fragmentu kodu JavaScript, który musi zostać wczytany i wykonany, zanim aplikacja internetowa otrzyma odpowiedzi na swoje żądania. Jeśli te odpowiedzi pochodzą z pamięci podręcznej na urządzeniu, a nie z sieci, obciążenie związane z działaniem service workera jest zwykle znikome w porównaniu z korzyściami wynikającymi z podejścia „najpierw pamięć podręczna”. Jeśli jednak wiesz, że w przypadku obsługi żądań nawigacyjnych service worker zawsze musi sprawdzać sieć, wstępne wczytywanie nawigacji jest kluczowym czynnikiem wpływającym na wydajność.
Service worker to (nadal!) progresywne ulepszenie
Obsługa service workerów jest dziś znacznie lepsza niż jeszcze rok temu. Wszystkie nowoczesne przeglądarki obsługują przynajmniej niektóre funkcje service worker, ale niestety niektóre zaawansowane funkcje service worker, takie jak synchronizacja w tle i wstępne wczytywanie nawigacji, nie są wdrażane powszechnie. Sprawdzanie funkcji pod kątem konkretnego podzbioru funkcji, których potrzebujesz, i rejestrowanie usługi Service Worker tylko wtedy, gdy są one dostępne, to nadal rozsądne podejście.
Podobnie, jeśli przeprowadzisz eksperymenty w warunkach rzeczywistych i zauważysz, że urządzenia z niższej półki działają słabo z dodatkowym obciążeniem związanym z service workerem, możesz w takich przypadkach zrezygnować z jego rejestracji.
Nadal traktuj service worker jako ulepszenie progresywne, które jest dodawane do aplikacji internetowej, gdy spełnione są wszystkie wymagania wstępne, a service worker poprawia wrażenia użytkowników i ogólną wydajność ładowania.
Mierz wszystko
Jedynym sposobem na sprawdzenie, czy wdrożenie service workera miało pozytywny czy negatywny wpływ na wrażenia użytkowników, jest przeprowadzenie eksperymentu i pomiar wyników.
Szczegóły konfiguracji miarodajnych pomiarów zależą od dostawcy usług analitycznych, z którego korzystasz, oraz od tego, jak zwykle przeprowadzasz eksperymenty w swojej konfiguracji wdrożenia. Jedno z podejść, polegające na zbieraniu danych za pomocą Google Analytics, zostało szczegółowo opisane w tym studium przypadku, które powstało na podstawie doświadczeń z używaniem service workerów w aplikacji internetowej Google I/O.
Nieuznane bramki
Wielu programistów internetowych kojarzy skrypty service worker z progresywnymi aplikacjami internetowymi, ale stworzenie „progresywnej aplikacji internetowej wyszukiwarki Google” nie było początkowym celem zespołu. Aplikacja internetowa Wyszukiwarka Google nie udostępnia metadanych w pliku manifestu aplikacji internetowej ani nie zachęca użytkowników do korzystania z procesu dodawania do ekranu głównego. Zespół wyszukiwarki jest zadowolony z tego, że użytkownicy trafiają do aplikacji internetowej za pomocą klasycznych punktów wejścia w wyszukiwarce Google.
Zamiast próbować przekształcić wyszukiwarkę Google w odpowiednik zainstalowanej aplikacji, w początkowej wersji skupiliśmy się na stopniowym ulepszaniu istniejącej witryny.
Podziękowania
Dziękujemy całemu zespołowi ds. rozwoju internetowego wyszukiwarki Google za pracę nad wdrożeniem mechanizmu Service Worker i za udostępnienie materiałów, które posłużyły do napisania tego artykułu. Szczególne podziękowania należą się Philippe’owi Golle, Rajeshowi Jagannathanowi i R. Samuel Klatchko, Andy Martone, Leonardo Peña, Rachel Shearer, Greg Terrono i Clay Woolam.
Aktualizacja (październik 2021 r.): od czasu opublikowania tego artykułu zespół wyszukiwarki Google ponownie ocenił zalety i wady obecnej architektury service workerów. Opisany powyżej service worker zostanie wycofany. W miarę rozwoju infrastruktury internetowej wyszukiwarki Google zespół może ponownie rozważyć projekt skryptu service worker.