Web-Apps einfacher aktualisieren

Dan Murphy

Dibyajyoti Pal

Veröffentlicht am 21. Januar 2026

Ab Chrome 144 wurde der Aktualisierungsprozess für installierbare Web-Apps mit einem Web-App-Manifest optimiert, sodass er deterministischer, vorhersehbarer und effizienter ist. In diesem Beitrag wird der aktuelle Ansatz erläutert und die Änderungen beschrieben, die wir vorgenommen haben, um ihn zu verbessern.

Das bisherige Verfahren (vor Chrome 144)

Vor Chrome 144 gab es in Webanwendungen kein bestimmtes Ereignis, um Updates proaktiv auszulösen. Stattdessen können Aktualisierungen erfolgen, wenn Entwickler das App-Manifest oder die zugehörigen Symbole ändern. Der Aktualisierungsvorgang beginnt, wenn ein User-Agent ein Manifest über einen Manifest-Link abruft. Das geschieht in der Regel, wenn ein Nutzer eine Website besucht oder eine App startet, die mit diesem Manifest verknüpft ist. Um festzustellen, ob ein Update erforderlich ist, vergleicht das System das aktuelle Manifest und die aktuellen Symbole mit dem zuvor aufgezeichneten Zustand. Dieses Verfahren war ressourcenintensiv, da immer Symbole aus dem Netzwerk heruntergeladen werden mussten, um einen Bitmap-Vergleich durchzuführen.

Um die Serverbelastung durch das Herunterladen von Symbolen zu verringern, hat Chrome eine Drosselung eingeführt, um diese Prüfungen auf einmal pro Tag und App zu beschränken. Der gesamte Bandbreitenverbrauch blieb jedoch hoch. Außerdem führt die Beschränkung der Prüfungen auf einmal pro Tag zu Inkonsistenzen bei der Entwicklung und beim Testen. Entwickler können Nutzern, die keine Updates erhalten haben, auch keine zuverlässigen Lösungen anbieten.

Bei diesem Ansatz mussten Entwickler bei der Implementierung sicherheitsrelevanter Änderungen, z. B. Aktualisierungen des Namens oder Symbols einer App (oft als Änderungen der App-Identität bezeichnet), mit Komplexitäten umgehen. Da Web-Apps keine zentrale Stelle wie Google Play haben, die Updates überprüft, müssen diese Änderungen den Nutzern zur Bestätigung deutlich präsentiert werden. Es war jedoch schwierig, den besten Zeitpunkt zu finden, um Nutzer auf diese Änderungen aufmerksam zu machen.

Frühere Versionen des Aktualisierungsdialogfelds haben häufig Verwirrung gestiftet, weil behauptet wurde, dass sich Symbole geändert hätten, obwohl sie für den Nutzer visuell identisch waren. Dieses Problem entstand dadurch, dass wir uns auf direkte Pixelvergleiche verlassen haben, bei denen oft vernachlässigbare Unterschiede erkannt wurden. Einige Variationen waren auf absichtliche Änderungen durch Entwickler zurückzuführen, viele wurden jedoch durch CDNs verursacht, die Bilder dynamisch neu codiert haben. Das häufige Auslösen des Bestätigungsdialogfelds führte schließlich dazu, dass Symbolaktualisierungen in Chrome 91 deaktiviert wurden.

Um dieses Problem in Chrome für Android zu beheben, wurde vor einigen Jahren ein Schwellenwert für visuelle Unterschiede eingeführt. Dadurch wird sichergestellt, dass die Nutzerbestätigung nur angefordert wird, wenn sich das Symbol deutlich ändert. Durch diese Optimierung konnte die Aktualisierung von Symbolen auf Android-Geräten wieder eingeführt werden. Die Funktion ist jedoch für Chrome auf dem Desktop weiterhin deaktiviert.

Einschränkungen und Ziele für Änderungen an Web-App-Updates

Die Entwicklung des neuen Updateprozesses wurde von den folgenden Zielen geleitet:

