Calendarul lansărilor de browsere s-a schimbat săptămâna aceasta, și s-a schimbat pentru toată lumea deodată. Mozilla a lansat Firefox 155 pe 1 septembrie, cu două săptămâni mai devreme decât data inițială de 15 septembrie, ca primă versiune a unui nou ritm de două săptămâni. Google a promovat Chrome 154 pe canalul Beta pe 2 septembrie, conform propriului calendar nou, iar Chrome 153 Stable sosește pe 8 septembrie. Microsoft a fost prima: Edge 152, din 27 august, a fost prima sa versiune Stable la două săptămâni.
Din 2021, cele trei browsere care poartă cea mai mare parte a traficului web mondial au lansat fiecare câte o versiune majoră aproximativ la fiecare patru săptămâni. Din această lună, intervalul se înjumătățește.
Cine ce a anunțat și când
Nimic din toate acestea nu a venit fără anunț, dar cele trei anunțuri au fost răspândite pe parcursul a șase luni, motiv pentru care efectul combinat a fost ușor de trecut cu vederea.
Google a publicat planul pe blogul Chrome for Developers pe 3 martie. Începând cu Chrome 153, o nouă versiune Beta și o nouă versiune Stable apar la fiecare două săptămâni pe Desktop, Android și iOS. Canalele Dev și Canary nu se schimbă. Actualizările săptămânale de securitate dintre versiunile majore continuă. Extended Stable, canalul pe care majoritatea administratorilor din companii își fixează parcul de dispozitive, rămâne pe un ciclu de opt săptămâni. Tabelul din blog arată cât de mult s-a mutat calendarul: Chrome 153 Stable era programat pe 22 septembrie și apare acum pe 8 septembrie; Chrome 154 se mută de pe 20 octombrie pe 22 septembrie.
Microsoft a urmat pe 11 iunie. De la Edge 152, pe 27 august, canalul Stable trece la două săptămâni, iar compania a fost explicită în privința a ceea ce înseamnă asta ca volum: fiecare versiune Stable conține aproximativ jumătate din modificările vechii versiuni lunare. Extended Stable își păstrează ritmul de opt săptămâni și preia acum fiecare a patra versiune, astfel că 156, 160 și 164 sunt următoarele repere Extended Stable. Sfatul Microsoft pentru organizații este să testeze pilot un grup pe Beta sau Enterprise Preview, astfel încât problemele să iasă la iveală înainte ca Stable să ajungă în producție.
Mozilla a fost ultima și cea mai prudentă. Sylvestre Ledru, director de inginerie la Mozilla, a scris pe lista dev-platform în iulie că firma era „planning to move Firefox Desktop and Android from a 4-week release cadence to a 2-week release cadence starting in September 2026.” În română: plănuiește să treacă Firefox Desktop și Android de la un ritm de lansare de 4 săptămâni la un ritm de 2 săptămâni, începând din septembrie 2026. The Register a relatat schimbarea pe 17 iulie și a notat că Mozilla o descrie drept un experiment pe care l-ar putea anula. Mozilla Support Blog a confirmat datele pe 19 august: Firefox 155 pe 1 septembrie ca primă versiune la două săptămâni, cu precizarea explicită că un ritm mai rapid „doesn’t mean Firefox will ship twice as many features.” În română: nu înseamnă că Firefox va livra de două ori mai multe funcții. Firefox ESR, linia anuală cu suport extins, nu este afectată; The Register relatează că Firefox 153 este următoarea bază ESR.
Ce s-a lansat de fapt săptămâna aceasta
Firefox 155 este un test util pentru a vedea dacă „jumătate din modificări, de două ori mai des” se confirmă. Notele de lansare din 1 septembrie enumeră extinderea funcției Smart Window, asistată de AI, în SUA, Canada și Franța, un contor al elementelor de urmărire blocate în bara de adrese, reordonarea containerelor în Setări și remedieri pentru întreruperile audio în fundal și pentru o eroare veche pe Linux care împiedica intrarea calculatoarelor în repaus după o sesiune de navigare.
Modificările pentru dezvoltatori consemnate pe MDN sunt partea care atinge site-urile web. Funcția CSS attr() funcționează acum în orice proprietate, cu valori tipizate și valori de rezervă, nu doar în content. Două funcții CSS noi, progress() și alpha(), sosesc împreună cu font-width, noul nume pentru font-stretch. JavaScript primește Promise.allKeyed() și Promise.allSettledKeyed(). Importurile de module eșuate nu mai sunt păstrate în cache, astfel că un script care a eșuat pe o rețea instabilă poate reuși la reîncercare. Pe partea de rețea, Firefox 155 implementează Happy Eyeballs versiunea 3 pentru conectarea concurentă prin IPv6 și IPv4 și negociază QUIC versiunea 2 pentru HTTP/3.
Nu este nimic spectaculos, și tocmai acesta este scopul. Argumentul declarat de Google este că „the smaller scope of these releases minimizes disruption and simplifies post-release debugging.” În română: sfera mai restrânsă a acestor versiuni reduce la minimum perturbările și simplifică depanarea după lansare. Iar Firefox 155 arată exact ca acest tip de versiune: câteva adăugiri la platformă, câteva remedieri, gata în două săptămâni.
De ce s-au mutat toate trei în același sezon
Google și Microsoft folosesc același motor Chromium, așa că, odată ce calendarul Chrome s-a schimbat, cel al Edge avea să urmeze. Raționamentul Mozilla, așa cum relatează The Register, a fost unul mai practic: funcțiile finalizate așteptau săptămâni întregi următorul „tren” de lansare, iar seria imprevizibilă de versiuni intermediare dintre ele era mai greu de planificat decât un ritm fix de două săptămâni.
Chrome a trecut de la lansări la șase săptămâni la lansări la patru săptămâni în 2021 și a adăugat actualizări săptămânale de securitate în 2023; două săptămâni este următorul pas în aceeași direcție.
Ce înseamnă pentru afacerea dumneavoastră
Site-ul dumneavoastră întâlnește acum un motor de browser nou aproximativ la fiecare două săptămâni. Pentru majoritatea site-urilor acest lucru este invizibil și ar trebui să rămână așa. Producătorii de browsere fac teste de compatibilitate tocmai pentru ca o schimbare de versiune să nu strice paginile. Dacă site-ul dumneavoastră depinde de un comportament specific unui anumit producător, de un polyfill care verifică numerele de versiune sau de un widget terț îmbătrânit, fereastra dintre „o modificare ajunge în Beta” și „o modificare este în fața clienților dumneavoastră” s-a redus de la aproximativ patru săptămâni la trei.
Canalul Beta este sistemul de avertizare timpurie și este gratuit. Chrome lansează fiecare Beta cu trei săptămâni înaintea versiunii Stable corespunzătoare. Sfatul Microsoft pentru companii se aplică la fel de bine unui site de marketing: păstrați un calculator sau un profil de browser pe Beta și parcurgeți o dată la două săptămâni procesul de finalizare a comenzii, formularele și fluxul de rezervare. Este mai ieftin decât să aflați de la un client că butonul de plată nu funcționează.
Urmăriți în analitice un salt, nu o tendință. Dacă o actualizare de browser strică ceva, o face la o dată anume. Segmentați rata de conversie după browser și versiune în instrumentul de analiză și căutați o scădere bruscă ce începe în ziua unei lansări și afectează un singur browser. Acest tipar este amprenta unei erori de compatibilitate.
Mențineți-vă propriile dependențe la zi. Site-urile care au dificultăți cu ciclurile rapide ale browserelor sunt de obicei cele care rulează un framework JavaScript, un CMS sau un plugin rămas în urmă cu câțiva ani. Producătorii acestor instrumente testează pe browserele actuale, nu pe propriul produs de acum câțiva ani. Acesta este ritmul de întreținere pe care îl includem în fiecare site web pe care îl livrăm: o revizuire a dependențelor după un calendar fix, nu atunci când ceva se strică.
Parcurile de dispozitive din companii sunt în mare parte neafectate, iar asta contează dacă le vindeți lor. Atât Chrome, cât și Edge păstrează Extended Stable la opt săptămâni, iar Firefox ESR rămâne anual. Dacă clienții dumneavoastră sunt utilizatori corporativi pe dispozitive administrate, ei vor vedea mai puține schimbări de motor decât publicul larg, iar funcțiile lansate într-o versiune Stable la două săptămâni pot avea nevoie de două luni ca să ajungă la ei. Nu construiți o pagină de destinație în jurul unei funcții CSS nou-nouțe pentru o audiență care nu o va vedea până în noiembrie.
Interpretarea noastră este că aceasta este o veste bună pentru web și ceva mai multă muncă pentru cei care întrețin site-urile de pe el. Versiunile mai mici și mai frecvente sunt mai ușor de depanat și mai rapid de reparat. Costul este că vechiul obicei de a verifica compatibilitatea cu browserele „cam o dată pe lună” nu se mai potrivește cu realitatea. Puneți un memento la două săptămâni în calendar; asta este cea mai mare parte a treburii.
