Tipik bir e-ticaret vitrininde LCP 3 saniyenin üzerine çıkabilir. Hero görseli zaten WebP, sunucu yanıtı 180 ms civarındadır; Lighthouse raporu kaynağı çoğu zaman başka yerde gösterir. LCP öğesi hero görseli değil, başlık metni olarak işaretlenmiştir. Font henüz yüklenmediği için tarayıcı metni boyayamaz, en büyük içerik alanını boş bırakır.

Bu durum alışılmıştan sık karşılaşılan bir senaryo. Tasarım sistemi özenle kurulmuş, animasyonlar CSS'e taşınmış, resimler sıkıştırılmış; ama font yüklemesi varsayılan ayarlarla çalışıyor. Varsayılan davranış font-display: block'tur: tarayıcı fontu bekler, gösteri yoktur. Kullanıcı metin yerine boşluk görür; LCP saati o boşlukla birlikte işlemeye başlar.

Font yüklemesini optimize etmek dört ayrı karardan oluşur: font-display değeri, preload etiketi, subset kırpması ve fallback font metrik uyumu. Bu kararların her biri tek başına kısmi etki yapar; birlikte uygulandığında LCP'ye olan etki toplamlı değil çarpımsal olur. Sıra bozulursa bir adım diğerinin kazancını yer.

LCP ile Font Arasındaki Bağlantıyı Anlamak

Largest Contentful Paint (LCP), görünür alanda en büyük metin veya görselin ekranda boyandığı anı ölçer. Hero görseli büyükse LCP öğesi genellikle o olur; ama metin bloğu geniş ve görünür alanda üst sıradaysa tarayıcı metni seçebilir. Metin LCP öğesiyse ve font henüz indirilmemişse, o metnin boyandığı an fontun geldiği ana kayar.

font-display: block davranışında tarayıcı yaklaşık 3 saniye boyunca görünmez metin (FOIT - Flash of Invisible Text) gösterir. Bu 3 saniye LCP ölçümünü doğrudan sürükler. swap değeri bu bloğu kaldırır: sistem fontuyla metni anında çizer, asıl font gelince değiştirir. Kullanıcı boşluk yerine metin görür; tarayıcı da LCP'yi erken kaydeder.

Yalnız font-display: swap yeterli değildir. Metni erken çizmek LCP zamanını öne çeker, ama asıl font isteği hâlâ aynı anda başlıyorsa swap gecikmeli gelir ve görsel sıçrama (CLS) üretebilir. Zincirin geri kalanı tam bu noktadan başlar.

Preload ile Font İsteğini Öne Çekmek

Tarayıcı bir sayfayı ayrıştırırken HTML'i önce okur, CSS'i sonra yükler, CSS içindeki @font-face bildirimlerini ise yalnızca o kuralın gerçekten kullanıldığını gördükten sonra işler. Bu zincir, font isteğinin ikinci veya üçüncü network turuna denk gelmesi anlamına gelir. <link rel="preload"> etiketi bu zinciri kırar; tarayıcı HTML'i ayrıştırırken hemen isteği başlatır, CSS render zincirini beklemez.

Etiket doğru yazılmalıdır:

<link
  rel="preload"
  href="/fonts/inter-var-latin.woff2"
  as="font"
  type="font/woff2"
  crossorigin
>

crossorigin özelliği eksik kalırsa tarayıcı fontu iki kez indirir: biri preload isteği, diğeri CSS kural eşleştiğinde açılan ikinci istek. Bu durum hem bant genişliğini hem önbelleği bozar. as="font" eksik olursa kaynak düşük öncelikli kuyrukta bekler; preload'ın faydası büyük ölçüde yok olur.

Hangi font dosyasını preload etmeli? LCP öğesini oluşturan font ağırlığını ve stilini. Birden fazla ağırlık preload etmek, ilk render sırasında kullanılmayanları gereksiz yere öne çeker ve kritik kaynakların bandını daraltır. Tek bir preload, doğru dosyaya yönlendirilmiş, çoğu durumda yeterlidir.

