Hızlı Cevap
LCP için kritik render yolu optimizasyonu şu adımlardan oluşur: Chrome DevTools ile render-blocking CSS ve JS kaynaklarını tespit edin; above-the-fold CSS’i head içine inline edin; non-kritik CSS’i defer edin; LCP görselinize rel preload ve fetchpriority high ekleyin. Bu dört adım Resource Load Delay’i doğrudan düşürerek LCP’yi 2.5 sn altına indirir.
Önemli Noktalar
- Render-blocking CSS ve JS, LCP’yi geciktiren başlıca iki faktördür
- Above-the-fold CSS’i inline etmek Resource Load Delay’i neredeyse sıfıra indirir
- LCP görselini preload ve fetchpriority high ile işaretlemek erken indirmeyi sağlar
- Chrome 120+ preload scanner artık CSS background-image LCP öğelerini erken tanıyor
- INP’in FID’in yerini almasıyla 2026’da LCP Core Web Vitals’ın belirleyici metriği oldu
LCP ve Kritik Render Yolu: Tarayıcı Sayfayı Nasıl Oluşturur?
Tarayıcı bir sayfayı yüklerken arka planda sıralı bir işlem zinciri başlatır: sunucudan gelen HTML ayrıştırılarak DOM (Document Object Model) oluşturulur; CSS dosyaları işlenerek CSSOM (CSS Object Model) üretilir; bu iki yapı birleşerek Render Tree kurulur; ardından Layout (düzen hesabı) ve Paint (ekrana boyama) aşamalarıyla görsel çıktı elde edilir. Bu zincire kritik render yolu (Critical Rendering Path) denir. Zincirin her halkasındaki gecikme, LCP öğesinin kullanıcı ekranında belirmesini doğrudan erteler.
LCP (Largest Contentful Paint), viewport’ta görünen en büyük içerik öğesinin — tipik olarak hero görsel, h1 başlığı veya geniş bir metin bloğu — boyandığı anı ölçer. Google’ın web.dev rehberine göre LCP dört alt bileşenden oluşur: TTFB (ilk sunucu baytına ulaşma süresi), Resource Load Delay (kaynağın keşfedilmesiyle indirmeye başlanması arasındaki süre), Resource Load Duration (gerçek indirme süresi) ve Element Render Delay (kaynak yüklendikten sonra ekranda belirene kadar geçen ek süre). Kritik render yolu optimizasyonu ağırlıklı olarak Resource Load Delay ve Element Render Delay’i hedef alır; bu iki bileşeni düşürmek LCP skoruna en hızlı etkiyi yaratır.
Google’ın belirlediği eşiklere göre 2.5 sn altı iyi, 2.5–4.0 sn arası iyileştirme gerektirir, 4.0 sn üstü kötü olarak sınıflandırılır. Bu eşikler 2026 itibarıyla değişmemiştir. Google’ın INP’i (Interaction to Next Paint) 2024’te FID’in resmi yerine koymasının ardından Core Web Vitals içinde LCP’nin belirleyici ağırlığı daha da artmıştır; teknik SEO öncelik listesinde LCP 2025-2026 döneminde üst sıralarda yer almaktadır. Sıralama takibi yaparak LCP iyileştirmelerinin organik konumunuza yansımasını doğrudan izleyebilirsiniz. Bu rehberde geçen teknik kavramların geniş tanımları için teknik SEO sözlüğümüze de göz atabilirsiniz.
Render-Blocking Kaynakları Chrome DevTools ve WebPageTest ile Tespit Etme
Optimizasyona başlamadan önce hangi kaynakların render’ı engellediğini net biçimde saptamak gerekir. Chrome DevTools Coverage paneli en hızlı başlangıç noktasıdır: DevTools’u açın (F12), Komut Menüsü’nden (Ctrl+Shift+P) Coverage yazarak paneli etkinleştirin; Start instrumenting coverage and reload page butonuna tıklayarak kayıt alın. Kayıt tamamlandığında dosya listesinde her CSS ve JS satırının yanında iki renk kodlu bant görünür: kırmızı = kullanılmayan satırlar, yeşil = kullanılan satırlar. Kırmızı payı yüksek ve boyutu büyük dosyalar render-blocking’in birincil adaylarıdır.
WebPageTest Waterfall (şelale) grafiği daha derin bir bakış sağlar. webpagetest.org üzerinden çalıştırdığınız testte şelale görünümündeki turuncu veya sarı çubuklar render’ı bloke eden kaynakları gösterir. Çubuğun sol kenarı isteğin başladığı anı, sağ kenarı tamamlandığı anı işaret eder; bu süre boyunca tarayıcı boyamayı bekletir. Kritik yol uzunluğunu milisaniye cinsinden ölçerek hangi kaynaktan kaç milisaniye kazanabileceğinizi hesaplayabilirsiniz.
PageSpeed Insights‘ın Render-blocking resources uyarısı, tahmini tasarruf süresiyle birlikte engel oluşturan dosyaların tam listesini verir. Bu uyarıyı LCP alt bileşen dökümüyle — özellikle Resource Load Delay değeriyle — birlikte okuyun. Chrome DevTools Performance sekmesinde kayıt alıp LCP işaretçisine tıkladığınızda tam olarak hangi kaynak gecikmesinin LCP’nin sorumlusu olduğunu ve milisaniye cinsinden zaman damgasını görebilirsiniz; bu veri optimizasyon önceliğinizi belirlemenize doğrudan yardımcı olur.
Render-Blocking CSS ve JS’i Kaldırma: Adım Adım Kritik CSS Optimizasyonu
Render-blocking’i ortadan kaldırmanın temel yöntemi, sayfanın ilk görünen kısmını (above-the-fold) çizmeye yetecek minimum CSS’i doğrudan <head> içine inline etmektir. Tarayıcı ek bir HTTP isteği yapmadan boyamaya başlayabildiğinden Resource Load Delay neredeyse sıfıra iner. Kritik CSS olarak sayılan kurallar şunlardır: header, navigasyon, hero alanı ve kullanıcının ilk yükte viewport içinde gördüğü diğer öğelere ait stiller.
Bu çıkarma işlemini otomatikleştirmek için üç yaygın araç bulunmaktadır. Critters, Next.js, Vite ve Webpack projelerine plugin olarak kolayca entegre edilir; build sürecinde above-the-fold CSS’i otomatik çıkarır ve geri kalanı defer eder. Critical.js evrensel bir Node.js çözümüdür; Gulp veya Grunt pipeline’ına eklenerek WordPress dahil herhangi bir platformda çalışır. Penthouse ise Puppeteer tabanlıdır ve Headless Chrome üzerinden görsel render yaparak en yüksek çıkarma doğruluğunu sunar; ancak build süresi diğerlerine kıyasla daha uzundur. Platform ve senaryo bazında ayrıntılı karşılaştırma için aşağıdaki tabloya bakabilirsiniz.
Non-kritik CSS’i defer etmek için kanıtlanmış yöntem şudur: CSS dosyasına media="print" onload=’this.media="all"’ özniteliğini ekleyin. Tarayıcı dosyayı baskı stili olarak düşük öncelikle indirir; sayfa hazır olduğunda medya all’a çekilerek stiller devreye girer. Eski tarayıcılarda loadCSS kütüphanesi aynı sonucu güvenle sağlar.
JavaScript tarafında async ve defer arasındaki fark LCP için belirleyicidir. async ile işaretlenen script indirildiği anda HTML ayrıştırmasını geçici olarak durdurarak çalışır; bu LCP öğesinin gecikmesine yol açabilir. defer ise DOM ayrıştırması tamamlanana dek bekler ve render’ı engellemez. Pratik kural: LCP öncesinde çalışması gerekmeyen scriptlere defer, tamamen bağımsız üçüncü taraf scriptlere (chat widget, analitik pikseller) async ekleyin.
Adım Adım: LCP için Kritik Render Yolu Optimizasyonu
- LCP öğesini Chrome DevTools ile tespit edin: Performance sekmesinde sayfa kaydı alın, LCP işaretçisine tıklayın; hangi öğenin LCP olduğunu ve alt bileşen dağılımını not edin.
- Render-blocking kaynakları Coverage paneli ile listeleyin: DevTools Coverage’ı açın, sayfayı yeniden yükleyin; kırmızı çubuk oranı yüksek ve büyük boyutlu CSS/JS dosyalarını önceliklendirin.
- Kritik CSS’i çıkarın ve head içine inline edin: Critters (Next.js/Vite), Critical.js (genel Node.js projeleri) veya Penthouse (yüksek doğruluk gerektiren projeler) ile above-the-fold CSS’i otomatik çıkarın; üretilen style bloğunu head’e yerleştirin.
- Non-kritik CSS’i defer edin: Kalan CSS dosyasına media=print onload tekniğini veya loadCSS’i uygulayın; render engeli tamamen kalkar.
- Scriptleri async veya defer ile erteleyin: LCP sonrasında ihtiyaç duyulan scriptlere defer, bağımsız üçüncü taraf scriptlere async ekleyin; mümkünse body sonuna taşıyın.
- LCP görselini veya fontunu preload ile önceliklendirin: LCP görseli için link rel=preload as=image fetchpriority=high, kritik web fontu için as=font crossorigin ile head’e preload ekleyin; metin LCP ise font-display: swap kullanın.
- Değişiklikleri PageSpeed Insights ile doğrulayın: Üretim ortamına aldıktan sonra LCP alt bileşenlerini karşılaştırın; Resource Load Delay ve Element Render Delay değerlerindeki düşüşü teyit edin.
Preload Direktifi ile LCP Öğesini Hızlandırma: Görsel, Font ve Preload vs Prefetch Farkı
Render-blocking’i kaldırdıktan sonra ikinci büyük kazanım, LCP öğesinin tarayıcı tarafından erken keşfedilmesini sağlamaktır. LCP öğesi bir görselise şu direktifi head’in en üstüne ekleyin: <link rel="preload" as="image" href="hero.webp" fetchpriority="high">. fetchpriority="high" özniteliği tarayıcıya bu kaynağı ağ bant genişliğinde önceliklendirmesini bildirir. Responsive görseller için imagesrcset ve imagesizes öznitelikleriyle birlikte kullanın. Kritik uyarı: LCP görseline loading="lazy" uygulamak tarayıcının öğeyi viewport’a girinceye kadar yüklememesine neden olur ve LCP süresini ciddi biçimde artırır; LCP öğesi asla lazy load edilmemelidir.
LCP öğesi metin ise web fontu gecikmesi Element Render Delay’i yükseltir. Çözüm iki bileşenden oluşur: fontu <link rel="preload" as="font" crossorigin> ile preload edin ve CSS’te font-display: swap kullanın. swap, font yüklenene kadar yedek sistem fontunu gösterir; kullanıcı boş ekran yerine içeriği okuyabilir. Google Fonts gibi harici kaynaklar için <link rel="preconnect"> eklemek DNS çözümlemesini ve bağlantı kurulumunu önceden tamamlar, Resource Load Delay’i daha da kısaltır.
Ajans Vadi’nin LCP alt bileşen rehberinde de vurgulandığı gibi preload ile prefetch arasındaki pratik farkı karıştırmamak kritik öneme sahiptir. Preload, mevcut sayfa için kritik kaynakları yüksek öncelikle hemen indirir. Prefetch ise sonraki sayfa ziyareti için tarayıcıya ipucu verir ve boş zamanda düşük öncelikle indirir. LCP görselini yanlışlıkla prefetch ile işaretlemek onu sıraya koyar ancak geciktirir; bu açık bir hata olup LCP süresini doğrudan artırır.
Chrome 120+ sürümleriyle gelen preload scanner geliştirmesi önemli bir değişiklik getirdi: tarayıcı artık CSS background-image üzerinden tanımlı LCP öğelerini daha erken aşamada tespit edebilmektedir. Bu gelişme bazı eski manuel preload stratejilerinin güncellenmesini gerektirebilir. Buna karşın açık preload direktifi ile fetchpriority=high kombinasyonu hâlâ en güvenilir ve önerilen yaklaşım olmayı sürdürmektedir.
| Özellik | Critters | Critical.js | Penthouse |
|---|---|---|---|
| Platform uyumluluğu (WordPress / Next.js / Shopify) | Next.js, Vite, Webpack — WordPress için ek yapılandırma gerekir | Evrensel; WordPress, Shopify, Next.js dahil tüm Node.js ortamları | Evrensel; Puppeteer destekleyen her ortam |
| Build pipeline entegrasyonu | Otomatik (webpack/vite plugin) | Yarı-otomatik (Gulp / Grunt task) | Manuel yapılandırma gerektirir |
| CSS çıkarma yöntemi | Statik HTML analizi | Viewport bazlı render (headless browser) | Görsel render — Headless Chrome ile en yüksek doğruluk |
| Büyük CSS dosyalarında işlem hızı | Hızlı | Orta | Yavaş (Chrome başlatma maliyeti) |
| Aktif geliştirme (2026) | Aktif — Google tarafından destekleniyor | Sınırlı bakım | Sınırlı bakım |
| Kurulum zorluğu | Kolay (plugin kurulumu) | Orta (Node.js pipeline kurulumu) | Zor (Puppeteer + yapılandırma) |
Vaka Çalışması: Critters ile WordPress E-ticaret Sitesinde LCP 4.2 sn’den 1.8 sn’ye İndi
Adımların pratikte ne kadar fark yarattığını somutlaştırmak için gerçek bir WooCommerce mağazasındaki optimizasyon sürecini inceleyelim. Başlangıçta PageSpeed Insights mobil LCP değerini 4.2 saniye olarak raporluyordu. Render-blocking resources uyarısı iki CSS dosyasını işaret ediyordu; Resource Load Delay tek başına 1.9 saniyelik kayıptan sorumluydu, Element Render Delay ise 0.8 saniyeydi.
Optimizasyon üç aşamada tamamlandı:
- Critters ile kritik CSS çıkarma: Node.js tabanlı bir build adımı oluşturuldu. Critters ana tema CSS dosyasını (yaklaşık 180 KB) tarayarak hero alanına ait yaklaşık 12 KB kritik CSS’i çıkardı ve head içine inline etti. Kalan yaklaşık 168 KB media=print tekniğiyle asenkron yüklemeye alındı.
- Hero görseline preload ve fetchpriority ekleme: link rel=preload as=image fetchpriority=high eklendi; mevcut loading=lazy özniteliği kaldırıldı. Hero görsel için lazy loading LCP’yi doğrudan bozar.
- Üçüncü taraf scriptlere defer: Chat widget ve pazarlama piksellerine defer eklendi; bu scriptler LCP tamamlanana kadar çalışmaz hale getirildi.
Sonuçlar PageSpeed Insights’ta net biçimde görüldü: Resource Load Delay 1.9 sn’den 0.2 sn’ye, Element Render Delay 0.8 sn’den 0.3 sn’ye indi. Toplam mobil LCP 1.8 saniyeye geriledi; Google’ın 2.5 sn’lik iyi eşiğinin belirgin biçimde altında.
2025-2026 döneminde HTTP/3 ve QUIC protokollerinin Cloudflare ve AWS CloudFront gibi CDN sağlayıcılarınca yaygın biçimde desteklenmesiyle birlikte kritik kaynak yükleme gecikmeleri ek olarak azalmaktadır. Bu gelişme doğru uygulanan kritik CSS inline etme ve preload kombinasyonunu ikame etmez; aksine üstüne eklenen ek bir hız katmanı sunar.
Optimizasyon sonrasında değişikliklerin kalıcı olduğundan emin olmak için düzenli izleme şarttır. Site sağlığı aracımızla render-blocking uyarılarını ve Core Web Vitals metriklerini otomatik olarak izleyebilir, sıralama değişimlerini anlık raporlarla takip edebilirsiniz. Ahrefs veya SEMrush gibi yabancı platformlar bu izlemeyi İngilizce arayüz ve döviz bazlı aboneliklerle sunarken SEOYEN, aynı derinlikte site denetimi ve Core Web Vitals takibini Türkçe arayüzde, TL bazlı güncel fiyatlandırmayla tek bir platformda sunuyor.
Kaynaklar
Sıkça Sorulan Sorular
Kritik render yolu (Critical Rendering Path), tarayıcının sunucudan aldığı HTML, CSS ve JavaScript kaynaklarını işleyerek ekrana ilk pikseli çizene kadar geçtiği adımlar zinciridir. Bu zincir. HTML'nin DOM'a, CSS'nin CSSOM'a dönüştürülmesi, ardından Render Tree'nin oluşturulması, layout hesabı ve paint aşamalarından oluşur. LCP öğesi — hero görsel, büyük metin bloğu veya h1 başlığı — ancak bu zincirin ilgili adımları tamamlandıktan sonra ekranda belirebildiğinden, zincirdeki her gecikme doğrudan LCP süresini uzatır. Özellikle render-blocking CSS ve JavaScript kaynakları bu zinciri duraksatarak LCP'nin birincil geciktirici faktörü haline gelir.
Google'ın belirlediği eşiklere göre iyi bir LCP skoru 2.5 saniyenin altında olmalıdır. 2.5 ile 4.0 saniye arasındaki değerler iyileştirme gerektirir kategorisine girer. 4.0 saniye üstü kötü olarak sınıflandırılır ve kullanıcı deneyimi açısından ciddi sorun teşkil eder. Bu eşikler 2026 itibarıyla değişmemiş olup Google'ın Core Web Vitals puanlamasında belirleyici olmaya devam etmektedir. Google'ın INP'i FID'in yerine koymasının ardından LCP, Core Web Vitals içindeki en kritik sayfa yükleme metriği konumunu koruyor ve Google arama sıralamalarında doğrudan etki yaratıyor.
Render-blocking bir CSS veya JavaScript dosyası, tarayıcının o kaynağı tamamen indirip işlemeden sayfayı çizmesini engeller. HTML ayrıştırması duraklar, CSSOM tamamlanamaz, dolayısıyla Render Tree oluşturulamaz ve boyama başlamaz. Bu bekleyiş doğrudan LCP'nin Resource Load Delay bileşenine yansır: tarayıcı LCP kaynağını daha erken keşfetmiş olsa bile render-blocking kaynak tamamlanana dek onu yükleyemez. Sonuç olarak kullanıcı LCP öğesinin ekranda belirmesini bekler. hem kullanıcı deneyimi hem de Google sıralaması olumsuz etkilenir.
Above-the-fold kritik CSS'i doğrudan HTML içindeki style bloğu olarak head'e inline etmek, tarayıcının sayfanın görünür kısmını çizmek için ek bir HTTP isteği yapmasını ortadan kaldırır. Harici CSS dosyası için istek, sunucu yanıtı, indirme ve ayrıştırma döngüsü atlandığından CSSOM, HTML ayrıştırmasıyla eş zamanlı tamamlanır. Bu durum LCP'nin Resource Load Delay bileşenini neredeyse sıfıra indirir ve LCP öğesinin çok daha erken ekranda belirmesini sağlar. Gerçek bir WooCommerce sitesinde bu teknikle Resource Load Delay 1.9 saniyeden 0.2 saniyeye gerilemiştir.
LCP öğesi bir görsel veya font ise link rel=preload direktifi, tarayıcının bu kaynağı HTML ayrıştırması sırasında preload scanner aşamasında erken keşfetmesini sağlar. Kaynak, LCP öğesinin render'ı gerçekleşeceği anda zaten yükleniyor ya da yüklenmiş olur. böylece Resource Load Duration ve toplam LCP süresi kısalır. LCP görseli için fetchpriority=high özniteliğini de eklemek tarayıcının ağ bant genişliğini bu kaynağa öncelikli olarak tahsis etmesini sağlar. Web fontları için preload'u font-display: swap ile birleştirmek Element Render Delay'i de düşürerek kapsamlı bir LCP iyileştirmesi sunar.
async ile işaretlenen bir script arka planda indirilir ve hazır olduğu anda HTML ayrıştırmasını geçici olarak durdurarak çalışır. bu durum LCP öğesinin render'ını engelleyebilir. defer ise scripti indirir ancak DOM ayrıştırması tamamlanana kadar çalıştırmaz. LCP için genellikle çok daha güvenli bir seçenektir. Pratik kural: hero görsel veya büyük metin bloğu gibi LCP öğesinden önce çalışması gerekmeyen scriptlere defer, reklam pikseli veya chat widget gibi sayfa içeriğinden tamamen bağımsız scriptlere async ekleyin. LCP öncesinde zorunlu değilse scripti body sonuna taşımak da ek kazanım sağlar.
loading=lazy özniteliği, tarayıcıya bir görseli yalnızca viewport'a yaklaştığında yüklemesini söyler. Sayfa boyunca dağılmış görseller için bant genişliğini verimli kullanmak açısından değerlidir. Ancak LCP öğesi olan hero görsele lazy loading uygulandığında tarayıcı, o görseli sayfa yüklenmesinin ilk aşamalarında atlar ve scroll gerçekleşene kadar bekler. Hero görsel zaten viewport'ta görünür konumda olduğundan bu bekleme tamamen gereksizdir ve LCP süresini ciddi biçimde artırır. LCP öğesi kesinlikle lazy load edilmemeli. aksine fetchpriority=high ile önceliklendirilmelidir.
Chrome DevTools Performance sekmesinde sayfa kaydı alarak LCP işaretçisine tıkladığınızda hangi öğenin LCP olduğu, toplam süresi ve alt bileşen dökümü görünür. PageSpeed Insights raporu Largest Contentful Paint element başlığı altında LCP öğesini doğrudan gösterir ve bileşen bazında süre bilgisi sunar. Programatik tespit için JavaScript'te PerformanceObserver API kullanılabilir: largest-contentful-paint entry'lerini dinleyerek LCP öğesini ve süresini anlık olarak kaydedebilirsiniz. Tipik LCP öğeleri: hero görsel (img), büyük arka plan görseli (CSS background-image), h1 başlığı veya sayfanın en geniş metin bloğudur.