Kısa cevap: Render engelleyen kaynaklar, tarayıcı sayfanın ilk içeriğini ekrana çizmeden önce indirip işlemek zorunda kaldığı CSS ve JavaScript dosyalarıdır. Bunları azaltmak için ilk görünüm için gereken kritik CSS'i sayfa içine gömün, kalan stilleri ve kritik olmayan scriptleri ertelenmiş (defer/async) ve asenkron biçimde yükleyin, kullanılmayan kodu temizleyin. Sonucu Lighthouse ve PageSpeed Insights ile, özellikle LCP üzerinden ölçersiniz.
Çoğu teknik SEO rehberi site hızından ve Core Web Vitals'tan bahseder ama "render engelleyen kaynak" konusunu ya hiç açmaz ya da bir cümlede geçer. Oysa bir sayfanın ilk açılış hissini en çok etkileyen şeylerden biri tam olarak budur. Bu yazıda render engellemenin ne olduğunu, kritik render yolunu, CSS ve JS tarafında ne yapabileceğinizi, üçüncü taraf scriptleri nasıl yöneteceğinizi ve sonucu nasıl ölçeceğinizi kaynaklara dayanarak ele alıyoruz.
Render engelleme nedir? Kritik render yolu
Bir tarayıcı bir sayfayı ekrana çizmeden önce iki şey kurar. Önce HTML'i ayrıştırıp DOM (Document Object Model) ağacını oluşturur, sonra CSS'i ayrıştırıp CSSOM (CSS Object Model) ağacını oluşturur. Render ağacı bu ikisinin birleşiminden doğar. İşte bu sıralamaya kritik render yolu denir.
Buradaki kritik nokta şudur: web.dev'e göre CSS varsayılan olarak render engelleyen bir kaynaktır. Tarayıcı, CSSOM tamamen kurulana kadar işlenmiş içeriği ekrana çizmez, çünkü render ağacı hem DOM hem de CSSOM gerektirir (web.dev). Yani sayfanız ne kadar hafif görünürse görünsün, tarayıcı tüm engelleyici CSS'i indirip işlemeden kullanıcıya boş ekran gösterir.
JavaScript tarafında da benzer bir durum vardır. Belge içinde uygun şekilde işaretlenmemiş scriptler, ayrıştırmayı durdurur ve sayfanın çizilmesini geciktirir. Lighthouse bu iki türü açıkça render engelleyen olarak işaretler: head içinde defer veya async niteliği olmayan scriptler ve bir media sorgusu ya da disabled niteliği taşımayan stil dosyaları (Chrome for Developers).
Pratikte amaç şu: tarayıcının ilk anlamlı çizimi yapmadan önce beklemek zorunda olduğu iş miktarını mümkün olduğunca küçültmek. Bunu yaparken sayfanın görünümünü bozmamanız, yani ilk ekranda gereken stillerin yerinde olması gerekir. Optimizasyonun zorluğu da burada başlar.
Kritik CSS: ilk görünüm için gerekeni öne almak
Kritik CSS, sayfanın ilk açılışında görünen alanın (above the fold) doğru görünmesi için mutlaka gereken stillerdir. Geri kalan her şey, sayfa aşağı kaydırıldığında devreye giren stiller, ilk çizim için zorunlu değildir.
Chrome for Developers'ın render engelleyen kaynaklar rehberinde önerilen yaklaşım nettir: ilk boyama için gereken kritik stilleri head içinde bir <style> bloğuna satır içi (inline) gömün, kalan stilleri preload ile asenkron yükleyin, kullanılmayan kodu kaldırın ve CSS'i küçültün (minify) (Chrome for Developers). Kritik CSS'i sayfanın içine gömdüğünüzde tarayıcının ayrı bir dosya için ağ isteği yapmasını beklemesine gerek kalmaz, ilk çizim hızlanır.
Kritik CSS'i elle ayıklamak büyük sitelerde zahmetlidir. Bu işi otomatikleştirmek için Critical gibi araçlar kullanılır; bu araçlar sayfanın görünen alanı için gereken stilleri çıkarıp ayırmanıza yardımcı olur. Tek tek sayfalarda manuel çalışmak yerine, bir derleme adımına bağlamak çoğu durumda daha sürdürülebilir olur.
CSS'i media sorgularıyla bölmek
Tüm CSS'i tek bir engelleyici dosyada tutmak zorunda değilsiniz. web.dev'e göre media tipleri ve sorguları CSS'i koşullu hale getirerek render engellemeyi azaltır. Örneğin media="print" ile yüklenen bir stil dosyası yalnızca yazdırma için geçerlidir; tarayıcı bu dosyayı yine indirir ama engellemeyen olarak işaretleyip düşük öncelik verir. Aynı mantık media="(min-width: 40em)" gibi sorgular için de geçerlidir, stil yalnızca koşul karşılandığında uygulanır (web.dev).
Yani stillerinizi bağlama göre bölerseniz, tarayıcı o anda gerekmeyen CSS'i ilk çizimi engellemeden arka planda indirir. Buna minify'ı da eklerseniz, hem indirilen bayt miktarı hem de işlenmesi gereken kod azalır. İkisi birlikte ilk çizime giden yolu kısaltır.
Kullanılmayan CSS'i temizlemek
Çoğu sitede CSS dosyaları zamanla şişer. Eklenen ama sonradan kaldırılmayan bileşenler, eski tema kalıntıları ve hiçbir sayfada kullanılmayan kurallar birikir. Chrome for Developers'ın önerileri arasında render engellemeyi azaltmak için kullanılmayan kodu kaldırmak ve CSS'i küçültmek açıkça yer alır (Chrome for Developers). Kullanılmayan kuralları temizlediğinizde tarayıcının indirip ayrıştırması gereken stil miktarı düşer, bu da CSSOM'un daha hızlı kurulması anlamına gelir.
Pratikte bu işi periyodik yapmak en sağlıklısıdır. Yeni bir tasarım bileşeni eklerken eskisini gerçekten kaldırdığınızdan emin olun, büyük yeniden tasarımlardan sonra stil dosyalarınızı gözden geçirin. Kullanılmayan CSS, ilk bakışta zararsız görünse de her sayfa yüklemesinde küçük bir gecikme olarak geri döner.
JS yükleme stratejileri: defer ve async farkı
Scriptlerin sayfayı engellemesini önlemenin en doğrudan yolu, doğru yükleme niteliğini kullanmaktır. Burada iki seçenek vardır ve aralarındaki fark çoğu zaman karıştırılır.
MDN'e göre defer niteliği, scripti belge ayrıştırmasına paralel olarak indirir, ancak scripti belge tamamen ayrıştırıldıktan sonra (DOMContentLoaded olayından hemen önce) belge sırasına göre çalıştırır. defer, ayrıştırmayı veya render'ı engellemez. async ise scripti yine paralel indirir fakat hazır olur olmaz çalıştırır; bu sırada indirme tamamlandığında sayfayı engelleyebilir ve birden fazla async script arasında çalışma sırası garanti edilmez (MDN).
Bu farkı pratik kararlara çevirmek gerekirse:
- defer, çalışma sırası önemli olan ve DOM'a ihtiyaç duyan scriptler için uygundur. Çoğu uygulama scripti, bileşen kodu ve sıraya bağımlı dosyalar için varsayılan tercih budur.
- async, diğer scriptlerden ve DOM'dan bağımsız çalışabilen, sırası önemsiz scriptler için uygundur. Bazı bağımsız ölçüm ya da izleme scriptleri bu kategoriye girer.
- İlk ekran için kritik olmayan her scripti ertelemek, ilk çizimi hızlandırmanın en kolay yollarından biridir.
Genel kural şu: ilk görünüm için gerçekten gerekmeyen JavaScript'i ilk çizimin önünden çekin. Kritik olmayan scriptlere defer veya async ekleyin, kullanılmayan JS'i tamamen kaldırın.
Üçüncü taraf scriptler: çoğu rehberin atladığı kısım
Analitik kodları, canlı sohbet widget'ları, reklam etiketleri, sosyal medya gömme kodları ve benzeri üçüncü taraf scriptler, performans sorunlarının sık karşılaşılan ama çoğu Türkçe teknik SEO içeriğinde es geçilen kaynağıdır. Bu scriptler sizin sunucunuzdan gelmediği için indirme süreleri ve davranışları üzerinde tam kontrolünüz yoktur, yine de yükleme biçimlerini siz yönetebilirsiniz.
Pratik yaklaşımlar şunlardır:
- Erteleme. Üçüncü taraf scriptlerini de mümkünse defer veya async ile yükleyin, head içine engelleyici biçimde koymaktan kaçının.
- Facade (cephe) tekniği. Ağır gömme bileşenleri için önce hafif bir yer tutucu görsel gösterin, gerçek scripti yalnızca kullanıcı etkileşime girdiğinde yükleyin. Örneğin bir video gömme alanı, tıklanana kadar tam oynatıcıyı yüklemek yerine sadece bir önizleme gösterir.
- Geç yükleme (lazy load). Sayfanın altındaki ya da hemen görünmeyen bileşenlere ait scriptleri, o alana yaklaşıldığında yükleyin.
- Gereksizleri eleme. Her eklenen üçüncü taraf scriptinin bir maliyeti vardır. Gerçekten kullanılmayan etiketleri ve widget'ları kaldırmak çoğu zaman en etkili iyileştirmedir.
Üçüncü taraf scriptler kontrolsüz biriktiğinde, sizin kendi kodunuzu ne kadar optimize ederseniz edin ilk çizim yine gecikebilir. Bu yüzden bunları düzenli olarak gözden geçirmek bakım işinin bir parçası olmalıdır.
Render engelleme ile Core Web Vitals ilişkisi
Render engelleyen kaynakların doğrudan etkilediği metrik, kullanıcının sayfanın ana içeriğini ne zaman gördüğüdür. Largest Contentful Paint (LCP), görünür alandaki en büyük içerik öğesinin render edilme süresini ölçer. Engelleyici CSS ve JS bu süreyi geciktirdiğinde, LCP de kötüleşir.
web.dev'e göre iyi bir LCP değeri 2.5 saniye veya altıdır; 4.0 saniyenin üzeri zayıf kabul edilir. Bu eşik, sayfa yüklemelerinin 75. yüzdelik diliminde, mobil ve masaüstü için ayrı ayrı değerlendirilir (web.dev). Yani sadece sizin hızlı internetinizdeki tek bir açılış değil, gerçek kullanıcıların büyük çoğunluğunun deneyimi önemlidir.
Bu bağlantı, render optimizasyonunu neden ciddiye almanız gerektiğini açıklar. Kritik CSS'i öne almak, gereksiz JS'i ertelemek ve üçüncü taraf scriptleri dizginlemek, doğrudan ilk çizimi ve dolayısıyla LCP'yi iyileştirir. Rakip içeriklerin çoğu Core Web Vitals'a değinip render engellemeyle ilişkisini kurmaz; oysa pratikte LCP'yi düşüren en somut müdahalelerden biri budur.
Sonuçları ölçme: tahmin değil, veri
Yaptığınız değişikliklerin işe yarayıp yaramadığını görmek için ölçmeniz gerekir. İki tür veri vardır ve ikisini de kullanmak en sağlıklısıdır.
Laboratuvar verisi kontrollü bir ortamda ölçüm yapar. Lighthouse, render engelleyen kaynakları bir başlık altında listeler ve hangi dosyaların ilk çizimi geciktirdiğini gösterir. Chrome for Developers'ın belgelediği bu denetim, hangi scriptlerin ve stil dosyalarının engelleyici olduğunu tek tek ortaya koyar (Chrome for Developers). PageSpeed Insights de aynı Lighthouse motorunu kullanır ve tek bir URL için hızlı bir başlangıç noktası verir.
Saha verisi ise gerçek kullanıcıların deneyimini yansıtır. LCP gibi metriklerin 75. yüzdelik dilimde değerlendirilmesinin sebebi de budur; tek bir cihazda iyi görünen bir değer, gerçek kullanıcı dağılımında farklı çıkabilir (web.dev).
Ölçerken pratik bir akış izleyin:
- Değişiklik öncesi mevcut durumu Lighthouse veya PageSpeed Insights ile kaydedin, render engelleyen kaynak listesini ve LCP değerini not edin.
- Kritik CSS, defer/async ve üçüncü taraf düzenlemelerini uygulayın.
- Aynı sayfayı tekrar ölçün, render engelleyen kaynak listesinin kısaldığını ve LCP'nin düştüğünü doğrulayın.
- Mümkünse saha verisini de takip edin; gerçek kullanıcı dağılımında iyileşme olduğundan emin olun.
Wix, Ikas ve özel sitelerde uygulama notları
Optimizasyonun ne kadarını uygulayabileceğiniz platforma bağlıdır ve bunu baştan bilmek beklentinizi doğru ayarlar.
Kendi kodunu yazdığınız özel sitelerde (örneğin bir Next.js veya benzeri kurulumda) buradaki tekniklerin neredeyse tamamı elinizdedir. Kritik CSS'i ayırabilir, scriptlere defer/async ekleyebilir, üçüncü taraf gömmeleri facade ile yükleyebilir ve build adımında CSS'i küçültebilirsiniz. Modern çerçeveler bunların çoğunu zaten kolaylaştırır.
Wix ve Ikas gibi platformlarda ise CSS ve script yükleme sırası üzerindeki kontrolünüz daha sınırlıdır, çünkü temel render davranışını platform yönetir. Yine de yapabilecekleriniz vardır: gereksiz üçüncü taraf eklentilerini ve izleme kodlarını kaldırmak, ağır gömme bileşenleri yalnızca gerektiğinde göstermek, görselleri optimize etmek ve eklediğiniz özel kodları engelleyici biçimde head içine koymamak. Burada en büyük kazanç çoğu zaman "daha fazla kod ekleme" tarafında değil, "gereksiz yükü kaldırma" tarafındadır.
Hangi platformda olursanız olun, önce ölçün, neyin engellediğini görün, sonra elinizdeki kontrol kadarını uygulayın. Tahminle değişiklik yapmak yerine Lighthouse'un işaret ettiği somut kaynaklara odaklanmak zamanınızı en verimli kullanmanın yoludur.
VixSEO, Wix, Ikas ve özel sitelerde teknik SEO sinyallerini ve sayfa hızıyla ilgili sorunları tek panelden takip etmenize yardımcı olur; her sayfayı tek tek elle denetlemek yerine render engelleyen kaynaklar gibi noktaları toplu görebilirsiniz. Sitenizin teknik durumunu düzenli izlemek isterseniz araçlarımıza göz atabilir veya hizmetlerimizi inceleyebilirsiniz.