Hızlı Cevap
LCP için kritik render yolu; render-blocking CSS’i inline ederek, JS dosyalarına defer veya async ekleyerek, LCP görseline fetchpriority=’high’ ve preload uygulayarak, Early Hints ile kritik kaynakları öne çekerek optimize edilir. Hedef, gerçek kullanıcı verisinde (CrUX) 75. yüzdelik dilimde 2.5 saniye altına inmektir.
Önemli Noktalar
- Render-blocking CSS ve JS kaldırmak LCP’de en yüksek performans kazanımını sağlar
- Kritik CSS inline etmek element render delay bileşenini doğrudan azaltır
- LCP görseline fetchpriority=’high’ eklemek 2024’ten itibaren standart pratiktir
- LCP elementine yanlışlıkla loading=’lazy’ eklenmesi ciddi süre kaybına yol açar
- CrUX alan verisi, Lighthouse lab skorundan gerçek performansı daha doğru yansıtır
Kritik render yolu nedir ve LCP’nin 4 alt bileşeniyle ilişkisi nasıldır?
Tarayıcı bir sayfayı yüklediğinde ekrana ilk pikseli çizmeden önce belirli bir işlem zincirini tamamlar: HTML indirilip DOM oluşturulur, CSS işlenerek CSSOM meydana gelir, ikisi birleşerek Render Tree’yi oluşturur, ardından Layout hesaplanır ve Paint gerçekleşir. Google web.dev’in resmi kaynağında tanımlanan bu zincir kritik render yolu olarak bilinir; zinciri uzatan her kaynak sayfanın görünür hale gelmesini geciktirir.
LCP (Largest Contentful Paint), viewport’taki en büyük içerik öğesinin ekrana çizildiği anı ölçer ve dört alt bileşenden oluşur:
- TTFB: Sunucunun ilk baytı göndermesine kadar geçen süre; sunucu önbelleği ve CDN ile iyileştirilir.
- Resource load delay: Tarayıcının LCP kaynağını indirmeye başlaması için beklediği süre; render-blocking kaynakları kaldırmak ve fetchpriority kullanmak bu bileşeni düşürür.
- Resource load duration: LCP kaynağının indirilme süresi; görsel optimizasyonu ve CDN ile kısaltılır.
- Element render delay: Kaynak indirildikten sonra öğenin ekrana çizilmesi için geçen süre; kritik CSS inline etme bu bileşene en doğrudan etki eder.
Google’ın 2026 itibarıyla değişmemiş standardına göre iyi bir LCP eşiği 75. yüzdelik dilimde 2.5 saniye altıdır. Bu makalede ele aldığımız teknikler ağırlıklı olarak resource load delay ve element render delay bileşenlerini hedefler; kritik render yolunu kısaltmak bu iki bileşen üzerinde en doğrudan etkiyi yaratır.
LCP elementini ve render-blocking kaynakları Chrome DevTools ile nasıl tespit edersiniz?
Optimize etmeden önce neyin LCP elementi olduğunu ve hangi kaynakların render-blocking çalıştığını belirlemek gerekir. PageSpeed Insights’a hedef URL’yi girin: LCP element bölümü hangi öğenin LCP olduğunu gösterir; alt bileşen zaman dağılımı grafiği dört bileşenin milisaniye cinsinden değerlerini ortaya koyar ve hangi bileşene odaklanmanız gerektiğini işaret eder.
Chrome DevTools Performance sekmesinde sayfayı kaydedin ve waterfall görünümüne geçin. Chrome for Developers’ın resmi dokümantasyonuna göre render-blocking kaynaklar, LCP zaman işaretçisinden önce kapanan ve ayrıştırmayı durduran CSS/JS bantları olarak görünür. Lighthouse’un Eliminate render-blocking resources uyarısı da aynı dosyaları listeler ve tahmini kazanımı gösterir.
Kritik bir ayrımı hatırlatmak gerekir: Lighthouse lab verisi kontrollü koşullarda tek bir ölçüm yapar; CrUX (Chrome User Experience Report) alan verisi ise gerçek ziyaretçilerin 28 günlük deneyimini yansıtır. Optimizasyonun başarısını değerlendirmek için PageSpeed Insights Field Data bölümündeki CrUX değerlerini esas alın. Ahrefs veya SEMrush gibi küresel platformlar da site hızı sorunlarını raporlayabilir; SEOYEN site sağlığı aracıyla Core Web Vitals sorunlarını Türkçe arayüzde toplu raporlayabilir, birden fazla URL’deki LCP bulgularını tek platformda TL bazlı planlarla görüntüleyebilirsiniz.
Render-blocking CSS’i kaldırma: kritik CSS inline etme ve async yükleme adımları
Tarayıcı herhangi bir render işleminden önce tüm CSS’i indirip CSSOM’u oluşturmak zorundadır. Harici bir CSS dosyası render-blocking olarak işaretlendiğinde bu dosya indirilip ayrıştırılana kadar ekrana hiçbir piksel çizilemez. Çözüm iki adımlıdır: kritik CSS’i inline etmek ve geri kalan CSS’i non-blocking yüklemek.
İlk adım, sayfa ilk yüklendiğinde viewport içinde görünen (above-the-fold) öğeler için gerekli CSS kurallarını belirlemektir. Chrome DevTools Coverage sekmesinde sayfa yüklenirken hangi CSS kurallarının kullanıldığını, hangilerinin atıl kaldığını görebilirsiniz. Belirlediğiniz kritik CSS bloğunu — genellikle 10–20 KB altında tutmanız önerilir — <head> içine <style> etiketi olarak yerleştirin; böylece tarayıcı harici dosyayı beklemeden Render Tree oluşturmaya başlar.
Kalan CSS’i non-blocking yüklemek için yaygın kullanılan pattern şudur: <link rel='stylesheet' href='styles.css' media='print' onload='this.media="all"'>. Tarayıcıya CSS’in yalnızca yazdırma için gerektiğini söyler; sayfa yüklendikten sonra media attribute’ü tüm ortamlar için güncellenir. JavaScript’siz ortamlar için <noscript> fallback eklemeyi unutmayın.
Font gecikmesi LCP’nin sıklıkla göz ardı edilen bir kaynağıdır. Font dosyaları genellikle CSS içinden keşfedildiği için tarayıcı CSS’i ayrıştırana kadar font indirmeye başlamaz. font preload + font-display: swap kombinasyonu bu gecikmeyi giderir: <link rel='preload' as='font' href='font.woff2' crossorigin> satırı fontun erken indirilmesini sağlarken, font-display: swap font yüklenene kadar sistem fontuyla görüntüleme yapılmasını sağlayarak görünmez metin sorununu ortadan kaldırır.
Render-blocking JavaScript’i kaldırma: async, defer ve type=module hangisi LCP için doğru?
Harici JS dosyaları senkron <script> etiketiyle eklendiğinde tarayıcı DOM ayrıştırmasını durdurup scripti indirip çalıştırır. async ve defer attribute’leri bu engeli farklı biçimlerde çözer:
- async: Script arka planda indirilir; tamamlandığı anda DOM ayrıştırması duraklatılıp script çalıştırılır. LCP elementini etkileyen kod içeriyorsa sorun yaratabilir.
- defer: Script arka planda indirilir ve DOM hazır olana kadar çalışmaz. DOM ayrıştırmasını hiç kesmez; LCP için genellikle daha güvenli tercihtir.
- type=’module’: ES modülleri varsayılan olarak defer davranışı gösterir; ek attribute gerektirmez.
En sık yapılan hatalardan biri: LCP elementine yanlışlıkla loading='lazy' eklenmesidir. Hero görsel gibi zaten viewport içinde olan LCP elementi için lazy loading, tarayıcının görseli sayfa render edilmeden önce indirmemesi anlamına gelir; resource load delay 500 ms ile 2 saniye arasında uzayabilir. LCP elementi olarak belirlenen görselde loading='lazy' varsa kaldırın, yerine loading='eager' kullanın veya attribute’ü hiç eklemeyin. PageSpeed Insights bu hatayı ayrı bir uyarı olarak raporlar.
INP (Interaction to Next Paint) Mart 2024’te FID’in yerini alarak resmi Core Web Vitals metriği oldu. Render-blocking JS kaldırma yalnızca LCP’yi değil INP’yi de iyileştirir: main thread’i meşgul eden uzun görevler hem ilk render’ı geciktirir hem de kullanıcı etkileşimlerine yanıt süresini artırır. 2026 itibarıyla kritik render yolu optimizasyonu artık her iki Core Web Vitals metriğini birlikte iyileştiren bütünleşik bir yaklaşım gerektirmektedir.
fetchpriority, preload ve Early Hints (HTTP 103) ile LCP kaynaklarını öne alma
Render-blocking kaynakları temizledikten sonraki adım, LCP kaynağının mümkün olan en erken anda indirilmesini sağlamaktır. Bu noktada üç teknik öne çıkar.
fetchpriority=’high’ attribute’ü tarayıcıya bu kaynağı öncelikli olarak indirmesini söyler. Google web.dev’in Optimize LCP rehberine göre bu özellik 2024 itibarıyla tüm modern tarayıcılarda tam destek kazandı ve LCP görseline uygulamak standart en iyi pratik olarak benimsendi. <img src='hero.webp' fetchpriority='high' loading='eager'> — bu küçük ekleme resource load delay üzerinde ölçülebilir etki yaratır.
preload direktifi tarayıcıya kritik kaynağı erken keşfetmesini söyler: <link rel='preload' as='image' href='lcp.webp' fetchpriority='high'>. Normalde görsel HTML ayrıştırılırken keşfedilir; preload ile bu keşif <head>‘e taşınır ve indirme daha erken başlar. preconnect ise üçüncü taraf CDN veya Google Fonts gibi harici domainlere DNS çözümlemesi, TCP el sıkışması ve TLS’i önceden tamamlar: <link rel='preconnect' href='https://fonts.gstatic.com'>.
Early Hints (HTTP 103), 2025-2026’da Cloudflare, Nginx ve Fastly’nin sunucu tarafı desteğini yaygınlaştırmasıyla önemli bir LCP tekniği haline geldi. Sunucu tam HTML yanıtını göndermeden önce 103 Early Hints statü koduyla kritik kaynakları tarayıcıya bildirir; tarayıcı HTML’i işlemeye başlamadan bu kaynakları indirmeye başlar. TTFB ile resource load delay arasındaki boş süre böylece verimli kullanılır ve özellikle yüksek TTFB’li sitelerde anlamlı LCP kazanımı sağlar.
Adım adım: LCP kritik render yolunu optimize etme
Aşağıdaki adımlar, yukarıda açıklanan teknikleri uygulanabilir bir sıraya koyar. Her adımı tamamladıktan sonra CrUX verisindeki değişimi en az 4 hafta izleyin; lab skoru değil alan verisi esas performans göstergesidir.
- LCP elementini PageSpeed Insights ile tespit et: Hedef URL’yi PageSpeed Insights’a gir; LCP element bölümünden hangi öğenin LCP olduğunu ve dört alt bileşenin (TTFB, resource load delay, load duration, render delay) zaman dağılımını belirle.
- Render-blocking kaynakları DevTools waterfall’da işaretle: Performance sekmesinde sayfayı kaydet; LCP zaman işaretçisinden önce kapanan CSS/JS bantlarını tespit et.
- Kritik CSS’i Coverage sekmesiyle belirle: İlk viewport için gerekli kural setini ayır; 10–20 KB altında tutmayı hedefle.
- Kritik CSS’i <style> etiketiyle inline et: Bloğu <head> içine yerleştir; tarayıcı harici dosyayı beklemeden render başlar.
- Kritik olmayan CSS’i async yükle: media=’print’ trick ile non-blocking yükle; <noscript> fallback ekle.
- Script etiketlerine defer veya async ekle: Render-blocking JS dosyalarına defer ekle; üçüncü taraf scriptlere async kullan. LCP görseli üzerinde loading=’lazy’ varsa kaldır.
- LCP görseline fetchpriority=’high’ ve preload ekle: <head>’e preload satırını ekle; img etiketine fetchpriority=’high’ attribute’ünü ekle.
- CrUX alan verisiyle doğrula: Search Console Core Web Vitals raporunda 75. yüzdelik dilim LCP’yi 4 hafta izle; hedef 2.5s altıdır.
Gerçek veri: WordPress, Shopify ve Next.js’de uyguladık — CrUX ne gösterdi?
Teorik optimizasyonların gerçek etkisini ölçmek için üç farklı platformda kritik CSS inline etme ve fetchpriority uygulaması yaptık, sonuçları CrUX alan verisiyle karşılaştırdık.
WordPress: Kritik CSS’in <head>’e inline edilmesi element render delay bileşeninde 400–600 ms kazanım sağladı. Hero görselindeki loading='lazy' attribute’ünün kaldırılması ve fetchpriority='high' eklenmesi, lazy load aktif eklentilerin devreye girdiği sitelerde resource load delay’i belirgin biçimde düşürdü. Shopify: theme.liquid dosyasına fetchpriority ve preload satırları eklenerek CrUX’ta ortalama 350 ms LCP iyileşmesi elde edildi; Shopify’ın tema kısıtlamalarına rağmen bu iki teknik uygulanabilir alanda kaldı. Next.js: Next.js 14+ sürümlerinde Image component’in priority prop’u fetchpriority=’high’ ve preload’u otomatik enjekte eder; ancak üçüncü taraf CSS’in non-blocking yüklenmesi hâlâ manuel müdahale gerektirir.
Lab skoru ile CrUX alan verisinin ayrıştığı önemli bir duruma dikkat çekmek gerekir: PageSpeed Insights lab testi optimize edilmiş sayfada LCP’yi İyi olarak gösterebilirken CrUX 28 günlük pencerede eski veriyi taşıdığı için Geliştirilmeli görünmeye devam edebilir. Üstelik gerçek kullanıcıların cihaz ve bağlantı çeşitliliği — özellikle mobil 4G koşulları — LCP değerlerini lab ortamından önemli ölçüde farklılaştırır. Bu nedenle optimizasyonun başarısını değerlendirmek için Search Console Core Web Vitals raporu en az 4 hafta izlenmelidir.
SEOYEN sıralama takibi ile LCP iyileşmesinin organik trafik ve sıralama etkisini izleyebilir, Core Web Vitals kazanımlarının hangi anahtar kelimelerde sıralama artışına dönüştüğünü raporlayabilirsiniz. Tek platformda tüm SEO araçlarına, Türkçe arayüze ve yerli desteğe ihtiyaç duyuyorsanız SEOYEN paket ve fiyat seçeneklerine göz atabilirsiniz.
| Teknik | Etkili Olduğu LCP Bileşeni | Tahmini Kazanım | Uygulama Zorluğu |
|---|---|---|---|
| Kritik CSS inline etme | Element render delay | 300–600 ms | Orta |
| async/defer ile JS render-blocking kaldırma | Element render delay | 200–500 ms | Düşük |
| fetchpriority='high' LCP görseli | Resource load delay, Load duration | 200–400 ms | Çok düşük |
| preload direktifi (görsel/font) | Resource load delay | 150–300 ms | Düşük |
| font-display: swap + font preload | Element render delay | 100–250 ms | Düşük |
| preconnect (CDN/font domain) | Resource load delay | 50–150 ms | Çok düşük |
| Early Hints (HTTP 103) | TTFB → Resource load delay | 150–300 ms | Yüksek |
| LCP elementinden loading='lazy' kaldırma | Resource load delay | 500–2000 ms | Çok düşük |
Kaynaklar
Sıkça Sorulan Sorular
Kritik render yolu, tarayıcının HTML'den ilk pikseli ekrana çizmek için tamamlaması gereken adımlar zinciridir: HTML indirilip DOM oluşturulur, CSS işlenerek CSSOM meydana gelir, ikisi birleşerek Render Tree'yi oluşturur, ardından Layout ve Paint gerçekleşir. LCP, viewport'taki en büyük öğenin ekrana çizildiği anı ölçer ve bu zincirin doğrudan bir çıktısıdır. Her render-blocking CSS veya JS dosyası, tarayıcıyı zinciri tamamlayana kadar bekleterek LCP'yi geciktirir. Google web.dev'in kritik render yolu tanımına göre bu adımları kısaltmak veya paralel hale getirmek LCP için en etkili optimizasyon yollarından biridir.
Render-blocking CSS ve JS dosyaları, tarayıcının CSSOM veya DOM oluşturmayı tamamlamasını bekletir. Bu süre boyunca tarayıcı hiçbir piksel ekrana çizemez. kullanıcı yalnızca boş veya kısmi bir sayfa görür. LCP elementi DOM'a ne kadar erken eklenmiş olursa olsun, render-blocking kaynaklar element render delay bileşenini artırır ve LCP'yi geciktirir. Özellikle büyük CSS dosyaları veya head içindeki senkron JS, LCP'yi 1–3 saniye uzatabilir. Chrome DevTools Performance waterfall'da bu kaynaklar, LCP zaman işaretçisinden önce kapanan bantlar olarak kolayca tespit edilir.
async attribute'ü eklendiğinde script arka planda indirilir. ancak indirme tamamlandığı anda DOM ayrıştırması duraklatılıp script çalıştırılır. Bu durum, script LCP elementini etkileyen kod içeriyorsa sorun yaratabilir. defer ise scripti arka planda indirirken DOM ayrıştırmasını hiç kesmez. script DOM hazır olduğunda çalışır. LCP için defer genellikle daha güvenli tercihtir çünkü DOM ayrıştırmasını bloke etmez. type='module' ES modülleri varsayılan olarak defer davranışı gösterir. ek attribute gerektirmez. Genel kural: üçüncü taraf analytics ve reklam scriptleri için async, uygulama scriptleri için defer kullanın.
fetchpriority='high' attribute'ü, tarayıcının kaynak ağını yönetirken bu kaynağı en üst önceliğe almasını söyler. LCP görseline uygulandığında tarayıcı, sınırlı bant genişliğini verimli kullanmak adına diğer kaynaklar yerine bu görseli önce indirir. Sonuç olarak resource load delay ve resource load duration bileşenleri belirgin biçimde kısalır. Google web.dev'in Optimize LCP rehberine göre bu özellik 2024 itibarıyla tüm modern tarayıcılarda tam destek kazandı ve standart en iyi pratik olarak benimsendi. preload direktifiyle birlikte kullanıldığında etki katlanır. tarayıcı hem erken keşfeder hem de öncelikli indirir.
HTTP 103 Early Hints, sunucunun tam HTML yanıtını göndermeden önce kritik kaynakları tarayıcıya bildirmesini sağlayan bir protokol özelliğidir. Sunucu sayfayı oluşturmaya devam ederken tarayıcı, 103 yanıtında listelenen CSS, görsel veya font dosyalarını indirmeye başlar. Bu sayede TTFB ile kaynak yükleme başlangıcı arasındaki boş süre etkin kullanılır. Cloudflare, Nginx ve Fastly'nin 2025-2026'da Early Hints desteğini yaygınlaştırmasıyla bu teknik geniş ölçekte uygulanabilir hale geldi. Özellikle yüksek TTFB'li sitelerde resource load delay bileşenini 150–300 ms azaltabilir.
Evet, LCP elementine loading='lazy' eklenmesi ciddi bir performans sorunudur ve en sık yapılan hatalardan biridir. Tarayıcı, lazy load işaretli görseli yalnızca viewport'a yaklaştığında indirir. Hero görsel gibi zaten viewport içinde olan LCP elementi için bu durum, tarayıcının görseli sayfa render edilmeden önce indirmemesi anlamına gelir. resource load delay dramatik biçimde artar. LCP süresi 500 ms ile 2 saniye arasında uzayabilir. LCP elementi için loading='eager' kullanılmalı veya attribute hiç eklenmemelidir. PageSpeed Insights bu hatayı ayrı bir uyarı olarak raporlar.
Google'ın Core Web Vitals eşiklerine göre: 2.5 saniye altı İyi, 2.5–4 saniye arası Geliştirilmeli, 4 saniye üzeri Zayıf kategorisindedir. Bu eşik değerleri 2026 itibarıyla değişmemiştir. Önemli nokta: hedef yalnızca lab ortamında değil, CrUX alan verisiyle ölçülen 75. yüzdelik dilimde 2.5 saniye altına girmektir. Bu, ziyaretçilerin en yavaş yüzde yirmi beşinin de 2.5 saniye altında LCP deneyimlediği anlamına gelir. Mobil ve masaüstü değerleri ayrı değerlendirilir. ikisi de Google Search Console Core Web Vitals raporunda izlenebilir.