Inline Kritik CSS ve Kritik Render Yolu Rehberi

Bir sayfayı açtığınızda geçen ilk saniyede ekran boştur ama tarayıcı boş durmaz. HTML yanıtı gelir gelmez ayrıştırmaya başlar, karşılaştığı her stil dosyası bağlantısında durur ve o dosyayı indirip işleyene kadar tek bir piksel çizmez. Bu bekleme bir arıza değil, tasarımın kendisidir: tarayıcı ekrana stilsiz bir sayfa basıp saniyeler sonra düzeltmek yerine hazır olmayı bekler.

Beyaz ekranın ne kadar süreceğini belirleyen şey de burada saklıdır. Sayfanın ilk görüntüsü CSS'in ne kadar sürede geldiğine, metnin hangi fontu beklediğine ve ilk ekrandaki görselin ne zaman keşfedildiğine bağlıdır. Bu üçü ayrı ayrı konular gibi görünür ama hepsi aynı zincire bağlanır. O zincirin adı kritik render yoludur ve bu rehber üç halkasını da tek yerde ele alıyor.

Kritik Render Yolu Nedir ve Neyi Engeller

Kritik render yolu, tarayıcının sunucudan gelen ham HTML'i ekranda görünen piksellere dönüştürürken izlediği zorunlu adımlar dizisidir. HTML ayrıştırılarak DOM'a, CSS ayrıştırılarak CSSOM'a çevrilir. Tarayıcı ekrana bir şey çizebilmek için render ağacına ihtiyaç duyar ve render ağacı bu ikisinin birleşiminden doğar. Yani DOM tek başına yeterli değildir.

Sonuç şudur: CSS varsayılan olarak render engelleyici bir kaynaktır ve tarayıcı CSSOM kurulana kadar işlediği içeriğin hiçbirini ekrana çizmez. HTML'in engelleyici olması sezgiseldir, çünkü DOM olmadan çizilecek bir şey yoktur. CSS'in engelleyici olması ise daha az sezgiseldir. Tarayıcı bunu, kullanıcıya bir anlığına stilsiz sayfa gösterip hemen ardından düzenli haline geçmemek için yapar. Stilsiz içeriğin ekranda parlayıp kaybolduğu bu duruma FOUC adı verilir ve tarayıcılar bunu bilinçli olarak engeller.

Buradan çıkan pratik sonuç, çoğu hız yazısında atlanan bir ayrımdır. Bir stil dosyasını render engelleyici olmaktan çıkarmak, onu indirilmemiş hale getirmez. media özniteliği yalnızca engelleme davranışını değiştirir; tarayıcı engelleyici olsun olmasın tüm CSS kaynaklarını indirir.

<!-- Ekranda render'ı engeller -->
<link rel="stylesheet" href="/main.css">

<!-- Ekranda render'ı engellemez ama yine de indirilir -->
<link rel="stylesheet" href="/print.css" media="print">

Bu ayrım önemlidir çünkü bant genişliği kazanmakla ilk boyamayı hızlandırmak farklı problemlerdir. media ile oynamak ikincisini çözer, birincisini çözmez. Bant genişliği tarafı için gerçek çözüm dosyayı küçültmektir; bu konuyu kullanılmayan CSS ve JS temizliği rehberinde ayrıntılı işledik.

Kritik CSS'i Inline Etmek Ne Zaman Gerçekten İşe Yarar

Kritik CSS, sayfanın yalnızca ilk ekranında görünen içeriği doğru biçimde çizmeye yeten CSS alt kümesidir. Inline yüklemek ise bu alt kümeyi harici bir dosyadan çağırmak yerine doğrudan HTML'in içine bir style bloğu olarak koymak demektir. Amaç ek bir ağ isteğini tamamen ortadan kaldırmaktır: HTML geldiğinde ilk ekranın stilleri de gelmiş olur.

