Die Geschichte dessen, was ausgeliefert wurde, wie die Auswirkungen gemessen wurden und welche Kompromisse eingegangen wurden.
Veröffentlicht: 20. Juni 2019
Wenn Sie bei Google nach einem beliebigen Thema suchen, erhalten Sie eine sofort erkennbare Seite mit aussagekräftigen, relevanten Ergebnissen. Was Sie wahrscheinlich nicht wussten: Diese Suchergebnisseite wird in bestimmten Szenarien von einer leistungsstarken Webtechnologie namens Service Worker bereitgestellt.
Die Einführung der Service Worker-Unterstützung für die Google Suche, ohne die Leistung zu beeinträchtigen, erforderte die Zusammenarbeit von Dutzenden von Entwicklern in mehreren Teams. Hier erfahren Sie, was ausgeliefert wurde, wie die Leistung gemessen wurde und welche Kompromisse eingegangen wurden.
Wichtige Gründe für die Verwendung von Service Workern
Das Hinzufügen eines Service Workers zu einer Web-App sollte wie jede architektonische Änderung an Ihrer Website mit einem klaren Ziel vor Augen erfolgen. Für das Google Suche-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 bearbeiten.
Die Aktualität ist nicht zu unterschätzen. Nutzer suchen manchmal wiederholt nach denselben Begriffen, weil sich das Thema weiterentwickelt und sie aktuelle Ergebnisse erwarten. Durch die Verwendung eines Service Workers kann das Google Suche-Team eine detaillierte Logik implementieren, um die Lebensdauer lokal im Cache gespeicherter Suchergebnisse zu steuern und genau das richtige Verhältnis von Geschwindigkeit und Aktualität zu erreichen, das ihrer Meinung nach für die Nutzer am besten ist.
Sinnvolle Offline-Erlebnisse
Außerdem wollte das Google Suche-Team eine sinnvolle Offline-Nutzung ermöglichen. Wenn ein Nutzer etwas über ein Thema erfahren möchte, möchte er direkt zur Google Suche gehen und mit der Suche beginnen, ohne sich um eine aktive Internetverbindung kümmern zu müssen.
Ohne Service Worker würde beim Aufrufen der Google-Suchseite im Offlinemodus nur die Standardseite für Netzwerkfehler des Browsers angezeigt. Nutzer müssten sich merken, dass sie später noch einmal versuchen müssen, die Seite aufzurufen, wenn die Verbindung wiederhergestellt ist. Mit einem Service Worker ist es möglich, eine benutzerdefinierte Offline-HTML-Antwort zu senden und Nutzern zu erlauben, ihre Suchanfrage sofort einzugeben.
Die Ergebnisse sind erst verfügbar, wenn eine Internetverbindung besteht. Der Service Worker ermöglicht es jedoch, die Suche aufzuschieben und über die Background Sync API an die Google-Server zu senden, sobald das Gerät wieder online ist.
Intelligenteres Caching und Bereitstellen von JavaScript
Ein weiterer Grund war, das Caching und Laden des modularisierten JavaScript-Codes zu optimieren, der die verschiedenen Arten von Funktionen auf der Suchergebnisseite unterstützt. Das JavaScript-Bundling bietet eine Reihe von Vorteilen, die sinnvoll sind, wenn kein Service Worker beteiligt ist. Das Search-Team wollte das Bundling daher nicht einfach komplett einstellen.
Das Search-Team vermutete, dass sich durch die Möglichkeit von Service Workern, detaillierte JavaScript-Chunks zur Laufzeit zu versionieren und im Cache zu speichern, die Menge an Cache-Churn reduzieren und dafür sorgen lässt, dass in Zukunft wiederverwendetes JavaScript effizient im Cache gespeichert werden kann. Die Logik in ihrem Service Worker kann eine ausgehende HTTP-Anfrage für ein Bundle mit mehreren JavaScript-Modulen analysieren und sie durch Zusammenfügen mehrerer lokal im Cache gespeicherter Module erfüllen. So wird das Bundle nach Möglichkeit „entbündelt“. Das spart Bandbreite und verbessert die Reaktionsfähigkeit insgesamt.
Die Verwendung von im Cache gespeicherten JavaScript, das von einem Service Worker bereitgestellt wird, bietet auch Leistungsvorteile: In Chrome wird eine geparste Bytecode-Darstellung dieses JavaScript gespeichert und wiederverwendet. Dadurch muss zur 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 Ziele des Teams zu erreichen. Einige dieser Herausforderungen sind spezifisch für die Google Suche, viele gelten jedoch für eine Vielzahl von Websites, die eine Service Worker-Bereitstellung in Erwägung ziehen.
Problem: Service Worker-Overhead
Die größte Herausforderung und der einzige echte Blocker für die Einführung eines Service Workers in der Google Suche bestand darin, sicherzustellen, dass er nichts tut, was die von Nutzern wahrgenommene Latenz erhöhen könnte. Die Leistung ist für die Google Suche sehr wichtig. In der Vergangenheit wurden die Einführung neuer Funktionen blockiert, wenn sie auch nur wenige Millisekunden zusätzliche Latenz für eine bestimmte Nutzergruppe verursachten.
Als das Team in den ersten Tests mit der Erhebung von Leistungsdaten begann, wurde deutlich, dass es ein Problem geben würde. Das als Antwort auf Navigationsanfragen für die Suchergebnisseite zurückgegebene HTML ist dynamisch und variiert stark je nach Logik, die auf den Webservern von Google Suche ausgeführt werden muss. Der Service Worker kann diese Logik derzeit nicht replizieren und sofort zwischengespeicherten HTML-Code zurückgeben. Er kann Navigationsanfragen nur an die Backend-Webserver weiterleiten, was eine Netzwerkanfrage erfordert.
Ohne Service Worker erfolgt diese Netzwerkanfrage sofort nach der Navigation durch den Nutzer. Wenn ein Service Worker registriert ist, muss er immer gestartet werden und die Möglichkeit erhalten, seine fetch-Ereignishandler auszuführen, auch wenn diese Fetch-Handler nichts anderes tun können, als auf das Netzwerk zuzugreifen. Die Zeit, die zum Starten und Ausführen des ServiceWorker-Codes benötigt wird, ist reiner Overhead, der bei jeder Navigation hinzukommt:
Die Service Worker-Implementierung hat einen zu großen Latenznachteil, um andere Vorteile zu rechtfertigen. Außerdem stellte das Team fest, dass die Startzeiten von Service Workern auf realen Geräten sehr unterschiedlich waren. Bei einigen Low-End-Mobilgeräten dauerte es fast so lange, den Service Worker zu starten, wie die Netzwerkanfrage für das HTML der Ergebnisseite.
Lösung: Navigation vorab laden
Die wichtigste Funktion, die es dem Google Suche-Team ermöglichte, den Service Worker einzuführen, ist Navigation Preload. Die Verwendung von Navigations-Preload ist ein wichtiger Leistungsvorteil für jeden Service Worker, der eine Antwort aus dem Netzwerk benötigt, um Navigationsanfragen zu erfüllen. Sie gibt dem Browser einen Hinweis, die Navigationsanfrage sofort zu senden, gleichzeitig mit dem Start des Service Workers:
Solange die Zeit, die der Service Worker zum Starten benötigt, kürzer ist als die Zeit, die benötigt wird, um eine Antwort vom Netzwerk zu erhalten, sollte es keine Latenz geben, die durch den Service Worker verursacht wird.
Das Suchteam musste auch vermeiden, einen Service Worker auf Low-End-Mobilgeräten zu verwenden, auf denen die Startzeit des Service Workers die Navigationsanfrage überschreiten könnte. Da es keine allgemeingültige Regel dafür gibt, was ein Low-End-Gerät ausmacht, haben sie die Heuristik entwickelt, den auf dem Gerät installierten Gesamtspeicher zu prüfen. Geräte mit weniger als 2 GB Arbeitsspeicher fielen in die Kategorie der Low-End-Geräte, bei denen die Startzeit des Service Workers inakzeptabel wäre.
Auch der verfügbare Speicherplatz ist ein wichtiger Faktor, da die vollständige Gruppe der Ressourcen, die für die zukünftige Verwendung im Cache gespeichert werden sollen, mehrere Megabyte umfassen kann. Über die navigator.storage-Schnittstelle kann die Google Suche-Seite im Voraus feststellen, ob ihre Versuche, Daten im Cache zu speichern, aufgrund von Fehlern beim Speicherkontingent fehlschlagen könnten.
Das Suchteam hatte also mehrere Kriterien, anhand derer es entscheiden konnte, ob ein Service Worker verwendet werden sollte oder nicht: Wenn ein Nutzer über einen Browser, der Navigation Preload unterstützt, und mit mindestens 2 GB RAM und ausreichend freiem Speicherplatz auf die Google Suche-Seite gelangt, wird ein Service Worker registriert. Auf Browsern oder Geräten, die diese Kriterien nicht erfüllen, wird kein Service Worker installiert. Nutzer sehen aber weiterhin die Google Suche, wie sie sie kennen.
Ein Nebeneffekt dieser selektiven Registrierung ist die Möglichkeit, einen kleineren, effizienteren Service Worker zu versenden. Wenn Sie den Service Worker-Code auf relativ modernen Browsern ausführen, entfällt der Aufwand für die Transpilierung und Polyfills für ältere Browser. Dadurch wurden etwa 8 Kilobyte unkomprimierter JavaScript-Code aus der Gesamtgröße der Service Worker-Implementierung entfernt.
Problem: Service Worker-Bereiche
Nachdem das Suchteam genügend Latenztests durchgeführt hatte und zuversichtlich war, dass die Verwendung von Navigation Preload einen praktikablen, latenzneutralen Weg für die Verwendung eines Service Workers bot, traten einige praktische Probleme in den Vordergrund. Eines dieser Probleme hängt mit den Bereichsregeln von Service Workern zusammen. Der Bereich eines Service Workers bestimmt, welche Seiten er potenziell steuern kann.
Die Bereichsbegrenzung erfolgt auf Grundlage des URL-Pfadpräfixes. Bei Domains, auf denen eine einzelne Web-App gehostet wird, ist das kein Problem, da Sie normalerweise einfach einen Service Worker mit dem maximalen Bereich 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 Service Worker der maximale Bereich von / zugewiesen würde, könnte er die Kontrolle über jede Seite übernehmen, die unter www.google.com (oder dem regionalen Äquivalent) gehostet wird. Unter dieser Domain gibt es jedoch URLs, die nichts mit der Google Suche zu tun haben. Ein angemessenerer, restriktiverer Umfang wäre /search, wodurch zumindest URLs entfernt würden, die in keinerlei Zusammenhang mit Suchergebnissen stehen.
Leider wird dieser /search-URL-Pfad auch für verschiedene Arten von Google-Suchergebnissen verwendet. Über URL-Suchparameter wird festgelegt, welche Art von Suchergebnis angezeigt wird. Einige dieser Varianten verwenden völlig andere Codebases als die herkömmliche Seite mit Web-Suchergebnissen. Die Bildersuche und die Shopping-Suche werden beispielsweise beide unter dem URL-Pfad /search mit unterschiedlichen Abfrageparametern bereitgestellt. Für keine der beiden Oberflächen war es jedoch möglich, einen eigenen Service Worker zu implementieren.
Lösung: Weiterleitungs- und Routing-Framework erstellen
Es gibt zwar einige Vorschläge, die eine leistungsstärkere Methode als URL-Pfadpräfixe ermöglichen, um ServiceWorker-Bereiche zu bestimmen, aber das Google Suche-Team musste einen ServiceWorker bereitstellen, der für eine Teilmenge der von ihm gesteuerten Seiten nichts bewirkte.
Um dieses Problem zu umgehen, hat das Google Suche-Team ein spezielles Dispatch- und Routing-Framework entwickelt, das so konfiguriert werden konnte, dass es Kriterien wie die Abfrageparameter der Clientseite prüft und anhand dieser bestimmt, welcher spezifische Codepfad verwendet werden soll. Anstatt Regeln fest zu codieren, wurde das System so konzipiert, dass es flexibel ist und Teams, die den URL-Bereich gemeinsam nutzen, wie die Bildersuche und die Produktsuche, ihre eigene Service Worker-Logik einfügen können, wenn sie sich für die Implementierung entscheiden.
Problem: Personalisierte Ergebnisse und Messwerte
Nutzer können sich mit ihren Google-Konten in der Google Suche anmelden. Die Suchergebnisse können dann auf Grundlage der jeweiligen Kontodaten angepasst werden. Angemeldete Nutzer werden durch bestimmte Browser-Cookies identifiziert. Dies ist ein bewährter und weitgehend unterstützter Standard.
Ein Nachteil von Browser-Cookies ist jedoch, dass sie in einem Service Worker nicht verfügbar sind. Es gibt keine Möglichkeit, 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 daran gearbeitet, Service-Workern Zugriff auf Cookies zu ermöglichen. Derzeit ist der Ansatz jedoch experimentell und wird nicht allgemein unterstützt.
Wenn die Ansicht des Service Workers des aktuell angemeldeten Nutzers nicht mit dem tatsächlichen Nutzer übereinstimmt, der im Webinterface der Google Suche angemeldet ist, kann dies zu falsch personalisierten Suchergebnissen oder falsch zugeordneten Messwerten und Protokollierungen führen. Jedes dieser Szenarien 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 Browser-Cookies in einem Service Worker ermöglichen, hat sich das Google Suche-Team für eine Übergangslösung entschieden: Immer wenn eine Seite geladen wird, die vom Service Worker gesteuert wird, liest die Seite die relevanten Cookies und verwendet postMessage(), um sie an den Service Worker zu senden.
Der Service Worker vergleicht dann den aktuellen Cookie-Wert mit dem erwarteten Wert. Wenn es eine Abweichung gibt, werden alle nutzerspezifischen Daten aus dem Speicher gelöscht und die Suchergebnisseite wird ohne falsche Personalisierung neu geladen.
Die konkreten Schritte, die der Service Worker ausführt, um die Einstellungen auf einen Ausgangszustand zurückzusetzen, sind spezifisch für die Anforderungen der Google Suche. Der 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, führt das Google Suche-Team viele Tests in der Produktion durch und testet die Auswirkungen von neuem Code und neuen Funktionen in der Praxis, bevor sie standardmäßig aktiviert werden. Das kann bei einem statischen Service Worker, der stark auf zwischengespeicherte Daten angewiesen ist, eine Herausforderung sein, da für das Aktivieren und Deaktivieren von Nutzern für Tests häufig eine Kommunikation mit dem Backend-Server erforderlich ist.
Lösung: Dynamisch generiertes Service Worker-Script
Das Team entschied sich für ein dynamisch generiertes Service Worker-Skript, das vom Webserver für jeden einzelnen Nutzer angepasst wird, anstelle eines einzelnen, statischen Service Worker-Skripts, das im Voraus generiert wird. Informationen zu Tests, die sich auf das Verhalten des Service Workers oder auf Netzwerkanfragen im Allgemeinen auswirken könnten, sind direkt in diesen benutzerdefinierten Service Worker-Skripts enthalten. Die Änderung der aktiven Testgruppen für einen Nutzer erfolgt durch eine Kombination aus herkömmlichen Techniken wie Browser-Cookies und der Bereitstellung von aktualisiertem Code in der registrierten Service Worker-URL.
Die Verwendung eines dynamisch generierten Service Worker-Skripts erleichtert es auch, einen Ausweg zu schaffen, falls eine Service Worker-Implementierung einen schwerwiegenden Fehler aufweist, der vermieden werden muss. Die dynamische Server-Worker-Antwort könnte eine No-Op-Implementierung sein, wodurch der Service Worker für einige oder alle aktuellen Nutzer deaktiviert wird.
Problem: Koordinieren von Updates
Eine der größten Herausforderungen bei der Bereitstellung von Service Workern in der Praxis besteht darin, einen angemessenen Kompromiss zwischen der Vermeidung des Netzwerks zugunsten des Cache und der gleichzeitigen Sicherstellung zu finden, dass bestehende Nutzer kritische Updates und Änderungen kurz nach der Bereitstellung in der Produktion erhalten. Die richtige Balance hängt von vielen Faktoren ab:
- Ob Ihre Web-App eine Single-Page-App ist, die ein Nutzer unbegrenzt geöffnet lässt, ohne zu neuen Seiten zu navigieren.
- Wie oft Updates für Ihren Backend-Webserver bereitgestellt werden.
- Ob der durchschnittliche Nutzer eine leicht veraltete Version Ihrer Web-App tolerieren würde oder ob die Aktualität oberste Priorität hat.
Bei den Tests mit Service Workern hat das Google Suche-Team darauf geachtet, dass die Tests über eine Reihe von geplanten Backend-Updates hinweg laufen, damit die Messwerte und die Nutzerfreundlichkeit besser mit dem übereinstimmen, was wiederkehrende Nutzer in der Praxis sehen würden.
Lösung: Gleichgewicht zwischen Aktualität und Cache-Nutzung
Nachdem das Google Suche-Team eine Reihe verschiedener Konfigurationsoptionen getestet hatte, stellte es fest, dass die folgende Einrichtung das richtige Gleichgewicht zwischen Aktualität und Cache-Nutzung bietet.
Die URL des Service Worker-Skripts 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 ist, wie Sie sich vielleicht vorstellen können, eine große, global verteilte Gruppe von Servern, die eine Verfügbarkeit von nahezu 100% erfordert. Die Bereitstellung einer Änderung, die sich auf den Inhalt des Service Worker-Skripts auswirkt, erfolgt schrittweise.
Wenn ein Nutzer ein aktualisiertes Backend aufruft und dann schnell zu einer anderen Seite wechselt, die ein Backend aufruft, das den aktualisierten Service Worker noch nicht erhalten hat, wechselt er mehrmals zwischen den Versionen. Daher hat es keine nennenswerten Nachteile, wenn der Browser nur dann nach einem aktualisierten Skript sucht, wenn seit der letzten Suche 25 Minuten vergangen sind. Der Vorteil der Aktivierung dieses Verhaltens besteht darin, dass der Traffic, der vom Endpunkt empfangen wird, der das Service Worker-Skript dynamisch generiert, erheblich reduziert wird.
Außerdem wird in der HTTP-Antwort des Service-Worker-Scripts ein ETag-Header festgelegt. So kann der Server effizient mit einer HTTP 304-Antwort reagieren, wenn nach 25 Minuten eine Updateprüfung durchgeführt wird und in der Zwischenzeit keine Updates für den bereitgestellten Service Worker erfolgt sind.
Einige Interaktionen in der Google Suche erfolgen über Navigationen im Stil von Single-Page-Apps (d. h. über die History API). Die Google Suche ist aber größtenteils eine herkömmliche Web-App, die „echte“ Navigationen verwendet. Das ist der Fall, wenn das Team beschlossen hat, zwei Optionen zu verwenden, die den Aktualisierungszyklus des Service Workers beschleunigen:
clients.claim()
und
skipWaiting().
Wenn Sie in der Google Suche auf Elemente klicken, werden Sie in der Regel zu neuen HTML-Dokumenten weitergeleitet. Durch den Aufruf von skipWaiting wird sichergestellt, dass ein aktualisierter Service Worker diese neuen Navigationsanfragen sofort nach der Installation verarbeiten kann. Wenn clients.claim() aufgerufen wird, kann der aktualisierte Service Worker nach der Aktivierung des Service Workers die Kontrolle über alle offenen Google Suche-Seiten übernehmen, die nicht kontrolliert werden.
Der Ansatz der Google Suche ist nicht unbedingt eine Lösung, die für alle funktioniert. Er ist das Ergebnis sorgfältiger A/B-Tests verschiedener Kombinationen von Bereitstellungsoptionen, bis die beste Lösung gefunden wurde.
Entwickler, deren Backend-Infrastruktur es ihnen ermöglicht, Updates schneller bereitzustellen, bevorzugen möglicherweise, dass der Browser so oft wie möglich nach einem aktualisierten Service Worker-Script sucht, indem er den HTTP-Cache immer ignoriert.
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 für Sie. Sie riskieren Cache-Inkonsistenzen, wenn Sie zulassen, dass der neue Service Worker aktiviert wird, während Clients mit langer Lebensdauer vorhanden sind.
Zusammenfassung
Service Worker sind standardmäßig nicht leistungsneutral
Wenn Sie Ihrer Web-App einen Service Worker hinzufügen, fügen Sie ein zusätzliches JavaScript-Element ein, das geladen und ausgeführt werden muss, bevor Ihre Web-App Antworten auf ihre Anfragen erhält. Wenn diese Antworten aus einem lokalen Cache und nicht aus dem Netzwerk stammen, ist der Aufwand für die Ausführung des Service Workers in der Regel im Vergleich zum Leistungsgewinn durch die Cache-First-Strategie vernachlässigbar. Wenn Sie jedoch wissen, dass Ihr Service Worker bei der Verarbeitung von Navigationsanfragen immer das Netzwerk konsultieren muss, ist die Verwendung von Navigation Preload ein entscheidender Leistungsvorteil.
Service Worker sind (immer noch!) eine progressive Erweiterung
Die Unterstützung von Service Workern ist heute viel besser als noch vor einem Jahr. Alle modernen Browser bieten mittlerweile zumindest eine Unterstützung für Service Worker. Einige erweiterte Service Worker-Funktionen wie die Hintergrundsynchronisierung und das Vorabladen von Navigationen werden jedoch nicht universell eingeführt. Es ist weiterhin sinnvoll, die benötigten Funktionen zu prüfen und einen Service Worker nur zu registrieren, wenn diese vorhanden sind.
Wenn Sie bereits Tests in der Praxis durchgeführt haben und wissen, dass Low-End-Geräte aufgrund des zusätzlichen Overheads eines Service Workers schlecht abschneiden, können Sie in diesen Fällen auch darauf verzichten, einen Service Worker zu registrieren.
Sie sollten Service Worker weiterhin als progressive Verbesserung betrachten, die einer Web-App hinzugefügt wird, wenn alle Voraussetzungen erfüllt sind und der Service Worker die Nutzerfreundlichkeit und die allgemeine Ladeleistung verbessert.
Alles messen
Die einzige Möglichkeit, herauszufinden, ob sich die Bereitstellung eines Service Workers positiv oder negativ auf die Nutzererfahrung ausgewirkt hat, besteht darin, Tests durchzuführen und die Ergebnisse zu analysieren.
Die genauen Schritte zum Einrichten aussagekräftiger Analysen hängen davon ab, welchen Analyseanbieter Sie verwenden und wie Sie normalerweise Tests in Ihrer Bereitstellungsumgebung durchführen. Ein Ansatz, bei dem Google Analytics zum Erheben von Messwerten verwendet wird, wird in dieser Fallstudie beschrieben. Sie basiert auf den Erfahrungen mit Service Workern in der Google I/O-Web-App.
Nicht-Ziele
Viele Webentwickler verbinden Service Worker mit progressiven Web-Apps. Das Team hatte jedoch nicht von Anfang an das Ziel, eine „Google Suche-PWA“ zu entwickeln. Die Google Suche-Web-App stellt keine Metadaten in einem Web-App-Manifest bereit und fordert Nutzer auch nicht auf, den Vorgang zum Hinzufügen zum Startbildschirm zu durchlaufen. Das Suchteam ist zufrieden damit, dass Nutzer über die klassischen Einstiegspunkte für die Google Suche zu seiner Web-App gelangen.
Anstatt zu versuchen, die Google Suche im Web in das Äquivalent einer installierten Anwendung zu verwandeln, lag der Fokus bei der ersten Version darauf, die bestehende 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 für diesen Artikel. Ein besonderer Dank gilt 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 ursprünglichen Veröffentlichung dieses Artikels hat das Google Suche-Team die Vorteile und Nachteile der aktuellen Service Worker-Architektur neu bewertet. Der oben beschriebene Service Worker wird eingestellt. Wenn sich die Web-Infrastruktur der Google Suche weiterentwickelt, kann das Team das Service Worker-Design noch einmal überarbeiten.