Data di pubblicazione: 21 gennaio 2026
A partire da Chrome 114, il processo di aggiornamento delle app web installabili che hanno un manifesto dell'app web è stato semplificato, rendendolo più deterministico, prevedibile ed efficiente. Questo post spiega l'approccio attuale e le modifiche che abbiamo apportato per migliorarlo.
L'approccio precedente (prima di Chrome 144)
Prima di Chrome 144, le applicazioni web non avevano un evento specifico per attivare gli aggiornamenti in modo proattivo. Gli aggiornamenti possono invece verificarsi quando gli sviluppatori modificano il manifest dell'app o le icone associate. Il processo di aggiornamento inizia quando un user agent recupera un manifest utilizzando un link manifest, il che in genere avviene quando un utente visita un sito o avvia un'app (con il manifest collegato). Per determinare se è necessario un aggiornamento, il sistema confronta il manifest e le icone attuali con lo stato registrato in precedenza. Questa procedura richiedeva molte risorse, in quanto era sempre necessario scaricare le icone dalla rete per eseguire un confronto bitmap.
Per ridurre il carico del server dovuto ai download delle icone, Chrome ha implementato una limitazione per limitare questi controlli a una volta al giorno per app, ma il consumo totale di larghezza di banda è rimasto elevato. Inoltre, limitare i controlli a una volta al giorno causa incoerenze durante lo sviluppo e i test, impedendo agli sviluppatori di fornire soluzioni affidabili agli utenti che non hanno ricevuto aggiornamenti.
Con questo approccio, gli sviluppatori dovevano affrontare complessità durante l'implementazione di modifiche sensibili alla sicurezza, come gli aggiornamenti al nome o all'icona di un'app, spesso chiamati modifiche all'identità dell'app. Poiché le app web non dispongono di un'autorità centrale come Google Play per esaminare gli aggiornamenti, queste modifiche devono essere presentate chiaramente agli utenti per la conferma. Determinare il momento più opportuno per chiedere agli utenti di apportare queste modifiche, tuttavia, è rimasto un problema.
Anche le iterazioni precedenti della finestra di dialogo di aggiornamento hanno spesso causato confusione affermando che le icone erano cambiate quando apparivano visivamente identiche all'utente. Questo problema derivava dall'affidamento a confronti diretti dei pixel, che spesso segnalavano differenze trascurabili. Mentre alcune variazioni sono il risultato di modifiche intenzionali da parte degli sviluppatori, molte sono state causate dalla ricodifica dinamica delle immagini da parte delle CDN. Questo frequente attivazione eccessiva della finestra di dialogo di conferma ha portato alla disattivazione degli aggiornamenti delle icone in Chrome 91.
Per risolvere questo problema su Chrome per Android, è stata introdotta una soglia di differenza visiva diversi anni fa. In questo modo, la conferma dell'utente viene richiesta solo se le modifiche all'icona sono significative. Questo perfezionamento ha consentito di ripristinare l'aggiornamento delle icone su Android, anche se la funzionalità è rimasta disattivata per Chrome su computer.
Vincoli e obiettivi per le modifiche agli aggiornamenti delle app web
I seguenti obiettivi hanno guidato lo sviluppo della nuova procedura di aggiornamento:
- Preserva le aspettative degli utenti:poiché l'identità di un'app è intrinsecamente collegata alla sua origine, il suo nome e la sua icona non devono essere alterati senza l'approvazione esplicita dell'utente.
- Garantisci la coerenza funzionale:le applicazioni devono rimanere aggiornate il più possibile per tutti gli utenti per garantire una funzionalità coerente.
- Fornire UX e finestre di dialogo prevedibili: gli sviluppatori devono essere in grado di prevedere facilmente quando gli utenti incontreranno prompt dell'interfaccia relativi agli aggiornamenti di nomi o icone delle app.
- Ottimizzare l'utilizzo della rete:il meccanismo di aggiornamento deve ridurre al minimo il traffico di dati non necessario.
Che cosa è cambiato in Chrome 144?
Gli aggiornamenti del nome e dell'icona ora sono facoltativi
In passato, gli utenti dovevano affrontare una finestra di dialogo che li costringeva a disinstallare l'app o ad accettare immediatamente le modifiche all'icona e al nome. È stato sostituito da un suggerimento più intuitivo accessibile da un menu con tre puntini espanso. Una volta selezionate, gli utenti hanno ora la possibilità di ignorare completamente queste modifiche all'identità se preferiscono.
Sebbene la maggior parte degli aggiornamenti del manifest venga applicata immediatamente, le icone e i nomi delle app, considerati membri sensibili alla sicurezza, vengono memorizzati separatamente. In questo modo, gli utenti possono esaminare e applicare queste modifiche specifiche quando preferiscono.
Se fai clic su Rivedi aggiornamento app, viene visualizzata la finestra di dialogo rivista. Il titolo cambia in base agli elementi che vengono aggiornati.
Le icone non vengono scaricate se il campo delle icone non è stato modificato
Le icone vengono ora considerate invariate se il campo
icons
nel manifest rimane lo stesso dell'ultima versione applicata. In base a questa
nuova logica, Chrome evita di scaricare le icone per il confronto visivo, trattando
gli URL delle icone come
Cache-Control:immutable.
Per attivare un aggiornamento dell'icona, ora gli sviluppatori devono modificare i metadati o l'URL dell'icona.
Rimozione della limitazione degli aggiornamenti
Poiché Chrome non scarica più le icone ogni volta che rileva un manifest per un'applicazione installata, la precedente limitazione, che limitava i controlli degli aggiornamenti a una volta al giorno, è stata eliminata. Gli sviluppatori ora possono fare affidamento sull'aggiornamento immediato per tutti i membri non sensibili alla sicurezza.
Gestire piccole variazioni delle icone sulle varie piattaforme
Per migliorare l'esperienza utente, Chrome ora applica automaticamente gli aggiornamenti delle icone che mostrano una differenza inferiore al 10% in un confronto pixel per pixel. In questo modo, le variazioni minori, come quelle causate dalla ricodifica della CDN, non attivano una finestra di dialogo di aggiornamento confusa per l'utente.
Questo limite è limitato a una volta al giorno per evitare potenziali abusi. Se si verificano ulteriori modifiche all'interno di questa finestra, l'icona viene trattata come un aggiornamento standard e all'utente viene chiesto di confermare la modifica.
Esempio di aggiornamento di icona e nome
{
"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 ...
}
La modifica dell'URL dell'icona garantisce che l'utente visualizzerà una finestra di dialogo di aggiornamento per modificare l'icona.
{
"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 ...
}