Bu teknik dar bir koşulda gerçekten değerlidir. Stil dosyanız, sayfanın en büyük içerik elemanını oluşturan kaynaktan belirgin biçimde daha geç yükleniyorsa, o eleman kendi indirmesini bitirse bile ekrana çizilemez. Ağ şelalesine baktığınızda görsel hazır olduğu halde sayfanın hâlâ boş beklediğini görürsünüz. İşte bu tabloda stil dosyasını HTML'in içine almak, beklemeyi doğrudan kaldırır.

Aynı ölçüde önemli olan, tekniğin ne zaman değmediğidir. Inline edilen içerik HTML'in parçası olduğu için sonraki sayfa yüklemelerinde önbellekten faydalanamaz. Harici bir CSS dosyası bir kez indirilip ziyaretçinin gezindiği tüm sayfalarda yeniden kullanılırken, inline blok her HTML yanıtında baştan aktarılır. Dolayısıyla inline etmek yalnızca küçük stil setleri için önerilir. Stil dosyanız LCP kaynağından daha uzun sürede yüklenecek kadar büyükse, o dosya zaten iyi bir inline adayı değildir.

Google'ın kendi dokümantasyonu bu tekniği ileri seviye bir performans yöntemi olarak tanımlar ve doğru uygulanmadığında hata üretebileceğini açıkça söyler. Aynı kaynak, çoğu sitenin önerilen performans hedeflerine bu tekniği hiç uygulamadan ulaşabileceğini belirtir. Bu, tekniği küçümseyen bir uyarı değil, sıralamayla ilgili bir uyarıdır: kritik CSS listenin sonundaki adımdır, başındaki değil.

Çoğu durumda daha sağlıklı hamle, stil dosyasını LCP kaynağından küçük olacak kadar inceltmektir. Böylece dosya hiçbir ziyaretçi için darboğaz olmaz ve önbellek avantajı da korunur.

Yine de inline yoluna gidilecekse yaygın kalıp şudur:

<head>
  <style>/* yalnızca ilk ekranı çizen kurallar */</style>

  <!-- kalan CSS render'ı engellemeden yüklenir -->
  <link rel="stylesheet" href="/main.css"
        media="print" onload="this.media='all'">
  <noscript><link rel="stylesheet" href="/main.css"></noscript>
</head>

Buradaki media="print" hilesi, dosyanın render'ı engellemeden indirilmesini sağlar; yükleme bitince media değeri değiştirilerek stiller devreye girer. JavaScript devre dışıysa sayfanın stilsiz kalmaması için noscript yedeği zorunludur.

Kritik CSS'in Görünmeyen Bakım Maliyeti

Kritik CSS'in asıl bedeli ilk kurulumda değil, sonrasında ödenir. Bunu baştan kabul etmek, altı ay sonra bozuk bir sayfayla uğraşmaktan iyidir.

İlk sorun sınırın kendisidir. Ekran üstü dediğimiz alanın evrensel bir piksel yüksekliği yoktur, çünkü cihaz ve ekran çeşitliliği sınırsıza yakındır. Masaüstünde ekran üstü sayılan bir bölüm dar bir telefonda kaydırma gerektirir. Dolayısıyla çıkarılan kritik set her zaman bir tahmindir ve tahmin dar tutulursa ilk ekranda bozuk görüntü, geniş tutulursa inline bloğun şişmesi ortaya çıkar.

İkinci sorun çoğalmadır. Ana sayfa, kategori, ürün ve makale şablonlarının ilk ekranları birbirinden farklıdır. Tek bir kritik set hepsine uymaz, bu da şablon başına ayrı çıkarım ve ayrı doğrulama demektir.

Üçüncüsü ve en sinsisi bayatlamadır. Tasarımda yapılan her değişiklik çıkarılmış kritik seti geçersiz kılar. Bu çıkarım derleme sürecine bağlanmadıysa kimse fark etmeden eskir ve sayfa, bugünkü tasarımına ait olmayan stillerle çizilmeye başlar. Critical ve Penthouse gibi açık kaynak araçlar çıkarımı otomatikleştirir ve bazıları font tanımlarının dahil edilmesi üzerinde ayrıntılı kontrol verir, ancak hiçbiri sonucun görsel doğrulamasını sizin yerinize yapmaz.

