İçeriğe geç
Emir Hoca.

Core Web Vitals artık sayfa içi geçişleri de ölçmeyi deniyor

Chrome, Ekim 2026'da CrUX'e soft navigation metriklerini deneysel olarak ekledi. Next.js ve benzeri sitelerde ne değişiyor, şimdiden neye bakmalı?

2 dk okuma

Next.js ile yaptığım sitelerde müşterilere sık sık şunu anlatırım: ilk açılış hızı tek başına yeterli değil, ziyaretçi menüden başka bir sayfaya geçtiğinde de site hızlı hissettirmeli. Chrome ekibi tam bu konuda bir adım attı. web.dev'deki 13 Ekim 2026 tarihli duyuruya göre CrUX artık soft navigation içeren deneysel Core Web Vitals metriklerini yayımlıyor.

Soft navigation ne demek?

Klasik bir sitede her bağlantıya tıkladığınızda tarayıcı yeni bir sayfa yükler. Next.js gibi tek sayfa uygulaması mantığıyla çalışan sitelerde ise geçişlerin çoğu JavaScript ile, sayfa yeniden yüklenmeden yapılır. Bu geçişlere soft navigation deniyor. Şimdiye kadar Core Web Vitals ağırlıklı olarak ilk yüklemeye bakıyordu; sayfa içi geçişlerdeki gecikme ve kaymalar bu ölçümün dışında kalabiliyordu.

Ne değişti?

  • Yeni deneysel metrikler LCP, INP ve CLS'yi hem tam sayfa yüklemelerinde hem de JavaScript ile yapılan rota geçişlerinde ölçüyor.
  • Veriler Ekim 2026 CrUX sürümüyle BigQuery, CrUX API ve CrUX History API üzerinden erişilebilir durumda.
  • Bu ölçümü mümkün kılan web platformu API'si Chrome 151 ile geldi.
  • Google'ın kararlı Core Web Vitals puanları, deneysel metrikler değerlendirilirken şimdilik değişmiyor.

Chrome ekibinin beklentisi, klasik çok sayfalı sitelerin çoğunda sonuçların aynı ya da çok yakın çıkması. Yoğun şekilde istemci tarafı geçiş kullanan sitelerde ise fark görülmesi bekleniyor.

Bu sizi ne zaman ilgilendirir?

Siteniz WordPress gibi klasik bir yapıdaysa büyük ihtimalle bir şey değişmeyecek. Next.js ya da benzeri bir altyapı kullanıyorsanız, özellikle filtreli ürün listeleri, sonsuz kaydırma veya modal pencereler varsa, bu geçişlerde yaşanan yavaşlık ilk kez veriye yansıyabilir. Bu metrikler henüz deneysel ve tanımları değişebilir. Bu yüzden şu an sözleşmelerde hedef olarak kullanılmasını önermiyorum; ama ne gördüğünüzü bilmek için iyi bir zaman.

Next.js sitelerinde geçişleri neler yavaşlatır?

Kendi projelerimde ve devraldığım sitelerde gördüğüm en yaygın neden, sayfa değişirken tarayıcıya fazla iş bırakılması. Her geçişte büyük bir JavaScript paketi indirilip çalıştırılıyorsa, ziyaretçi menüye tıkladıktan sonra bir süre hiçbir şey olmadığını görür. Bu, INP'nin ölçtüğü türden bir gecikme.

İkinci neden üçüncü taraf etiketler. Analitik, reklam ve sohbet araçları her rota değişiminde yeniden tetiklenebiliyor ve ana iş parçacığını meşgul ediyor. Üçüncüsü de yeni sayfanın içeriği geldikçe yerinden oynayan bileşenler: yüksekliği belli olmayan görseller, sonradan yüklenen bannerlar ya da filtre sonuçları gelince aşağı kayan bir ürün ızgarası. Bunlar CLS'ye yansıyor.

Bu sorunların çoğu ilk açılışta da görülebiliyor, ama soft navigation ölçümü onları uygulamanın içinde de görünür kılacak. Yani bugüne kadar "ilk açılış hızlı" diye rahat ettiğimiz siteler için bakılacak yeni bir yer açılıyor.

Şimdiden yapabilecekleriniz

  1. Menü ve ürün listeleme geçişlerini gerçek kullanıcı izleme aracıyla rota bazında ölçün.
  2. CrUX API'deki deneysel soft navigation alanlarını mevcut LCP, INP ve CLS sonuçlarınızla karşılaştırın.
  3. Filtreleme, sonsuz kaydırma, modal ve istemci tarafı rota değişimlerinde gecikme ve kaymaları test edin.
  4. Yavaş geçişlerde ağır JavaScript'i, üçüncü taraf etiketleri ve büyük görsel bileşenleri azaltın.
  5. Deneysel veriyi sözleşmesel bir performans hedefine çevirmeden önce metriklerin kararlı hale gelmesini bekleyin.

Next.js sitenizin geçişlerini birlikte ölçmek isterseniz bir mesaj bırakın, hangi sayfalardan başlayacağımıza beraber karar verelim.

Kaynaklar