Web Fontlarını Kendin Host Etmek: Google Fonts’tan Self‑Hosted WOFF2’ye Geçiş

Web fontlarını kendin host etmek neden bu kadar konuşuluyor?

Son birkaç yılda performans ve gizlilik tarafında yapılan denetimlerde, en çok gördüğümüz tekrar eden bulgulardan biri harici font servisleri oldu. Tasarım ekipleri doğal olarak Google Fonts gibi servisleri kullanarak hızlıca tipografi kararlarını hayata geçiriyor; ancak iş Core Web Vitals, gizlilik uyumu ve uzun vadeli kontrol konularına geldiğinde, bu konforun ciddi bir bedeli ortaya çıkıyor. Ek DNS sorguları, harici TLS bağlantıları, font indirilene kadar bloklanan metinler ve bazen de Avrupa’daki gizlilik regülasyonlarıyla çelişebilen 3. taraf isteği kayıtları…

DCHost tarafında hem küçük kurumsal sitelerde hem de yüksek trafikli projelerde şunu sık sık görüyoruz: Sadece web fontlarını self‑hosted WOFF2 yapısına taşımak bile, LCP ve FCP tarafında hissedilir iyileşme sağlayabiliyor. Üstelik bu değişiklik, altyapıyı kökten değiştirmeyi gerektirmeyen; daha çok uygulama katmanında yapılabilen bir optimizasyon. Bu yazıda Google Fonts entegrasyonunun nasıl çalıştığını, hangi dar boğazları yarattığını, self‑hosted WOFF2 mimarisine adım adım nasıl geçebileceğinizi ve tüm bunların performans ile gizlilik üzerindeki somut etkilerini detaylı şekilde anlatacağız.

Google Fonts entegrasyonu ağ tarafında nasıl çalışır?

Google Fonts bugün hâlâ en yaygın kullanılan web font kaynaklarından biri. Çoğu projede tipik entegrasyon şu şekilde yapılıyor:

<link rel='preconnect' href='https://fonts.googleapis.com'>
<link rel='preconnect' href='https://fonts.gstatic.com' crossorigin>
<link href='https://fonts.googleapis.com/css2?family=Inter:wght@400;600&display=swap' rel='stylesheet'>

Bu satırlar aslında tarayıcıya şunu söyler:

• Önce fonts.googleapis.com alan adına bağlan, CSS dosyasını al.
• CSS içinden fonts.gstatic.com alan adındaki WOFF2 dosyalarının adreslerini öğren.
• Sonra her bir font dosyası için ayrı HTTP isteği gönder.

Waterfall grafiğine baktığınızda şunu görürsünüz:

• Ekstra bir DNS çözümlemesi ve TCP/TLS el sıkışması (iki farklı domain için).
• Önce CSS, ardından bu CSS’de referans verilen WOFF2 dosyalarının indirilmesi.
• Fontlar tamamlanana kadar metnin geçici olarak görünmemesi (FOIT) veya stil değişimi (FOUT).

Bu ekstra basamaklar; özellikle mobil ağlarda ve yüksek gecikmeli bağlantılarda FCP ve LCP metriklerini olumsuz etkiler. Zaten Core Web Vitals ve hosting altyapısı ilişkisini anlattığımız rehberde de görebileceğiniz gibi, render sürecini geciktiren her dış bağımlılık, zincirleme şekilde kullanıcı deneyimini zayıflatır.

Self‑hosted web font mimarisinin temel avantajları

Web fontlarını kendi sunucunuzda barındırdığınızda ağ trafiği çok daha sade bir hal alır:

• Tarayıcı, font dosyalarını aynı origin üzerinden (örneğin example.com) çeker.
• Ek DNS ve TLS handshake ihtiyacı ortadan kalkar.
• HTTP/2 veya HTTP/3 üzerinden tek bağlantı ile birden fazla font dosyası paralel taşınır.
• Cache ve sıkıştırma ayarlarını doğrudan siz kontrol edersiniz.