Metin Neden Geç Görünür: Block Period ve Swap Period

CSS hazır olduğunda hikâye bitmez. Sayfanın en büyük elemanı bir metin bloğuysa, o metnin çizilmesi web fontunun durumuna bağlıdır ve tarayıcının burada iki farklı davranışı vardır.

FOIT, tarayıcının web fontu inene kadar metni tamamen görünmez tutmasıdır. Düzen oluşur, kutular yerine oturur ama yazı alanları boştur. FOUT ise tarayıcının önce sistem fontuyla metni göstermesi, font geldiğinde ona geçmesidir. Kullanıcı metni anında görür, karşılığında anlık bir görsel değişim yaşar.

Bu davranışı yöneten şey font-display tanımlayıcısıdır ve iki süre üzerinden çalışır. Block period, tarayıcının fontu istediği anda başlar; bu süre boyunca font yoksa metin görünmez bir yedekle çizilir, yani kullanıcı yazıyı göremez. Swap period block period'dan sonra gelir; web fontu bu aralıkta hazır olursa devreye alınır.

Tanım yazılmadığında auto geçerli olur ve strateji tarayıcının insafına kalır. Metin tabanlı bir LCP elemanı olan sayfada bu, ölçülemeyen bir gecikme kaynağıdır.

swap Değerinin Sessiz Yan Etkisi

Yaygın tavsiye font-display: swap yönündedir ve ilk boyama açısından mantıklıdır: block period sıfıra yakındır, metin hemen görünür, LCP sayacı font indirmesini beklemez. Ancak swap'ın swap period'u sınırsızdır. Bu, web fontunun çok geç gelmesi durumunda bile takas edileceği anlamına gelir. Kazanç ile risk aynı özellikten doğar.

Risk şudur: yedek font ile web fontunun karakter genişlikleri ve satır yükseklikleri farklıdır. Takas gerçekleştiğinde metin bloğunun kapladığı alan değişir ve altındaki içerik yerinden oynar. Kullanıcı okumaya başladıktan sonra gerçekleşen bu kayma, düzen kaymasını ölçen metriğe doğrudan yazılır. Yani metin görünürlüğü için kazandığınızı düzen kararlılığından kaybedebilirsiniz.

Bunu çözmenin yolu takası engellemek değil, takası görünmez kılmaktır. CSS'in size-adjust, ascent-override, descent-override ve line-gap-override tanımlayıcıları yedek fontun metriklerini web fontununkine yaklaştırır. Yedek font neredeyse aynı alanı kapladığında takas anında kayacak bir şey kalmaz.

@font-face {
  font-family: "Govde";
  src: url("/fonts/govde.woff2") format("woff2");
  font-display: swap;
}

@font-face {
  font-family: "Govde Yedek";
  src: local("Arial");
  size-adjust: 100%;        /* fonta özgü hesaplanır */
  ascent-override: 100%;    /* fonta özgü hesaplanır */
  descent-override: 100%;   /* fonta özgü hesaplanır */
  line-gap-override: 0%;
}

body { font-family: "Govde", "Govde Yedek", sans-serif; }

Buradaki yüzdeler tabelaya bakıp yazılacak sabitler değildir; her font çiftine göre hesaplanır ve font metriklerini okuyan araçlarla üretilir. Başka bir yazıdan kopyalanan değerler çoğu zaman kaymayı azaltmak yerine artırır.

Kayma riskini tamamen ortadan kaldırmak isteyen sitelerin ikinci seçeneği optional değeridir. Swap period'u olmadığı için font zamanında hazır değilse o sayfa yüklemesinde hiç devreye girmez ve takas kaynaklı kayma imkânsız hale gelir. Bedeli, bazı ziyaretçilerin markanın tipografisini hiç görmemesidir. Tek bir doğru cevap yoktur; seçim, fontun marka için ne kadar önemli olduğuna ve geç gelen bir takasın ne kadar rahatsız edici olacağına bağlıdır.

Lazy Loading Nedir ve Ekran Üstü İstisnası Neden Var

