Core/Dash Boyutu: Gezinme Kökeni

Ziyaretçilerinizin aynı alan adından mı yoksa harici kaynaklardan mı geldiğini ve bu ayrımın Core Web Vitals metriklerinizi nasıl şekillendirdiğini görün.

Ücretsiz deneme

Trusted by market leaders · Client results

happyhorizonebaycomparesaturnharvardfotocasawhowhatwearmy work featured on web.devworkivaadevintadpg medianestlemarktplaatsperionnina careerasmusmckpnaleteiavpnloopearplugsmonarchsnv

Gezinme Kökeni (Navigation Origin) neyi ölçer?

Gezinme Kökeni boyutu, saha verilerinizi iki gruba ayırır:

  • Same Origin (1) — önceki sayfa aynı alan adındaydı.
  • Cross Origin (2) — kullanıcı farklı bir alan adından, bir arama motorundan, sosyal platformdan geldi veya URL'yi doğrudan yazdı.

Bu ayrım önemlidir çünkü tarayıcının başlangıç koşulları her iki durumda da tamamen farklıdır. Aynı kökenden (same-origin) gelen bir gezinme, mevcut bir bağlantıyı yeniden kullanabilir, alt kaynaklar için HTTP önbelleğinden yararlanabilir ve sitenizin kurduğu herhangi bir önceden getirme (prefetching) işleminden faydalanabilir. Farklı kökenden (cross-origin) gelen bir gezinme ise sıfırdan başlar.

Cross-origin gezinmeler neden daha yavaştır?

Kullanıcı harici bir sitedeki bağlantıya tıkladığında, tarayıcının HTML'nizi talep etmeden önce bile yapması gereken işler vardır:

  1. DNS sorgusu — alan adınızı bir IP adresine çözümler.
  2. TCP el sıkışması — sunucunuzla bir bağlantı açar.
  3. TLS müzakeresi — HTTPS el sıkışmasını tamamlar.

Tüm bu adımlar bir araya geldiğinde genellikle, sayfanızın ilk baytı talep edilmeden önce bir mobil bağlantıda 200 ila 500 ms arasında bir süre ekler. Bu maliyet doğrudan Time to First Byte (TTFB) metriğine yansır ve LCP öğeniz HTML ulaştıktan sonra yüklenen bir kaynağa bağlıysa, daha kötü bir Largest Contentful Paint (LCP) skoruna da yol açar.

Önbelleğe alınmış alt kaynaklar da kullanılamaz. Google'dan tıklayarak gelen bir ziyaretçinin tarayıcısında yazı tiplerinizin, kahraman görselinizin veya kritik CSS'nizin önbelleğe alınmış bir kopyası yoktur. Az önce ana sayfanızdan gelen bir ziyaretçide ise muhtemelen bunların tümü bulunur.

Same-origin gezinmeler ve back-forward cache

Same-origin gezinmeler, cross-origin gezinmelerin aynı güvenilirlikle kullanamayacağı iki performans avantajına kapı açar.

İlk olarak, Speculation Rules API, kullanıcı tıklamadan önce dahili sayfaları önceden getirmenize (prefetch) veya oluşturmanıza (prerender) olanak tanır. Tarayıcı, bir sonraki sayfayı arka plan sekmesinde tam olarak oluşturarak gezinmeyi anında gerçekleştirebilir. Bu yalnızca same-origin (aynı köken) hedefleri için geçerlidir.

İkinci olarak, back-forward cache (bfcache), kullanıcı geri düğmesine bastığında bir sayfayı bellekten geri yükler. Bfcache isabetleri son derece hızlıdır ve tüm Core Web Vitals metriklerinde iyi puan alır. Verilerinizde same-origin gezinmeler olarak görünürler. Same-origin LCP'niz cross-origin LCP'nizden önemli ölçüde daha iyiyse, bu farka büyük olasılıkla bfcache ve prefetch katkıda bulunuyordur.

Bu boyut CoreDash'te nasıl okunur?

coredash metric table urls

CoreDash'te Gezinme Kökenini bir filtre veya herhangi bir metriğin yanında kırılım boyutu olarak kullanın. En kullanışlı karşılaştırma, gezinme kökenine göre LCP'dir. Same-origin ve cross-origin LCP arasındaki büyük bir fark size şu üç şeyden birini söyler:

  • Cross-origin giriş sayfalarınız LCP'yi şişiren yavaş bir TTFB'ye sahiptir.
  • Same-origin gezinmeler prefetch veya bfcache'den faydalanırken, cross-origin sayfalarınız bunlardan yararlanamaz.
  • Önbelleğe alınmış alt kaynaklarınız geri dönen ziyaretçilere yardımcı olur, ancak harici kaynaklardan ilk kez gelen ziyaretçilere yardımcı olmaz.

Cross-origin verileri SEO için genellikle daha önemli bir değerdir. Google'ın Chrome UX Report (CrUX) verileri tüm gezinme türlerini içerir, ancak organik arama trafiği neredeyse tamamen cross-origin'dir. Cross-origin LCP'niz geçer not alırken same-origin LCP'niz başarısız oluyorsa, bu alışılmadık bir durumdur ve araştırılmaya değerdir. Tersi durum ise çok daha yaygındır.

Cross-origin cezasını azaltmak

Soğuk başlangıç cezasını tamamen ortadan kaldıramazsınız, ancak azaltabilirsiniz:

  • Hızlı TTFB'ye sahip bir CDN kullanın. Sunucunuz coğrafi olarak kullanıcıya yakın olduğunda ve hızlı yanıt verdiğinde bağlantı yükü küçülür. HTML belgesi için 200 ms'nin altında bir TTFB hedefleyin.
  • LCP görselini önceden yükleyin (preload). <head> içindeki bir <link rel="preload">, görsel getirme işlemini mümkün olan en erken aşamada başlatarak HTML teslimi ile LCP öğesinin boyanması arasındaki süreyi kısaltır.
  • Kritik CSS'yi satır içi (inline) yapın. Oluşturmayı engelleyen stil dosyası isteklerinin olmaması, tarayıcının soğuk bir bağlantıda bile daha erken boyama yapabilmesi anlamına gelir.
  • Üçüncü taraf kökenler için preconnect ipuçları ekleyin. LCP görseliniz veya oluşturmayı engelleyen bir kaynağınız farklı bir alan adında barındırılıyorsa, bir rel="preconnect" ipucu TCP ve TLS işlemlerini erkenden başlatır.

Same-origin gezinmeler için Speculation Rules API, bugün mevcut olan en yüksek etkili geliştirmedir. Muhtemel bir sonraki sayfayı önceden oluşturmak (prerendering), bu geçişlerde LCP'yi sıfıra yaklaştırır.

Bağlam içinde Gezinme Kökeni

Gezinme Kökeni, Navigation Type boyutu (navigate, reload, back-forward ve prerender'ı ayırır) ve Effective Connection Type boyutu ile birlikte iyi çalışır. Yavaş bir bağlantıda yapılan cross-origin gezinme, sitenizin karşılaştığı en zor senaryodur. Bu iki koşula birlikte filtreleme yapmak, size en kötü durumdaki gerçek performansınızı ve en büyük iyileştirme fırsatlarının nerelerde olduğunu gösterecektir.