Modern arayüzlerin en ağır maliyetlerinden biri, metni boyamak için kullanılan font dosyalarının tarayıcıya indirilme ve çözümlenme fazında yarattığı asimetridir. Bir sayfanın görsel ve iskeletsel yüklemesi bitmiş dahi olsa; font dosyası geç inerse, metin ya tamamen gizlenir (FOIT - Flash of Invisible Text) ya da yedek (fallback) bir fontla işlenip asıl dosya geldiğinde aniden şekil değiştirerek düzeni zıplatır (FOUT - Flash of Unstyled Text). Font optimizasyonu, .woff2 dosyasının indirme saniyesinden ziyade, bu iki tarayıcı kusurunu dengeleme mühendisliğidir.

Tipografi seçimi ürün toplantılarında estetik karar gibi görünse de, front-end safhasında bir ağ bileşenidir. Seçtiğiniz her kalınlık (weight) ve her karakter seti (Latin, Cyrillic) şebekeye fazladan veri taşır. Web fontlarını statik görseller gibi değil, metnin çerçevesini anlık hesaplayan bir motor parçası gibi görmediğiniz sürece CLS (Cumulative Layout Shift) tuzaklarından sıyrılamazsınız.

Her font varyasyonu donanıma ekstra yüktür

Laboratuvar ortamından çıkıp düşük performanslı ağlara (3G) inildiğinde kriz boy gösterir. Inter ya da Roboto ailesinden 300, 400, 500, 600, 700 ve bunların italik versiyonlarını tek bir CSS dosyası üzerinden (veya CDN aracılığıyla) içeri yığmak, indirme bandını anında 300 KB bariyerine iter. Okuyucu ekrana baktığında sadece 400 ve 700 ağırlığından metinler görüyorken, çalışmayan glifleri baştan yükletmek net bir ağ zafiyetidir.

Bunun karşısındaki kesin çözüm Subsetting (alt kümeleme) pratiğidir. Geliştirdiğiniz projede Rusça veya Yunanca yayın yoksa Cyrillic ya da Greek alfabelerinin glifleri silinmek zorundadır. Terminal üzerinden glyphhanger gibi Node araçlarıyla elinizdeki dosyalardan kullanmadığınız ikonları ve harfleri ayıklayarak tekil bir font kalibresini 80 KB'lardan 12 KB bandına düşürebilirsiniz. Sırf çap çap küçülttüğünüz glifler sayesinde LCP sürenizde saniyelik toparlanmalar elde edersiniz.

FOUT ve FOIT dengesi: font-display seçimi

Tarayıcının orijinal font inene kadar kaba metne nasıl tepki vereceğini, CSS içerisindeki font-display direktifi belirler. Geliştiricinin en klasik refleksi, "Metin hiç olmazsa okunur olsun" diyerek font-display: swap; komutunu basmaktır. İşin ehli bilir ki, bu komut FOIT (Görünmez metin) hatasını çözer ve arayüze anında yedek sistem fontunu (genelde Arial, sans-serif) damgalar.

Ancak faturayı görsel bütünlük öder. swap kullandığınızda, Arial ile dizilen bir metin 1.2 saniye boyunca okunur, akabinde sizin geciken 25 KB'lık Inter fontunuz ağı aşıp DOM'a sızar. Inter fontunun x-height hesaplamaları Arial'dan daha sıkıysa o satır aniden 4 piksel aşağı çöker. Bu sekme, okuyucunun konforunu bozar ve CLS testlerinde sayfanızı aşağılara fırlatır.

@font-face {
  font-family: 'AnaFont';
  src: url('/fonts/anafont.woff2') format('woff2');
  font-display: swap;
  
  /* Yedek fontun metriklerini gerçeğe uyarlayan CSS override'ları */
  ascent-override: 95%;
  descent-override: 20%;
  size-adjust: 105%;
}

Yukarıdaki kod bloğu sayfa hizasını koruyan gerçek bir denge çözümüdür. Sadece swap atıp dosyayı kendi haline bırakmazsınız; sisteme ait yedek fontun boyut (size-adjust) ve yükseklik (ascent/descent) parametrelerini, dışarıdan inecek fontun ölçüsüne yakın olacak şekilde ayarlarsınız. Böylece asıl font sisteme aktığında karakter değişse bile kapladığı alan sıfıra yakın kaymayla korunur.

Variable font ne zaman avantaj sağlar?

Modern dönemin en popüler savunma mekanizması Variable Fonts (Değişken Fontlar) teknolojisidir. Sisteminizdeki 6 farklı kalınlık (weight) dosyasına 6 ayrı HTTP isteği yapmak (6 x ~20KB = ~120KB) yerine, bütün eksenlerin birleşimi olan tekil bir .woff2-variations dosyası (örneğin ~60KB) çağırırsınız. Ağ talebi (Request) bire düşer, TCP handshake maliyeti birleşerek silinir, ara kalınlık hesapları (font-weight: 430) CSS'ten ateşlenebilir.