Lazy loading, bir kaynağın yüklenmesini gerçekten ihtiyaç duyulacağı ana kadar ertelemektir. Tarayıcı düzeyinde bu, görsele loading="lazy" özniteliği eklenerek yapılır ve tarayıcı o görseli, görünüm alanına hesaplanmış bir mesafe kalana kadar indirmez. Karşıt değer olan eager, tarayıcının zaten varsayılan davranışıdır: görsel sayfanın neresinde olursa olsun yüklenir.

<!-- ilk ekranda görünen görseller -->
<img src="/urun-1.avif" alt="..." width="400" height="400">
<img src="/urun-2.avif" alt="..." width="400" height="400">

<!-- ekran dışındaki görseller -->
<img src="/urun-7.avif" alt="..." width="400" height="400" loading="lazy">
<img src="/urun-8.avif" alt="..." width="400" height="400" loading="lazy">

İstisnanın nedeni tekniğin çalışma biçiminde saklıdır. Tarayıcı bir görseli erteleyip ertelemeyeceğine, o görselin sayfada nerede duracağını bilmeden karar veremez. Yani loading="lazy" yazılan her görselin indirmesi, düzen hesabının ilerlemesini bekler. Ekran dışındaki bir görsel için bu bekleme bedavadır, çünkü kullanıcı oraya kaydırana kadar zaman vardır. İlk ekranda duran görsel içinse tam tersi geçerlidir: kazanılacak hiçbir şey yoktur, yalnızca kaybedilecek zaman vardır. Google'ın açık tavsiyesi, sayfa yüklendiğinde görünür olması muhtemel görsellere ve özellikle LCP görseline lazy-load uygulanmamasıdır.

JavaScript kütüphaneleriyle yapılan lazy loading aynı hatanın daha ağır halini üretir. Bu kütüphaneler görselin adresini src yerine data-src gibi bir öznitelikte sakladığı için tarayıcının ön yükleme tarayıcısı kaynağı HTML yanıtında hiç göremez. Kaynak, ancak script çalıştıktan sonra keşfedilir. Aynı görünmezlik sorunu CSS arka plan görselleri için de geçerlidir: bir background-image, stil dosyası işlenene kadar keşfedilemez.

Bu hatanın büyüklüğüne dair iki farklı türde kanıt var ve ikisini ayırmak gerekir. Birincisi ilişkiseldir: gerçek kullanıcı verisine dayanan geniş bir sayfa havuzunda, tarayıcı düzeyinde lazy loading kullanmayan medyan sayfanın 75. yüzdelik LCP değeri 2.922 ms iken, kullanan medyan sayfada 3.546 ms ölçülmüştür. Bu bir eğilimdir, özniteliğin farkı tek başına yarattığının kanıtı değildir; lazy loading kullanan siteler tipik olarak daha görsel yoğun sitelerdir. İkincisi nedenseldir ama kapsamı dardır: varsayılan lazy loading davranışının açık ve kapalı halleriyle koşulan kontrollü bir test, arşiv sayfasının masaüstü ölçümünde medyan LCP'yi kapalı durumda yaklaşık yüzde 13 daha iyi bulmuştur. İkisi birlikte okunduğunda tablo nettir: yanlış yerde uygulanan lazy-load ölçülebilir bir zarardır.

Buna karşılık doğru yerde uygulandığında teknik oldukça güvenlidir. Chrome'un Android üzerindeki denemelerinde 4G bağlantıda ertelenmiş görsellerin yüzde 97,5'i görünür olduktan sonraki 10 ms içinde tamamen yüklenmiştir; yavaş 2G'de bu oran yüzde 92,6'dır. Yani sorun tekniğin kendisinde değil, uygulandığı yerdedir.

LCP Görselini Doğru İşaretlemek

Ekran üstündeki en büyük görsel için hedef basittir: tarayıcı onu mümkün olan en erken anda keşfetsin ve mümkün olan en yüksek öncelikle indirsin. Üç işaret bunu birlikte sağlar.

<head>
  <link rel="preload" as="image" href="/hero.avif" fetchpriority="high">