Somut faydaları şöyle özetleyebiliriz:

• Daha düşük TTFB ve daha hızlı LCP: Tarayıcı yeni bir domain çözmek ve TLS kurmak zorunda kalmaz, kritik fontlar sunucuya giden ilk istek setinin içinde hızla gelir.
• İstikrarlı performans: Üçüncü taraf CDN tarafındaki yoğunluk, throttle veya bölgesel sorunlar sitenizi etkilemez.
• Gizlilik ve uyum: Ziyaretçi IP adresleri ve user‑agent bilgileri harici bir font sağlayıcısına gönderilmez, KVKK / GDPR açısından daha temiz bir model ortaya çıkar.
• Ön bellekleme kontrolü: max‑age, immutable, ETag gibi başlıkları dilediğiniz gibi ayarlayabilirsiniz. Bu konuya benzer mantıkla bakan tarayıcı ve CDN önbellek stratejileri rehberimize de göz atmanızı öneririz.

Google Fonts’tan self‑hosted WOFF2’ye geçiş: Adım adım plan

Şimdi pratiğe geçelim. Aşağıdaki adımlar, hem küçük WordPress sitelerinde hem de özel framework kullanan projelerde defalarca uyguladığımız, sahada kendini ispatlamış bir akış.

1. Mevcut font envanterini çıkarmak

Önce hangi font ailelerini ve varyantlarını kullandığınızı netleştirin. Çoğu projede ihtiyaçtan çok daha fazla varyant yüklendiğini görüyoruz:

• Normal, bold, medium, semibold, light…
• İtalik sürümler
• Latin, Latin‑ext, Cyrillic gibi birden fazla dil subset’i

Chrome DevTools içinde Network sekmesinde type sütununu font olarak filtreleyip hangi WOFF2 dosyalarının geldiğini görebilirsiniz. Ayrıca Google Fonts’tan eklediğiniz link etiketine bakarak da hangi aileleri çağırdığınızı görebilirsiniz.

İlk optimizasyon fırsatı genelde burada ortaya çıkar: Kullanılmayan ağırlık ve stil varyantlarını devreden çıkarmak. Ne kadar az varyant, o kadar az dosya ve o kadar hızlı ilk boyama.

2. Font dosyalarını indirmek ve WOFF2’ye dönüştürmek

İkinci adımda, seçtiğiniz font ailelerini indirmeniz gerekiyor. Bunu iki şekilde yapabilirsiniz:

• Google Fonts arayüzünden ilgili aileyi seçip indir düğmesiyle TTF/OTF paketini almak.
• Veya Google Fonts CSS çıktısından WOFF2 adreslerini bulup doğrudan indirerek mevcut optimize edilmiş dosyaları almak.

Standart pratik, modern tarayıcılar için WOFF2 kullanmak ve gerekli görüyorsanız çok eski tarayıcılar için WOFF fallback bırakmaktır. Çoğu yeni projede sadece WOFF2 yeterli olur. Fontlar elinizde TTF/OTF formatında ise, yerel makinenizde veya CI pipeline’ınızda WOFF2’ye dönüştürmek için fonttools, woff2 gibi araçlar kullanabilirsiniz.

Dosyaları proje yapınızda genelde şöyle bir hiyerarşide tutmak pratik olur:

/assets/
  css/
  js/
  fonts/
    inter-400.woff2
    inter-600.woff2

Paylaşımlı hosting kullanıyorsanız bu klasörler public_html altında; VPS veya dedicated sunucuda ise web root olarak tanımladığınız dizinin içinde yer alacaktır. DCHost altyapısında bu yapıyı ister cPanel ile ister doğrudan Nginx/Apache sanal host ayarlarıyla rahatlıkla kurgulayabilirsiniz.

3. Subset ve unicode-range planlamak

Bir diğer büyük kazanım, font dosyalarınızı gerçekten ihtiyacınız olan karakter setine indirgemektir. Örneğin sadece Türkçe ve temel Latin karakterler kullanıyorsanız; Kiril, Yunanca ya da Asya alfabelerini barındıran büyük font dosyalarına ihtiyacınız yoktur.

