Die Geschichte darüber, was veröffentlicht wurde, wie die Auswirkungen gemessen wurden und welche Kompromisse eingegangen wurden.
Hintergrund
Wenn Sie bei Google nach einem beliebigen Thema suchen, wird Ihnen sofort eine Seite mit aussagekräftigen, relevanten Ergebnissen angezeigt. Was Sie wahrscheinlich nicht wussten, ist, dass diese Suchergebnisseite in bestimmten Fällen über eine leistungsstarke Webtechnologie namens Service Worker bereitgestellt wird.
Für die Einführung der Service Worker-Unterstützung für die Google Suche ohne negative Auswirkungen auf die Leistung waren Dutzende von Entwicklern in mehreren Teams erforderlich. Hier erfahren Sie, was veröffentlicht wurde, wie die Leistung gemessen wurde und welche Kompromisse eingegangen wurden.
Wichtige Gründe für die Verwendung von Dienstprogrammen
Das Hinzufügen eines Dienstarbeiters zu einer Webanwendung sollte, genau wie jede architektonische Änderung an Ihrer Website, mit klaren Zielen erfolgen. Für das Google Search-Team gab es einige wichtige Gründe, warum es sich lohnte, einen Service Worker hinzuzufügen.
Eingeschränktes Caching von Suchergebnissen
Das Google Suche-Team hat festgestellt, dass Nutzer häufig innerhalb kurzer Zeit mehrmals nach denselben Begriffen suchen. Anstatt eine neue Backend-Anfrage auszulösen, um wahrscheinlich dieselben Ergebnisse zu erhalten, wollte das Suchteam das Caching nutzen und diese wiederholten Anfragen lokal erfüllen.
Die Bedeutung der Aktualität kann nicht unterschätzt werden. Manchmal suchen Nutzer wiederholt nach denselben Begriffen, weil es sich um ein sich entwickelndes Thema handelt und sie aktuelle Ergebnisse erwarten. Mit einem Service Worker kann das Suchteam eine detaillierte Logik implementieren, um die Lebensdauer der lokal im Cache gespeicherten Suchergebnisse zu steuern und das optimale Gleichgewicht zwischen Geschwindigkeit und Aktualität zu erreichen, das den Nutzern am besten dient.
Sinnvolle Offlinefunktionen
Außerdem wollte das Google Suche-Team eine sinnvolle Offlinenutzung ermöglichen. Wenn Nutzer etwas über ein Thema erfahren möchten, möchten sie direkt zur Google Suche gehen und suchen, ohne sich Gedanken über eine aktive Internetverbindung machen zu müssen.
Ohne Service Worker würde der Besuch der Google-Suchseite im Offlinemodus nur zur Standard-Netzwerkfehlerseite des Browsers führen. Nutzer müssten sich dann merken, später noch einmal zu versuchen, wenn die Verbindung wiederhergestellt ist. Mit einem Service Worker können Sie eine benutzerdefinierte Offline-HTML-Antwort senden und Nutzern ermöglichen, ihre Suchanfrage sofort einzugeben.
Die Ergebnisse sind erst verfügbar, wenn eine Internetverbindung besteht. Mit dem Dienst-Worker kann die Suche jedoch verschoben und an die Google-Server gesendet werden, sobald das Gerät wieder online ist. Dazu wird die Background Sync API verwendet.
Intelligenteres JavaScript-Caching und -Bereitstellen
Ein weiterer Grund war die Optimierung des Cachings und Ladens des modularisierten JavaScript-Codes, der die verschiedenen Arten von Funktionen auf der Suchergebnisseite unterstützt. Das Bündeln von JavaScript bietet eine Reihe von Vorteilen, die sinnvoll sind, wenn keine Service Worker beteiligt sind. Das Suchteam wollte das Bündeln daher nicht einfach ganz einstellen.
Durch die Verwendung der Möglichkeit eines Service Workers, JavaScript-Chunks bei der Laufzeit zu versionieren und im Cache zu speichern, vermutete das Suchteam, dass es die Cache-Auslastung reduzieren und dafür sorgen könnte, dass JavaScript, das in Zukunft wiederverwendet wird, effizient im Cache gespeichert werden kann. Die Logik im Service Worker kann eine ausgehende HTTP-Anfrage für ein Bundle analysieren, das mehrere JavaScript-Module enthält, und sie erfüllen, indem mehrere lokal im Cache gespeicherte Module zusammengesetzt werden. So wird nach Möglichkeit ein „Unbundling“ durchgeführt. Dadurch wird die Bandbreite der Nutzer gespart und die Gesamtreaktionszeit verbessert.
Außerdem bietet die Verwendung von im Cache gespeichertem JavaScript, das von einem Service Worker bereitgestellt wird, Leistungsvorteile: In Chrome wird eine geparste Bytecode-Darstellung dieses JavaScripts gespeichert und wiederverwendet. Dadurch muss bei der Laufzeit weniger Arbeit geleistet werden, um das JavaScript auf der Seite auszuführen.
Herausforderungen und Lösungen
Hier sind einige der Hürden, die überwunden werden mussten, um die angegebenen Ziele des Teams zu erreichen. Einige dieser Herausforderungen sind spezifisch für die Google Suche, viele davon gelten jedoch für eine Vielzahl von Websites, bei denen eine Service Worker-Bereitstellung in Betracht gezogen werden könnte.
Problem: Overhead von Dienstmitarbeitern
Die größte Herausforderung und der einzige echte Stolperstein bei der Einführung eines Service Workers in der Google Suche bestand darin, dafür zu sorgen, dass er nichts tut, was die von Nutzern wahrgenommene Latenz erhöhen könnte. Bei der Google Suche wird die Leistung sehr ernst genommen. In der Vergangenheit wurden neue Funktionen blockiert, wenn sie für eine bestimmte Gruppe von Nutzern zu einer zusätzlichen Latenz von nur wenigen Millisekunden geführt haben.
Als das Team in seinen ersten Tests Leistungsdaten erfasste, wurde schnell klar, dass es ein Problem geben würde. Der HTML-Code, der als Antwort auf Navigationsanfragen für die Suchergebnisseite zurückgegeben wird, ist dynamisch und variiert stark je nach Logik, die auf den Webservern der Google Suche ausgeführt werden muss. Derzeit gibt es keine Möglichkeit für den Service Worker, diese Logik zu replizieren und sofort gecachte HTML-Seiten zurückzugeben. Das Beste, was er tun kann, ist, Navigationsanfragen an die Backend-Webserver weiterzuleiten, was eine Netzwerkanfrage erfordert.
Ohne Service Worker erfolgt diese Netzwerkanfrage sofort nach der Nutzernavigation. Wenn ein Dienstarbeiter registriert ist, muss er immer gestartet und die Möglichkeit gegeben werden, seine fetchEreignis-Handler auszuführen, auch wenn diese Abruf-Handler nichts anderes tun, als das Netzwerk aufzurufen. Die Zeit, die zum Starten und Ausführen des Dienst-Worker-Codes benötigt wird, ist reiner Overhead, der bei jeder Navigation hinzukommt:
Dies führt zu einer zu hohen Latenz bei der Service Worker-Implementierung, um andere Vorteile zu rechtfertigen. Außerdem stellte das Team fest, dass die Startzeiten der Dienstprogramme auf realen Geräten sehr unterschiedlich sind. Auf einigen Low-End-Mobilgeräten dauert es fast genauso lange, den Dienst zu starten, wie die Netzwerkanfrage für die HTML-Seite mit den Ergebnissen.
Lösung: Navigationsvorabladen verwenden
Die wichtigste Funktion, die es dem Team der Google Suche ermöglichte, mit der Einführung von Service Workern fortzufahren, war die Navigationsvorab-Ladefunktion. Die Navigationsvorab-Ladefunktion ist ein wichtiger Leistungsvorteil für alle Service Worker, die eine Antwort vom Netzwerk verwenden müssen, um Navigationsanfragen zu erfüllen. Sie gibt dem Browser einen Hinweis, die Navigationsanfrage sofort zu stellen, also gleichzeitig mit dem Start des Service Workers:
Solange der Start des Service Workers kürzer ist als die Zeit, die für den Empfang einer Antwort vom Netzwerk benötigt wird, sollte es keinen zusätzlichen Latenzoverhead durch den Service Worker geben.
Außerdem musste das Suchteam die Verwendung eines Service Workers auf Low-End-Mobilgeräten vermeiden, da die Startzeit des Service Workers die Navigationsanfrage überschreiten könnte. Da es keine feste Regel dafür gibt, was ein „Low-End-Gerät“ ist, haben sie die Heuristik entwickelt, den gesamten auf dem Gerät installierten RAM zu prüfen. Geräte mit weniger als 2 Gigabyte Arbeitsspeicher wurden in die Kategorie der Low-End-Geräte eingestuft, bei denen die Startzeit von Dienst-Workern inakzeptabel wäre.
Ein weiterer wichtiger Faktor ist der verfügbare Speicherplatz, da die Gesamtzahl der Ressourcen, die für die zukünftige Verwendung im Cache gespeichert werden sollen, mehrere Megabyte betragen kann. Über die navigator.storage-Benutzeroberfläche kann die Google Suche im Voraus ermitteln, ob das Caching von Daten aufgrund von Speicherkontingentüberschreitungen fehlschlagen könnte.
Das Suchteam hatte also mehrere Kriterien, anhand derer es entscheiden konnte, ob ein Service Worker verwendet werden sollte: Wenn ein Nutzer die Google Suche mit einem Browser aufruft, der die Navigationsvorab-Ladefunktion unterstützt, mindestens 2 Gigabyte RAM und genügend freien Speicherplatz hat, wird ein Service Worker registriert. Bei Browsern oder Geräten, die diese Kriterien nicht erfüllen, wird kein Dienstarbeiter verwendet. Die Google Suche funktioniert aber wie gewohnt.
Ein Nebeneffekt dieser selektiven Registrierung ist die Möglichkeit, einen kleineren, effizienteren Service Worker bereitzustellen. Wenn Sie den Dienstworker-Code auf relativ moderne Browser ausrichten, entfällt der Overhead von Transpilation und Polyfills für ältere Browser. Dadurch konnten etwa 8 Kilobyte unkomprimierter JavaScript-Code aus der Gesamtgröße der Service Worker-Implementierung entfernt werden.
Problem: Service Worker-Bereiche
Nachdem das Suchteam genügend Latenztests durchgeführt und sich sicher war, dass die Navigationsvorab-Ladefunktion eine praktikable, latenzneutrale Möglichkeit zur Verwendung eines Service Workers bietet, rückten einige praktische Probleme in den Vordergrund. Eines dieser Probleme hängt mit den Begrenzungsregeln von Service Workern zusammen. Der Umfang eines Service Workers bestimmt, für welche Seiten er die Kontrolle übernehmen kann.
Die Einschränkung erfolgt anhand des URL-Pfadpräfixes. Bei Domains, auf denen eine einzelne Webanwendung gehostet wird, ist das kein Problem, da Sie normalerweise nur einen Service Worker mit dem maximalen Umfang von / verwenden, der die Kontrolle über jede Seite unter der Domain übernehmen kann.
Die URL-Struktur der Google Suche ist jedoch etwas komplizierter.
Wenn dem Dienstarbeiter der maximale Umfang von / zugewiesen würde, könnte er die Kontrolle über jede Seite übernehmen, die unter www.google.com (oder dem regionalen Äquivalent) gehostet wird. Es gibt jedoch URLs unter dieser Domain, die nichts mit der Google Suche zu tun haben. Eine angemessenere, restriktivere Reichweite wäre /search. Dadurch werden zumindest URLs entfernt, die in keinerlei Beziehung zu den Suchergebnissen stehen.
Leider wird auch dieser /search-URL-Pfad für verschiedene Arten von Google-Suchergebnissen verwendet. URL-Suchparameter bestimmen, welche Art von Suchergebnis angezeigt wird. Einige dieser Varianten verwenden völlig unterschiedliche Codebases als die herkömmliche Seite mit Websuchergebnissen. Die Bild- und Shopping-Suche werden beispielsweise über den URL-Pfad /search mit unterschiedlichen Suchparametern ausgeliefert. Für keine dieser Oberflächen war es jedoch noch möglich, eigene Service Worker zu implementieren.
Lösung: Ein Dispatch- und Routing-Framework erstellen
Es gibt zwar einige Vorschläge, die eine effizientere Bestimmung des Service Worker-Bereichs als über URL-Pfadpräfixe ermöglichen, aber das Google Search-Team konnte keinen Service Worker bereitstellen, der für einen Teil der von ihm verwalteten Seiten nichts tat.
Um dieses Problem zu umgehen, hat das Google Search-Team ein benutzerdefiniertes Framework für die Weiterleitung und das Routing entwickelt, das so konfiguriert werden kann, dass Kriterien wie die Abfrageparameter der Clientseite geprüft und anhand dieser Kriterien der Codepfad festgelegt wird. Anstatt Regeln hartzucodieren, wurde das System so konzipiert, dass Teams, die den URL-Bereich gemeinsam nutzen, wie die Bildersuche und die Shopping-Suche, ihre eigene Service Worker-Logik einbinden können, falls sie diese implementieren möchten.
Problem: Personalisierte Ergebnisse und Messwerte
Nutzer können sich mit ihren Google-Konten in der Google Suche anmelden. Die Suchergebnisse können dann anhand ihrer Kontodaten angepasst werden. Angemeldete Nutzer werden anhand bestimmter Browser-Cookies identifiziert. Dies ist ein bewährter und weithin unterstützter Standard.
Ein Nachteil der Verwendung von Browser-Cookies besteht jedoch darin, dass sie nicht innerhalb eines Dienstarbeiters freigegeben werden und es keine Möglichkeit gibt, ihre Werte automatisch zu prüfen und sicherzustellen, dass sie sich nicht geändert haben, weil sich ein Nutzer abgemeldet oder das Konto gewechselt hat. Es wird zwar daran gearbeitet, Service Workern Zugriff auf Cookies zu ermöglichen, aber zum Zeitpunkt der Erstellung dieses Artikels ist der Ansatz noch experimentell und wird nicht weithin unterstützt.
Eine Abweichung zwischen der Ansicht des Service Workers zum aktuell angemeldeten Nutzer und dem tatsächlichen Nutzer, der in der Weboberfläche der Google Suche angemeldet ist, kann zu falsch personalisierten Suchergebnissen oder falsch zugeordneten Messwerten und Protokollen führen. Jedes dieser Fehlerszenarien wäre ein ernstes Problem für das Google Suche-Team.
Lösung: Cookies mit postMessage senden
Anstatt auf die Einführung experimenteller APIs zu warten, die direkten Zugriff auf die Cookies des Browsers in einem Dienstarbeiter bieten, entschied sich das Google Search-Team für eine Notlösung: Jedes Mal, wenn eine vom Dienstarbeiter gesteuerte Seite geladen wird, werden die relevanten Cookies gelesen und über postMessage() an den Dienstarbeiter gesendet.
Der Service Worker vergleicht dann den aktuellen Cookie-Wert mit dem erwarteten Wert. Bei einer Abweichung werden alle nutzerspezifischen Daten aus dem Speicher gelöscht und die Suchergebnisseite ohne fehlerhafte Personalisierung neu geladen.
Die spezifischen Schritte, die der Dienstarbeiter ausführt, um die Einstellungen auf die Standardwerte zurückzusetzen, sind speziell auf die Anforderungen der Google Suche zugeschnitten. Derselbe allgemeine Ansatz kann jedoch auch für andere Entwickler nützlich sein, die mit personalisierten Daten arbeiten, die auf Browser-Cookies basieren.
Problem: Tests und Dynamik
Wie bereits erwähnt, setzt das Google Suche-Team stark auf Tests in der Produktion und testet die Auswirkungen von neuem Code und neuen Funktionen in der Praxis, bevor sie standardmäßig aktiviert werden. Bei einem statischen Dienst-Worker, der stark auf zwischengespeicherte Daten angewiesen ist, kann das etwas schwierig sein, da die Aktivierung und Deaktivierung von Tests für Nutzer häufig die Kommunikation mit dem Backend-Server erfordert.
Lösung: dynamisch generiertes Service Worker-Script
Das Team entschied sich für ein dynamisch generiertes Service Worker-Script, das vom Webserver für jeden einzelnen Nutzer angepasst wird, anstelle eines einzelnen statischen Service Worker-Scripts, das vorab generiert wird. Informationen zu Tests, die sich auf das Verhalten des Service Workers oder Netzwerkanfragen im Allgemeinen auswirken können, sind direkt in diesen benutzerdefinierten Service Worker-Scripts enthalten. Die aktiven Versionen für einen Nutzer werden durch eine Kombination aus traditionellen Techniken wie Browser-Cookies und dem Bereitstellen von aktualisiertem Code in der registrierten Service Worker-URL geändert.
Mit einem dynamisch generierten Service Worker-Script lässt sich auch leichter ein Notfallausstieg für den unwahrscheinlichen Fall bereitstellen, dass eine Service Worker-Implementierung einen schwerwiegenden Fehler aufweist, der vermieden werden muss. Die dynamische Server-Worker-Antwort kann eine No-Op-Implementierung sein, wodurch der Service Worker für einige oder alle aktuellen Nutzer effektiv deaktiviert wird.
Problem: Koordination von Updates
Eine der größten Herausforderungen bei der Bereitstellung von Service Workern besteht darin, einen angemessenen Kompromiss zwischen dem Vermeiden des Netzwerks zugunsten des Caches zu finden und gleichzeitig dafür zu sorgen, dass bestehende Nutzer wichtige Updates und Änderungen bald nach der Produktionsbereitstellung erhalten. Das richtige Gleichgewicht hängt von vielen Faktoren ab:
- Ob es sich bei Ihrer Webanwendung um eine langlebige Single-Page-App handelt, die ein Nutzer unbegrenzt offen lässt, ohne zu neuen Seiten zu wechseln.
- Wie oft werden Updates für Ihren Backend-Webserver bereitgestellt?
- Ob der durchschnittliche Nutzer die Verwendung einer etwas veralteten Version Ihrer Webanwendung tolerieren würde oder ob Aktualität oberste Priorität hat.
Bei den Tests mit Service Workern hat das Google Suche-Team darauf geachtet, die Tests über mehrere geplante Backend-Updates hinweg laufen zu lassen, damit die Messwerte und die Nutzerfreundlichkeit besser mit dem übereinstimmen, was wiederkehrende Nutzer in der Praxis sehen würden.
Lösung: Aktualität und Cache-Nutzung in Einklang bringen
Nach dem Testen verschiedener Konfigurationsoptionen stellte das Google Search-Team fest, dass die folgende Konfiguration das richtige Gleichgewicht zwischen Aktualität und Cache-Nutzung bietet.
Die URL des Service Worker-Scripts wird mit dem Antwortheader Cache-Control: private, max-age=1500 (1.500 Sekunden oder 25 Minuten) ausgeliefert und mit „updateViaCache“ auf „all“ registriert, damit der Header berücksichtigt wird. Das Web-Backend der Google Suche besteht aus einer großen Anzahl global verteilter Server, die eine möglichst hohe Verfügbarkeit von 100% erfordern. Änderungen, die sich auf den Inhalt des Service Worker-Scripts auswirken, werden nach und nach eingeführt.
Wenn ein Nutzer ein aktualisiertes Backend aufruft und dann schnell zu einer anderen Seite wechselt, die ein Backend aufruft, das den aktualisierten Dienstarbeiter noch nicht erhalten hat, wechselt er mehrmals zwischen den Versionen. Daher ist es nicht von Nachteil, wenn der Browser nur dann nach einem aktualisierten Script sucht, wenn seit der letzten Prüfung 25 Minuten vergangen sind. Der Vorteil dieser Option besteht darin, dass der Traffic, der vom Endpunkt empfangen wird, über den das Service Worker-Script dynamisch generiert wird, erheblich reduziert wird.
Außerdem wird in der HTTP-Antwort des Service Worker-Scripts ein ETag-Header festgelegt, damit der Server bei einer Updateprüfung nach 25 Minuten effizient mit einer HTTP 304-Antwort antworten kann, wenn in der Zwischenzeit keine Updates für den Service Worker bereitgestellt wurden.
Für einige Interaktionen in der Webanwendung der Google Suche wird die Navigation im Stil einer Single-Page-App verwendet (d. h. über die History API). Die Google Suche ist jedoch größtenteils eine herkömmliche Webanwendung mit „echten“ Navigationselementen. Das Team entschied sich, zwei Optionen zu verwenden, die den Aktualisierungszyklus von Service Workern beschleunigen: clients.claim() und skipWaiting().
Wenn Sie in der Google Suche herumklicken, werden in der Regel neue HTML-Dokumente geöffnet. Wenn Sie skipWaiting aufrufen, erhält ein aktualisierter Service Worker die Möglichkeit, diese neuen Navigationsanfragen direkt nach der Installation zu verarbeiten. Wenn Sie clients.claim() aufrufen, erhält der aktualisierte Dienst-Worker die Möglichkeit, nach der Aktivierung des Dienst-Workers alle offenen Google Suche-Seiten zu steuern, die nicht gesteuert werden.
Der Ansatz, den wir in der Google Suche gewählt haben, ist nicht unbedingt eine Lösung, die für alle funktioniert. Er ist das Ergebnis sorgfältiger A/B-Tests verschiedener Kombinationen von Auslieferungsoptionen, bis wir die für uns am besten geeignete gefunden haben.
Entwickler, deren Backend-Infrastruktur es ihnen ermöglicht, Updates schneller bereitzustellen, möchten möglicherweise, dass der Browser so oft wie möglich nach einem aktualisierten Service Worker-Script sucht. Dazu muss der HTTP-Cache immer ignoriert werden.
Wenn Sie eine Single-Page-App entwickeln, die Nutzer möglicherweise über einen längeren Zeitraum geöffnet lassen, ist skipWaiting() wahrscheinlich nicht die richtige Wahl. Es besteht das Risiko von Cache-Inkonsistenzen, wenn Sie zulassen, dass der neue Dienst-Worker aktiviert wird, während es langlebige Clients gibt.
Zusammenfassung
Standardmäßig sind Service Worker nicht leistungsneutral
Wenn Sie Ihrer Webanwendung einen Dienst-Worker hinzufügen, fügen Sie ein zusätzliches JavaScript-Snippet ein, das geladen und ausgeführt werden muss, bevor Ihre Webanwendung Antworten auf ihre Anfragen erhält. Wenn diese Antworten aus einem lokalen Cache und nicht aus dem Netzwerk stammen, ist der Overhead beim Ausführen des Service Workers im Vergleich zum Leistungsgewinn durch die Cache-first-Methode in der Regel vernachlässigbar. Wenn Sie jedoch wissen, dass Ihr Service Worker beim Bearbeiten von Navigationsanfragen immer das Netzwerk konsultieren muss, ist die Navigationsvorab-Ladefunktion ein entscheidender Leistungsgewinn.
Service Worker sind (immer noch) eine progressive Verbesserung
Die Situation beim Support für Service Worker ist heute viel besser als noch vor einem Jahr. Alle modernen Browser bieten jetzt zumindest eine gewisse Unterstützung für Service Worker. Leider gibt es einige erweiterte Service Worker-Funktionen wie die Hintergrundsynchronisierung und die Navigationsvorab-Ladefunktion, die nicht allgemein eingeführt wurden. Es ist jedoch immer noch sinnvoll, die Funktion für die bestimmte Teilmenge der Funktionen zu prüfen, die Sie benötigen, und einen Service Worker nur dann zu registrieren, wenn diese vorhanden sind.
Wenn Sie ähnliche Tests durchgeführt haben und wissen, dass auf Low-End-Geräten aufgrund des zusätzlichen Overheads eines Service Workers eine schlechte Leistung erzielt wird, können Sie auch in diesen Fällen keinen Service Worker registrieren.
Sie sollten weiterhin mit Service Workern als progressiver Verbesserung umgehen, die einer Webanwendung hinzugefügt werden, wenn alle Voraussetzungen erfüllt sind und der Service Worker die Nutzerfreundlichkeit und die Gesamtladeleistung positiv beeinflusst.
Alles messen
Die einzige Möglichkeit, herauszufinden, ob die Bereitstellung eines Service Workers sich positiv oder negativ auf die Nutzerfreundlichkeit ausgewirkt hat, besteht darin, Tests durchzuführen und die Ergebnisse zu messen.
Die Details zur Einrichtung aussagekräftiger Messungen hängen davon ab, welchen Analyseanbieter Sie verwenden und wie Sie normalerweise Tests in Ihrer Bereitstellungseinrichtung durchführen. Ein Ansatz, bei dem Google Analytics zur Erfassung von Messwerten verwendet wird, wird in dieser Fallstudie beschrieben. Sie basiert auf der Erfahrung mit Service Workern in der Google I/O-Web-App.
Nicht als Tor gewertete Treffer
Viele in der Webentwicklungsbranche assoziieren Service Worker mit progressiven Web-Apps. Die Entwicklung einer „Google Suche als PWA“ war jedoch nicht das ursprüngliche Ziel des Teams. Die Web-App der Google Suche stellt derzeit keine Metadaten über ein Web-App-Manifest bereit und fordert Nutzer auch nicht dazu auf, den Vorgang zum Hinzufügen zum Startbildschirm auszuführen. Das Suchteam ist derzeit zufrieden mit den Nutzern, die über die traditionellen Einstiegspunkte für die Google Suche auf die Web-App zugreifen.
Anstatt die Google Suche im Web so zu gestalten, dass sie einer installierten Anwendung entspricht, lag der Schwerpunkt beim ersten Roll-out darauf, die vorhandene Website schrittweise zu verbessern.
Danksagungen
Vielen Dank an das gesamte Webentwicklungsteam der Google Suche für die Arbeit an der Service Worker-Implementierung und für die Bereitstellung des Hintergrundmaterials, das für die Erstellung dieses Artikels verwendet wurde. Besonderer Dank geht an Philippe Golle, Rajesh Jagannathan und R. Samuel Klatchko, Andy Martone, Leonardo Peña, Rachel Shearer, Greg Terrono und Clay Woolam.
Update (Oktober 2021): Seit der Veröffentlichung dieses Artikels hat das Google Search-Team die Vorteile und Nachteile der aktuellen Service Worker-Architektur noch einmal überdacht. Der oben beschriebene Dienst-Worker wird eingestellt. Wenn sich die Webinfrastruktur der Google Suche weiterentwickelt, kann das Team sein Service Worker-Design noch einmal überarbeiten.