</head>
<body>
  <img src="/hero.avif" alt="Ürün görseli"
       width="1200" height="675"
       loading="eager" fetchpriority="high">
</body>

loading="eager" zaten varsayılandır, ama açıkça yazmanın pratik bir değeri vardır: birçok içerik yönetim sistemi ve tema, değer belirtilmemiş her görsele otomatik olarak lazy ekler. Açık eager, bu otomatizmi devre dışı bırakır.

fetchpriority="high" ise kaynağın hesaplanmış önceliğini yükseltir. Bu özniteliğin etkisini gösteren belgelenmiş bir deneyde, büyük bir uçuş arama sayfasının hero görseline yüksek öncelik verilmesiyle LCP 2,6 saniyeden 1,9 saniyeye inmiştir. Tek bir sayfa üzerinde yapılmış bir ölçüm olduğu için bunu evrensel bir kazanç oranı değil, tekniğin yönü hakkında bir gösterge olarak okumak gerekir.

Görsel ön yüklemelerinin varsayılan önceliği düşük ya da ortadır. Bu yüzden yalnızca preload yazmak bir görseli acil hale getirmez; önceliği asıl yükselten fetchpriority ile eşleştirmedir. width ve height ise ayrı bir işi görür: tarayıcı yer ayırabilsin ve görsel indiğinde altındaki içerik zıplamasın diye gereklidir. Görselin kendi ağırlığını düşürmek de aynı yarışın parçasıdır; format seçiminin bu denklemdeki yerini WebP ve AVIF format kullanımı yazısında ele aldık.

Preload ve Preconnect'i Ölçülü Kullanmak

Bu iki ipucu güçlüdür ve tam da bu yüzden kolayca zarar verir. İkisi de tarayıcının doğal öncelik sırasına müdahale eder; gereksiz kullanıldıklarında önemli kaynakları geriye iterler.

preload, tarayıcının kendiliğinden geç keşfedeceği kaynaklar için vardır. Stil dosyasının içinde tanımlanmış fontlar, CSS arka plan görselleri ve script tarafından üretilen kaynaklar tipik örneklerdir. HTML'de zaten açıkça duran ve ön yükleme tarayıcısının ilk taramada gördüğü bir kaynağı preload etmek kazanç üretmez, yalnızca sıralamayı karıştırır. Yerleşim de önemlidir: font ön yüklemeleri genellikle head'in sonuna ya da body'nin başına konduğunda daha iyi çalışır, HTML'in en tepesine yığılan preload'lar daha kritik kaynakların önüne geçebilir.

preconnect yalnızca kendi kaynağınız dışındaki alan adları için anlamlıdır; kendi origin'inize preconnect yazmanın etkisi yoktur. Tarayıcı, 10 saniye içinde kullanılmayan bağlantıyı kapatır, dolayısıyla ihtimal üzerine açılan bağlantılar boşa gider. Fontlar anonim modda indirildiği için font sunan bir origin'e verilen ipucunda crossorigin zorunludur.

<link rel="preconnect" href="https://fonts.ornek.com" crossorigin>
<link rel="preload" as="font" type="font/woff2"
      href="/fonts/govde.woff2" crossorigin>

Pratik kural: preconnect listesini gerçekten ilk saniyede iş yapan üçüncü taraf origin'lerle sınırlayın, preload'u ise sayfa başına bir avuç kaynağın ötesine taşımayın.

Hangi Teknik Hangi Metriğe Dokunuyor

Bu tekniklerin karıştırılmasının başlıca nedeni, hepsinin "hız" başlığı altında toplanıp aynı şeyi yaptıklarının sanılmasıdır. Oysa LCP dört alt parçadan oluşur: sunucunun ilk baytı gönderme süresi, kaynağın keşfedilmesindeki gecikme, kaynağın indirilme süresi ve elemanın çizilmesindeki gecikme. Her teknik bu parçalardan yalnızca birine dokunur.

