Self-hosted font kullanmak her durumda CDN'den daha hızlıdır düşüncesi, web performansı konuşmalarının yaygın yanılgılarından biridir. Gerçek biraz daha karmaşık: doğru koşullarda self-hosting belirgin bir avantaj sağlar, ancak yanlış yapılandırılmış bir self-hosting kurulumu Google Fonts'tan bile daha yavaş çalışabilir. Belirleyici olan yaklaşımın kendisi değil, arkasındaki yapılandırmadır.

Bir font dosyası sayfaya üç ayrı noktada yük oluşturur: kaynak keşfi, bağlantı kurulumu ve dosya transferi. Google Fonts ya da benzeri bir CDN kullandığınızda bu adımların bir kısmı üçüncü taraf bir sunucuya taşınır. Self-hosting kullandığınızda ise tüm süreç kendi altyapınızda gerçekleşir. Hangisinin daha hızlı olduğu bu adımların toplamına ve sitenizin mevcut yapısına bağlıdır.

Farklı projelerde yapılan performans ölçümleri tutarsız sonuçlar ortaya koyar: bazı ortamlarda self-hosting 300–400 ms kazanırken, bazı durumlarda fark 50 ms'nin altında kalır ya da pratikte neredeyse hiç olmaz. Bu farkın nereden geldiğini anlamak, doğru kararı vermenin önkoşuludur.

CDN bağlantısının gizli maliyeti

Üçüncü taraf bir font CDN'i kullandığınızda tarayıcı, CSS içindeki @font-face tanımını işleyene kadar font kaynağını bilemez. Bu gecikme zincirlenir: tarayıcı önce HTML'i indirip parse eder, ardından CSS dosyasını talep eder, CSS parse edildikten sonra @font-face kuralını görür ve ancak o noktada font URL'ini keşfeder. Tarayıcı keşif sırası bu şekilde işlediğinden harici font kaynağı her zaman gecikmeli öğrenilir.

Üstüne bir de bağlantı maliyeti eklenir. Farklı bir origin'e bağlanmak DNS çözümleme, TCP handshake ve TLS müzakeresi gerektirir. Bu üç adımın toplamı fiber bağlantılarda 100–200 ms, mobil bağlantılarda ise 300 ms'nin üzerine çıkabilir. Preconnect hint ekleyerek bu maliyeti öne almak mümkündür; ancak bu yalnızca bağlantı kurulum süresini azaltır, keşif gecikmesini ortadan kaldırmaz.

Self-hosting kullandığınızda font dosyaları kendi origin'inizde bulunur. Tarayıcı ek bir DNS çözümlemesi yapmaz, yeni bir TCP bağlantısı açmaz. HTTP/2 ya da HTTP/3 yapılandırılmış bir ortamda font istekleri HTML ve CSS istekleriyle aynı bağlantıyı paylaşır. Bu, CDN'in DNS+TCP+TLS üçlüsünü tamamen devre dışı bırakır ve keşif sırası sorununun kapsamını önemli ölçüde daraltır.

WOFF2 ve font-display birlikte nasıl kurulur

Self-hosting kararı alındıktan sonra kurulum iki temel bileşenden oluşur: doğru dosya formatı ve font-display değeri. Bunlardan biri eksik ya da yanlış yapılandırılmışsa performans kazanımı beklentinin altında kalır.

WOFF2 formatı günümüzde tüm modern tarayıcılarda desteklenir ve Brotli tabanlı sıkıştırmasıyla WOFF'a kıyasla yaklaşık %30 daha küçük dosya boyutu sunar. Orta ağırlıkta bir Latin karakter setinde WOFF dosyası 60–80 KB arasında gezinirken, aynı fontu WOFF2 ile sunmak bu boyutu 40–55 KB'ye indirebilir. Self-hosting yaparken yalnızca WOFF2 dosyaları kullanmak, eski format fallback'leri eklemeden yeterli tarayıcı kapsamını sağlar.

@font-face {
  font-family: 'InterVariable';
  src: url('/fonts/inter-variable.woff2') format('woff2');
  font-weight: 100 900;
  font-style: normal;
  font-display: swap;
}

font-display: swap değeri, font yüklenirken sistemin yedek fontunu gösterir ve font hazır olduğunda değiştirir. Bu FOIT (görünmez metin yanıp sönmesi) yerine FOUT (stil olmadan metin yanıp sönmesi) tercih etmek anlamına gelir; kullanıcı en azından içeriği okuyabilir. Düşük bant genişliğinde bağlanan kullanıcılar için bu tercih doğrudan okunabilirliği etkiler.

