Gepubliceerd: 21 januari 2026
Vanaf Chrome 144 is het updateproces voor installeerbare webapps met een webappmanifest gestroomlijnd, waardoor het voorspelbaarder, deterministischer en efficiënter is geworden. In dit bericht wordt de huidige aanpak uitgelegd en de wijzigingen die we hebben aangebracht om deze te verbeteren.
De vorige aanpak (vóór Chrome 144)
Vóór Chrome 144 hadden webapplicaties geen specifieke gebeurtenis om proactief updates te activeren. Updates vonden in plaats daarvan plaats wanneer ontwikkelaars het app-manifest of de bijbehorende pictogrammen wijzigden. Het updateproces begint wanneer een user agent een manifest ophaalt via een manifestlink , wat doorgaans gebeurt wanneer een gebruiker een site bezoekt of een app start (waaraan dat manifest is gekoppeld). Om te bepalen of een update nodig is, vergelijkt het systeem het huidige manifest en de pictogrammen met de eerder opgeslagen status. Deze procedure was resource-intensief, omdat er altijd pictogrammen van het netwerk moesten worden gedownload om een bitmapvergelijking uit te voeren.
Om de serverbelasting door het downloaden van pictogrammen te verminderen, heeft Chrome een beperking ingevoerd waardoor deze controles slechts één keer per dag per app worden uitgevoerd. Desondanks bleef het totale bandbreedteverbruik hoog. Bovendien zorgt het beperken van de controles tot één keer per dag voor inconsistenties tijdens de ontwikkeling en het testen, en belemmert het ontwikkelaars om betrouwbare oplossingen te bieden aan gebruikers die geen updates hebben ontvangen.
Met deze aanpak moesten ontwikkelaars complexe situaties het hoofd bieden bij het implementeren van beveiligingsgevoelige wijzigingen , zoals updates van de naam of het pictogram van een app, vaak aangeduid als wijzigingen in de app-identiteit. Omdat webapps geen centrale instantie zoals Google Play hebben om updates te beoordelen, moeten deze wijzigingen duidelijk aan gebruikers worden gepresenteerd ter bevestiging. Het bepalen van het meest geschikte moment om gebruikers om deze wijzigingen te vragen, bleef echter een uitdaging.
Eerdere versies van het updatevenster zorgden ook vaak voor verwarring doordat ze beweerden dat pictogrammen waren gewijzigd, terwijl ze er voor de gebruiker visueel identiek uitzagen. Dit probleem kwam voort uit het gebruik van directe pixelvergelijkingen, die vaak verwaarloosbare verschillen aan het licht brachten. Hoewel sommige variaties het gevolg waren van opzettelijke aanpassingen door ontwikkelaars, werden veel ervan veroorzaakt door CDN's die afbeeldingen dynamisch opnieuw codeerden. Deze frequente activering van het bevestigingsvenster leidde er uiteindelijk toe dat pictogramupdates in Chrome 91 werden uitgeschakeld.
Om dit probleem in Chrome voor Android op te lossen, werd enkele jaren geleden een drempelwaarde voor visuele verschillen geïntroduceerd. Dit zorgt ervoor dat gebruikersbevestiging alleen wordt gevraagd als de pictogramwijzigingen significant zijn. Deze verbetering maakte het mogelijk om pictogramupdates in Android weer in te schakelen, hoewel de functie voor Chrome op desktop uitgeschakeld blijft.
Beperkingen en doelstellingen voor wijzigingen in webapp-updates
De volgende doelstellingen stonden centraal bij de ontwikkeling van het nieuwe updateproces:
- Behoud de verwachtingen van de gebruiker: Omdat de identiteit van een app intrinsiek verbonden is aan de oorsprong ervan, mogen de naam en het pictogram niet worden gewijzigd zonder uitdrukkelijke toestemming van de gebruiker.
- Zorg voor functionele consistentie: applicaties moeten voor alle gebruikers zo actueel mogelijk blijven om een consistente functionaliteit te garanderen.
- Zorg voor een voorspelbare gebruikerservaring en dialoogvensters: ontwikkelaars moeten gemakkelijk kunnen voorspellen wanneer gebruikers interfaceprompts tegenkomen met betrekking tot updates van appnamen of -pictogrammen.
- Optimaliseer het netwerkgebruik: het updateproces moet onnodig dataverkeer minimaliseren.
Wat is er veranderd in Chrome 144?
Naam- en pictogramupdates zijn nu optioneel.
In het verleden kregen gebruikers een storend dialoogvenster te zien waarin ze werden gedwongen de app te verwijderen of direct akkoord te gaan met wijzigingen in het pictogram en de naam. Dit is vervangen door een gebruiksvriendelijker suggestie die toegankelijk is via een uitgebreid menu met drie puntjes. Na selectie kunnen gebruikers er nu voor kiezen om deze identiteitswijzigingen volledig te negeren.
Hoewel de meeste manifestupdates direct worden toegepast, worden app-pictogrammen en -namen – die als veiligheidsgevoelige onderdelen worden beschouwd – apart opgeslagen. Hierdoor kunnen gebruikers deze specifieke wijzigingen op hun eigen gemak bekijken en toepassen.
Als je op 'App-update controleren' klikt, verschijnt het herziene dialoogvenster. De titel verandert afhankelijk van welke elementen worden bijgewerkt.
Pictogrammen worden niet gedownload als er geen wijzigingen zijn aangebracht in het pictogramveld.
Pictogrammen worden nu als ongewijzigd beschouwd als het veld icons in het manifest hetzelfde blijft als de laatst toegepaste versie. Volgens deze nieuwe logica downloadt Chrome geen pictogrammen meer voor visuele vergelijking, waardoor URL's van pictogrammen effectief als Cache-Control:immutable worden behandeld. Om een pictogramupdate te activeren, moeten ontwikkelaars nu de metadata of de URL van het pictogram aanpassen.
Verwijdering van de updatebeperking
Omdat Chrome niet langer pictogrammen downloadt telkens wanneer het een manifest tegenkomt voor een geïnstalleerde applicatie, is de eerdere beperking – die het controleren op updates beperkte tot één keer per dag – opgeheven. Ontwikkelaars kunnen er nu op vertrouwen dat de update onmiddellijk plaatsvindt voor alle niet-beveiligingsgevoelige onderdelen.
Beheer kleine variaties in pictogrammen op verschillende platforms.
Om de gebruikerservaring te verbeteren, past Chrome nu automatisch pictogramupdates toe die een verschil van minder dan 10% vertonen in een pixel-voor-pixelvergelijking. Dit zorgt ervoor dat kleine variaties, zoals die veroorzaakt door CDN-hercodering, geen verwarrend updatevenster voor de gebruiker activeren.
Deze mogelijkheid is beperkt tot één keer per dag om misbruik te voorkomen. Als er binnen dat tijdsbestek verdere wijzigingen plaatsvinden, wordt het pictogram beschouwd als een standaardupdate en wordt de gebruiker gevraagd de wijziging te bevestigen.
Voorbeeld van het bijwerken van pictogram en naam
{
"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 ...
}
Door de URL van het pictogram te wijzigen, wordt gegarandeerd dat de gebruiker een dialoogvenster te zien krijgt om het pictogram aan te passen.
{
"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 ...
}