• Nutzererwartungen erfüllen:Da die Identität einer App untrennbar mit ihrem Ursprung verbunden ist, dürfen ihr Name und ihr Symbol nicht ohne ausdrückliche Genehmigung des Nutzers geändert werden.
• Funktionale Konsistenz sicherstellen:Anwendungen sollten für alle Nutzer so aktuell wie möglich sein, um eine konsistente Funktionalität zu gewährleisten.
• Vorhersehbare Benutzeroberfläche und Dialogfelder bereitstellen:Entwickler sollten leicht vorhersehen können, wann Nutzer auf Aufforderungen zur Aktualisierung von App-Namen oder ‑Symbolen stoßen.
• Netzwerknutzung optimieren:Der Aktualisierungsmechanismus sollte unnötigen Datenverkehr minimieren.

Was hat sich in Chrome 144 geändert?

Aktualisierungen von Name und Symbol sind jetzt optional

Bisher wurde Nutzern ein störendes Dialogfeld angezeigt, in dem sie entweder die App deinstallieren oder Änderungen an Symbol und Namen sofort akzeptieren mussten. Diese Funktion wurde durch einen nutzerfreundlicheren Vorschlag ersetzt, auf den über ein maximiertes Dreipunkt-Menü zugegriffen werden kann. Nutzer haben jetzt die Möglichkeit, diese Identitätsänderungen zu ignorieren.

Die meisten Manifest-Updates werden sofort angewendet. App-Symbole und ‑Namen, die als sicherheitsrelevante Elemente gelten, werden jedoch separat gespeichert. So können Nutzer diese Änderungen nach Belieben prüfen und anwenden.

Wenn Sie auf App-Update überprüfen klicken, wird das überarbeitete Dialogfeld angezeigt. Der Titel ändert sich je nachdem, welche Elemente aktualisiert werden.

Symbole werden nicht heruntergeladen, wenn sich das Feld „Symbole“ nicht ändert.

Symbole gelten jetzt als unverändert, wenn das Feld icons im Manifest mit der zuletzt angewendeten Version übereinstimmt. Gemäß dieser neuen Logik vermeidet Chrome das Herunterladen von Symbolen für den visuellen Vergleich und behandelt Symbol-URLs effektiv als Cache-Control:immutable. Um ein Symbol-Update auszulösen, müssen Entwickler jetzt entweder die Metadaten oder die Symbol-URL ändern.

Entfernung der Update-Drosselung

Da Chrome nicht mehr jedes Mal Symbole herunterlädt, wenn ein Manifest für eine installierte Anwendung gefunden wird, wurde die bisherige Einschränkung, die Updateprüfungen auf einmal pro Tag beschränkte, aufgehoben. Entwickler können sich jetzt darauf verlassen, dass die Aktualisierung für alle nicht sicherheitssensiblen Mitglieder sofort erfolgt.

Geringfügige Symbolvariationen auf verschiedenen Plattformen berücksichtigen

Um die Nutzerfreundlichkeit zu verbessern, wendet Chrome jetzt automatisch Symbolaktualisierungen an, die bei einem Pixel-für-Pixel-Vergleich weniger als 10% Unterschied aufweisen. So wird verhindert, dass geringfügige Abweichungen, z. B. durch die erneute Codierung durch das CDN, ein verwirrendes Update-Dialogfeld für den Nutzer auslösen.

Diese Menge ist auf einmal pro Tag begrenzt, um potenziellen Missbrauch zu verhindern. Wenn innerhalb dieses Zeitraums weitere Änderungen vorgenommen werden, wird das Symbol als Standardaktualisierung behandelt und der Nutzer wird aufgefordert, die Änderung zu bestätigen.

Beispiel für die Aktualisierung von Symbol und Name

{
  "name": "Example App",
  "short_name": "App",
  "id": "https://www.example-app.com/",
  "start_url": "https://www.example-app.com/index.html",
  "scope": "https://www.example-app.com/",
  "icons": [
    {
      "src": "https://www.example-app.com/img/app.png",
      "sizes": "512x512",
      "type": "image/png",
      "purpose": "any"
    }
  ],

  ... other attributes omitted ...
}

Wenn Sie die Symbol-URL ändern, wird dem Nutzer garantiert ein Aktualisierungsdialogfeld zum Ändern des Symbols angezeigt.

{
  "name": "Example App",
  "short_name": "App",
  "id": "https://www.example-app.com/",
  "start_url": "https://www.example-app.com/index.html",
  "scope": "https://www.example-app.com/",
  "icons": [
    {
      "src": "https://www.example-app.com/img/app-NEW-URL.png",
      "sizes": "512x512",
      "type": "image/png",
      "purpose": "any"
    }
  ],

  ... other attributes omitted ...
}