font-display: optional ise farklı bir davranış sunar: tarayıcıya yeterince hızlı gelmeyen fontlar için yedek fontu kalıcı olarak kullanmasını söyler. LCP üzerindeki baskıyı azaltır; ancak tasarımdaki font varyasyonu görüntülenmeyebilir. İki değer arasındaki seçim, sayfanızın tipografisinin font yüklenmesine ne kadar bağımlı olduğuyla doğrudan ilişkilidir.

Gerçek hız farkı nerede ölçülür

Self-hosting kurulumu tamamlandıktan sonra farkın gerçekten var olup olmadığını doğrulamak gerekir. Sezgiye ya da tahmine güvenmek yanıltıcı olabilir; araçlar net veri sunar.

Chrome DevTools'un Network sekmesinde font dosyalarının yüklenme zamanlamasını incelemek en hızlı yoldur. Timing bölümünde "Stalled" ve "Connection Start" süreleri CDN kullanımında belirgin biçimde uzarken, self-hosting'de bu süreler sıfıra yakın olur. DNS çözümlemesi ve TLS müzakeresi de ayrıca görünür; bu rakamlar değerlendirmeyi somutlaştırır. Üçüncü taraf bir CDN'in bağlantı maliyeti burada milisaniye cinsinden okunabilir hale gelir.

WebPageTest gibi dışarıdan ölçüm yapan bir araçla farklı coğrafi konumlardan test yapmak ise gerçek kullanıcı deneyimini daha doğru yansıtır. CDN'in PoP (Point of Presence) noktasının hedef kitlenize uzak olduğu durumlarda beklenti ile gerçeklik arasındaki uçurum açılır. Türkiye'deki kullanıcıların Avrupa ya da ABD'deki CDN sunucularına bağlandığı senaryolarda bu fark gözlemlenebilir biçimde büyür; CDN seçiminin coğrafi dağılımı göz ardı edilmemelidir.

LCP ölçümüne de ayrıca bakmak gerekir. Eğer sayfanızın en büyük içerik öğesi, font yüklenene kadar görüntülenemeyen bir metin bloğuysa font gecikmesi doğrudan LCP değerini etkiler. Bu durumda self-hosting ve preload kombinasyonu, CDN ile preconnect kombinasyonundan ölçülebilir biçimde daha iyi sonuç üretir. Render engelleyen kaynak konumuna düşen bir font bağlantısı, çözülene kadar tüm render sürecini bloke eder.

Cache stratejisi self-hosting'i anlamlı kılar

CDN tabanlı font servislerinin öne sürdüğü argümanlardan biri paylaşımlı cache'dir: aynı CDN'i kullanan farklı siteler aynı font dosyasını cache'lediğinden, kullanıcı ikinci bir siteye girdiğinde fontu zaten indirmiş olabilir. Bu argüman teorik olarak doğruydu; 2020 sonrasında tarayıcı partitioning politikalarıyla birlikte pratikte büyük ölçüde geçerliliğini yitirdi.

Chrome, Firefox ve Safari'de devreye giren cache partitioning, farklı origin'lerden gelen isteklerin ayrı cache bölmelerinde saklanmasını sağlar. fonts.gstatic.com üzerinden yüklenen bir font, başka bir sitede aynı URL'den indirilmiş olsa bile artık cache'den gelmez. Paylaşımlı cache avantajı çoğu kullanıcı için işlevsiz hale geldi; bu, CDN lehine öne sürülen en güçlü argümanın ortadan kalkması anlamına gelir.

Self-hosting bu bağlamda net bir avantaj sağlar: font dosyaları üzerinde tam kontrol size aittir ve agresif cache başlıkları tanımlayabilirsiniz. Tarayıcı önbellekleme yapılandırması doğru kurulduğunda, tekrar ziyaret eden kullanıcılar için font yükleme süresi pratikte sıfıra düşer.

Cache-Control: public, max-age=31536000, immutable

