Il calendario delle release dei browser è cambiato questa settimana, e per tutti allo stesso tempo. Mozilla ha rilasciato Firefox 155 il 1° settembre, due settimane prima della data originaria del 15 settembre, come prima release di una nuova cadenza di due settimane. Google ha promosso Chrome 154 al canale Beta il 2 settembre secondo il proprio nuovo calendario, e Chrome 153 Stable arriva l’8 settembre. Microsoft è stata la prima: Edge 152 del 27 agosto è stata la sua prima release Stable a due settimane.
Dal 2021 i tre browser che gestiscono la maggior parte del traffico web mondiale hanno rilasciato ciascuno una versione principale all’incirca ogni quattro settimane. Da questo mese quell’intervallo si dimezza.
Chi ha annunciato cosa, e quando
Nulla di tutto questo è arrivato senza preavviso, ma i tre annunci sono stati distribuiti su sei mesi, ed è per questo che l’effetto complessivo è passato facilmente inosservato.
Google ha pubblicato il piano sul blog Chrome for Developers il 3 marzo. A partire da Chrome 153, una nuova Beta e una nuova Stable escono ogni due settimane su Desktop, Android e iOS. I canali Dev e Canary non cambiano. Gli aggiornamenti di sicurezza settimanali tra una milestone e l’altra continuano. Extended Stable, il canale a cui la maggior parte degli amministratori aziendali vincola il proprio parco macchine, resta su un ciclo di otto settimane. La tabella dello stesso blog mostra quanto si è spostato il calendario: Chrome 153 Stable era previsto per il 22 settembre e ora esce l’8 settembre; Chrome 154 passa dal 20 ottobre al 22 settembre.
Microsoft ha seguito l’11 giugno. Da Edge 152 del 27 agosto il canale Stable passa a due settimane, e l’azienda è stata esplicita su cosa significa in termini di volume: ogni release Stable contiene circa la metà delle modifiche della vecchia release mensile. Extended Stable mantiene il ritmo di otto settimane e ora riprende una release ogni quattro, quindi 156, 160 e 164 sono le prossime milestone Extended Stable. Il consiglio di Microsoft alle organizzazioni è di mettere un gruppo pilota su Beta o Enterprise Preview, così che i problemi emergano prima che Stable arrivi in produzione.
Mozilla è stata l’ultima, e la più cauta. Sylvestre Ledru, Director of Engineering di Mozilla, ha scritto a luglio alla lista dev-platform che l’azienda stava “planning to move Firefox Desktop and Android from a 4-week release cadence to a 2-week release cadence starting in September 2026.” In italiano: pianificando di portare Firefox Desktop e Android da una cadenza di rilascio di 4 settimane a una di 2 settimane a partire da settembre 2026. The Register ha riportato il cambiamento il 17 luglio e ha osservato che Mozilla lo descrive come un esperimento che potrebbe annullare. Il Mozilla Support Blog ha confermato le date il 19 agosto: Firefox 155 il 1° settembre come prima release a due settimane, con l’avvertenza esplicita che una cadenza più rapida “doesn’t mean Firefox will ship twice as many features.” In italiano: non significa che Firefox rilascerà il doppio delle funzionalità. Firefox ESR, il canale annuale a supporto esteso, non è interessato; The Register riferisce che Firefox 153 sarà la prossima base ESR.
Cosa è uscito davvero questa settimana
Firefox 155 è un buon banco di prova per verificare se “metà delle modifiche, il doppio delle volte” regge. Le note di rilascio del 1° settembre elencano l’estensione di Smart Window, assistito dall’AI, a Stati Uniti, Canada e Francia, un contatore dei tracker bloccati nella barra degli indirizzi, il riordino dei container nelle Impostazioni, e correzioni per le interruzioni dell’audio in background e per un bug di lunga data su Linux che impediva alle macchine di andare in sospensione dopo una sessione di navigazione.
Le modifiche per gli sviluppatori registrate su MDN sono la parte che riguarda i siti web. La funzione CSS attr() ora funziona in qualsiasi proprietà, con valori tipizzati e fallback, non solo in content. Due nuove funzioni CSS, progress() e alpha(), arrivano insieme a font-width come nuovo nome di font-stretch. JavaScript guadagna Promise.allKeyed() e Promise.allSettledKeyed(). Gli import di moduli falliti non vengono più messi in cache, quindi uno script fallito su una rete instabile può riuscire al secondo tentativo. Sul fronte rete, Firefox 155 implementa Happy Eyeballs versione 3 per la connessione in parallelo su IPv6 e IPv4 e negozia QUIC versione 2 per HTTP/3.
Non è nulla di eclatante, ed è proprio questo il punto. La motivazione dichiarata da Google è che “the smaller scope of these releases minimizes disruption and simplifies post-release debugging.” In italiano: la portata ridotta di queste release riduce al minimo le interruzioni e semplifica il debugging successivo al rilascio. E Firefox 155 sembra esattamente quel tipo di release: una manciata di aggiunte alla piattaforma, una manciata di correzioni, pronta in due settimane.
Perché tutti e tre si sono mossi nella stessa stagione
Google e Microsoft condividono il motore Chromium, quindi una volta cambiato il calendario di Chrome, quello di Edge avrebbe seguito. Le ragioni di Mozilla, come riporta The Register, erano più interne: funzionalità già pronte aspettavano per settimane il treno successivo, e una serie imprevedibile di release intermedie era più difficile da pianificare rispetto a un ritmo fisso di due settimane.
Chrome è passato da release ogni sei settimane a ogni quattro nel 2021 e ha aggiunto aggiornamenti di sicurezza settimanali nel 2023; due settimane sono il passo successivo nella stessa direzione.
Cosa significa per la tua azienda
Il tuo sito ora incontra un nuovo motore browser all’incirca ogni due settimane. Per la maggior parte dei siti questo è invisibile, e dovrebbe restarlo. I produttori di browser eseguono test di compatibilità proprio perché un cambio di versione non rompa le pagine. Se il tuo sito dipende da un comportamento specifico di un produttore, da un polyfill che rileva i numeri di versione o da un widget di terze parti ormai datato, la finestra tra “una modifica arriva in Beta” e “una modifica è davanti ai tuoi clienti” si è ridotta da circa quattro settimane a tre.
Il canale Beta è il sistema di allerta precoce, ed è gratuito. Chrome rilascia ogni Beta tre settimane prima della Stable corrispondente. Il consiglio di Microsoft alle aziende vale altrettanto per un sito di marketing: tieni una macchina, o un profilo del browser, su Beta e una volta ogni due settimane percorri il tuo checkout, i tuoi moduli e il tuo flusso di prenotazione. Costa meno che scoprire da un cliente che il pulsante di pagamento non funziona.
Cerca nei tuoi dati analytics un gradino, non una tendenza. Se un aggiornamento del browser rompe qualcosa, lo fa in una data precisa. Segmenta il tasso di conversione per browser e versione nel tuo strumento di analytics e cerca un calo improvviso che inizia il giorno di una release e riguarda un solo browser. Quel pattern è l’impronta di un bug di compatibilità.
Tieni aggiornate le tue dipendenze. I siti che faticano con i cicli rapidi dei browser sono di solito quelli che usano un framework JavaScript, un CMS o un plugin indietro di diversi anni. I produttori di questi strumenti testano sui browser attuali, non sul proprio prodotto di diversi anni fa. Questo è il ritmo di manutenzione che integriamo in ogni sito web che consegniamo: una revisione delle dipendenze a calendario fisso, non quando qualcosa si rompe.
I parchi macchine aziendali sono in gran parte esclusi, e questo conta se vendi a loro. Sia Chrome sia Edge mantengono Extended Stable a otto settimane, e Firefox ESR resta annuale. Se i tuoi clienti sono utenti aziendali su dispositivi gestiti, vedranno meno cambiamenti di motore rispetto al pubblico generale, e le funzionalità rilasciate in una Stable a due settimane potrebbero impiegare due mesi per raggiungerli. Non costruire una landing page attorno a una funzionalità CSS appena uscita per un pubblico che non la vedrà prima di novembre.
La nostra lettura è che si tratta di una buona notizia per il web e di un po’ di lavoro in più per chi mantiene i siti che ci vivono sopra. Release più piccole e più frequenti sono più facili da debuggare e più rapide da correggere. Il costo è che la vecchia abitudine di controllare la compatibilità dei browser “più o meno ogni mese” non corrisponde più alla realtà. Metti un promemoria ogni due settimane in calendario; è già gran parte del lavoro.