İki yaklaşım var:

• Tek ama optimize edilmiş bir latin‑ext dosyası kullanmak.
• Birden fazla küçük dosya üretip unicode‑range ile bölmek (örneğin temel Latin ve Latin‑ext’i ayırmak).

İkinci yöntemde CSS tarafında şöyle tanımlar görebilirsiniz:

@font-face {
  font-family: 'Inter';
  src: url('/assets/fonts/inter-latin.woff2') format('woff2');
  font-weight: 400;
  font-style: normal;
  font-display: swap;
  unicode-range: U+0000-00FF;
}

@font-face {
  font-family: 'Inter';
  src: url('/assets/fonts/inter-latin-ext.woff2') format('woff2');
  font-weight: 400;
  font-style: normal;
  font-display: swap;
  unicode-range: U+0100-024F;
}

Tarayıcı, sayfadaki gerçek karakterlere bakarak hangi dosyaya ihtiyaç olduğunu otomatik seçer. Özellikle çok dilli büyük projelerde bu yaklaşım ciddi bant genişliği tasarrufu sağlayabilir.

4. Font dosyalarını sunucuya yerleştirmek

Fontları dönüştürdükten sonra, artık bunları sunucunuza yükleme aşamasına geçebilirsiniz. DCHost üzerindeki tipik senaryolar:

• Paylaşımlı hosting / cPanel: public_html/assets/fonts benzeri bir klasör açıp dosyaları FTP, SFTP veya panel dosya yöneticisi ile yüklemek.
• VPS / dedicated sunucu: /var/www/proje-adi/current/public/assets/fonts gibi bir path altında versiyonlanabilir bir yapı kurmak.

Bu noktada en önemli detay, font dosyalarınızın HTTP üzerinden doğrudan erişilebilir olması ve doğru MIME tipiyle servis edilmesidir. Çoğu modern web sunucusunda WOFF2 için type otomatik tanınır; yine de emin olmak için Nginx veya Apache yapılandırmanızı kontrol edebilirsiniz.

5. CSS içinde @font-face tanımlarını yazmak

Artık projenizi Google Fonts CSS çıktısından ayırıp kendi @font-face tanımlarınızı yazabilirsiniz. Minimal, modern ve performans dostu bir örnek şöyle olabilir:

@font-face {
  font-family: 'Inter';
  src: local('Inter Regular'),
       url('/assets/fonts/inter-400.woff2') format('woff2');
  font-weight: 400;
  font-style: normal;
  font-display: swap;
}

@font-face {
  font-family: 'Inter';
  src: local('Inter SemiBold'),
       url('/assets/fonts/inter-600.woff2') format('woff2');
  font-weight: 600;
  font-style: normal;
  font-display: swap;
}

Buradaki kritik noktalar:

• local() ifadesi, kullanıcının işletim sisteminde aynı font zaten kuruluysa ağ isteği göndermeden onu kullanmanıza imkân verir.
• font-display: swap ile FOIT yerine, önce sistem fontuyla metni gösterip font dosyası geldiğinde yumuşak bir geçiş sağlarsınız.
• Sadece ihtiyaç duyduğunuz ağırlıkları tanımlarsanız, CSS’iniz sade ve yönetilebilir kalır.

Ardından body veya ilgili bileşenlerde fontu normal şekilde kullanabilirsiniz:

body {
  font-family: 'Inter', system-ui, -apple-system, BlinkMacSystemFont, 'Segoe UI', sans-serif;
}

6. HTML tarafında preload ile kritik fontları öne almak

Özellikle hero alanında görünen ana metin için kullanılan font dosyalarını ön yüke almak, LCP süresini hissedilir biçimde düşürebilir. Bunun için HTML head kısmına aşağıdaki gibi preload etiketleri ekleyebilirsiniz:

