PageSpeed Insights raporunu açan hemen herkes aynı satırla karşılaşır: "Render engelleyen kaynakları ortadan kaldırın". Altında bir dosya listesi ve yanlarında "tahmini tasarruf" olarak yazılmış milisaniyeler durur. Türkçe kaynaklarda bu uyarının çözümü genellikle tek cümleye indirgenir: "bir önbellek eklentisi kurun ve CSS/JS optimizasyonunu açın". O kutuyu işaretleyip siteye baktığınızda ise tasarım dağılmış, menü açılmıyor, slider kaybolmuş olabilir. Sonra kutu geri kapatılır ve uyarı hayatının sonuna kadar raporda kalır.
Bu yazı o döngüyü kırmak için yazıldı. Sırayla şunları yapacağız: uyarının teknik olarak ne anlama geldiğini kuracağız, hangi dosyanın gerçekten kritik olduğunu Chrome'un Coverage aracıyla ölçeceğiz, defer ile async arasındaki farkı somut örnekle ayıracağız, CSS'i güvenli biçimde ertelemenin media yöntemini göstereceğiz, kritik CSS'i çıkarıp yerleştireceğiz, WordPress'te bunu hem eklentisiz hem eklentiyle nasıl uygulayacağınızı anlatacağız ve en önemlisi — yanlış erteleme yüzünden bozulan tasarımı nasıl teşhis edeceğinizi adım adım vereceğiz. Neyi ertelememeniz gerektiğine ayrı bir bölüm ayırdım, çünkü asıl hasar orada oluşuyor.
Render Engelleyen Kaynak Ne Demek#
Render engelleyen kaynak, tarayıcının sayfanın ilk pikselini çizmeden önce indirmek ve işlemek zorunda kaldığı dosyadır. İki tür vardır ve nedenleri farklıdır.
CSS varsayılan olarak render engeller. Tarayıcı, stil dosyalarının tamamını indirip birleştirmeden hiçbir şey çizmez. Bunun sebebi mantıklıdır: yarım stille çizim yapsa sayfa önce çıplak görünür, sonra birdenbire biçimlenir; buna "stilsiz içerik parlaması" denir ve kullanıcı deneyimi açısından beklemekten daha kötüdür.
JavaScript ise HTML ayrıştırmasını durdurur. <head> içinde <script src="..."> gördüğünde tarayıcı HTML okumayı durdurur, dosyayı indirir, çalıştırır, sonra kaldığı yerden devam eder. Sebebi yine tarihseldir: betik document.write() ile HTML'e müdahale edebilir, dolayısıyla tarayıcı ne olacağını bilmeden devam edemez.
Zinciri görselleştirelim. Şöyle bir <head> düşünün:
<head>
<link rel="stylesheet" href="/tema.css"> <!-- 180 KB -->
<link rel="stylesheet" href="/eklenti-a.css"> <!-- 40 KB -->
<link rel="stylesheet" href="/ikon-seti.css"> <!-- 90 KB -->
<script src="/jquery.js"></script> <!-- 90 KB -->
<script src="/slider.js"></script> <!-- 60 KB -->
</head>
Bu sayfanın ilk pikseli çizilmeden önce 460 KB indirilmesi ve çalıştırılması gerekir. Mobil bağlantıda bu, saniyeler demektir ve doğrudan ilk içerikli boyama ile en büyük içerikli boyama metriklerine yansır. LCP tarafındaki etkinin ayrıntısı için lcp nasıl iyileştirilir yazısına bakabilirsiniz.
Uyarının çözümü bu 460 KB'yi silmek değil — çizim başlamadan önce indirilmesi zorunlu olan kısmı ayırmak, geri kalanını çizimden sonraya bırakmaktır.
Hangi Dosyanın Gerçekten Kritik Olduğunu Bulma#
Bu, atlanan en önemli adımdır. Hangi CSS kurallarının ilk ekran için gerçekten gerektiğini tahminle değil ölçerek bulun. Chrome'un Coverage (Kapsam) aracı tam olarak bunun içindir.
Adımlar:
- Chrome'da sayfayı açın,
F12ile geliştirici araçlarını açın. Ctrl + Shift + Pile komut kutusunu açın, "Coverage" yazıp Show Coverage seçin.- Alt panelde yenile simgesine (⟳) basın; sayfa yeniden yüklenir ve kayıt başlar.
- Sayfayı kaydırmadan, hiçbir menüye tıklamadan bekleyin.
- Listede her dosyanın yanında kullanılan/kullanılmayan bayt oranı çıkar.
Tipik bir sonuç şöyle görünür:
| Dosya | Toplam | Kullanılmayan | Yorum |
|---|---|---|---|
tema.css | 184 KB | %78 | Sadece ilk ekran kuralları kritik |
ikon-seti.css | 92 KB | %96 | İlk ekranda 3 ikon var, gerisi gereksiz |
eklenti-iletisim.css | 24 KB | %100 | Sayfada form yok, hiç yüklenmemeli |
jquery.js | 89 KB | %71 | Menü için gerekli ama çizimden sonra da olur |
slider.js | 58 KB | %12 | İlk ekranda slider var, dikkatli davranın |
Bu tablodan çıkan üç karar nettir: eklenti-iletisim.css bu sayfada hiç yüklenmemeli (koşullu yükleme), ikon-seti.css ertelenebilir, slider.js ise ilk ekranda görünen bir öğeyi çizdiği için ertelenirse görsel boşluk oluşur.
Kullanılmayan yüzdesi yüksek dosyaların kaynağını bulmak ayrı bir iştir. Bir WordPress sitesinde bu dosyaların çoğu eklentilerden gelir; hangisinin ne yüklediğini ayıklamak için hangi eklenti siteyi yavaşlatıyor yazısındaki tek tek devre dışı bırakma yöntemi en güvenilir yoldur.
defer ile async Arasındaki Fark#
İkisi de betiğin HTML ayrıştırmasını durdurmasını engeller ama çalıştırma zamanları ve sıra garantileri farklıdır. Bu farkı bilmemek, sitesi bozulan insanların çoğunun asıl sorunudur.
| Özellik | Normal <script> | async | defer |
|---|---|---|---|
| HTML ayrıştırması durur mu | Evet | Hayır (indirme sırasında) | Hayır |
| Ne zaman çalışır | Hemen | İndirme biter bitmez | HTML tamamen ayrıştırılınca |
| Dosya sırası korunur mu | Evet | Hayır — önce inen önce çalışır | Evet |
| DOM hazır mı | Hayır | Belki | Evet |
| Uygun kullanım | Neredeyse hiç | Bağımsız betikler | Sayfa betiklerinin geneli |
Somut örnek üzerinden gidelim. Şu sıralamayı düşünün:
<script async src="/jquery.js"></script>
<script async src="/menu-eklentisi.js"></script>
menu-eklentisi.js küçük olduğu için jQuery'den önce inebilir ve $ is not defined hatasıyla çöker. Aynı dosyalar defer ile yazılsaydı sıra garanti altında olurdu:
<script defer src="/jquery.js"></script>
<script defer src="/menu-eklentisi.js"></script>
Pratik kural: Birbirine bağımlı betiklerin tamamında defer kullanın. async'i yalnızca hiçbir şeye bağımlı olmayan, hiçbir şeyin ona bağımlı olmadığı bağımsız betiklerde (analitik, hata izleme gibi) kullanın.
Bir de sık yapılan bir hata var: defer ve async, satır içi betiklerde çalışmaz. Yani şu kod bir işe yaramaz ve betik yine ayrıştırmayı durdurur:
<!-- Bu nitelikler burada YOK SAYILIR -->
<script defer>
console.log("bu hemen çalışır");
</script>
Satır içi betiği ertelemek istiyorsanız ya harici dosyaya taşıyın ya da DOMContentLoaded olayına bağlayın.
CSS Nasıl Ertelenir#
CSS'te defer niteliği yoktur. Ertelemek için media niteliğinin bir özelliği kullanılır: tarayıcı, o an geçerli olmayan bir media sorgusuna sahip stil dosyasını düşük öncelikle indirir ve render engellemez.
<!-- Kritik olmayan CSS: önce eşleşmeyen media, yüklenince gerçeğine dön -->
<link rel="stylesheet" href="/ikon-seti.css" media="print" onload="this.media='all'">
<noscript><link rel="stylesheet" href="/ikon-seti.css"></noscript>
Burada olan şu: tarayıcı media="print" gördüğü için dosyayı ekran çizimi için gerekli saymaz, engellemeden indirir. İndirme bitince onload tetiklenir ve media değeri all yapılır; stil o anda uygulanır. <noscript> satırı, JavaScript kapalı ziyaretçiler için yedektir.
Daha modern ve okunaklı alternatif preload ile aynı işi yapar:
<link rel="preload" href="/ikon-seti.css" as="style" onload="this.rel='stylesheet'">
Her iki yöntemde de dikkat edilecek nokta aynıdır: ertelenen CSS ilk ekranda görünen hiçbir öğeyi biçimlendirmemelidir. Aksi hâlde sayfa önce biçimsiz çizilir, sonra stil gelince yeniden düzenlenir — bu da düzen kayması demektir ve metriği doğrudan bozar. Konunun tamamı için cls düzen kayması nasıl düzeltilir yazısındaki ölçüm yöntemi işinize yarar.
Kritik CSS Çıkarma ve Yerleştirme#
Kritik CSS, ilk ekranı doğru çizmek için gereken en küçük kural kümesidir. Ana stil dosyasını ertelerken bu kümeyi HTML'in içine gömersiniz; böylece tarayıcı hiçbir dosya beklemeden ilk ekranı doğru çizer.
Hedef yapı şudur:
<head>
<style>
/* Kritik CSS — genellikle 8-14 KB arası, satır içi */
:root{--ana:#1a3a6b}
body{margin:0;font-family:system-ui,sans-serif;color:#111}
.ust-bar{height:64px;background:var(--ana);display:flex;align-items:center}
.hero{min-height:420px;display:flex;align-items:center;padding:0 24px}
.hero h1{font-size:2.25rem;line-height:1.2;margin:0 0 12px}
</style>
<link rel="preload" href="/tema.css" as="style" onload="this.rel='stylesheet'">
<noscript><link rel="stylesheet" href="/tema.css"></noscript>
</head>
Kritik CSS'i elle çıkarmak için pratik yöntem:
- Coverage panelinde ana stil dosyasını açın; kullanılan satırlar yeşil işaretlidir.
- Tarayıcı penceresini mobil ölçüye (örneğin 390×844) ayarlayın ve sayfayı kaydırmadan kaydı alın.
- Yeşil kuralları kopyalayıp bir
kritik.cssdosyasında toplayın. @font-face, CSS değişkenleri (:root) ve sıfırlama (reset) kurallarını mutlaka dahil edin — Coverage bunları bazen kullanılmamış gösterir ama olmazsa tüm düzen kayar.- Sonucu 14 KB civarında tutmaya çalışın; büyürse HTML'in kendisi ağırlaşır ve kazanç tersine döner.
Bu kümeyi doğru çıkardığınızı anlamanın en hızlı yolu: geliştirici araçlarında ağı yavaşlatıp ana CSS dosyasını engelleyin (Network → dosyaya sağ tık → Block request URL) ve sayfayı yenileyin. İlk ekran doğru görünüyorsa kritik CSS tamamdır; menü kaymışsa veya yazı tipi bozuksa eksik kural vardır.
WordPress'te Uygulama#
WordPress'te betikler ve stiller wp_enqueue_script / wp_enqueue_style ile kuyruğa alınır, dolayısıyla müdahale de oradan yapılır.
Tüm betiklere defer eklemek (jQuery hariç):
<?php
// child tema functions.php dosyasına
add_filter( 'script_loader_tag', function ( $tag, $handle ) {
// Bu listedeki betiklere DOKUNMA
$haric = array( 'jquery-core', 'jquery-migrate' );
if ( in_array( $handle, $haric, true ) ) {
return $tag;
}
if ( is_admin() ) {
return $tag;
}
if ( false !== strpos( $tag, ' defer' ) || false !== strpos( $tag, ' async' ) ) {
return $tag;
}
return str_replace( ' src=', ' defer src=', $tag );
}, 10, 2 );
Bu kodu child temaya yazın; ana temanın functions.php dosyasına yazarsanız ilk tema güncellemesinde silinir ve site sessizce eski davranışına döner. Ek CSS eklemek gerektiğinde de doğru yeri seçmek için wordpress custom css yazısındaki seçeneklere bakın.
Sayfada gerekmeyen stilleri hiç yüklememek:
<?php
add_action( 'wp_enqueue_scripts', function () {
// İletişim formu eklentisinin stilini yalnızca iletişim sayfasında yükle
if ( ! is_page( 'iletisim' ) ) {
wp_dequeue_style( 'contact-form-stil-handle' );
wp_dequeue_script( 'contact-form-script-handle' );
}
}, 100 );
Doğru handle adını bulmak için sayfa kaynağındaki <link id="...-css"> niteliğine bakın; -css ekinden önceki kısım handle'dır. Öncelik değerini 100 yapmak önemlidir, aksi hâlde eklenti kendi stilini sizden sonra kuyruğa alır ve dequeue işe yaramaz.
Eklentiyle yapmak. Önbellek eklentilerinin "CSS/JS Optimize" bölümleri aynı işi arayüzden yapar. Kullanacaksanız sırayı şöyle kurun: önce sadece JS ertelemeyi açın, siteyi baştan sona test edin; sorun yoksa CSS ertelemeyi açın, tekrar test edin; en son kritik CSS üretimini açın. Üçünü aynı anda açıp "hangisi bozdu" diye aramak saatlerinizi alır. Her adımdan sonra önbelleği temizlemeyi ve gizli pencerede test etmeyi unutmayın; kendi tarayıcınızın önbelleği size eski hâli gösterebilir.
Erteleme Sonrası Bozulan Tasarımı Teşhis Etme#
Buraya kadar her şey kitabi. Asıl mesele, kutuyu işaretledikten sonra bozulan sitede sorunun hangi dosyadan kaynaklandığını bulmaktır. Şu sırayı izleyin:
1. Konsolu açın ve hata metnini okuyun. F12 → Console. En sık görülen üç hata ve anlamları:
| Konsol hatası | Anlamı | Çözüm |
|---|---|---|
$ is not defined veya jQuery is not defined | jQuery, ona bağımlı betikten sonra çalıştı | jQuery'yi erteleme listesinden çıkarın veya async yerine defer kullanın |
Cannot read properties of null (reading 'addEventListener') | Betik, DOM'da henüz olmayan bir öğeyi arıyor | O betiği defer ile çalıştırın, async'ten çıkarın |
Uncaught SyntaxError: Unexpected token | Birleştirme sırasında dosyalar bozulmuş | Birleştirme (combine) özelliğini kapatın, sadece erteleme bırakın |
2. Ertelemeyi tek dosya için geri alın. Eklenti kullanıyorsanız çoğunun "hariç tutulacak dosyalar" alanı vardır. Şüpheli dosyayı oraya ekleyip test edin. Eklenti kullanmıyorsanız yukarıdaki PHP filtresindeki $haric dizisine handle'ı ekleyin.
3. Bozulmanın türüne göre daralt. Belirti, sorunun sınıfını doğrudan söyler:
- Sayfa çıplak açılıyor, sonra biçimleniyor: Kritik CSS eksik veya yanlış çıkarılmış. Ana CSS'i ertelemeyi kapatın, kritik kümeyi genişletin.
- Menü tıklanmıyor, açılır kapanmıyor: Menü betiği ya hiç çalışmıyor ya sıra bozulmuş. Konsolda hata var mı bakın; yoksa betik
asyncile bağımlılığından önce çalışmıştır. - Slider görünmüyor veya üst üste biniyor: Slider betiği ertelenmiş ama ilk ekranda. Slider dosyalarını erteleme dışında bırakın.
- İkonlar kare veya boş görünüyor: İkon fontunun CSS'i ertelenmiş; ya kritik kümeye ikon
@font-facekuralını ekleyin ya o dosyayı hariç tutun. - Site tamamen beyaz: Erteleme değil, PHP tarafında bir hata olması muhtemel. Bu durumda wordpress kritik hata oluştu yazısındaki hata ayıklama adımlarına geçin;
functions.phpdüzenlemesi sırasında kalan bir sözdizimi hatası en yaygın nedendir.
4. Farkı ölçün, hissetmeyin. Her değişiklikten sonra tarayıcının Performance panelinde kayıt alın ve First Contentful Paint ile Largest Contentful Paint işaretlerini karşılaştırın. Rapor skorundan çok bu iki değerin milisaniyesi anlam taşır; skor, ağırlıklandırılmış bir özet olduğu için tek bir metrikteki iyileşmeyi bazen hiç yansıtmaz.
Yazı Tipleri de Render Engelleyebilir#
Uyarı listesinde CSS ve JS yanında bazen yazı tipi dosyaları da görürsünüz. Web fontları doğrudan render engellemez ama metnin görünmesini geciktirir: tarayıcı font inene kadar metni çizmeyi bekleyebilir, buna "görünmez metin parlaması" denir.
Çözüm iki satırdır:
@font-face {
font-family: 'SiteFontu';
src: url('/fontlar/site.woff2') format('woff2');
font-display: swap; /* Font gelene kadar sistem fontuyla çiz */
font-weight: 400;
font-style: normal;
}
font-display: swap metni hemen yedek fontla çizer, asıl font gelince değiştirir. Bu değişim küçük bir kayma üretir; kaymayı azaltmak için yedek fontu benzer ölçülü seçin ve font dosyasını önceden yükleyin:
<link rel="preload" href="/fontlar/site.woff2" as="font" type="font/woff2" crossorigin>
crossorigin niteliği burada zorunludur; unutulursa tarayıcı dosyayı iki kez indirir.
Neyi Ertelemeyin#
Burası çoğu felaketin çıktığı yer. Şu beş grup dosyaya dokunmayın:
- Kritik CSS'in kendisi. Satır içi gömülü stil zaten dosya değildir, ertelenemez ve ertelenmemelidir.
- İlk ekranda görünen bir öğeyi çizen betikler. Slider, üst menünün sabitlenmesi, çerez bandı yerleşimi gibi. Bunlar ertelenirse sayfa iki aşamada çizilir ve kullanıcı sıçrama görür.
- jQuery ve benzeri temel kütüphaneler
asyncile.deferuygundur,asyncsıra garantisi vermediği için değildir. - Ödeme ve form doğrulama betikleri. Bir e-ticaret sitesinde ödeme sağlayıcısının betiğini ertelemek, ödeme formunun geç açılmasına ve terk edilen sepete yol açar. Kazandığınız 100 milisaniye, kaybettiğiniz siparişe değmez.
- Yapılandırma tanımlayan satır içi betikler.
var ayarlar = {...}gibi bloklar, kendisini kullanan dosyadan önce çalışmalıdır; onları harici dosyaya taşırken sırayı bozmayın.
Ayrıca birleştirme (concatenate) ile ertelemeyi karıştırmayın. Birleştirme, çok sayıda dosyayı tek dosyada toplar; HTTP/2 ve üzeri bağlantılarda kazancı sınırlıdır, buna karşılık bir dosyadaki sözdizimi hatası tüm paketi düşürür. Uyarıyı çözmek için birleştirmeye ihtiyacınız yok; erteleme ve kritik CSS yeterlidir.
Sıkça Sorulan Sorular#
Render engelleyen kaynakları ortadan kaldırın uyarısı tam olarak ne demek#
Bu uyarı, tarayıcının sayfanın ilk pikselini çizebilmek için önce indirip işlemesi gereken CSS ve JavaScript dosyaları olduğunu söyler. CSS varsayılan olarak çizimi bekletir çünkü tarayıcı yarım stille sayfa göstermek istemez; <head> içindeki betikler ise HTML okumasını tamamen durdurur. Uyarının yanındaki milisaniye değeri, o dosyayı çizim yolundan çıkarırsanız kazanacağınız tahmini süredir. Çözüm dosyaları silmek değil, ilk ekran için gerekli olan küçük kısmı ayırıp geri kalanını çizimden sonraya bırakmaktır.
defer mi async mi kullanmalıyım#
Neredeyse her durumda defer kullanın. defer, betikleri HTML'de yazıldıkları sırayla ve DOM hazır olduktan sonra çalıştırır; bu yüzden birbirine bağımlı dosyalarda güvenlidir. async ise indirme biter bitmez çalıştırır ve sıra garantisi vermez, dolayısıyla jQuery'ye bağımlı bir eklenti betiği jQuery'den önce çalışıp $ is not defined hatası verebilir. async'i yalnızca hiçbir şeye bağımlı olmayan ve hiçbir şeyin kendisine bağımlı olmadığı bağımsız betiklerde tercih edin.
CSS dosyasına defer eklenebilir mi#
Hayır, defer niteliği yalnızca <script> etiketinde geçerlidir. CSS'i ertelemek için media="print" onload="this.media='all'" kalıbı ya da rel="preload" as="style" onload="this.rel='stylesheet'" yöntemi kullanılır; ikisi de tarayıcının dosyayı render engellemeden indirmesini sağlar. Her iki durumda da JavaScript kapalı ziyaretçiler için <noscript> içinde normal bir <link> yedeği bırakmayı unutmayın. Ertelenen dosyanın ilk ekranda görünen hiçbir öğeyi biçimlendirmediğinden emin olun.
Erteleme sonrası menüm çalışmıyor ne yapmalıyım#
Önce tarayıcı konsolunu açıp hata metnini okuyun. $ is not defined veya jQuery is not defined görüyorsanız sıra bozulmuştur; menü betiği jQuery'den önce çalışmıştır ve çözüm async yerine defer kullanmak ya da jQuery'yi erteleme listesinden çıkarmaktır. Cannot read properties of null hatası ise betiğin DOM'da henüz var olmayan bir öğeyi aradığını gösterir; o betiği defer ile çalıştırmak sorunu çözer. Konsolda hiç hata yoksa ve menü yine çalışmıyorsa büyük ihtimalle menünün stilini taşıyan CSS ertelenmiştir.
Kritik CSS ne kadar büyük olmalı#
Pratik hedef 14 KB civarı, üst sınır olarak 20 KB düşünülebilir. Kritik CSS HTML'in içine gömüldüğü için her sayfa isteğinde yeniden indirilir ve önbelleklenmez; büyüdükçe HTML belgesi ağırlaşır ve kazanç tersine döner. İçine yalnızca ilk ekranda görünen öğelerin kuralları, CSS değişkenleri, sıfırlama kuralları ve @font-face tanımları girmelidir. Doğru çıkarıp çıkarmadığınızı test etmek için geliştirici araçlarında ana CSS dosyasını engelleyip sayfayı yenileyin; ilk ekran düzgün görünüyorsa küme yeterlidir.
Önbellek eklentisinin optimize kutusunu açmam yeterli değil mi#
Çoğu zaman yeterli değildir ve bazen zararlıdır. O kutular erteleme, birleştirme ve kritik CSS üretimini aynı anda devreye sokar; bir şey bozulduğunda hangisinin sebep olduğunu ayırt edemezsiniz. Doğru yöntem üç özelliği sırayla açmak, her adımda siteyi baştan sona gezerek test etmektir: önce JS erteleme, sonra CSS erteleme, en son kritik CSS. Ayrıca birleştirme özelliği modern bağlantılarda kayda değer kazanç sağlamazken tek bir bozuk dosyanın tüm paketi düşürmesine yol açar; uyarıyı çözmek için ona ihtiyacınız yoktur.
Yazı tipi dosyaları da render engeller mi#
Doğrudan çizimi engellemezler ama metnin görünmesini geciktirebilirler. Tarayıcı, web fontu inene kadar metni çizmeyi bekleyebilir ve kullanıcı boş bir alan görür. Çözüm @font-face bloğuna font-display: swap eklemektir; bu, metnin hemen sistem fontuyla çizilmesini, asıl font geldiğinde değiştirilmesini sağlar. Değişim sırasındaki kaymayı azaltmak için font dosyasını rel="preload" as="font" crossorigin ile önceden yükleyin — crossorigin niteliği unutulursa dosya iki kez indirilir.
Erteleme yaptım ama PageSpeed skoru değişmedi neden#
En yaygın sebep, uyarıya konu dosyaların üçüncü taraf betikler olmasıdır; kendi dosyalarınızı ertelemeniz reklam, sohbet veya analitik betiklerinin ürettiği engeli kaldırmaz. İkinci sebep, ertelenen dosyaların zaten kritik yolda olmamasıdır — asıl darboğaz sunucu yanıt süresi veya en büyük görselin boyutu olabilir. Rapordaki "Tahmini tasarruf" değerinin milisaniyesine bakın; on-yirmi milisaniyelik kalemler skoru kayda değer biçimde değiştirmez. Ölçümü tek bir rapor skoruyla değil, Performance panelindeki ilk içerikli boyama ve en büyük içerikli boyama değerleriyle yapın.
Kapanış#
"Render engelleyen kaynakları ortadan kaldırın" uyarısının çözümü bir kutuyu işaretlemek değil, sıralı bir karar zinciridir: önce Coverage aracıyla hangi dosyanın gerçekten kritik olduğunu ölçün, sonra bağımlı betiklere defer verin ve async'i yalnızca bağımsız olanlara saklayın, kritik olmayan CSS'i media veya preload kalıbıyla erteleyin, ilk ekranın kurallarını 14 KB civarında bir kritik kümede satır içine gömün, yazı tiplerine font-display: swap ekleyin ve ilk ekranda görünen hiçbir şeyi ertelemeyin. Bir şey bozulduğunda ise konsoldaki hata metni sizi doğrudan sebebe götürür; belirtiyi tahmin etmek yerine hatayı okuyun ve ertelemeyi tek dosya için geri alarak daraltın.
Bu iş bir kere yapılıp bitmiyor: her yeni eklenti kendi CSS ve JS dosyasını kuyruğa ekler, her tema güncellemesi kritik CSS'inizi bayatlatabilir. Düzenli olarak kontrol edilmesini istiyorsanız Clou.TR'nin WordPress bakım hizmeti güncelleme sonrası performans kontrollerini de kapsar. Sunucu yanıt süresi ertelemeden daha büyük bir darboğaz hâline geldiyse WordPress hosting paketleri önbellek ve PHP tarafını hazır yapılandırmayla sunar. Ölçekli bir sitede kritik CSS üretimini ve varlık boru hattını kendiniz kurmak istiyorsanız VDS sunucu tarafında tam yapılandırma erişimi bulursunuz.