PageSpeed Insights Neden Hâlâ "Eliminate render-blocking resources" Diyor?
CSS dosyanızı minify ettiniz, görselleri sıkıştırdınız, hatta CDN kullanıyorsunuz. Ama PageSpeed Insights raporu hâlâ o her zamanki kırmızı çizgiyi gösteriyor: "Eliminate render-blocking resources". Altında da görünüşte hiçbiri "gerekli" görünmeyen CSS ve JavaScript dosyalarının bir listesi var.
Bu hata, tarayıcının sayfanın ilk pikselini çizebilmesi için bu dosyaların indirilmesini ve işlenmesini beklediği anlamına gelir. Sadece indirilmelerini değil, tamamen işlenmelerini. Sayfanın altındaki bir slider'ın stilini belirleyen 20 KB'lık bir CSS dosyası, tüm sayfanın render'ını 300 milisaniye geciktirebilir. 100 milisaniye gecikmeli bir bağlantıda, bu tek dosya yüklemeye üç ekstra gidiş-dönüş ekler.
Sorun sadece hız değil. Google, 2021'den beri arama sonuçlarında Core Web Vitals metriklerini uyguluyor ve LCP, üç ana metrikten biri. Render blocking doğrudan LCP'yi etkiler. Yani bu hata bir SEO önerisi değil; bir sıralama faktörüdür.
Çözüm de dosyaları silmek değil. Çözüm, hangi kaynakların gerçekten ilk render için gerekli olduğunu ve hangilerinin bekleyebileceğini anlamaktır. Bu makalede, üç aracı da teknik detaylarıyla inceliyoruz: critical CSS, defer ve async nitelikleri ve preload. En önemlisi, her birinin nerede işe yaradığını ve nerede sorun çıkardığını söylüyoruz.
critical CSS: Sadece İlk Render İçin Gerekli Olan
critical CSS, sayfanın üst kısmındaki (above-the-fold) içerikle ilgili stilleri ayırıp HTML'e satır içi (inline) olarak eklemek demektir. Geri kalan stilleri ayrı bir dosyada tutun ve eşzamansız (async) yüklemeyle ekleyin.
Gerçek bir örnek. style.css dosyanızın 45 KB olduğunu varsayalım. Tarayıcının sayfayı çizebilmesi için bu dosyanın tamamını indirip parse etmesi gerekir. Ancak bu 45 KB'ın belki de sadece 8 KB'ı header, ana menü ve sayfanın ilk alanıyla ilgilidir. O 8 KB'ı <head> içindeki <style> etiketine koyun. Tarayıcı artık hiçbir harici dosyayı beklemez.
critical CSS'i otomatik üretmek için çeşitli araçlar var. npm'deki ücretsiz critical aracı en bilinenlerden biridir:
npm install -g critical
critical --base https://example.com --width 1366 --height 768 --inlineBu komut, sayfayı belirtilen boyutlarda render eder ve o alanla ilgili CSS'i çıkarır. Çıktıyı <head> içine yerleştirin ve geri kalan CSS'i aşağıdaki yöntemle yükleyin:
<link rel="stylesheet" href="/tr/css/style.css" media="print" onload="this.media='all'">Bu eski ama etkili numara, tarayıcıya dosyayı düşük öncelikle (print) indirmesini ve load'dan sonra normal durumuna döndürmesini söyler. Modern tarayıcılar bu kalıbı bilir ve dosyayı render'ı engellemeden indirir.
İşte Burada Hata Yapıyorlar
Gördüğüm en yaygın hata şu: geliştirici tüm CSS'i inline yapıyor. Harici dosyayı siliyor ve 45 KB'ın tamamını <style> içine döküyor. Sonuç? Sayfanın HTML'i 30 KB'tan 75 KB'a çıkıyor. Artık tarayıcının daha fazla HTML indirmesi gerekiyor ve ilk bayta kadar geçen süre (TTFB) artıyor. Ayrıca CSS HTML'in içinde olduğu için önbelleğe alınamıyor. Her ziyaret, o 75 KB'ı yeniden indiriyor.
Bu hatanın belirtisi: HTML boyutunuz anormal şekilde arttı ve LCP iyileşmedi, hatta kötüleşti. critical CSS, tüm stiller değil, yalnızca sayfanın üst kısmındaki stillerdir.
Bir başka not: Siteniz tek sayfalık (SPA) ise veya React gibi bir framework kullanıyorsa, critical CSS'i manuel üretmek neredeyse imkânsızdır. Bu durumda, framework içindeki otomatik araçları (örneğin CSS'i varsayılan olarak inline yapan Next.js) tercih edin.
defer ve async: İki Nitelik, İki Farklı Davranış
JavaScript için, her biri farklı davranışa sahip iki niteliğiniz var. Farkları ince ama yükleme hızındaki sonucu oldukça belirgindir.
defer niteliği tarayıcıya şunu söyler: Dosyayı HTML ile paralel indir, ancak çalıştırmayı HTML parse işlemi bitene kadar ertele. defer script'leri HTML'de görünme sırasına göre çalıştırılır. Bu nitelik, DOM'a bağımlı script'ler için uygundur.
async niteliği ise: Dosyayı paralel indir ve hazır olur olmaz çalıştır. Çalıştırma sırası garanti edilmez. Önce indirilen script önce çalışır. Bu nitelik, analitik veya reklam enjeksiyon script'i gibi bağımsız script'ler için uygundur.
Hangisini seçmelisiniz? Basit kural: Script'iniz DOM'a ihtiyaç duyuyorsa ve çalıştırma sırası önemliyse defer. Script bağımsızsa ve başka bir şeye bağımlı değilse async. Hiçbirini koymazsanız, script'iniz render blocking olur ve tarayıcı, tamamen indirilip çalıştırılana kadar render'ı durdurur.
Doğru kullanıma bir örnek. İki script'iniz olduğunu varsayalım: jquery.js ve jQuery'ye bağımlı olan main.js. İkisini de defer ile yükleyin. Çalıştırma sırası korunur ve render engellenmez. Şimdi bağımsız bir çevrimiçi sohbet script'iniz olduğunu varsayalım. Onu async ile yükleyin.
<script src="/js/jquery.js" defer></script>
<script src="/js/main.js" defer></script>
<script src="/js/live-chat.js" async></script>defer'ın İşe Yaramadığı Durum
Belge ayrıştırılırken öğe enjekte eden script'ler (bazı eski reklam script'leri gibi) defer ile bozulur. Çünkü defer, çalıştırmayı parse işleminden sonraya erteler ve bu script'ler parse sırasında çalışmayı bekler. defer ekledikten sonra sayfada belirli bir içeriğin görünmediğini veya öğelerin sırasının bozulduğunu fark ederseniz, muhtemelen böyle bir script'le karşı karşıyasınız. Bu durumda, script'i <body> sonuna koyun ve defer niteliğini kaldırın. Evet, bu ideal değil, ancak bazen üçüncü taraf script'ler için tek pratik çözümdür.
preload: Kendisi Darboğaz Haline Gelen Araç
rel="preload" niteliği tarayıcıya şunu söyler: Bu kaynağı hemen yüksek öncelikle indir, çünkü yakında ihtiyacın olacak. Ana kullanımı, tarayıcının ilgili CSS ile karşılaşana kadar varlığından haberdar olmadığı fontlar ve hero görselleri içindir.
<link rel="preload" href="/tr/fonts/vazir.woff2" as="font" type="font/woff2" crossorigin>İşte preload'un tam olarak işe yaradığı yer burası. Vazir fontunu düşünün. Tarayıcı, CSS'i okuyup fontun gerekli olduğunu anlamadan font indirmeye başlamaz. preload ile font indirme en baştan başlar ve CSS ile paralel ilerler.
Ama işte burada hata yapıyorlar: preload'u her şey için kullanıyorlar. Her görsel, her CSS dosyası, her script. Sonuç? Tarayıcı her şeyi yüksek öncelikle indiriyor ve tarayıcının sınırlı bant genişliği bu kaynaklar arasında bölünüyor. Gerçekten kritik kaynaklar (ana CSS gibi) daha yavaş indiriliyor. LCP kötüleşiyor. Ve PageSpeed Insights'ta yeni bir uyarı alıyorsunuz: "Preload key requests".
Benim kuralım şu: preload'u yalnızca fontlar ve tarayıcının geç fark ettiği en fazla bir veya iki kritik kaynak için kullanın. 3-4'ten fazla preload'unuz varsa, tarayıcının önceliklendirme sistemine zarar veriyorsunuz demektir.
Bir başka teknik not: Fontlar için mutlaka crossorigin niteliğini ekleyin. Olmadan font indirilmez ve tarayıcı konsolunda CORS hatası görürsünüz. Bu hatayı defalarca gördüm: geliştirici preload'u doğru eklemiş ama crossorigin'ı unutmuş ve font hâlâ geç yükleniyor.
Doğru Sıralama: Nereden Başlamalı
Siteniz WordPress tabanlıysa, WP Rocket veya Perfmatters gibi eklentiler bu işleri otomatik yapar. Ancak özel bir siteniz varsa veya bunu manuel yapmak istiyorsanız, önerdiğim sıralama şu:
- Önce PageSpeed Insights veya hız testi ve SEO araçları ile rapor alın ve tam olarak hangi dosyaların render blocking olduğunu görün.
- CSS dosyalarını inceleyin. CSS dosyanız büyükse (20 KB'ın üzerinde) ve yalnızca bir kısmı ilk render için gerekiyorsa, critical CSS'i uygulayın.
- JavaScript script'lerini kategorize edin: hangileri DOM'a ihtiyaç duyuyor (defer), hangileri bağımsız (async), hangileri parse sırasında çalışmalı (hiçbiri, body sonunda bırakın).
- Fontları preload ile yükleyin ve crossorigin'ı unutmayın.
- Tekrar test edin ve sayıları karşılaştırın.
Önemli bir not: Her değişiklikten sonra sitenin görsel olarak sağlıklı olduğunu mutlaka test edin. Otomatik araçlar bazen yanlış CSS'i critical olarak algılar ve sonuç, stilleri zamanla ve gecikmeyle uygulanan bir sayfa olur. Kullanıcı sayfayı CSS'siz görür ve sonra aniden her şey yerine oturur. Bu deneyim, yavaş yüklenmeden daha kötüdür.
Core Web Vitals metrikleriyle yeni başlıyorsanız, önce Core Web Vitals Pratik Rehberi'ni okumanızı öneririm, böylece metrikler hakkında daha eksiksiz bir resme sahip olursunuz. Ve sorununuz render blocking'in ötesindeyse ve sitenin genel hızı düştüyse, site hızını artırma kapsamlı rehberi adım adım yolu gösterir.
Render blocking'i kaldırmak tek seferlik bir iş değildir. Her yeni eklenti kurduğunuzda veya yeni bir script eklediğinizde, sayfaya yeni bir engelleyici kaynak girebilir. PageSpeed Insights veya benzeri bir araçla aylık kontrol, sorunun kademeli olarak geri dönmesini engeller.
Bu işleri yaptıysanız ve LCP'niz hâlâ yüksekse, sorun başka yerde demektir. Belki görseller ağır veya sunucu yanıtı yavaş. Bu durumda, LCP iyileştirme rehberi'ne bakın ve WebP ile AVIF formatlarını kullanarak görsel optimizasyonuna geçin. Render blocking bulmacanın sadece bir parçası; ancak genellikle puan alabileceğiniz ilk ve en kolay yerdir.
Ve bu işleri müşteri siteleri için yapıyorsanız ve manuel uygulama için yeterli zamanınız yoksa, SEO hizmetleri bu teknik optimizasyon kısmını sizin için yönetebilir. Ancak kendiniz manuel çalışıyorsanız, hemen şimdi başlayın: bir CSS dosyası alın ve onu media="print" ile yüklerseniz ne olacağını görün.
Sıkça Sorulan Sorular
defer ve async arasındaki fark nedir ve hangisini kullanmalıyım?
defer, script'i HTML parse işlemi tamamlandıktan sonra çalıştırır ve çalıştırma sırasını korur. async, script'i hazır olur olmaz çalıştırır ve sıra garantisi yoktur. DOM'a bağımlı script'ler için defer, analitik gibi bağımsız script'ler için async kullanın.
Render blocking'i kaldırmak SEO'yu etkiler mi?
Evet. Render blocking doğrudan, Core Web Vitals metriklerinden biri olan LCP'yi etkiler. Google bu metrikleri mobil sıralamada dikkate alır. LCP'yi iyileştirmek hem kullanıcı deneyimini hem de sıralamanızı iyileştirebilir.
Tüm CSS'i inline yapabilir miyim?
Hayır. Tüm CSS'i inline yapmak HTML boyutunu ciddi şekilde artırır ve önbelleğe alınma olasılığını ortadan kaldırır. Yalnızca sayfanın üst kısmıyla ilgili stilleri (critical CSS) inline yapın ve gerisini eşzamansız yöntemlerle yükleyin.
Font preload'u neden çalışmıyor?
En olası neden, preload etiketinde crossorigin niteliğinin olmamasıdır. Fontlar CORS ile yüklenir ve crossorigin olmadan tarayıcı isteği reddeder. Etikete mutlaka crossorigin ekleyin.
Yorumlar 0
Henüz yorum yok — ilk siz olun!