Informacje o tym, co zostało wdrożone, jak zmierzono wpływ i jakie kompromisy trzeba było wprowadzić.
Tło
Wystarczy, że wyszukasz w Google dowolny temat, a otrzymasz od razu rozpoznawalną stronę z trafnymi i istotnymi wynikami. Prawdopodobnie nie wiesz, że ta strona wyników wyszukiwania jest w pewnych przypadkach obsługiwana przez potężną technologię internetową zwaną elementem usługi.
Wdrożenie obsługi service workera w wyszukiwarce Google bez negatywnego wpływu na wydajność wymagało zaangażowania kilkudziesięciu inżynierów z różnych zespołów. To historia tego, co zostało wdrożone, jak mierzono skuteczność i jakie kompromisy trzeba było wprowadzić.
Najważniejsze powody korzystania z usług dla programistów
Dodawanie do aplikacji internetowej serwisu internetowego, podobnie jak wprowadzanie zmian w architekturze witryny, powinno być poprzedzone określeniem jasnych celów. Zespół wyszukiwarki Google wymienił kilka głównych powodów, dla których warto było zastosować usługę w tle.
Ograniczone przechowywanie w pamięci podręcznej wyników wyszukiwania
Zespół wyszukiwarki Google stwierdził, że użytkownicy często wyszukiwali te same hasła więcej niż raz w krótkim czasie. Zamiast wywoływać nowe żądanie na zapleczu tylko po to, aby uzyskać te same wyniki, zespół ds. wyszukiwania postanowił skorzystać z pamięci podręcznej i wypełniać powtarzające się żądania lokalnie.
Nie można lekceważyć znaczenia aktualności. Czasami użytkownicy wielokrotnie wyszukują te same hasła, ponieważ jest to rozwijający się temat, a oni oczekują aktualnych wyników. Użycie service workera pozwala zespołowi ds. wyszukiwania zaimplementować szczegółową logikę, aby kontrolować czas trwania wyników wyszukiwania przechowywanych lokalnie w pamięci podręcznej, oraz osiągnąć dokładną równowagę między szybkością a świeżością, która ich zdaniem najlepiej służy użytkownikom.
Ważne funkcje offline
Dodatkowo zespół wyszukiwarki Google chciał zapewnić użytkownikom większą użyteczność offline. Gdy użytkownik chce dowiedzieć się czegoś na dany temat, przechodzi bezpośrednio na stronę wyszukiwarki Google i rozpoczyna wyszukiwanie, nie martwiąc się o aktywne połączenie z internetem.
Bez pracownika serwisu odwiedzenie strony wyszukiwania Google w trybie offline prowadziłoby do standardowej strony błędu sieci w przeglądarce, a użytkownicy musieliby pamiętać, aby wrócić i spróbować ponownie, gdy tylko połączenie zostanie przywrócone. Dzięki service workerowi możesz wyświetlić niestandardową odpowiedź HTML offline i umożliwić użytkownikom natychmiastowe wpisanie zapytania.
Wyniki nie będą dostępne, dopóki nie będzie połączenia z internetem, ale usługa workera umożliwia odroczenie wyszukiwania i wysłanie go na serwery Google, gdy tylko urządzenie ponownie połączy się z internetem, korzystając z interfejsu Background Sync API.
Inteligentniejsze buforowanie i przesyłanie kodu JavaScript
Innym powodem było zoptymalizowanie buforowania i wczytywania modułowego kodu JavaScript, który obsługuje różne typy funkcji na stronie wyników wyszukiwania. Pakowanie kodu JavaScriptu ma wiele zalet, które są przydatne, gdy nie ma potrzeby angażowania workerów usług, dlatego zespół wyszukiwarki nie chciał całkowicie rezygnować z pakowania.
Korzystając z możliwości usługi workera w zakresie wersji i zapisywania w pamięci podręcznej szczegółowych fragmentów kodu JavaScriptu w czasie wykonywania, zespół Search podejrzewał, że może zmniejszyć częstotliwość zastępowania pamięci podręcznej i zapewnić, że kod JavaScriptu używany ponownie w przyszłości będzie efektywnie zapisywany w pamięci podręcznej. Logika w usługowym komponencie roboczym może analizować wychodzące żądanie HTTP dotyczące pakietu zawierającego wiele modułów JavaScript, a następnie realizować je, łącząc ze sobą wiele modułów zapisanych w miejscowym pamięci podręcznej – w praktyce oznacza to „rozbrajanie” pakietu, gdy jest to możliwe. Pozwala to zaoszczędzić przepustowość użytkownika i poprawić ogólną szybkość reakcji.
Korzystanie z przechowywanego w pamięci podręcznej kodu JavaScriptu w ramach usługi workera przynosi też korzyści w zakresie wydajności: w Chrome przechowywana i wykorzystywana jest reprezentacja tego kodu w postaci sformatowanego kodu bajtowego, co pozwala ograniczyć ilość pracy, jaką należy wykonać w czasie wykonywania, aby uruchomić kod JavaScript na stronie.
Problemy i rozwiązania
Oto kilka przeszkód, które trzeba było pokonać, aby osiągnąć zamierzone cele. Chociaż niektóre z nich są specyficzne dla wyszukiwarki Google, wiele z nich dotyczy wielu witryn, które rozważają wdrożenie usług workerów.
Problem: obciążenie skryptu service worker
Największym wyzwaniem i jedynym prawdziwym problemem przy wdrażaniu usługi workera w wyszukiwarce Google było zapewnienie, aby nie wykonywała ona żadnych działań, które mogłyby zwiększyć opóźnienia odczuwane przez użytkownika. Wyszukiwarka Google bardzo poważnie traktuje wydajność i w przeszłości blokowała uruchamianie nowych funkcji, jeśli nawet o kilka dziesiąt milisekund wydłużały czas oczekiwania dla danej grupy użytkowników.
Gdy zespół zaczął zbierać dane o wydajności podczas swoich pierwszych eksperymentów, stało się jasne, że pojawi się problem. Kod HTML zwracany w odpowiedzi na żądania nawigacyjne na stronie wyników wyszukiwania jest dynamiczny i bardzo zróżnicowany w zależności od logiki, która musi być wykonywana na serwerach WWW wyszukiwarki. Obecnie nie ma możliwości, aby worker usługi mógł odtworzyć tę logikę i natychmiast zwrócić zaszyfrowany kod HTML. Może jedynie przekazać żądania nawigacyjne do serwerów WWW backendu, co wymaga wysłania żądania sieciowego.
Bez usługowego workera żądanie sieci jest wysyłane natychmiast po nawigacji użytkownika. Gdy usługa robocza zostanie zarejestrowana, zawsze trzeba ją uruchomić i dać jej możliwość wykonania fetchobsług zdarzeń, nawet jeśli nie ma szans, że te moduły obsługi pobierania będą robić coś innego niż tylko łączyć się z siecią. Czas potrzebny na uruchomienie i wykonywanie kodu usługi to czysta nadwyżka dodana do każdej nawigacji:
W przypadku implementacji usług workerów czas reakcji jest zbyt długi, aby uzasadniał jakiekolwiek inne korzyści. Na podstawie pomiarów czasu uruchamiania usług na urządzeniach w rzeczywistych warunkach zespół stwierdził, że czas uruchamiania jest bardzo zróżnicowany. Na niektórych tanich urządzeniach mobilnych uruchamianie usługi zajmuje prawie tyle samo czasu, co wysłanie żądania sieci dotyczącego strony wyników w formacie HTML.
Rozwiązanie: użyj wstępnego wczytania nawigacji
Najważniejszą funkcją, która umożliwiła zespołowi wyszukiwarki Google wdrożenie usługi workera, jest wstępny ładunek nawigacji. Wstępne wczytywanie danych nawigacyjnych to kluczowy element wydajności dla każdego serwisu workera, który musi używać odpowiedzi z sieci, aby spełniać żądania nawigacyjne. Przekazuje przeglądarce wskazówkę, aby zaczęła wysyłać żądanie nawigacji natychmiast, w tym samym momencie, gdy uruchamia się usługa:
Dopóki czas uruchamiania pracownika usługi jest krótszy niż czas oczekiwania na odpowiedź z sieci, nie powinno być żadnych opóźnień spowodowanych przez pracownika usługi.
Zespół ds. wyszukiwania musiał też unikać korzystania z usług w przypadku słabszych urządzeń mobilnych, na których czas uruchamiania usługi mógł przekroczyć czas żądania nawigacji. Ponieważ nie ma ścisłych zasad dotyczących tego, co jest „niskobudżetowym” urządzeniem, opracowaliśmy heurystyczny algorytm sprawdzający łączną ilość pamięci RAM zainstalowanej na urządzeniu. Urządzenia z mniej niż 2 GB pamięci należą do kategorii urządzeń niskiego poziomu, na których czas uruchamiania usługi roboczej byłby nie do przyjęcia.
Dostępna przestrzeń dyskowa to kolejna kwestia, ponieważ pełny zestaw zasobów do umieszczenia w pamięci podręcznej na przyszłość może zajmować kilka megabajtów. navigator.storageInterfejs pozwala stronie wyszukiwarki Google z wyprzedzeniem określić, czy próby zapisania danych w pamięci podręcznej mogą się nie udać z powodu przekroczenia limitu miejsca na dane.
Zespół wyszukiwarki miał więc do dyspozycji wiele kryteriów, które mógł wykorzystać do określenia, czy użyć service workera: jeśli użytkownik wchodzi na stronę wyszukiwarki Google za pomocą przeglądarki obsługującej wstępny wczyt nawigacji, ma co najmniej 2 gigabajty pamięci RAM i wystarczająco dużo wolnego miejsca na dane, to service worker jest zarejestrowany. Przeglądarki i urządzenia, które nie spełniają tych kryteriów, nie będą miały dostępu do usługi Service Worker, ale nadal będą korzystać z tych samych funkcji wyszukiwarki Google.
Jednym z efektów ubocznych tej selektywnej rejestracji jest możliwość wysłania mniejszego, bardziej wydajnego procesu obsługi. Kierowanie na dość nowe przeglądarki do uruchamiania kodu usługi usuwa narzut na transpilację i polyfille w starszych przeglądarkach. W efekcie udało się wyeliminować około 8 kilobajtów niezwinszowanego kodu JavaScriptu z łącznego rozmiaru implementacji usługi.
Problem: zakresy skryptów service worker
Gdy zespół ds. wyszukiwania przeprowadził wystarczającą liczbę eksperymentów dotyczących opóźnień i uzyskał pewność, że korzystanie z wstępnego wczytywania nawigacji stanowi praktyczną, neutralną pod względem opóźnień drogę do korzystania z elementu service worker, na pierwszy plan zaczęły wysuwać się pewne praktyczne kwestie. Jeden z tych problemów dotyczy reguł określania zakresu usługi. Zakres skryptu service worker określa, nad którymi stronami może on przejąć kontrolę.
Określanie zakresu działa na podstawie prefiksu ścieżki adresu URL. W przypadku domen, które hostują jedną aplikację internetową, nie jest to problemem, ponieważ zwykle używasz skryptu service worker z maksymalnym zakresem /, który może przejąć kontrolę nad dowolną stroną w domenie.
Struktura adresów URL wyszukiwarki Google jest jednak nieco bardziej skomplikowana.
Jeśli skrypt service worker miałby maksymalny zakres /, mógłby przejąć kontrolę nad każdą stroną hostowaną w domenie / (lub jej odpowiedniku regionalnym), a w tej domenie znajdują się adresy URL, które nie mają nic wspólnego z wyszukiwarką Google.www.google.com Bardziej rozsądny i ograniczony zakres to /search, który pozwoliłby przynajmniej wyeliminować adresy URL całkowicie niezwiązane z wynikami wyszukiwania.
Niestety nawet ten adres URL /search jest używany w różnych odmianach wyników wyszukiwania Google, a parametry zapytania w adresie URL określają, jaki konkretny typ wyniku wyszukiwania jest wyświetlany. Niektóre z nich korzystają z całkowicie innych baz kodu niż tradycyjna strona wyników wyszukiwania w internecie. Na przykład wyszukiwarka obrazów i wyszukiwarka Zakupów wyświetlają się pod adresem URL /search z różnymi parametrami zapytania, ale żaden z tych interfejsów nie był jeszcze gotowy do obsługi własnych pracowników obsługi klienta.
Rozwiązanie: utworzenie ramowego rozwiązania do wysyłania i przekierowywania
Chociaż istnieją niektóre propozycje, które umożliwiają określenie zakresów skryptu service worker za pomocą czegoś bardziej zaawansowanego niż prefiksy ścieżek adresów URL, zespół wyszukiwarki Google nie mógł wdrożyć skryptu service worker, który nie wykonywał żadnych działań na podzbiorze stron, nad którymi sprawował kontrolę.
Aby temu zaradzić, zespół Google Search opracował niestandardowy system kierowania i przesyłania danych, który można skonfigurować tak, aby sprawdzał kryteria takie jak parametry zapytania na stronie klienta, i na ich podstawie określał, którą ścieżkę kodu ma wybrać. Zamiast twardego kodowania reguł system został zaprojektowany tak, aby był elastyczny i umożliwiał zespołom, które korzystają z tej samej przestrzeni adresów URL, takim jak wyszukiwarka obrazów czy wyszukiwarka Zakupy, dodanie własnej logiki usługi workera w przyszłości, 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 konkretnego konta. Zalogowani użytkownicy są identyfikowani za pomocą określonych plików cookie przeglądarki, które są szanowanym i powszechnie obsługiwanym standardem.
Jednym z minusów używania plików cookie przeglądarki jest to, że nie są one dostępne w ramach skryptu service worker. Nie ma też możliwości automatycznego sprawdzenia ich wartości ani upewnienia się, że nie zmieniły się z powodu wylogowania użytkownika lub przełączenia kont. (W trakcie są prace nad udostępnianiem dostępu do plików cookie usługom działającym w tle, ale w momencie pisania tego artykułu podejście to jest eksperymentalne i nie jest powszechnie obsługiwane).
Niezgodność między widokiem bieżącego zalogowanego użytkownika w usługach workera a rzeczywistym użytkownikiem zalogowanym w interfejsie internetowym wyszukiwarki Google może prowadzić do nieprawidłowo spersonalizowanych wyników wyszukiwania lub nieprawidłowo przypisanych danych i rejestrowania. Każdy z tych scenariuszy awarii byłby poważnym problemem dla zespołu wyszukiwarki Google.
Rozwiązanie: wysyłanie plików cookie za pomocą postMessage
Zamiast czekać na wdrożenie interfejsów API w wersji eksperymentalnej i zapewnianie bezpośredniego dostępu do plików cookie przeglądarki w ramach usługi pomocniczej, zespół wyszukiwarki Google wdrożył tymczasowe rozwiązanie: gdy tylko wczytuje się strona kontrolowana przez usługę pomocniczą, odczytuje ona odpowiednie pliki cookie i wysyła je do usługi pomocniczej za pomocą interfejsu postMessage().
Następnie sprawdza bieżącą wartość pliku cookie w porównaniu z oczekiwaną wartością. Jeśli występuje niezgodność, usuwa z magazynu wszelkie dane dotyczące użytkownika i ponownie wczytuje stronę wyników wyszukiwania bez nieprawidłowej personalizacji.
Konkretne kroki, które usługa w tle wykonuje, aby przywrócić stan domyślny, są specyficzne dla wymagań wyszukiwarki Google, ale ogólne podejście może być przydatne dla innych deweloperów, którzy pracują z danymi spersonalizowanymi na podstawie kluczy w plikach cookie przeglądarki.
Problem: eksperymenty i dynamika
Jak już wspomnieliśmy, zespół wyszukiwarki Google bardzo często przeprowadza eksperymenty w produkcji i testuje efekty działania nowego kodu oraz funkcji w rzeczywistych warunkach, zanim włączy je domyślnie. Może to być nieco kłopotliwe w przypadku statycznego workera usługi, który w dużej mierze korzysta z danych w pamięci podręcznej, ponieważ dołączanie i wyłączanie użytkowników do eksperymentów często wymaga komunikacji z serwerem backendu.
Rozwiązanie: skrypt service workera generowany dynamicznie
Zespół zdecydował się na użycie dynamicznie generowanego skryptu service workera, który jest dostosowywany przez serwer WWW do każdego użytkownika zamiast pojedynczego statycznego skryptu service workera generowanego z wyprzedzeniem. Informacje o eksperymentach, które mogą wpływać na zachowanie usługi lub żądania sieci, są zawarte bezpośrednio w spersonalizowanych skryptach usługi. Zmiana zestawów aktywnych doświadczeń dla użytkownika odbywa się za pomocą kombinacji tradycyjnych technik, takich jak pliki cookie w przeglądarce, oraz wyświetlania zaktualizowanego kodu w zarejestrowanym adresie URL usługi.
Korzystanie ze skryptu usługi generowanego dynamicznie ułatwia też zapewnienie ucieczki w nieprawdopodobnym przypadku, gdy w implementacji usługi jest krytyczny błąd, którego należy uniknąć. Dynamiczna odpowiedź serwera może być implementacją no-op, która skutecznie wyłącza usługę workera dla niektórych lub wszystkich obecnych użytkowników.
Problem: koordynacja aktualizacji
Jednym z najtrudniejszych wyzwań, przed którymi stoją użytkownicy, jest opracowanie rozsądnego kompromisu między unikaniem sieci na rzecz pamięci podręcznej, a jednoczesnym zapewnieniem, aby obecni użytkownicy otrzymywali ważne aktualizacje i zmiany w krótkim czasie po ich wdrożenie w produkcji. Prawidłowe wyważenie zależy od wielu czynników:
- Czy Twoja aplikacja internetowa to długo działająca aplikacja jednostronicowa, którą użytkownik może otwierać w nieskończoność, bez przechodzenia na nowe strony.
- Jak często wdrażasz aktualizacje serwera WWW.
- Czy przeciętny użytkownik akceptuje korzystanie z nieco przestarzałej wersji aplikacji internetowej, czy też priorytetem jest aktualność.
Podczas eksperymentowania z usługami działającymi w tle zespół Google Search prowadził eksperymenty w ramach zaplanowanych aktualizacji zaplecza, aby dane i wrażenia użytkowników były bardziej zbliżone do tego, co użytkownicy widzą w rzeczywistych warunkach.
Rozwiązanie: zachowaj równowagę między świeżością a wykorzystaniem pamięci podręcznej
Po przetestowaniu wielu różnych opcji konfiguracji zespół wyszukiwarki Google stwierdził, że następująca konfiguracja zapewnia odpowiednią równowagę między świeżością a wykorzystaniem pamięci podręcznej.
Adres URL skryptu usługi workera jest wyświetlany z nagłówkiem odpowiedzi Cache-Control: private, max-age=1500 (1500 sekund, czyli 25 minut) i zarejestrowany z wartością updateViaCache równą „all”, aby zapewnić uwzględnienie tego nagłówka. Jak zapewne wiesz, backend wyszukiwarki Google to rozległy, globalnie rozproszony zbiór serwerów, który musi działać możliwie najdłużej. Wdrażanie zmiany, która ma wpływ na zawartość skryptu service workera, odbywa się w sposób ciągły.
Jeśli użytkownik wejdzie na backend, który został zaktualizowany, a następnie szybko przejdzie na inną stronę, która korzysta z backendu, który nie otrzymał jeszcze zaktualizowanego workera usługi, 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 znaczących wad. Zaletą korzystania z tego zachowania jest znaczne ograniczenie ruchu otrzymywanego przez punkt końcowy, który dynamicznie generuje skrypt usługi.
Dodatkowo w odpowiedzi HTTP skryptu usługi w ramach usługi internetowej ustawiany jest nagłówek ETag, aby po upływie 25 minut od sprawdzenia dostępności aktualizacji serwer mógł efektywnie odpowiedzieć odpowiedzią HTTP 304, jeśli w tym czasie nie wprowadzono żadnych aktualizacji usługi internetowej.
Chociaż niektóre interakcje w aplikacji internetowej wyszukiwarki Google korzystają z przełączania się między stronami w stylu aplikacji (np. za pomocą interfejsu History API), wyszukiwarka Google jest w większości tradycyjną aplikacją internetową, która korzysta z „prawdziwych” przełączeń. Ta opcja jest dostępna, gdy zespół zdecyduje, że warto użyć 2 opcji przyspieszających cykl aktualizacji usługi:
clients.claim()
i
skipWaiting().
Klikanie w interfejsie wyszukiwarki Google zwykle powoduje przejście do nowych dokumentów HTML. Wywołanie skipWaiting zapewnia, że zaktualizowany serwis worker dostaje szansę na obsłużenie nowych żądań nawigacji natychmiast po instalacji. Podobnie wywołanie clients.claim() oznacza, że zaktualizowany service worker może zacząć kontrolować wszystkie otwarte strony wyszukiwarki Google, które nie są kontrolowane, po aktywacji service workera.
Podejście stosowane przez wyszukiwarkę Google niekoniecznie sprawdza się w przypadku wszystkich – jest ono wynikiem starannego testowania A/B różnych kombinacji opcji wyświetlania, aż do znalezienia tej, która sprawdza się najlepiej.
Deweloperzy, którzy mogą wdrażać aktualizacje szybciej dzięki infrastrukturze backendu, mogą preferować, aby przeglądarka sprawdzała, czy nie ma zaktualizowanego skryptu service workera, tak często, jak to możliwe, zawsze ignorując pamięć podręczną HTTP.
Jeśli tworzysz aplikację jednostronicową, którą użytkownicy mogą trzymać otwartą przez długi czas, prawdopodobnie nie powinieneś używać skipWaiting(), ponieważ możesz napotkać problemy z niespójnościami w pamięci podręcznej, jeśli zezwolisz na aktywację nowego pracownika usługi, gdy są aktywne długotrwałe klienci.
Podsumowanie
Domyślnie skrypty service worker nie są neutralne pod względem wydajności.
Dodanie do aplikacji internetowej pracownika usługi oznacza wstawienie dodatkowego fragmentu kodu JavaScript, który musi zostać załadowany i wykonany, zanim aplikacja internetowa otrzyma odpowiedzi na swoje żądania. Jeśli odpowiedzi pochodzą z pamięci podręcznej, a nie z sieci, to obciążenie związane z uruchomieniem workera usługi jest zwykle znikome w porównaniu z zyskiem w kształcie wydajności dzięki korzystaniu z pamięci podręcznej. Jeśli jednak wiesz, że Twój serwis worker zawsze musi konsultować się z siecią podczas obsługi żądań nawigacji, użycie wstępnego wczytania nawigacji może znacznie poprawić wydajność.
Serwisy są (nadal!) stopniowo ulepszane
Wsparcie dla usług działających w tle jest dziś znacznie lepsze niż jeszcze rok temu. Wszystkie nowoczesne przeglądarki oferują obecnie co najmniej pewną obsługę usług działających w tle, ale niektóre zaawansowane funkcje usług działających w tle, takie jak synchronizacja w tle i wstępne wczytywanie nawigacji, nie są jeszcze powszechnie dostępne. Sprawdzanie funkcji w przypadku określonego podzbioru funkcji, których potrzebujesz, i rejestrowanie tylko wtedy, gdy są one dostępne, to nadal rozsądne podejście.
Podobnie, jeśli przeprowadziłeś już eksperymenty w warunkach rzeczywistych i wiesz, że na urządzeniach niskiej klasy usługa workera nie działa dobrze z dodatkowym obciążeniem, możesz też zrezygnować z rejestracji usługi workera w tych scenariuszach.
Nadal należy traktować usługę workera jako ulepszenie progresywne, które jest dodawane do aplikacji internetowej, gdy spełnione są wszystkie wymagania wstępne, a usługa workera wnosi pozytywny wkład w wrażenia użytkownika i ogólne działanie.
Pomiar wszystkiego
Jedynym sposobem na ustalenie, czy wdrożenie workera usługi miało pozytywny czy negatywny wpływ na wrażenia użytkowników, jest przeprowadzenie eksperymentu i zmierzenie wyników.
Szczegóły konfigurowania wiarygodnych pomiarów zależą od dostawcy usługi analitycznej, z której korzystasz, oraz od tego, jak zwykle przeprowadzasz eksperymenty w ramach swojej konfiguracji wdrożenia. Jedno z podejść, polegające na zbieraniu danych za pomocą Google Analytics, zostało szczegółowo opisane w tym opracowaniu, które opiera się na doświadczeniach z użyciem usług działających w tle w aplikacji internetowej Google I/O.
Cele niespełnione
Chociaż wielu członków społeczności programistów łączy skrypty service worker z progresywnymi aplikacjami internetowymi, tworzenie „Google Search PWA” nie było początkowym celem zespołu. Aplikacja internetowa wyszukiwarki Google nie udostępnia obecnie metadanych za pomocą pliku manifestu aplikacji internetowej ani nie zachęca użytkowników do przejścia przez proces dodawania aplikacji do ekranu głównego. Zespół ds. wyszukiwania jest obecnie zadowolony z tego, że użytkownicy trafiają do aplikacji internetowej przez tradycyjne punkty wejścia w wyszukiwarce Google.
Zamiast dążyć do tego, aby wyszukiwarka Google w wersji internetowej była odpowiednikiem zainstalowanej aplikacji, podczas wstępnego wdrażania skupiliśmy się na stopniowym ulepszaniu dotychczasowej witryny.
Podziękowania
Dziękujemy całemu zespołowi programistów wyszukiwarki Google za wdrożenie service workera i udostępnienie materiałów pomocniczych, które posłużyły do napisania tego artykułu. Szczególne podziękowania kierujemy do Philippe Golle, Rajesha Jagannathna 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 przeanalizował zalety i wady obecnej architektury usług workerów. Opisywany powyżej serwis web worker jest wycofywany. Wraz z rozwojem infrastruktury internetowej wyszukiwarki Google zespół może ponownie przyjrzeć się projektowi skryptu service worker.