CoreDash Boyutu: Ağ Hızı

Hangi bant genişliği katmanlarının LCP'nize zarar verdiğini bulmak için Core Web Vitals'ı kullanıcı indirme hızına göre segmentlere ayırın.

Ücretsiz deneme

Trusted by market leaders · Client results

marktplaatsnestlemonarcherasmusmcaleteiavpnloopearplugscomparemy work featured on web.devworkivaperionhappyhorizonkpnfotocasawhowhatwearnina careadevintaebaydpg mediasaturnsnvharvard

Boyut: Ağ Hızı (dl)

dl boyutu, sayfa ziyareti sırasındaki her kullanıcının bağlantısının Megabit/saniye (Mbps) cinsinden ölçülen efektif indirme bant genişliğini raporlar. CoreDash bu değeri tarayıcının Network Information API'sinden toplar ve ziyaretleri bant genişliği katmanlarına gruplar. CoreDash tablosundaki her satır belirli bir hız aralığını temsil eder, böylece Core Web Vitals puanlarınızı hızlı geniş bant kullanıcıları, orta hızlı bağlantılar ve yavaş veya mobil bağlantılar arasında yan yana karşılaştırabilirsiniz.

Bant genişliği, sayfa yükleme performansını şekillendiren iki ağ özelliğinden biridir. Diğeri, sunucuya gidiş-dönüş süresini kontrol eden gecikmedir. CoreDash'in dl boyutu bant genişliği değişkenini izole eder, böylece somut bir soruyu yanıtlayabilirsiniz: Core Web Vitals puanlarınız bağlantı hızı düştükçe kötüleşiyor mu ve ne kadar kötüleşiyor?

coredash metric table urls

Ağ Hızı Core Web Vitals İçin Neden Önemlidir?

İndirme bant genişliğinin Largest Contentful Paint üzerinde doğrudan ve ölçülebilir bir etkisi vardır. LCP neredeyse her zaman bir hero görseli, büyük bir arka plan görseli veya ağır bir web fontu tarafından tetiklenir. 100 Mbps'lik bir bağlantıda, 400 KB'lık bir hero görseli kabaca 32 milisaniyelik aktarım süresinde ulaşır. 5 Mbps'lik bir bağlantıda ise aynı görsel, herhangi bir gecikme veya işleme yükü hesaba katılmadan sadece aktarım süresi olarak 640 milisaniyeden fazla sürer. Sadece bu fark bile geçerli bir LCP puanını "iyileştirme gerekiyor" aralığına itebilir.

Time to First Byte, bant genişliğine daha az duyarlıdır. TTFB, aktarılan bayt hacminden ziyade sunucu işlem süresi ve ağ gidiş-dönüş gecikmesi tarafından domine edilir. Yavaş bir sunucu yanıtı, her bağlantı hızında yavaştır. CoreDash'te TTFB tüm bant genişliği katmanlarında zayıfsa, bu istemci tarafı bir bant genişliği sorunundan ziyade sunucu veya CDN sorunlarına işaret eder.

Interaction to Next Paint neredeyse tamamen CPU'ya bağlıdır. INP, kullanıcı girdisi ile bir sonraki görsel güncelleme arasındaki süreyi ölçer. Ağır JavaScript yürütmesi, uzun görevler ve ana iş parçacığı engellemesi zayıf INP puanlarına yol açar. Yavaş bir bağlantı, JavaScript paketlerinin ilk indirilmesini geciktirebilir; bu da, kullanıcı sayfayla ilk etkileşime girdiğinde komut dosyaları hala ayrıştırılıyorsa INP'yi dolaylı olarak kötüleştirebilir. Ancak komut dosyaları yüklendikten sonra, INP performansı ağ tarafından değil, cihazın işlem gücü tarafından belirlenir.

Pratikte bant genişliği sorunları, tarayıcının LCP kaynağını keşfettikten sonra onu indirmek için ne kadar zaman harcadığını ölçen LCP'nin alt bölümü olan LCP Load Time'da açıkça ortaya çıkar. CoreDash, LCP Load Time'ı ayrı olarak raporlar, bu da yavaş kullanıcıların ağda mı yoksa başka bir şeyde mi beklediğini doğrulamayı kolaylaştırır.

Verileri Okumak

Tipik sitelerdeki CoreDash trafiği üç bant genişliği katmanına ayrılır. Her bir katmanın neyi temsil ettiğini anlamak, düzeltmeleri önceliklendirmenize yardımcı olur.

Hızlı Geniş Bant: 50 Mbps ve üzeri

CoreDash trafiğinin yaklaşık %35'i bu katmana girer. Bu; fiber bağlantıları, kablolu geniş bantı ve iyi sinyal koşullarındaki 5G mobil kullanıcılarını içerir. 2025'teki ortalama 5G indirme hızları 184 Mbps civarındayken, ABD'deki sabit geniş bant ortalamaları 214 Mbps'ye ulaşmıştır. Bu katmandaki kullanıcıların, iyi optimize edilmiş sayfalarda ağ kaynaklı LCP gecikmeleri yaşaması pek olası değildir. LCP puanları burada kötüyse, sorun bant genişliği değil; sunucu yanıt süresi, oluşturmayı engelleyen kaynaklar veya LCP öğesi keşif gecikmesidir.

