Sayfa içi geçiş performansı bugün yalnızca teknik ekibin konuştuğu bir detay değil. Google, Core Web Vitals metriklerinin yükleme, etkileşim ve görsel kararlılığı ölçtüğünü açıkça söylüyor; aynı zamanda iyi skorların tek başına üst sıralama garantisi vermediğini de ekliyor. Bu iki cümle birlikte okunduğunda tablo netleşiyor: ilk açılış hızını iyileştirmek gerekli, ama kullanıcı site içinde dolaşırken yaşadığı akış da en az onun kadar önemli.
Bir kullanıcı ana sayfanıza hızlı girip kategoriye geçerken bekliyorsa, filtreden sonra ürünler geç toparlanıyorsa ya da geri tuşunda sayfa yeniden yükleniyorsa, “site hızlı” demek sahada pek bir şey ifade etmez. Özellikle e-ticaret, landing page ve çok adımlı hizmet sitelerinde kullanıcı deneyimi ilk ekranda değil, ardışık geçişlerde kırılır. Chrome ve web.dev dokümantasyonu da bugün tam bu alanlara daha fazla odaklanıyor: anlık geri-ileri geçişleri, gelecekteki navigasyonları hızlandırma ve etkileşim gecikmesini düşürme.
İlk açılış hızı neden tek başına yeterli değildir?
LCP hâlâ önemlidir. Google, iyi bir kullanıcı deneyimi için LCP’nin yüklemenin başlamasından itibaren 2,5 saniye içinde gerçekleşmesini öneriyor. Ama aynı belgede INP’nin de Core Web Vitals’ın parçası olduğu ve 200 milisaniyenin altında tutulmasının hedeflenmesi gerektiği yazıyor. Yani iyi deneyim, sadece en büyük içeriğin erken görünmesi değil; kullanıcının tıkladığında sayfanın tutarlı biçimde hızlı tepki vermesi anlamına geliyor.
INP’nin farkı burada ortaya çıkıyor. web.dev, INP’yi kullanıcının ziyaret süresi boyunca gerçekleşen nitelikli etkileşimlerin gecikmesini izleyen bir metrik olarak tanımlıyor. Bu şu demek: menü açılışı, filtre tıklaması, varyant seçimi, sepete ekleme, akordeon kullanımı ya da form alanları arasında gezinme sadece “frontend hissi” değildir; ölçülebilir performans davranışıdır. Ana sayfanız hızlı açılıp içerideki etkileşimler ağırsa, kullanıcı bunu doğrudan hisseder.
Google ayrıca iyi Core Web Vitals skorlarının üst sıralamayı garanti etmediğini söylüyor. Bu cümle bazen yanlış okunuyor. Buradan çıkarılması gereken şey “performans önemsiz” değil. Asıl mesaj, tek metrikli düşünmenin zayıf kaldığıdır. Fabrikido tarafında bunu sık görüyoruz: Lighthouse puanı temiz, ama kullanıcı ürün listeleme sayfasından ürün detayına geçerken yavaşlık hissediyor. Skor raporu ile gerçek kullanım arasında fark oluştuğunda, çoğu zaman sorun ilk yüklemede değil geçiş akışındadır.
Sayfa içi geçiş performansı tam olarak neyi kapsar?
Bu kavramı sadece tek sayfa uygulamalara sıkıştırmak yanlış olur. MPA mimarisinde kategori sayfasından ürün detayına geçiş, blog yazısından iletişim sayfasına tıklama, tarayıcı geri-ileri kullanımı veya dahili linkler arası dolaşım bunun içindedir. SPA tarafında ise route değişimi, filtre sonrası içerik yenilenmesi, sekme geçişleri ve aynı doküman içindeki görünüm değişimleri işin parçasıdır. Kullanıcı gözünde fark basittir: “Yeni bir yere geçtim ve bekledim mi, beklemedim mi?”
Back/forward cache burada çok öğretici bir örnek. web.dev, bfcache’i geri ve ileri navigasyonları anlık hale getiren bir tarayıcı optimizasyonu olarak tanımlıyor. Sayfa yok edilmek yerine bellekte tutuluyor; kullanıcı geri döndüğünde JavaScript ve DOM durumu tekrar ayağa kalkıyor. Bu yüzden geri dönüş yeniden yükleme gibi hissettirmiyor. Daha da önemlisi, aynı kaynaklar yeniden indirilmediği için veri kullanımı da azalıyor.
Gelecekteki navigasyonları hızlandırma tarafında da benzer bir mantık var. Chrome’un Speculation Rules API rehberi, gelecekteki sayfaların prefetch veya prerender ile daha hızlı, hatta anlık açılabileceğini söylüyor. Prefetch ilk adımdır; prerender daha ileri gider ve sayfayı arka planda hazırlar. Ama burada ince bir sınır var: Chrome, aşırı spekülasyonun bant genişliği, bellek ve CPU maliyeti yaratabileceğini özellikle vurguluyor. Yani sayfa içi geçiş performansı sadece “her şeyi önceden yükle” meselesi değildir; akıllı seçim meselesidir.
Modern sitelerde ölçüm neden bazen eksik kalıyor?
Bugünün önemli açmazlarından biri şu: kullanıcı deneyimi ile standart metrik raporları her zaman birebir örtüşmüyor. web.dev’in SPA rehberine göre Core Web Vitals bugün hâlâ top-level page navigation’a göre ölçülüyor; SPA route geçişleri mevcut metrikleri sıfırlamıyor. Yani URL adres çubuğunda değişse bile metrikler o yeni route’u bağımsız bir tam sayfa yüklemesi gibi değerlendirmiyor. Bu yüzden Search Console yeşil görünürken kullanıcı SPA içinde yavaş filtre akışı yaşayabiliyor.
Chrome ekibi de bu boşluğu kabul ediyor. Nisan 2026’da yayınlanan soft navigations deneyi, modern web’de sık görülen ama mevcut metriklerde eksik kalan bu deneyimi daha iyi ölçebilmek için hazırlanmış durumda. Belge açıkça bunun hâlâ deneysel aşamada olduğunu söylüyor. Yani bugün tüm araçların kusursuz biçimde “sayfa içi geçiş performansı” ölçtüğünü varsaymak doğru olmaz. Özellikle React, Vue, Nuxt, Next, app shell ve ağır frontend state kullanan projelerde, kendi RUM ölçümünüz olmadan kullanıcı deneyimini eksik okuyabilirsiniz.
Bizim ajans tarafında en sık gördüğümüz hata tam burada çıkıyor. Marka yalnızca landing page LCP’sine bakıyor. Oysa kullanıcı asıl işini filtre, arama, varyant ve ödeme adımlarında yapıyor. Eğer ölçümünüz sadece ilk giriş ekranını parlatıyorsa, gerçekte kazandığınız şey skor olabilir; akış olmayabilir. Bu ayrım özellikle WooCommerce, çok varyantlı kataloglar ve Elementor ile büyümüş sayfalarda daha görünür hale geliyor. Bu son cümle, resmi dokümanlardan değil, projelerde gördüğümüz pratik örüntüden çıkan bir ajans gözlemidir.
SEO tarafında neden önemlidir?
Google’ın resmi çizgisi burada dengeli. Core Web Vitals ranking sistemlerinde kullanılıyor; fakat iyi skorlar tek başına üst sıralama garantisi vermiyor. Bu, performansın ikincil olduğu anlamına gelmez. Daha doğru okuma şudur: performans, özellikle kullanıcı memnuniyeti ve sayfa deneyimi tarafında genel kalite sinyallerinin parçasıdır. Arama görünürlüğünü konuşurken kullanıcı akışını görmezden gelmek, SEO’yu dar okumaktır.
İşin ticari karşılığı daha da net. Ray-Ban’ın web.dev vaka çalışmasında, Speculation Rules API ile gelecekteki navigasyonları prerender ederek dönüşüm oranını iki katına çıkardığı ve exit rate’i yüzde 13 düşürdüğü anlatılıyor. Yahoo! JAPAN News ise bfcache uyumluluğunu artırdıktan sonra mobilde reklam gelirinde yüzde 9 artış gördüğünü paylaşıyor. Yani hızlı geçişler sadece geliştirici mutluluğu üretmiyor; doğrudan iş sonucuna da dokunabiliyor.
Bu yüzden “sayfa içi geçiş performansı SEO metriği mi, CRO konusu mu?” tartışması çok verimli değil. İkisi de. Kullanıcı akışı rahatladığında hem arama kaynaklı trafiğin değeri artıyor hem de site içi kopuş azalıyor. Fabrikido gibi SEO ile dönüşüm optimizasyonunu aynı masada ele alan ekipler için doğru soru şu olur: Trafiği getirdik, peki kullanıcı içeride akıyor mu? Bu, kaynaklarda doğrudan bu cümleyle yazmıyor; ama Google’ın sayfa deneyimi yaklaşımı ile vaka çalışmalarının ortak yönünden çıkan makul bir sonuçtur.
Sayfa içi geçiş performansı nasıl iyileştirilir?
MPA yapılarında ilk bakılacak alan bfcache uyumluluğudur. Chrome DevTools, Application içindeki Back/forward cache paneliyle sayfanın anlık geri-ileri yükleme için uygun olup olmadığını test etmenize izin veriyor. Aynı belgede iki büyük engel açıkça sayılıyor: Cache-Control: no-store ve problemli unload handler’ları. Chrome ayrıca unload olayını hiç kullanmamanızı öneriyor ve bu tür handler’ların bfcache’i bozduğunu söylüyor.
Aynı konu sahada daha görünür izlenebilir hale de geldi. notRestoredReasons API, bir sayfanın neden bfcache’ten yararlanamadığını alan verisinde görebilmenizi sağlıyor. Yani artık “geri tuşu neden yeniden yüklendi?” sorusunu sadece laboratuvarda değil, gerçek kullanıcı davranışına yakın verilerle de incelemek mümkün. Bu, özellikle reklam script’i, chat widget’ı veya üçüncü parti etkileşim katmanları kullanan sitelerde ciddi avantaj sağlar.
MPA sitelerde ikinci alan gelecekteki navigasyonları hazırlamaktır. Chrome, belge navigasyonlarında eski <link rel="prefetch"> yerine Speculation Rules kullanımını öneriyor ve bunu daha hızlı, hatta bazen anlık geçişler için resmi yol olarak anlatıyor. Ama burada iştah ayarı şart. Belgenin kendisi, fazla agresif spekülasyonun kullanıcı cihazı ve veri tüketimi açısından bedeli olduğunu özellikle yazıyor. Bu yüzden en çok tıklanan ürün detayları, kategori-sonraki sayfalar veya form adımları gibi belirli akışlara odaklanmak daha sağlıklıdır.
SPA tarafında ise yaklaşım biraz farklı. Speculation Rules tam sayfa navigasyonlar için çalışıyor; Chrome’un belgesine göre SPA soft navigations bu sistemle prerender edilemiyor. Bu noktada iki şey öne çıkıyor: birincisi, route değişimlerini kendi analytics veya RUM katmanınızda ayrıca işaretlemek; ikincisi, geçişin hissini iyileştirmek için View Transition API gibi araçları doğru yerde kullanmak. View Transition API hem SPA’da same-document geçişleri hem de Chrome 126 ve üzeri sürümlerde aynı origin içindeki cross-document geçişleri görsel olarak daha akıcı hale getirebiliyor. Ama bu noktayı karıştırmamak gerekir: akıcı animasyon, ağır JavaScript’i gizleyebilir; çözmez.
Tasarım hızlıysa, deneyim de hızlı mıdır?
Hayır. Güzel görünen geçiş ile hızlı hissedilen geçiş aynı şey değildir.
Bir ürün kartının yumuşak animasyonla açılması hoş görünür. Ama tıkladıktan sonra varyantlar geç geliyor, sepete ekleme butonu donuyor ya da filtre sonucu geç hesaplanıyorsa kullanıcı “şık” değil “ağır” hisseder. INP’nin tam değeri burada ortaya çıkıyor: ziyaretin tüm yaşam döngüsündeki etkileşim gecikmesini ölçmesi. Yani performans 2026’da sadece açılış anı konuşularak yönetilemez. Asıl soru artık şudur: Kullanıcı sitenizde ilerledikçe hız korunuyor mu, yoksa sadece ilk ekranda mı parlıyor?
Sıkça Sorulan Sorular
Sayfa içi geçiş performansı SEO’yu etkiler mi?
Dolaylı ve doğrudan etkileri vardır. Google, Core Web Vitals’ın ranking sistemlerinde kullanıldığını söylüyor; ayrıca daha iyi geçiş performansının kullanıcı deneyimi ve ticari sonuçları iyileştirdiğine dair vaka çalışmaları da var.
İlk açılış hızı iyiyse başka bir şey yapmaya gerek var mı?
Hayır. LCP yalnızca yükleme performansını ölçer. INP ise ziyaret süresi boyunca etkileşim gecikmesini izler; bu yüzden ilk açılış iyi olsa bile site içi geçişler kötü olabilir.
Sayfa içi geçiş performansı en çok hangi sitelerde önemlidir?
E-ticaret, çok adımlı formlar, kategori-ürün akışı olan siteler ve SPA mimarileri burada daha hassastır. Çünkü kullanıcı işi tek sayfada bitirmez; art arda etkileşimlerle ilerler. Bu çıkarım, Google’ın SPA ölçüm sınırlamaları ve navigasyon optimizasyon belgeleriyle uyumludur.
bfcache neden bu kadar önemli?
Çünkü geri ve ileri navigasyonları anlık hale getirebilir. web.dev, bfcache’in hem gezinmeyi hızlandırdığını hem de kaynakların yeniden indirilmemesi sayesinde veri kullanımını azalttığını söylüyor.
SPA sitelerde sayfa içi geçiş performansı nasıl ölçülmeli?
Tek başına Search Console yetmeyebilir. web.dev, mevcut Core Web Vitals metriklerinin SPA route geçişlerini ayrı sayfa yüklemeleri gibi ölçmediğini söylüyor; bu yüzden route bazlı kendi RUM veya analytics işaretlemeleri gerekir.