<link rel='preload'
      href='/assets/fonts/inter-400.woff2'
      as='font'
      type='font/woff2'
      crossorigin>

<link rel='preload'
      href='/assets/fonts/inter-600.woff2'
      as='font'
      type='font/woff2'
      crossorigin>

Dikkat edilmesi gerekenler:

• Mutlaka as=’font’ ve type=’font/woff2′ kullanın; aksi halde tarayıcı isteği doğru kategorize etmeyebilir.
• Fontlar CORS gerektirdiği için crossorigin eklemeyi unutmayın.
• Gerçekten kritik olmayan fontları preload etmeyin; gereksiz ön yükleme, ağ tıkanıklığı yaratabilir.

7. Önbellekleme, sıkıştırma ve HTTP/2/3 ayarları

Fontlarınız artık kendi sunucunuzda olduğuna göre, HTTP başlıklarını tam kontrol edebilirsiniz. İyi bir pratik, fontlarınızı uzun süreli cache ile sunmaktır çünkü çok sık değişmezler. Nginx için örnek bir ayar:

location ~* .(woff2|woff)$ {
    add_header Cache-Control 'public, max-age=31536000, immutable';
}

Ayrıca font dosyalarınız için Brotli veya Gzip sıkıştırmasını etkinleştirmek, özellikle yavaş bağlantılarda fark yaratır. Bu konuyu detaylı anlattığımız Brotli ve Gzip sıkıştırma ayarları rehberine mutlaka göz atın. Fonts gibi statik varlıklar, doğru sıkıştırma ve cache ayarlarıyla neredeyse görünmez hale getirilebilir.

Sunucunuz HTTP/2 veya HTTP/3 destekliyse (DCHost altyapısında bu desteği yaygın olarak sağlıyoruz) tek TCP bağlantısı üzerinden tüm font ve statik dosyalarınız paralel taşınır. HTTP protokol sürümlerinin SEO ve performansa etkisini de HTTP/2 ve HTTP/3 rehberimizde ayrıntılı olarak ele aldık.

Performans etkilerini ölçmek: Öncesi ve sonrası

Yaptığınız değişikliğin işe yarayıp yaramadığını anlamanın en iyi yolu objektif ölçüm yapmaktır. Biz genellikle şu yolu izliyoruz:

• Google Fonts kullanılan sürüm için bir hız raporu almak.
• Self‑hosted WOFF2 sürümünü canlıya aldıktan sonra aynı testleri tekrarlamak.
• Network waterfall, FCP, LCP ve CLS metriklerini yan yana kıyaslamak.

Bu testler için PageSpeed Insights, WebPageTest veya GTmetrix üçlüsünü kullanmak oldukça pratik. Ölçüm sürecini daha detaylı anlatmak için hazırladığımız web sitesi hızını doğru ölçme rehberine de mutlaka bakmanızı öneririz.

Gerçek projelerde çoğu zaman şunları görüyoruz:

• Google Fonts’tan self‑hosted WOFF2’ye geçişte LCP’nin 200–400 ms arası iyileşmesi.
• FOIT yerine font-display: swap ile birlikte metnin çok daha erken görünmesi.
• Harici istek sayısının azalmasıyla birlikte daha temiz waterfall ve daha öngörülebilir performans.

Eğer siteniz yoğun görsel içerik de barındırıyorsa, font optimizasyonunu görsel optimizasyon ve WebP/AVIF stratejileri ile birleştirdiğinizde, Core Web Vitals tarafında oldukça güçlü bir tablo elde edebilirsiniz.

Gizlilik ve uyum boyutu: Google Fonts çağrıları neden tartışılıyor?

Performans tarafının yanında, Avrupa’da ve Türkiye’de artan gizlilik tartışmaları da web fontlarını kendiniz host etmenizi teşvik ediyor. Harici font servisleri her ziyaretçide şunları görebilir:

• IP adresi
• Tarayıcı ve işletim sistemi bilgisi (user‑agent)
• Ziyaret zamanına ilişkin zaman damgası
• Referrer başlığı üzerinden geldiği sayfa