Orta Hız: 10 ila 50 Mbps

CoreDash trafiğinin yaklaşık %40'ı bu aralıkta yer alır. Bu katman daha eski kablo bağlantılarını, ortalama sinyal koşullarındaki 4G LTE'yi (tipik 4G gerçek dünya hızları 10 ile 50 Mbps arasındadır) ve bazı sabit kablosuz kullanıcılarını kapsar. 300 KB'lık bir hero görseli bu hızlarda 48 ila 240 milisaniye arası bir aktarım süresi alır. Optimize edilmemiş görsellere veya oluşturmayı engelleyen birden fazla kaynağa sahip sayfalar bu katmanda LCP eşiklerinde başarısız olmaya başlayacaktır. Bu, görsel formatı seçimlerinin (WebP, AVIF) ve fetchpriority="high" ile agresif bir şekilde önceden yüklemenin ölçülebilir bir fark yarattığı katmandır.

Yavaş ve Mobil: 10 Mbps altı

CoreDash trafiğinin yaklaşık %25'i 10 Mbps'nin altındaki bağlantılardan gelir. Bu; 3G mobil kullanıcılarını, kırsal sabit bağlantıları ve zayıf sinyal veya sıkışık ağ koşullarındaki 4G kullanıcılarını içerir. 5 Mbps'de, 400 KB'lık bir görsel 640 milisaniyeden fazla aktarım süresi gerektirir. LCP görseli agresif bir şekilde sıkıştırılmadığı, kullanıcıya yakın bir CDN uç düğümü aracılığıyla sunulmadığı ve doğru şekilde önceden yüklenmediği sürece bu katmandaki LCP hataları neredeyse kesindir. İşletmeniz tarihsel olarak daha yavaş altyapıya sahip bölgelerdeki kullanıcılara hizmet veriyorsa, yavaş hızlı trafiğin coğrafi olarak yoğunlaşıp yoğunlaşmadığını doğrulamak için dl'nin yanı sıra CoreDash Ülke boyutunu kontrol edin.

Hata Ayıklama İş Akışı

  1. CoreDash'te 10 Mbps altı katmanına filtre uygulayın ve LCP Load Time'ı kontrol edin. Eğer başarısız bir LCP puanına baskın bir şekilde katkıda bulunan LCP Load Time ise, LCP kaynağı yavaş bağlantılar için çok büyüktür. Görseli daha fazla sıkıştırın, AVIF formatına geçin ve kaynağın, etkilenen kullanıcılara yakın bir uç düğüme sahip bir CDN'den sunulduğunu onaylayın.
  2. Ülke boyutuyla çapraz başvuru yapın. Yavaş hızlı kullanıcılar belirli ülkelerde yoğunlaşıyorsa, CDN'nizin o bölgelerde iyi bir kapsama alanına sahip olup olmadığını kontrol edin. 200 ms uzaklıktaki bir CDN uç düğümü tarafından sunulan 15 Mbps bağlantıdaki bir kullanıcı, 10 ms uzaklıktaki bir düğüm tarafından sunulan aynı hızdaki bir kullanıcıdan çok daha kötü bir deneyim yaşayacaktır.
  3. Katmanlar genelinde INP ve TTFB puanlarını kontrol edin. INP düşük bant genişliği katmanlarında kötüleşiyor ancak yüksek katmanlarda kötüleşmiyorsa, kullanıcılar ilk etkileşime girdiğinde büyük JavaScript paketleri hala indiriliyor demektir. JavaScript'inizi bölün, kritik olmayan komut dosyalarını erteleyin ve ayrıştırma aşaması sırasında INP riskini azaltmak için başlatma sırasında ana iş parçacığına bırakmayı (yielding to the main thread) düşünün.

Mühendislik Pratik Kuralları

  • LCP Load Time'ı 5 Mbps bağlantılarda bile 200 ms'nin altında tutmak için LCP görsel dosya boyutunun 100 KB'ın (AVIF veya WebP) altında olmasını hedefleyin.
  • 10 Mbps bağlantılarda 2,5 saniyelik eşik içinde makul bir LCP sağlamak için ekranın üst kısmındaki kaynaklar için toplam sayfa ağırlığı 500 KB'ın altında kalmalıdır.
  • LCP görselinde fetchpriority="high" kullanın ve tarayıcının bant genişliğini önce daha düşük öncelikli kaynaklar için boşa harcamaması amacıyla bunu belgenin <head> kısmında önceden yükleyin.
  • Tüm statik varlıkları bir CDN'den sunun. CoreDash'teki bant genişliği rakamları sunucunun değil, istemcinin bağlantısını ölçer. Sunucu coğrafi olarak uzaksa ve ilk bayt gelmeden önce 300 ms gecikme ekliyorsa, hızlı bir istemci bağlantısı yardımcı olmaz.
  • Trafiğinizin %15'inden fazlası 10 Mbps altı katmanındaysa ve bu kullanıcılar için LCP başarısız oluyorsa, başka bir şeyi ele almadan önce görsel optimizasyonunu ve CDN kapsama alanını P1 sorunları olarak değerlendirin.