Die Geschichte, was geliefert wurde, wie die Auswirkungen gemessen wurden und welche Kompromisse eingegangen wurden.
Hintergrund
Wenn Sie auf Google nach nahezu jedem Thema suchen, erhalten Sie eine sofort erkennbare Seite mit sinnvollen, relevanten Ergebnissen. Wahrscheinlich wissen Sie nicht, dass diese Suchergebnisseite in bestimmten Fällen von einer leistungsstarken Webtechnologie namens Service Worker bereitgestellt wird.
Damit Service Worker-Unterstützung für die Google-Suche ohne negative Auswirkungen auf die Leistung eingeführt wurde, mussten Dutzende von Entwicklern in mehreren Teams arbeiten. Dies ist die Geschichte dessen, was versendet wurde, wie die Leistung gemessen wurde und welche Kompromisse eingegangen wurden.
Hauptgründe für die Suche nach Service Workern
Das Hinzufügen eines Service Workers zu einer Webanwendung sollte genau wie bei jeder Architekturänderung an einer Website mit klaren Zielen erfolgen. Für das Team der Google Suche gab es mehrere Gründe, warum sich das Hinzufügen eines Service Workers lohnt.
Eingeschränktes Caching von Suchergebnissen
Das Team der Google Suche stellte fest, dass Nutzer innerhalb kurzer Zeit mehrmals nach den gleichen Begriffen suchen. Anstatt eine neue Back-End-Anfrage auszulösen, um wahrscheinlich dieselben Ergebnisse zu erhalten, wollte das Search-Team die Vorteile des Caching nutzen und diese wiederholten Anfragen lokal ausführen.
Die Bedeutung der Aktualität kann dabei nicht ignoriert werden. Manchmal suchen Nutzer wiederholt nach denselben Begriffen, da es sich um ein sich änderndes Thema handelt und sie erwarten, aktuelle Ergebnisse zu erhalten. Mit einem Service Worker kann das Team der Google Suche eine präzise Logik implementieren, um die Lebensdauer von lokal im Cache gespeicherten Suchergebnissen zu steuern und genau das richtige Gleichgewicht zwischen Geschwindigkeit und Aktualität zu erreichen, das den Nutzern seiner Meinung nach am besten gefällt.
Aussagekräftige Offline-Nutzung
Außerdem wollte das Team der Google Suche Nutzern eine sinnvolle Offline-Erfahrung bieten. Wenn ein Nutzer mehr über ein Thema erfahren möchte, möchte er direkt zur Google-Suchseite gehen und mit der Suche beginnen, ohne sich Sorgen um eine aktive Internetverbindung machen zu müssen.
Ohne einen Service Worker würde ein Offlinezugriff auf die Google-Suchseite lediglich zur standardmäßigen Netzwerkfehlerseite des Browsers führen. Nutzer müssten es dann noch einmal versuchen, sobald die Verbindung wiederhergestellt ist. Mit einem Service Worker ist es möglich, eine benutzerdefinierte Offline-HTML-Antwort bereitzustellen und Nutzern die sofortige Eingabe ihrer Suchanfrage zu ermöglichen.
Die Ergebnisse sind erst verfügbar, wenn eine Internetverbindung besteht. Der Service Worker lässt jedoch zu, dass die Suche aufgeschoben und an die Google-Server gesendet werden kann, sobald das Gerät über die Background Sync API wieder online ist.
Intelligenteres JavaScript-Caching und -Bereitstellung
Ein weiterer Grund bestand darin, das Caching und Laden des modularisierten JavaScript-Codes zu optimieren, der die verschiedenen Arten von Funktionen auf der Suchergebnisseite unterstützt. Die JavaScript-Bündelung bietet eine Reihe von Vorteilen, die auch ohne Service-Worker-Beteiligung sinnvoll sind, sodass das Team der Google Suche nicht einfach aufhören wollte, die Bündelung ganz zu bündeln.
Das Team der Google Suche nutzte die Fähigkeit eines Service Workers, JavaScript-Chunks zur Laufzeit zu versionieren und im Cache zu speichern, und vermutete, dass das Team die Abwanderung aus dem Cache reduzieren und dafür sorgen könnte, dass in Zukunft wiederverwendete JavaScripts effizient im Cache gespeichert werden können. Die Logik innerhalb des Service Workers kann eine ausgehende HTTP-Anfrage für ein Bundle analysieren, das mehrere JavaScript-Module enthält, und diese erfüllen, indem mehrere lokal im Cache gespeicherte Module zusammengefasst werden, um die Gruppierung nach Möglichkeit sozusagen „Entbündelung“ durchzuführen. Das spart Bandbreite und verbessert die Reaktionsfähigkeit insgesamt.
Die Verwendung von im Cache gespeichertem JavaScript, das von einem Service Worker bereitgestellt wird, bietet auch Leistungsvorteile: In Chrome wird eine geparste Bytecode-Darstellung dieses JavaScript gespeichert und wiederverwendet. Dadurch ist weniger Arbeitsaufwand erforderlich, der zur Laufzeit ausgeführt werden muss, um das JavaScript auf der Seite auszuführen.
Herausforderungen und Lösungen
Hier sind einige Hürden, die gelöst werden müssen, um die gesteckten Ziele des Teams zu erreichen. Einige dieser Herausforderungen betreffen zwar die Google Suche, aber viele davon betreffen eine Vielzahl von Websites, die eine Service Worker-Bereitstellung in Betracht ziehen.
Problem: Aufwand für Service Worker
Die größte Herausforderung und das einzige Problem beim Starten eines Service Workers in der Google Suche bestand darin, sicherzustellen, dass nichts unternommen wurde, was die vom Nutzer wahrgenommene Latenz erhöhen könnte. Die Google Suche nimmt Leistung sehr sehr ernst. In der Vergangenheit wurde die Einführung neuer Funktionen blockiert, wenn dadurch für eine bestimmte Nutzerpopulation eine um mehrere zehn Millisekunden erhöhte Latenz verursacht wurde.
Als das Team bei seinen ersten Tests mit der Erfassung von Leistungsdaten anfing, wurde klar, dass es ein Problem gab. Der HTML-Code, der als Antwort auf Navigationsanfragen für die Suchergebnisseite zurückgegeben wird, ist dynamisch und hängt stark von der Logik ab, die auf den Webservern der Google Suche ausgeführt werden muss. Derzeit gibt es für den Service Worker keine Möglichkeit, diese Logik zu replizieren und im Cache gespeicherte HTML-Inhalte sofort zurückzugeben. Stattdessen könnten Navigationsanfragen an die Back-End-Webserver weitergeleitet werden, wofür eine Netzwerkanfrage erforderlich ist.
Ohne Service Worker erfolgt diese Netzwerkanfrage sofort nach der Navigation des Nutzers. Wenn ein Service Worker registriert ist, muss er immer gestartet werden und die Möglichkeit haben, seine fetch-Event-Handler auszuführen. Das gilt auch, wenn die Wahrscheinlichkeit besteht, dass diese Abruf-Handler nur eine Verbindung zum Netzwerk herstellen. Die Zeit, die zum Starten und Ausführen des Service-Worker-Codes benötigt wird, ist ein reiner Aufwand, der jeder Navigation zusätzlich hinzugefügt wird:
Dadurch wird die Service Worker-Implementierung einem zu großen Latenznachteil ausgesetzt und alle anderen Vorteile rechtfertigen. Außerdem stellte das Team fest, dass die Startzeiten von Service Workern auf realen Geräten gemessen wurden und die Startzeiten weit verteilt waren. Bei einigen Low-End-Mobilgeräten dauerte der Start des Service Workers auf einigen Low-End-Mobilgeräten fast so viel Zeit, wie nötig war, um die Netzwerkanfrage für den HTML-Code der Ergebnisseite zu senden.
Lösung: Vorabladen der Navigation verwenden
Die wichtigste Funktion, mit der das Team der Google Suche den Service Worker eingeführt hat, ist das Vorabladen der Navigation. Die Verwendung des Vorabladens der Navigation ist ein entscheidender Leistungsgewinn für jeden Service Worker, der eine Antwort des Netzwerks verwenden muss, um Navigationsanfragen zu erfüllen. Sie gibt dem Browser den Hinweis, die Navigationsanfrage sofort zu dem Zeitpunkt zu starten, zu dem der Service Worker gestartet wird:
Solange die Zeit für den Start des Service Workers kürzer ist als die Zeit, die benötigt wird, um eine Antwort vom Netzwerk zu erhalten, sollte kein Latenzaufwand durch den Service Worker entstehen.
Das Search-Team musste außerdem vermeiden, einen Service Worker auf Low-End-Mobilgeräten zu verwenden, bei denen die Bootzeit des Service Workers die Navigationsanfrage überschreiten konnte. Da es keine feste Regel dafür gibt, was ein „Low-End“-Gerät ist, hat das Unternehmen die Heuristik entwickelt, mit der der auf dem Gerät installierte Gesamt-RAM überprüft wird. Alles unter 2 Gigabyte Arbeitsspeicher fiel in die Low-End-Gerätekategorie, bei der die Service-Worker-Startzeit inakzeptabel wäre.
Der verfügbare Speicherplatz ist ein weiterer Aspekt, da alle Ressourcen, die für die zukünftige Verwendung im Cache gespeichert werden sollen, mehrere Megabyte umfassen können. Über die navigator.storage-Schnittstelle kann die Google-Suchseite im Voraus ermitteln, ob beim Speichern von Daten die Gefahr besteht, dass sie aufgrund von Fehlern beim Speicherkontingent fehlschlagen.
Dadurch standen dem Team der Google Suche mehrere Kriterien zur Verfügung, anhand derer es entscheiden konnte, ob ein Service Worker verwendet werden sollte: Wenn ein Nutzer die Google-Suche mit einem Browser aufruft, der das Vorabladen der Navigation unterstützt und mindestens 2 Gigabyte RAM und genügend freien Speicherplatz hat, ist ein Service Worker registriert. Browser oder Geräte, die diese Kriterien nicht erfüllen, erhalten keinen Service Worker, sehen aber die Google Suche wie gewohnt.
Ein weiterer Vorteil dieser selektiven Registrierung ist die Möglichkeit, einen kleineren, effizienteren Service Worker auszuliefern. Wenn Sie zum Ausführen des Service Worker-Codes relativ moderne Browser verwenden, fallen keine Transpilation und Polyfills für ältere Browser an. Dadurch entfielen etwa 8 Kilobyte unkomprimierter JavaScript-Code auf die Gesamtgröße der Service Worker-Implementierung.
Problem: Service Worker-Bereiche
Nachdem das Team der Google Suche genügend Latenztests durchgeführt und sich sicher war, dass die Vorabladefunktion der Navigation einen realisierbaren, latenzneutralen Weg für den Einsatz eines Service Workers bot, traten einige praktische Probleme in den Vordergrund. Eines dieser Probleme hat mit den Bereichsregeln des Service Workers zu tun. Der Bereich eines Service Workers bestimmt, welche Seiten er potenziell steuern kann.
Der Umfang basiert auf dem Präfix des URL-Pfads. Für Domains, die eine einzelne Webanwendung hosten, ist dies kein Problem, da Sie normalerweise einfach einen Service Worker mit dem maximalen Bereich / verwenden würden, der die Kontrolle über jede Seite unter der Domain übernehmen könnte.
Die URL-Struktur der Google-Suche ist jedoch etwas komplizierter.
Wenn dem Service Worker der maximale Bereich / zugewiesen würde, könnte er die Kontrolle über jede Seite übernehmen, die unter www.google.com (oder dem regionalen Äquivalent) gehostet wird, und es gibt URLs unter dieser Domain, die nichts mit der Google Suche zu tun haben. Ein sinnvollerer, restriktiverer Bereich wäre /search. Damit werden zumindest URLs ausgeschlossen, die völlig nichts mit den Suchergebnissen zu tun haben.
Leider wird auch dieser /search-URL-Pfad für verschiedene Varianten der Google-Suchergebnisse verwendet, wobei URL-Suchparameter bestimmen, welche Art von Suchergebnissen angezeigt wird. Einige dieser Geschmacksrichtungen verwenden völlig andere Codebasen als die traditionelle Suchergebnisseite. So werden beispielsweise die Bildersuche und die Shopping-Suche beide unter dem URL-Pfad /search mit unterschiedlichen Abfrageparametern bereitgestellt, aber keine dieser Oberflächen war (noch) für eine eigene Service Worker-Umgebung bereit.
Lösung: Weiterleitungs- und Routing-Framework erstellen
Es gibt einige Vorschläge, die eine leistungsfähigere Funktion als URL-Pfadpräfixe zur Bestimmung von Service Worker-Bereichen zulassen, aber das Team der Google Suche hat bei der Bereitstellung eines Service Workers festgehalten, der für einen Teil der von ihm kontrollierten Seiten nichts tat.
Zur Umgehung dieses Problems hat das Team der Google Suche ein individuelles Weiterleitungs- und Routing-Framework erstellt, das so konfiguriert werden konnte, dass es nach Kriterien wie den Abfrageparametern der Clientseite sucht und anhand dieser Kriterien ermittelt, welcher Codepfad ausgeführt werden soll. Statt Regeln hartzucodieren, ist das System flexibel gestaltet und ermöglicht es Teams mit gemeinsamem URL-Bereich wie der Bildersuche und der Shopping-Suche, später ihre eigene Service Worker-Logik zu implementieren, wenn sie diese implementieren.
Problem: personalisierte Ergebnisse und Messwerte
Nutzer können sich mit ihren Google-Konten in der Google Suche anmelden. Die Suchergebnisse können dann an ihre jeweiligen Kontodaten angepasst werden. Angemeldete Nutzer werden durch spezifische Browser-Cookies identifiziert, einem etablierten und weithin unterstützten Standard.
Ein Nachteil der Verwendung von Browser-Cookies ist jedoch, dass sie nicht innerhalb eines Service Workers verfügbar gemacht werden und es keine Möglichkeit gibt, ihre Werte automatisch zu untersuchen und sicherzustellen, dass sie sich nicht geändert haben, weil sich ein Nutzer abmeldet oder das Konto wechselt. Es wird laufend gearbeitet, Service Worker den Cookie-Zugriff bereitzustellen. Zum Zeitpunkt der Abfassung dieses Artikels ist der Ansatz jedoch experimentell und wird nicht allgemein unterstützt.
Wenn die Ansicht des aktuell angemeldeten Nutzers für den Service Worker nicht mit der des tatsächlichen in der Weboberfläche der Google Suche angemeldeten Nutzers übereinstimmt, kann dies zu falsch personalisierten Suchergebnissen oder falsch zugeordneten Messwerten und Logging führen. Jedes dieser Fehlerszenarien wäre ein ernstes Problem für das Team der Google Suche.
Lösung: Cookies mit postMessage senden
Anstatt auf das Starten experimenteller APIs zu warten und direkten Zugriff auf die Browser-Cookies in einem Service Worker zu ermöglichen, entschied sich das Team der Google Suche für eine Notlösung: Wenn eine vom Service Worker kontrollierte Seite geladen wird, liest die Seite die entsprechenden Cookies und sendet sie mithilfe von postMessage() an den Service Worker.
Der Service Worker prüft dann den aktuellen Cookiewert mit dem erwarteten Wert. Wenn eine Abweichung vorliegt, werden alle nutzerspezifischen Daten dauerhaft aus dem Speicher gelöscht und die Suchergebnisseite ohne falsche Personalisierung neu geladen.
Die spezifischen Schritte, die der Service Worker zum Zurücksetzen der Daten auf die Referenzwerte unternimmt, sind für die Anforderungen der Google Suche spezifisch. Derselbe allgemeine Ansatz kann jedoch auch für andere Entwickler nützlich sein, die mit personalisierten Daten arbeiten, die von Browsercookies verwendet werden.
Problem: Experimente und Dynamik
Das Team der Google Suche führt Tests in der Produktion durch und testet die Auswirkungen von neuem Code und neuen Funktionen in der Praxis, bevor es standardmäßig aktiviert wird. Dies kann für einen statischen Service Worker, der stark auf im Cache gespeicherte Daten angewiesen ist, eine Herausforderung darstellen, da die Aktivierung und Deaktivierung von Tests für Nutzer häufig eine Kommunikation mit dem Back-End-Server erfordert.
Lösung: dynamisch generiertes Service Worker-Skript
Das Team entschied sich für die Lösung, ein dynamisch generiertes Service-Worker-Skript zu verwenden, das vom Webserver für jeden einzelnen Nutzer angepasst wird, anstatt ein einzelnes statisches Service-Worker-Skript, das im Voraus generiert wird. Informationen zu Tests, die sich auf das Verhalten des Service Workers oder allgemeine Netzwerkanfragen auswirken können, sind direkt in diesen angepassten Service Worker-Skripts enthalten. Das Ändern der Gruppen aktiver Tests für einen Nutzer erfolgt über eine Kombination aus herkömmlichen Methoden wie Browser-Cookies sowie der Bereitstellung von aktualisiertem Code in der registrierten Service Worker-URL.
Die Verwendung eines dynamisch generierten Service Worker-Skripts erleichtert es auch, eine Notlösung für den unwahrscheinlichen Fall bereitzustellen, dass bei einer Service Worker-Implementierung ein schwerwiegender Fehler auftritt, der vermieden werden muss. Die dynamische Server-Worker-Antwort könnte eine No-Op-Implementierung sein, die den Service Worker für einige oder alle aktuellen Nutzer deaktiviert.
Problem: Updates koordinieren
Eine der größten Herausforderungen für eine reale Service-Worker-Bereitstellung besteht darin, einen angemessenen Kompromiss zwischen der Vermeidung des Netzwerks durch den Cache zu finden und gleichzeitig sicherzustellen, dass bestehende Nutzer wichtige Updates und Änderungen erhalten, sobald sie für die Produktion bereitgestellt wurden. Das richtige Verhältnis hängt von vielen Faktoren ab:
- Ob Ihre Webanwendung eine langlebige einseitige Anwendung ist, die ein Nutzer unbegrenzt offen hält, ohne zu neuen Seiten wechseln zu müssen.
- Der Bereitstellungsrhythmus für Updates auf Ihrem Backend-Webserver
- Ob der durchschnittliche Nutzer eine etwas veraltete Version Ihrer Web-App tolerieren würde oder ob Aktualität oberste Priorität hat
Während der Tests mit Service Workern achtete das Team der Google Suche darauf, dass die Tests über eine Reihe geplanter Back-End-Updates hinweg ausgeführt wurden, um sicherzustellen, dass die Messwerte und die Nutzererfahrung besser mit dem übereinstimmen, was wiederkehrende Nutzer in der realen Welt sehen würden.
Lösung: Aktualität und Cache-Auslastung ausgleichen
Nachdem das Team der Google Suche verschiedene Konfigurationsoptionen getestet hatte, stellte es fest, dass die folgende Einrichtung die richtige Balance zwischen Aktualität und Cache-Auslastung bot.
Die Service Worker-Skript-URL wird mit dem Antwortheader Cache-Control: private, max-age=1500 (1.500 Sekunden oder 25 Minuten) bereitgestellt und mit der Einstellung „updateViaCache“ auf „all“ registriert, damit der Header berücksichtigt wird. Das Web-Back-End der Google Suche ist, wie Sie sich vorstellen können, eine große, global verteilte Gruppe von Servern, die eine möglichst hohe Verfügbarkeit von 100% erfordert. Änderungen, die sich auf den Inhalt des Service Worker-Skripts auswirken, werden rollierend bereitgestellt.
Wenn ein Nutzer auf ein aktualisiertes Back-End stößt und dann schnell zu einer anderen Seite wechselt, die ein Back-End erreicht, das den aktualisierten Service Worker noch nicht erhalten hat, wechselt er am Ende mehrmals zwischen den Versionen. Daher hat es keinen nennenswerten Nachteil, den Browser anzuweisen, nach einem aktualisierten Skript nur dann zu suchen, wenn 25 Minuten seit der letzten Überprüfung vergangen sind. Der Vorteil dieser Aktivierung besteht darin, den Traffic deutlich zu reduzieren, der von dem Endpunkt empfangen wird, der das Service Worker-Skript dynamisch generiert.
Darüber hinaus wird ein ETag-Header für die HTTP-Antwort des Service Worker-Skripts festgelegt. So kann der Server bei einer Prüfung auf Updates effizient mit einer HTTP 304-Antwort antworten, sofern in der Zwischenzeit keine Updates für den Service Worker bereitgestellt wurden.
Für einige Interaktionen in der Webanwendung der Google Suche werden Navigationen im Stil einer einseitigen Anwendung (d. h. über die Verlaufs-API) verwendet. Die Google Suche ist zum größten Teil eine traditionelle Webanwendung, die „echte“ Navigationen verwendet. Dies kommt ins Spiel, als das Team beschloss, zwei Optionen zu verwenden, die den Service Worker-Aktualisierungszyklus beschleunigen: clients.claim() und skipWaiting().
Wenn Sie auf der Benutzeroberfläche der Google Suche klicken, gelangen Sie in der Regel zu neuen HTML-Dokumenten. Durch das Aufrufen von skipWaiting wird sichergestellt, dass ein aktualisierter Service Worker diese neuen Navigationsanfragen direkt nach der Installation verarbeiten kann. Ebenso bedeutet das Aufrufen von clients.claim(), dass der aktualisierte Service Worker nach der Aktivierung des Service Workers alle geöffneten, nicht kontrollierten Google-Suchseiten steuern kann.
Der Ansatz, den die Google Suche gewählt hat, ist nicht unbedingt eine Lösung, die für alle funktioniert. Er war das Ergebnis sorgfältiger A/B-Tests verschiedener Kombinationen von Bereitstellungsoptionen, bis sie die beste Lösung für sie fanden.
Entwickler, deren Back-End-Infrastruktur es ermöglicht, Updates schneller bereitzustellen, ziehen es vielleicht vor, dass der Browser so oft wie möglich nach einem aktualisierten Service Worker-Skript sucht, indem der HTTP-Cache immer ignoriert wird.
Wenn Sie eine Single-Page-Anwendung erstellen, die Nutzer möglicherweise über einen längeren Zeitraum geöffnet lassen, ist die Verwendung von skipWaiting() wahrscheinlich nicht die richtige Wahl für Sie. Das Risiko von Cache-Inkonsistenzen besteht, wenn Sie den neuen Service Worker aktivieren lassen, während langlebige Clients vorhanden sind.
Fazit
Service Worker sind standardmäßig nicht leistungsneutral
Wenn Sie Ihrer Webanwendung einen Service Worker hinzufügen, wird zusätzlicher JavaScript-Code eingefügt, der geladen und ausgeführt werden muss, bevor die Webanwendung Antworten auf ihre Anfragen erhält. Wenn diese Antworten am Ende 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, der durch einen Cache-First-Ansatz entsteht, in der Regel vernachlässigbar. Wenn Sie jedoch wissen, dass Ihr Service Worker bei der Verarbeitung von Navigationsanfragen immer auf das Netzwerk zugreifen muss, ist die Verwendung des Vorabladens der Navigation ein entscheidender Leistungsgewinn.
Service Worker sind (noch!) eine progressive Verbesserung.
Der Service Worker Support ist heute viel heller als vor einem Jahr. Alle modernen Browser bieten jetzt zumindest eine gewisse Unterstützung für Service Worker, aber es gibt auch einige erweiterte Service Worker-Funktionen wie Hintergrundsynchronisierung und Vorabladen der Navigation, die nicht allgemein eingeführt werden. Es ist immer noch ein vernünftiger Ansatz, Featuretests für eine bestimmte Teilmenge von Funktionen durchzuführen, von denen Sie wissen, dass Sie sie benötigen. Außerdem ist es weiterhin ein vernünftiger Ansatz, einen Service Worker nur zu registrieren, wenn diese vorhanden sind.
Wenn Sie Tests in der Wildnis durchgeführt haben und wissen, dass Low-End-Geräte aufgrund des zusätzlichen Aufwands eines Service Workers schlecht abschneiden, können Sie in diesen Fällen auch auf die Registrierung eines Service Workers verzichten.
Sie sollten Service Worker weiterhin als Progressive Verbesserung in einer Webanwendung behandeln, wenn alle Voraussetzungen erfüllt sind und der Service Worker die Nutzerfreundlichkeit und die Ladeleistung insgesamt positiv beeinflusst.
Alles analysieren
Die einzige Möglichkeit herauszufinden, ob der Versand eines Service Workers positive oder negative Auswirkungen auf die Nutzererfahrung hatte, besteht darin, zu experimentieren und die Ergebnisse zu messen.
Wie Sie aussagekräftige Messungen einrichten, hängt davon ab, welchen Analyseanbieter Sie verwenden und wie Sie normalerweise Tests in Ihrer Bereitstellungskonfiguration durchführen. Ein Ansatz, bei dem Messwerte mit Google Analytics erfasst werden, wird in dieser Fallstudie beschrieben. Er basiert auf der Verwendung von Service Workern in der Google I/O-Webanwendung.
Keine Zielvorhaben
Während viele Mitglieder der Webentwicklungs-Community Service Worker mit Progressive Web Apps verknüpfen, war die Entwicklung einer „Google Search PWA“ nicht das anfä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 Startbildschirm hinzufügen“ zu verwenden. Das Team der Google Suche ist derzeit zufrieden mit den Nutzern, die über die herkömmlichen Einstiegspunkte in die Google Suche zu ihrer Webanwendung gelangen.
Anstatt zu versuchen, die Webnutzung der Google Suche in das Äquivalent zu verwandeln, was Sie von einer installierten Anwendung erwarten, bestand der Schwerpunkt der ersten Einführung darin, die vorhandene Website schrittweise zu verbessern.
Danksagungen
Vielen Dank an das gesamte Webentwicklungsteam der Google Suche für ihre Arbeit an der Service Worker-Implementierung und für das Teilen des Hintergrundmaterials, das zum Verfassen dieses Artikels verwendet wurde. Ein besonderer Dank geht an Philippe Golle, Rajesh Jagannathan, R. Samuel Klatchko, Andy Martone, Leonardo Peña, Rachel Shearer, Greg Terrono und Clay Woolam.
Update (Okt. 2021): Seit der Veröffentlichung dieses Artikels hat das Team der Google Suche die Vor- und Nachteile der aktuellen Service-Worker-Architektur neu bewertet. Der oben beschriebene Service Worker wird eingestellt. Im Zuge der Weiterentwicklung der Webinfrastruktur für die Google Suche kann das Team auch sein Service Worker-Design überarbeiten.