Bu veriler tek başına kişisel veri sayılmasa da, IP adresi ile birlikte değerlendirildiğinde KVKK / GDPR kapsamında yorumlanabiliyor. Bazı ülkelerde Google Fonts entegrasyonuna ilişkin hukuki kararlar bile verildi. Self‑hosted modele geçtiğinizde, font çağrılarının tamamı kendi alan adınız üzerinden gerçekleşir; üçüncü bir tarafa veri aktarımı ortadan kalkar.

Bu da hem gizlilik politikalarınızı sadeleştirir hem de hukuki risklerinizi azaltır. Özellikle sağlık, hukuk, finans gibi hassas veri işleyen sektörlerde hizmet veriyorsanız, harici font servislerinden uzak durmak makul bir önlem haline geliyor.

Farklı proje tipleri için pratik senaryolar

WordPress siteleri

WordPress dünyasında çoğu premium tema Google Fonts ile entegre gelir. Self‑hosted WOFF2’ye geçmek için tipik akış şöyle:

1. Tema ayarlarında Google Fonts çağrılarını devre dışı bırakmak (mümkünse).
2. Kullandığınız font ailelerini tespit edip WOFF2 olarak projeye eklemek.
3. Child theme veya özel bir CSS dosyasında @font-face tanımlarını yazmak.
4. Header içinde preload etiketleri eklemek.

Büyük WooCommerce mağazalarında, bu değişikliği cache stratejileriyle birlikte ele almak çok daha iyi sonuç veriyor. Örneğin ürün listeleme sayfalarının HTML çıktısını önbelleğe alırken, fontları da agresif cache ile servis etmek; hem TTFB’yi hem de LCP’yi aşağı çeker. Bu yaklaşımı WooCommerce için CDN ve önbellek ayarları rehberimiz ile harmanlayarak güçlü bir yapı kurabilirsiniz.

Statik HTML ve Jamstack projeleri

Statik sitelerde işler daha da basit. Build aşamasında tüm CSS ve font referanslarını kontrol edebildiğiniz için, Google Fonts çağrılarını tamamen kaldırıp kendi WOFF2 dosyalarınıza yönlendirmek oldukça kolaydır. Statik site jeneratörleriyle çalışan müşterilerimizde sıkça yaptığımız pratiklerden bazıları:

• Build pipeline’ına font subset ve WOFF2 dönüştürme adımı eklemek.
• Output klasörü içinde fonts dizinini otomatik oluşturmak.
• CDN önbelleklemesini uzun süreli olacak şekilde ayarlamak.

Statik yapıların hosting tarafındaki avantajlarını Jamstack ve statik site hosting rehberimizde detaylı anlattık. Self‑hosted fontlar, bu mimarinin doğal bir uzantısı gibi düşünülebilir.

SPA, Next.js, Nuxt ve benzeri modern framework’ler

Next.js, Nuxt gibi framework’lerde genellikle bir asset pipeline’ınız zaten vardır. Burada dikkat edilmesi gerekenler:

• Global layout veya _document benzeri dosyalarda preload etiketlerini eklemek.
• CSS‑in‑JS veya module CSS kullanıyorsanız, @font-face tanımlarını tek bir global dosyada toplamak.
• SSR/SSG senaryolarında font dosyalarının build çıktısında gerçekten mevcut olduğundan emin olmak.

DCHost üzerinde bu tür uygulamaları host ederken genellikle font ve diğer statik varlıkları aynı origin’de, ancak ayrı bir path altında (örneğin /_assets) konumlandırmayı öneriyoruz. Bu sayede cache ve güvenlik politikalarını daha rahat yönetebiliyorsunuz.

DCHost tarafında web fontlarını hızlandırmak için neler yapıyoruz?

Altyapı seviyesinde doğru ayarlar yapılmadığında, self‑hosted fontların potansiyelinden tam olarak faydalanmak zorlaşıyor. DCHost olarak sahada en sık uyguladığımız optimizasyonlar şunlar:

