Chrome'un Eylül 2026'dan itibaren iki haftalık sürüm döngüsü, tek CrUX penceresine iki ana sürüm sığdırıyor

Chrome iki haftalık Stable temposuna geçiyor

dev.to'da yayımlanan bir yazıya göre Google, Mart 2026'da Chrome'un dört haftalık Stable takvimini bırakıp 8 Eylül 2026'daki Chrome 153 Stable ile başlayan iki haftalık bir döngüye geçeceğini duyurdu. Beta ve Stable'a yükseltmeler masaüstü, Android ve iOS'ta iki haftada bir gerçekleşirken, Extended Stable daha uzun doğrulama pencerelerine ihtiyaç duyan kurumlar için sekiz haftalık ritmini koruyor. Yazı, sıkışmayı iki kilometre taşıyla özetliyor: Chrome 153, 8 Eylül 2026'da herkese açık Stable kanalına ulaşıyor ve Chrome 154, 22 Eylül'de geliyor — eski dört haftalık takvimde bu slotlar eylül sonuna ve ekim sonuna denk gelirdi. Yazı ayrıca Firefox'un 1 Eylül 2026'dan itibaren Firefox 155 civarında benzer bir deneme yürüttüğünü gösteren topluluk haberlerine değiniyor.

Bunun 28 günlük saha verisine etkisi

Yazının merkezindeki endişe Chrome User Experience Report. CrUX — ve PageSpeed Insights'taki saha paneli — izin verilen Chrome oturumlarını 28 günlük kayan bir pencerede topluyor ve CrUX API bu aralığı başlangıç ve bitiş tarihli bir toplama dönemi olarak sunuyor. Pencere her gün kayıyor: en eski gün çıkıyor, en yeni giriyor ve hiçbir şey tüm popülasyonu yayın gününde yeni çıkan ana sürüme aniden geçiriyor.

Eski dört haftalık tempoda tek bir pencere genellikle bir yeni Stable ana sürümü ile geride kalan eski sürümleri içeriyordu. İki haftalık tempoda aynı pencere 152 ve 153 gibi iki ardışık ana sürümü barındırabiliyor — bu sırada otomatik güncelleme kurulu tabana yayılıyor. Her ana sürüm değişmemiş bir sayfada paint zamanlamasını, görsel kod çözmeyi, lazy-loading buluşlarını veya etkileşim planlamasını değiştirebiliyor; dolayısıyla yayımlanan p75 LCP, INP veya CLS değeri, kaynağa hiç dokunulmayan nedenlerle oynayabiliyor.

Deploy olmadan kayma

Yazı, ajans işlerinde tekrar eden üç deploy dışı nedeni sayıyor:

• Tarayıcı güncellemeleri. Pencere ortasında otomatik güncellenen kullanıcılar, tek bir toplama içinde güncelleme sonrası oturumları güncelleme öncesi oturumların yanına ekler.
• Kanal sapması. Beta, Dev ve Canary çoğu perakende sitesi için küçük dilimlerdir; ancak Extended Stable kitleleri Stable'ın haftalar gerisinde kalabildiğinden, kilitli bir kurumsal kitle aynı URL şablonunda tüketici kitlesinden farklı bir saha bandı okuyabilir.
• Trafik kompozisyonu. Kampanyalar, coğrafi değişimler veya mevsimsellik hangi şablonların oturumlara hâkim olduğunu değiştirir; daha yavaş bir kategori listesi ana sayfaya karşı pay kazandığında, iki şablonda da kod değişikliği olmadan kaynak düzeyinde LCP oynar.

Yazının yaptığı ayrım araçlara dair: sabit bir URL'deki lab çalışmaları deploy'unuzun kritik yolu değiştirip değiştirmediğini söylerken, saha CrUX Chrome kullanıcılarının sürümler ve kullanıcı yolculukları boyunca gerçekte ne yaşadığını söyler. Bir saha hareketini önce tarayıcı ve trafik kompozisyonunu kontrol etmeden deploy regresyonu olarak değerlendirmek, mühendisleri hiç yapılmamış bir değişikliği geçmişte aramaya gönderir.

Pratik öneriler

Yazıdaki öneriler teknik değil operasyonel. Tarayıcı Stable ve Beta tarihlerini, uygulama deploy'ları, CDN kural değişiklikleri ve tag manager yayınları için kullanılan takvime not edin. Saha verisini tam Chrome ana sürümüne göre dilimlemeden önce örneklem eşikleri belirleyin; çünkü ince dilimler her hafta regresyon gibi görünen sıçrayan p75 çizgileri üretir. Retainer raporlarında dilimlenmemiş LCP, INP ve CLS'yi ana seri olarak tutun, tarayıcı ana sürümü dilimlerini mühendisler için ek malzemeye indirin. Benzeri benzeriyle karşılaştırın — aynı form factor, aynı URL veya kaynak kapsamı, aynı toplama tarihleri — ve her dilimlenmiş grafiği dilimlenmemiş bir çizgiyle eşleştirin ki yönetim tüm popülasyonun mu yoksa yalnızca bir dilimin mi kaydığını görebilsin. Planlı lab çalışmaları, kaynağın kendisinin değişmediğine dair aynı haftaya ait kanıt görevi görür.

Yazı ayrıca performans danışmanı Harry Roberts'a atıf yapıyor; Roberts bir Web-Perf Wednesday bölümünde, daha hızlı tarayıcı sürümlerinin yalnızca sunucudaki kodu değil, bir RUM ortalamasının çekildiği popülasyonu da değiştirdiğini savunuyor. Bu bakışla, örneklem büyüklükleri olmadan ana sürüm bazında LCP rakamları raporlamak, her yayın tarihi çevresinde yanlış alarmları davet ediyor.

Neden önemli

Daha hızlı ana sürümler güvenlik ve platform ilerlemesi için net bir olumlu; ancak saha panellerinin anlamını sessizce yeniden tanımlıyorlar. 28 günlük CrUX rakamı hiçbir zaman aynı gün ölçümü değildi; Eylül 2026'dan itibaren bu pencerenin farklı render davranışına sahip iki tarayıcı neslini harmanlaması rutin hale gelecek. Yalnızca kendi yayınlarını not eden ekipler popülasyon kaymalarını regresyon olarak okumaya devam edecek ve örneklem eşiği olmadan Chrome ana sürümüne göre dilimleyen ekipler gürültünün peşinden koşacak. Not takvimine bir tarayıcı sürümü satırı eklemek, tekrar eden bir yanlış alarm sınıfını önceden engelleyen küçük bir değişiklik.