Subset ile Dosya Boyutunu Kırmak

Bir Latin alfabesi yazı tipi 20-80 KB arasında değişebilir; Kiril, Yunanca veya tam Unicode desteği taşıyorsa bu rakam 200 KB'ı geçebilir. Sayfa yalnızca Türkçe içerik sunuyorsa bu gliflerin büyük çoğunluğu hiç kullanılmaz.

Subset işlemi, fontun yalnızca kullanılacak karakter aralığını içeren bir sürümünü üretir. Google Fonts API'si bunu subset=latin parametresiyle yapar; kendi sunucunuzda barındırdığınız fontlarda pyftsubset gibi araçlarla aynı sonuca ulaşırsınız. Türkçe için Latin Extended-A bloğu genellikle yeterlidir: ş, ğ, ü, ö, ı, ç ve büyük karşılıkları bu blokta yer alır.

Asıl kazanım yalnızca transfer boyutundan gelmez; tarayıcının daha az veriyi ayrıştırması da render süresini kısaltır. Geniş Unicode gliflerine sahip bir fondaki azalma belirgin olabilir, ama zaten Latin-only bir fondaki fark küçüktür. Karar vermeden önce orijinal dosyanın neler taşıdığını kontrol edin.

Bir çekince: dinamik içerik barındıran sayfalarda kullanıcı tarafından üretilen metinler beklenmedik karakterler içerebilir. Subset'te bulunmayan bir karakter için tarayıcı fallback'e düşer; görsel tutarsızlık üretir. Subset kararı içerik türüne ve kontrolünüzün kapsamına göre verilmelidir.

Fallback Font Metrik Uyumu: Layout Shift'i Ezmek

Swap davranışı metni erken gösterir; ama sistem fontu ile asıl font arasındaki boyut farkı layout shift üretir. Başlık satırı önce Arial ile çizilir, asıl font gelince Inter ile yeniden çizilir; satır yüksekliği değişir, içerik kayar. LCP erken kaydedilmiş olsa da CLS skoru bozulabilir.

CSS'teki size-adjust, ascent-override, descent-override ve line-gap-override tanımlayıcıları sistem fontunu asıl fonta benzer ölçülere çeker. Bu tanımlayıcılar @font-face bloğunda, fallback atamasıyla birlikte kullanılır:

@font-face {
  font-family: "InterFallback";
  src: local("Arial");
  size-adjust: 107%;
  ascent-override: 90%;
  descent-override: 22%;
  line-gap-override: 0%;
}

body {
  font-family: "Inter", "InterFallback", sans-serif;
}

Değerler fonttan fonta değişir; piksel düzeyinde hizalama için ölçümü yapılmış değerler gerekir. Bunu elle hesaplamak zahmetlidir. fontaine veya @next/font gibi araçlar uygun değerleri otomatik üretir. Değerler doğru ayarlandığında geçiş anında kayma neredeyse yok olur; CLS sıfıra yakın kalır.

Dört Adım Birlikte: Uygulama Sırası Farkı Belirler

Bu dört kararın her biri bağımsız iyileştirme sağlar; ama birbirinden kopuk uygulandığında bir adım diğerinin etkisini azaltabilir. Önce subset alın: dosya küçülmeden preload kazancı sınırlı kalır. Sonra doğru dosyaya preload ekleyin, en küçük gerekli ağırlığa, WOFF2 formatında. Ardından font-display: swap tanımını ekleyin; metin erken görünecek ama sistem fontuyla ölçüsel uyumsuzluk olabilir. Son adımda fallback metrik değerlerini ayarlayın: kayma kaybolur, geçiş pürüzsüzleşir.

Sıra ters kurulursa tablo değişir. Önce swap eklenince başlık sıçraması artar. Preload tam font dosyasına işaret ederse transfer süresi düşmez. Subset ve metrik uyumu en sona bırakılırsa LCP birkaç saniyeden 1-2 saniye bandına inebilir, CLS de 0,1 üstünden 0,05 altına gerileyebilir. Adımların sırası, nihai kazancı büyük ölçüde belirler.