Bu başlık font dosyasını bir yıl boyunca cache'de tutar. immutable direktifi tarayıcıya koşullu istek bile göndermemesini söyler; içerik değişmediği sürece hiçbir ağ trafiği oluşmaz. Dosya güncellenirse yeni dosyayı farklı bir URL ile sunmak yeterlidir; dosya adında content hash kullanmak bunu otomatik hale getirir. CDN'lerde bu düzeyde başlık kontrolü genellikle ücretli plan ya da özel yapılandırma gerektirir; çoğu ücretsiz font CDN'i cache başlıklarını sizin adınıza yönetir ve değiştiremezsiniz.

CDN'den self-hosting'e geçiş süreci

Google Fonts ya da başka bir CDN'den self-hosting'e geçmek, harici bağımlılıkları kaldırıp dosyaları kendi altyapınıza taşımak anlamına gelir. Süreç birkaç adımdan oluşur ve her adımda dikkat edilmesi gereken bir nokta vardır.

İlk adım, kullanılan font dosyalarını doğru formatta indirmektir. Google Fonts için google-webfonts-helper aracı, seçtiğiniz fontu WOFF2 dosyaları ve hazır @font-face CSS bloğuyla birlikte sunar. Yalnızca kullandığınız ağırlıkları indirmek kritik bir ayrıntıdır. 400, 600 ve 700 ağırlıklarından yalnızca 400'ü kullanıyorsanız diğer ikisini barındırmak gereksiz yük oluşturur; her kullanılmayan varyasyon, boşuna sunulan kilobaytlardır.

İkinci adım, dosyaları sitenizin sunucusuna taşıyıp doğru başlıklarla yapılandırmaktır. /fonts/ klasörü yaygın bir tercihken, önemli olan sunucu tarafında cache başlıklarının doğru kurulmasıdır. WOFF2 zaten sıkıştırılmış bir format olduğundan ek Brotli ya da gzip sıkıştırması genellikle anlamlı boyut kazanımı sağlamaz; ancak sunucu düzeyinde sıkıştırma tamamen kapalıysa durum farklıdır ve kontrol edilmesi gerekir.

Üçüncü adım, HTML ve CSS içindeki harici font referanslarını kaldırmaktır. Google Fonts kullanan projelerde bu genellikle <link> etiketleri ya da CSS'deki @import satırları anlamına gelir. Bu harici çağrıların kaldırılması render zincirini doğrudan sadeleştirir ve tarayıcının kritik yolu kısalır.

Son adımda, kritik fontlar için <link rel="preload"> eklemek gecikmeyi minimuma indirir. Tarayıcı CSS'i parse etmeden önce font dosyasını öğrenir ve daha erken indirmeye başlar. Preload ile prefetch arasındaki fark burada pratik sonuçlar doğurur; preload yalnızca o sayfanın ilk render'ında kullanılacağı kesin olan kaynaklar için uygulanmalıdır, aksi halde bant genişliği gereksiz yere tüketilir.

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

Geçiş tamamlandıktan sonra önceki ve sonraki ölçümleri karşılaştırmak, kazanımın boyutunu netleştirir. Beklenti ile gerçek sonuç arasında belirgin bir fark yoksa CSS'deki eski @font-face bloklarının silindiğinden ve harici <link> etiketlerinin tamamen kaldırıldığından emin olmak gerekir; ikisinin bir arada kalması sık yapılan bir hatadır.

Self-hosted font ile CDN arasındaki tercih ikili bir soru değildir. Hedef kitlesi geniş coğrafyalara yayılmış, iyi yapılandırılmış global CDN altyapısından beslenen büyük siteler için CDN bazı durumlarda makul bir seçenek olmaya devam edebilir. Ancak tipik bir web projesi için self-hosting, cache partitioning gerçeği ve sunucu başlığı üzerindeki kontrol avantajı göz önüne alındığında, çoğu durumda daha öngörülebilir performans sunar.

Asıl kazanım, font dosyalarının nerede barındırıldığından değil, kurulumun her katmanının doğru yapılandırılmasından gelir: WOFF2 formatı, uygun font-display değeri, agresif cache başlıkları ve yalnızca kullanılan ağırlıklar. Bu dört bileşen bir araya geldiğinde self-hosting'in potansiyeli gerçek ölçüme dönüşür.

Font yükleme optimizasyonu ve Google Fonts performans iyileştirmeleri birbirini tamamlayan konulardır; her ikisi de uygulamanın mevcut yapısına ve gerçek kullanıcı verilerine göre değerlendirilmelidir. Ölçmeden verilen kararlar hem yatırımın hem de beklentinin yanlış yöne gitmesine neden olur.