Tablodan çıkması gereken sonuç, tek bir parçayı kısaltmanın toplam süreyi kısaltacağının garanti olmadığıdır. Kaynak indirme süresini düşürdüğünüzde, eleman JavaScript bitene kadar gizli tutuluyorsa kazandığınız zaman doğrudan çizim gecikmesine kayar ve LCP değişmez. Bu yüzden ölçüm parça bazında değil bütün üzerinden yapılmalıdır; metriğin eşik ve okuma mantığını LCP süresini 2,5 saniyenin altına çekme rehberinde ayrıntılandırdık.

Uygulama Sırası

Bu rehberdeki tekniklerin tamamını aynı anda uygulamak gerekmez ve genelde gerekmemelidir. Ucuz ve geri dönüşü kesin olandan başlayıp pahalı ve kırılgan olana doğru ilerlemek, hem daha az risk hem daha net ölçüm üretir.

1. Ölçün. Hangi elemanın LCP olduğunu ve hangi kaynağın render'ı engellediğini bilmeden yapılan her müdahale tahmindir.
2. İlk ekrandaki görsellerden lazy-load'u kaldırın, tüm görsellere width ve height ekleyin. En düşük maliyetli ve en sık karşılaşılan kazanç budur.
3. Kullanılmayan CSS ve JS'i temizleyin. Stil dosyasını LCP kaynağından küçük tutmak, inline etmeye gerek bırakmayabilir.
4. Font stratejisini seçin. Metrik uyumlu yedekle swap ya da düzen kararlılığı öncelikliyse optional, ve fontu preload edin.
5. LCP görselini eager ve fetchpriority="high" ile işaretleyin, gerekiyorsa preload ekleyin.
6. İlk saniyede gerçekten iş yapan üçüncü taraf origin'ler için sınırlı sayıda preconnect tanımlayın.
7. Buraya rağmen çizim gecikmesi baskınsa kritik CSS'i inline edin ve çıkarımı derleme sürecine bağlayın.

Sıkça Sorulan Sorular

Kritik CSS'i elle yazabilir miyim?

Teknik olarak yazabilirsiniz ama sürdürülemez. Elle yazılan kritik set ilk tasarım değişikliğinde geçersiz olur ve bunu kimse fark etmez, çünkü sayfa açılmaya devam eder, yalnızca yanlış görünür. Çıkarımı derleme sürecine bağlayamıyorsanız bu adımı hiç uygulamamak daha güvenlidir.

Tüm CSS'i inline etsem daha mı hızlı olur?

Genelde hayır. Tüm stilleri HTML'e gömdüğünüzde ziyaretçinin gezdiği her sayfa aynı stilleri baştan indirir, çünkü inline içerik önbelleğe alınamaz. Büyük bir inline blok ayrıca HTML yanıtını şişirir ve ilk baytın işlenmesini geciktirir. Tek sayfalık kampanya sayfalarında savunulabilir, çok sayfalı sitelerde savunulamaz.

iframe'lere de lazy loading uygulanır mı?

Evet, loading="lazy" iframe elemanı için de standartlaşmıştır. Video gömüleri, haritalar ve sosyal medya kutuları genellikle ekranın çok altında durur ve ciddi miktarda kaynak yükler, bu yüzden en verimli lazy-load adaylarıdır.

font-display tanımlamazsam ne olur?

auto geçerli olur ve strateji tarayıcıya bırakılır. Block ve swap sürelerinin ne olacağı tarayıcıya göre değişir, dolayısıyla metnin ne kadar süre görünmez kalacağını öngöremezsiniz. Metin tabanlı LCP elemanı olan sayfalarda bu, kontrol edilmeyen bir değişkendir.

Ekran üstü sınırını nasıl belirlerim?

Sabit bir piksel değeri yoktur ve aramak yanlış sorudur. Pratik yaklaşım, dar bir mobil ekranda ilk görüntüde ne görünüyorsa onu ekran üstü kabul etmek ve o kümeyi eager bırakmaktır. Şüpheli durumda bir görseli fazladan eager bırakmanın maliyeti, LCP görselini yanlışlıkla ertelemenin maliyetinden çok daha düşüktür.