Bu Optimizasyonlar Ne Zaman Gereksizdir?

Font yüklemesi her sayfada LCP belirleyicisi değildir. LCP öğesi bir görsel ya da arka plan görseli ise font gecikmeleri LCP skorunu doğrudan etkilemez. Özel font yalnızca logo tipografisinde ve görünür alan dışında kullanılıyorsa preload kritik kaynakların bandını daraltır, net kazanç sağlamaz.

Variable font (değişken font) kullanıyorsanız ve tüm ağırlıklar aynı dosyadan geliyorsa subset mantığı değişir: ağırlık başına ayrı dosya yerine tek bir değişken font dosyası daha az HTTP isteği üretir, ama dosya boyutu statik ağırlıklara kıyasla büyük kalabilir. Seçim, kullanılan ağırlık sayısına göre yapılmalıdır. İki ağırlıktan fazlasında variable font çoğu durumda daha avantajlıdır. Bir frontend performans kontrol listesi bu bağlamı sistematik kurmak için iyi bir başlangıç noktasıdır.

Değişikliği Doğrulamak: Ne Ölçülür, Nasıl Okunur?

Lighthouse lab verisini ölçer; alan verisi ise Chrome User Experience Report (CrUX) üzerinden gelir. Lab ortamında LCP iyileşmesi görülebilir ama alan verisinde haftalarca gecikmeli yansıyabilir. İki kaynağın birbirini teyit etmesini beklemek, gerçek etkiyi anlamak için daha güvenilirdir.

DevTools'un "Performance" sekmesinde "Font" satırı isteğin ne zaman başladığını ve ne kadar sürdüğünü gösterir. Preload eklenince bu isteğin ne kadar öne kaydığını görmek mümkündür. Network sekmesinde "font" filtresiyle istek başlangıcı ile bitişini karşılaştırın; Transfer Size sütunu subset öncesi ve sonrasını doğrular.

CLS ölçümü için "Layout Shift" olaylarına bakın: Performance sekmesinde kırmızı çubuklar olarak görünür. Fallback metrik uyumu eklenince bu çubuklar küçülmeli ya da yok olmalıdır. Herhangi bir değişiklik olmadan raporlarda iyileşme görüyorsanız, değişikliğin önbellek katmanında ya da başka bir kaynakta gerçekleşip gerçekleşmediğini kontrol edin.

Font optimizasyonu, tasarım sistemi kararlarından ayrılamaz: hangi fontların kullanılacağı, kaç ağırlık gerekeceği, hangi sayfalarda özel tipografi olacağı - bunların hepsi yükleme stratejisini şekillendirir. Optimizasyon geriye dönük bir düzeltme olarak değil, tasarım aşamasında verilen bir karar olarak ele alındığında daha az iş gerektirir ve daha kalıcı sonuç üretir.

LCP'yi düşürmenin pek çok yolu arasında font yüklemesi çoğu zaman gözden kaçar, çünkü doğrudan bir görsel yükleme sorunu gibi görünmez. Performans kararlarında ne zaman kod bölünmeli, ne zaman sayfa sadeleştirilmeli sorusu gibi font kararı da bağlama göre verilir; evrensel bir reçete yoktur. Ama başlık metninin ekranda kaç milisaniye geç göründüğü, ölçüm araçlarının sayıyla ifade ettiğinden daha büyük bir kullanıcı deneyimi etkisi bırakır.

Production build yapılandırması da font optimizasyonunu doğrudan etkiler: bazı bundler yapılandırmaları font dosyalarını otomatik hash'ler, bazıları cache-busting için sorgu parametresi ekler. Bu davranış, preload etiketindeki href'in derleme sonrası dosya adıyla eşleşip eşleşmediğini belirler. Hash tabanlı isimlendirme kullanıyorsanız preload href'ini statik yazmak yerine build aracının ürettiği değeri kullanmalısınız; aksi durumda preload iki farklı kaynağı işaret eder ve fayda sıfıra döner.