Bu yaklaşımın sınırı da vardır. Şayet blog projenizde sadece Ana Başlık (700) ve Paragraf (400) ağırlığı kullanıyorsanız asıl ağırlık 2 x 15 KB ile toplam 30 KB bandında kalacaktır. Böyle basit bir arayüz için variable font aktarıp cihazı 60 KB yüklemeye zorlamak gereksiz olabilir. Variable fontlar, daha çok kalınlık veya italik kombinasyonu gerçekten kullanıldığında avantaj üretir.

Self-Hosting (Yerel Dosya) vs Dış Servis CDN

Google Fonts emsali barındırma servislerinin ağ yapılarına güvenip dış bağlantıları HTML tabanına iliştirmek otomatizasyon kolaylığıdır. Eskiden tarayıcılar yaygın Google fontlarını cihaz önbelleğinde (shared cache) biriktirip maliyeti kırardı. Güncel tarayıcıların mahremiyet (cache partitioning) önlem blokları devreye girdiği için, artık her site o font dosyası dışarıdan sıfırdan çekilmektedir.

Bağlantıyı CDN'den tetiklemek, tarayıcının fonts.googleapis.com ile DNS ve TLS bağlantısı kurması, dönen veri içerisinden okuduğu gerçek .woff2 dosyası için bu kez fonts.gstatic.com adresine yeni bir handhake zinciri ateşlemesi demektir. Bu sekmeler originler arası 300 ms gibi israf kayıplarına mani olamaz.

Profesyonel düzlemde fontları yerel dosya sisteminizde (Self-Hosted) domain altında barındırmak ve spesifik olarak sadece WOFF2 formatını bırakmak (EOT, SVG, TTF atıl kalmıştır), kritik render zincirinin kopmasını katı bir şekilde engeller.

Font dosyalarını erkene çekmek: preload kararı

Arama süreçlerini hızlandırmak için geliştirilen preload mekanizması konfigürasyonlarında sivri bir dikkat gerektirir. Sitenin kahraman görselindeki başlığın (hero headline) fontunu derhal yazdırmak istiyorsanız <link rel="preload" as="font" ...> stratejisi kurtarıcıdır. Tarayıcı CSS'in kendi içinde o familyayı okumasını beklemeden, HTML parsing aşamasında derhal isteğe yönelir.

Ancak footer alanında unutulmuş bir sembol fontunu veya alt bildirimlerdeki ince italik serisini preload ile öne çekerseniz, bu küçük ağırlıklar ana iş parçacığında CSS ya da JS modüllerinin yolunu gereksiz yere tıkayabilir. Font kurgusunda her varyasyonun bir önceliği vardır; ekranda görünmeden önce çağrılan her stil fazladan maliyet üretir.

Fallback metrikleri ve karakter seti planı birlikte düşünülmelidir

Font optimizasyonunda en sık atlanan konu, dosya küçültmenin tek başına yeterli sanılmasıdır. Oysa kullanıcı ilk anda çoğu zaman fallback fontu görür; asıl dosya birkaç yüz milisaniye sonra gelir. Eğer fallback olarak seçtiğiniz sistem fontunun harf genişlikleri, satır yüksekliği ve x-height oranı hedef fonttan belirgin biçimde farklıysa, dosya ne kadar küçük olursa olsun metin yer değiştirir. Bu yüzden optimizasyon yalnızca indirme maliyeti değil, geçiş anındaki geometrik tutarlılık meselesidir.

Burada size-adjust, ascent-override ve descent-override gibi ayarlar kritik rol oynar. Ama bunların yanında doğru fallback seçimi de gerekir. Geniş ve yuvarlak karakter yapısına sahip bir başlık fontu için çok dar bir sistem fontunu yedek bırakmak, daha ilk sahnede taşma ve satır kırılması üretir. Kısacası en iyi preload kararı bile kötü fallback seçimini telafi edemez. Önce metrik uyumu, sonra indirme stratejisi gelir.

Karakter seti tarafında da benzer bir plan gerekir. Türkçe içerik yayınlayan bir sitede yalnızca temel Latin alt kümesini bırakmak yeterli değildir; ğ, ı, İ, ş gibi harfleri eksik bir alt küme üretirseniz tarayıcı bu karakterlerde başka fonta düşer ve aynı paragraf içinde görsel kopuş yaratır. Buna karşılık hiç kullanılmayacak sembol bloklarını, uzak alfabeleri veya yönetim paneline özel ikon fontlarını herkese taşımak da gereksiz yük üretir. Doğru strateji, yayındaki gerçek karakter ihtiyacını koruyup kullanılmayan kapsamı dışarıda bırakmaktır.

Uzun ömürlü projelerde font haritasını sayfa tiplerine göre düşünmek de işe yarar. Blog gövdesinde yalnızca düzenli metin ve başlık kullanılıyorsa, yönetim panelinde gereken ekstra ağırlıklar veya tablo fontları herkese yüklenmemelidir. Böylece hem ilk görünür metin daha hızlı gelir hem de yazı sayfalarında gereksiz tipografi yükü birikmez. Font performansında gerçek kazanım, dosyayı yalnızca küçültmekten değil, doğru karakterleri doğru ekrana doğru öncelikle taşımaktan doğar.