Core/Dash Boyutu: Urls

Belirli Url'ler ile Core Web Vitals performans darboğazlarını izole edin ve düzeltin

Ücretsiz deneme

Trusted by market leaders

workivafotocasawhowhatwearebayhappyhorizonadevintaaleteiasnvnestledpg mediaperioncompareerasmusmcvpnharvardnina caremonarchsaturnmarktplaatskpnloopearplugs

Boyut: Sayfa & Navigasyon: URLs (u)

Element Type (LCP) boyutu (lcpet), Largest Contentful Paint düğümünü dört mimari sınıftan birine ayırır: text, image, background-image veya video.

Attribution Element boyutu tam DOM düğümünü belirlerken, Element Type boyutu üst düzey mühendislik stratejinizi belirler. LCP, dört zamanlama aralığının toplamıdır: TTFB, Load Delay, Load Time ve Render Delay. Element Type, bu aralıklardan hangisinin puanınıza zarar verdiğini söyler ve tahmin yürütmeden doğru optimizasyon protokolünü seçmenizi sağlar.

coredash metric table urls

LCP element type'a göre Core Web Vitals optimizasyonu

LCP element type'dan bağımsız olan TTFB iyileştirildikten sonra, farklı LCP elementinize bakarak LCP optimizasyonuna farklı bir yaklaşım getirmelisiniz.

1. Text

CoreDash, Element Type olarak metni raporladığında, statik ağ kaynağı bant genişliği nadiren darboğaz oluşturur. Metin doğrudan HTML belgesinde bulunur, yani içerik ilk sunucu yanıtından (TTFB) hemen sonra kullanılabilir durumdadır. Eğer LCP burada yavaşsa, sorun neredeyse tamamen Render Delay kaynaklıdır.

Bunu düzeltmek için tamamen Critical Rendering Path üzerine odaklanın. Tarayıcının metni boyaması, muhtemelen ağır CSS hesaplamaları veya <head> içindeki senkron JavaScript tarafından engellenmektedir. Ayrıca, yazı tipi yükleme stratejinizi kontrol edin; font-display: swap veya optional kullanmıyorsanız, tarayıcı yazı tipi dosyasının indirilmesini beklerken metni yapay olarak gizler (FOIT).

2. Image (<img>)

Bu tür, tam kaynak hattını tetikler: keşif, indirme ve kod çözme. Metnin aksine, bir resim LCP'si büyük ölçüde Load Delay ve Load Time'a bağlıdır. Burada fizik kuralları ve ağ gecikmesiyle savaşıyorsunuz, bu yüzden hedefiniz varlığı daha hafif hale getirmek ve daha erken keşfedilebilir kılmaktır.

Burada optimizasyon, sıkı bir varlık yönetimi gerektirir. Load Delay süresini en aza indirmek için <img> etiketinin ilk HTML kaynağında (Server-Side Rendering) bulunduğundan emin olun. fetchpriority="high" ekleyin ve loading="lazy" özniteliklerini kesinlikle kaldırın, çünkü bunlar tarayıcının isteğini geciktirir. Son olarak, yeni nesil formatlar (AVIF/WebP) sunarak ve mobil cihazların masaüstü boyutundaki dosyaları indirmesini önlemek için srcset kullanarak Load Time sorununu ele alın.

3. Background Image

Bu sınıflandırma, mimari bir verimsizliğe işaret eder. Resim CSS içinde tanımlandığı için (örneğin, background-image: url(...)), tarayıcı stil sayfalarınızı tamamen indirip ayrıştırana kadar URL'yi keşfedemez. Bu durum devasa bir Load Delay yaratır çünkü Preload Scanner bu varlığa karşı fiilen kördür.

Tek sağlam mühendislik çözümü yeniden düzenlemedir (refactoring). URL'yi tarayıcıya hemen göstermek için görsel varlığı CSS'ten standart bir HTML <img> etiketine taşıyın. İşaretlemeyi yeniden düzenleyemiyorsanız, erken keşfi zorlamak için belge başlığında <link rel="preload"> kullanmalısınız; ancak bu, yerel bir resim öğesi kullanmaya kıyasla genellikle bir bakım yükü oluşturur.

4. Video

LCP öğesi bir video olduğunda, tarayıcı poster resminin veya (otomatik oynatılıyorsa) ilk karenin boyama süresini ölçer. Bu, Resim türüne benzer şekilde davranır ancak video varlıklarının dosya boyutu nedeniyle genellikle daha ağırdır.

Bunu kesinlikle bir resim optimizasyonu görevi olarak ele alın. Tarayıcının ilk pikseli oluşturmak için video segmentlerini indirmek zorunda kalmaması adına HTML'de hafif bir poster özniteliğinin bulunduğundan emin olun. Poster resmini, standart bir LCP resminde yapacağınız kadar agresif bir şekilde sıkıştırın.

İş akışı: LCP element type'a göre LCP sorunlarını bulma

LCP Element Type statik değildir ve her ziyaretçi için aynı değildir. Kullanıcının cihazına bağlı olarak sık sık değişir ve responsive tasarımda temel kusurları ortaya çıkarır.

Mobil ve Masaüstü arasındaki Element Type'ları karşılaştırmak için CoreDash Device Form Factor filtresini kullanın. Genellikle Masaüstü kullanıcılarının bir resim LCP'si (örneğin, bir Hero Banner) aldığını, Mobil kullanıcıların ise bir metin LCP'si aldığını göreceksiniz. Bu durum, mobil CSS düzeninizin Hero Banner'ı ekranın alt kısmına (below the fold) ittiğini veya o kadar küçülttüğünü doğrular ki, bir metin paragrafı "En Büyük" (Largest) öğe haline gelir.

Bu senaryoda mobil LCP'yi iyileştirmek için hero resmini optimize ediyorsanız, çabanızı boşa harcıyorsunuz demektir. Tarayıcı resmi hesaba bile katmıyor. Ya resmi tekrar birincil görünüme getirmek için düzeni ayarlamalı ya da odağınızı mobil kullanıcılar için metin oluşturmayı (yazı tipleri/CSS) optimize etmeye kaydırmalısınız.


Boyut: Element Type (LCP)Core Web Vitals Boyut: Element Type (LCP)