• HTTP/2 ve HTTP/3 desteği: Fontlar da dahil tüm statik varlıklar tek bağlantı üzerinden paralel taşınır.
• Brotli ve Gzip sıkıştırma: WOFF2 zaten sıkıştırılmış bir format olsa da, doğru sunucu ayarlarıyla ilave kazançlar elde edilebiliyor.
• Uzun ömürlü cache başlıkları: Font dosyaları için public, max-age=31536000, immutable gibi başlıkları uygulamaya hazır şablonlar ile öneriyoruz.
• NVMe diskler: Yüksek IOPS sayesinde, yoğun trafikli ortamlarda bile font dosyalarına erişim gecikmesi minimumda kalıyor.

Tüm bunlar, sitenizin Core Web Vitals metriklerini toparlarken uygulama katmanında yaptığınız optimizasyonlarla birleştiğinde anlam kazanıyor. Zaten Core Web Vitals’ı hosting tarafında iyileştirmek için hazırladığımız rehberde de vurguladığımız gibi, sunucu ve uygulama optimizasyonu birbirini tamamlayan iki parçadan ibaret.

Kontrol listesi: Google Fonts’tan self‑hosted WOFF2’ye geçerken unutulmaması gerekenler

Yazıyı bitirirken, uygulama sırasında elinizin altında bulunması için kısa ama pratik bir kontrol listesi bırakalım:

• Kullandığınız font ailelerini, ağırlıkları ve stil varyantlarını netleştirin.
• Gereksiz varyantları eleyin; mümkün olduğunca az dosya ile başlayın.
• Fontları TTF/OTF veya doğrudan WOFF2 olarak indirin, gerekirse dönüştürün.
• Projede tutarlı bir fonts klasör yapısı oluşturun.
• @font-face tanımlarını kendi CSS’inizde oluşturun; font-display: swap kullanın.
• Kritik fontlar için preload etiketlerini head içine ekleyin.
• Sunucuda doğru MIME tipleri, cache başlıkları ve sıkıştırma ayarlarını kontrol edin.
• Canlıya almadan önce PageSpeed Insights ve WebPageTest ile test yapın.
• Geçişten sonra Core Web Vitals ve hata loglarını bir süre daha izlemeye devam edin.

Sonuç: Küçük bir adımla büyük bir hız ve kontrol kazanabilirsiniz

Web fontlarını kendiniz host etmek, kâğıt üzerinde ufak bir değişiklik gibi görünse de, pratikte hem performans hem de gizlilik tarafında ciddi kazanımlar sağlayan bir adım. Google Fonts entegrasyonunu kaldırıp self‑hosted WOFF2 yapısına geçtiğinizde; daha düşük LCP, daha hızlı ilk boyama, daha sade bir ağ trafiği ve üçüncü taraflara daha az veri aktarımı elde ediyorsunuz. Üstelik bunu yapmak için devasa bir mimari dönüşüme de ihtiyacınız yok; çoğu zaman doğru dosya yapısı, birkaç @font-face tanımı ve düzgün yapılandırılmış bir web sunucusu yeterli oluyor.

Eğer sitenizi DCHost üzerinde barındırıyor veya projelerinizi yeni bir altyapıya taşımayı planlıyorsanız, font optimizasyonunu genel performans stratejinizin doğal bir parçası haline getirmenizi öneririz. Mevcut hosting paketinizde HTTP/2/3, Brotli, önbellekleme başlıkları ve benzeri konularda nasıl iyileştirmeler yapabileceğinizi birlikte gözden geçirmek isterseniz, ekibimiz bu süreci adım adım planlamanıza yardımcı olabilir. Bugün sadece fontları kendi sunucunuza alarak başlayın; sonrasında görseller, cache ve CDN tarafında yapacağınız ek optimizasyonlarla sitenizi bir üst lige taşımak çok daha kolay hale gelecek.