Web Fontları Siteyi Yavaşlatır mı? Hızlı Font Yükleme Rehberi

Biz Talha Aslan ve ekibi olarak sahada en sık gördüğümüz tablo şudur: tasarımcı güzel bir yazı tipi seçer, geliştirici paketin tamamını ekler ve kimse dosya boyutuna bakmaz. Sonuç olarak ziyaretçi birkaç saniye boyunca boş başlıklar görür ya da metin aniden zıplar. Bu rehberde web fontları için uygulamalı bir yol haritası çiziyoruz. Yani hangi ayarın neyi çözdüğünü, hangi adımı atlarsanız ne kaybettiğinizi tek tek anlatıyoruz.

Tarayıcı font dosyasını hangi sırayla indirir?

Tarayıcı bir fontu hemen indirmez. Önce HTML'i okur, ardından CSS dosyasını indirir ve içindeki @font-face kurallarını görür. Sonra sayfada o fontu gerçekten kullanan bir metin olup olmadığını hesaplar. Ancak bu hesaplamadan sonra font dosyasını ister. Dolayısıyla font, yükleme zincirinin oldukça geç bir halkasında devreye girer.

Bu zincir şu adımlardan oluşur:

1. HTML belgesi gelir ve tarayıcı stil dosyası bağlantısını bulur.
2. CSS dosyası iner; font tanımları burada ortaya çıkar.
3. Tarayıcı sayfa ağacını ve stilleri birleştirir, hangi fontun gerektiğine karar verir.
4. Font dosyası için ağ isteği başlar; dosya başka bir alan adındaysa tarayıcı önce bağlantı kurar.
5. Dosya indikten sonra tarayıcı metni bu fontla yeniden çizer.

Her adım bir öncekini bekler. Örneğin font başka bir alan adından geliyorsa DNS sorgusu, TCP ve TLS el sıkışması da zincire girer. Bu yüzden font optimizasyonu aslında bekleme süresini kısaltma işidir. Dosyayı küçültmek, isteği erkene almak ve bekleme sırasında ne göstereceğinize karar vermek üç ana koldur.

Web fontları hangi Core Web Vitals metriklerini etkiler?

Web fontları en çok iki metriği etkiler: Largest Contentful Paint (LCP, en büyük içerikli boyama) ve Cumulative Layout Shift (CLS, kümülatif düzen kayması). Sayfanın en büyük öğesi çoğu zaman bir başlık ya da metin bloğudur. O metin font beklerken görünmez kalırsa LCP gecikir. Ayrıntılar için LCP rehberimize bakabilirsiniz.

CLS tarafında sorun farklıdır. Tarayıcı önce yedek fontla metni çizer, ardından web fontu gelince metni yeniden çizer. İki yazı tipinin genişliği ve satır yüksekliği farklıysa paragraflar uzar ya da kısalır. Böylece altındaki düğmeler ve görseller yer değiştirir. Bu kaymanın nasıl ölçüldüğünü CLS rehberimiz ayrıntılı anlatıyor.

Etkileşim metriği INP ile fontun ilişkisi ise dolaylıdır. Çok sayıda font dosyası ana iş parçacığını meşgul eden yeniden çizimlere yol açabilir. Ancak pratikte asıl kazancı LCP ve CLS tarafında görürsünüz. Üç metriğin genel çerçevesi için Core Web Vitals yazımıza göz atabilirsiniz.

Font dosya boyutu neden bu kadar önemlidir?

Her font dosyası ağ üzerinden inen bir kaynaktır ve boyutu doğrudan bekleme süresine dönüşür. Bir yazı tipi ailesinde normal, kalın, italik ve kalın italik gibi her stil ayrı bir dosyadır. Üstelik birçok paket yüzlerce, hatta binlerce karakter (glif) içerir. Siz yalnız Türkçe ve İngilizce yayın yapsanız bile Yunanca, Kiril veya Vietnamca karakterleri indirmek zorunda kalabilirsiniz.

web.dev'in font en iyi uygulamaları rehberi, Latin fontlarının yaklaşık 100 ile 1.000 glif, CJK (Çince, Japonca, Korece) fontlarının ise 10.000'den fazla glif içerebildiğini belirtir. Dolayısıyla kullanmadığınız glifleri taşımak, hiç okumayacağınız bir kitabı çantada taşımaya benzer.

Örnek hesap: Bir site dört stil kullanıyor ve her stil sıkıştırılmış halde yaklaşık 40 KB tutuyor. Toplam 160 KB eder. Aynı site iki stile iner ve alt küme uygularsa toplamı belirgin biçimde düşürebilir. Bu rakamlar yalnız örnek hesaptır; gerçek boyut yazı tipine göre değişir. Önemli olan, kendi dosyalarınızın boyutunu tarayıcı geliştirici araçlarında tek tek görmenizdir.

WOFF2 dışında bir formata gerek var mı?

Günümüz projelerinde çoğu zaman gerek yoktur. WOFF2 (Web Open Font Format 2), font dosyaları için tasarlanmış sıkıştırılmış bir formattır ve Brotli sıkıştırması kullanır. web.dev rehberine göre WOFF2 en yeni ve en geniş tarayıcı desteğine sahip formattır; WOFF'a göre yaklaşık yüzde 30 daha iyi sıkıştırma sağlar. Rehberde alıntılanan bir uzman görüşü de yalnız WOFF2 kullanmayı önerir.

Eski projelerde sık gördüğümüz durum şudur: CSS içinde EOT, TTF, SVG ve WOFF dosyaları sıra sıra yer alır. Bu liste artık işe yaramayan bir mirastır. Ayrıca sunucuda gereksiz dosya tutarsınız ve bakım zorlaşır. Bu nedenle font kaynağını tek bir WOFF2 dosyasına indirmek hem kodu sadeleştirir hem de yanlış formatın inme ihtimalini ortadan kaldırır.

Elinizde yalnız TTF veya OTF varsa açık kaynak dönüştürücülerle WOFF2 üretebilirsiniz. Ancak önce lisansa bakın. Bazı ticari lisanslar dosyayı dönüştürmeye ya da web için yeniden paketlemeye izin vermez. Lisans metni web kullanımını açıkça içeriyorsa dönüşüm genellikle sorun yaratmaz; emin değilseniz font satıcısına sorun.

font-display nedir ve hangi değeri seçmelisiniz?

font-display, @font-face kuralına eklediğiniz ve font gelene kadar tarayıcının ne yapacağını belirleyen bir CSS tanımlayıcısıdır. MDN belgesine göre font zaman çizelgesi üç dönemden oluşur: engelleme (block), değiştirme (swap) ve başarısızlık (failure) dönemi.

Engelleme döneminde metin görünmez bir yedek fontla çizilir. Değiştirme döneminde metin görünür bir yedek fontla çizilir ve font gelince değişir. Başarısızlık döneminde ise tarayıcı fontu yüklenemedi sayar ve yedekte kalır. Yani her değer bu üç dönemin uzunluğunu farklı ayarlar.

Pratik seçim kuralımız şöyledir. Marka kimliği için fontun mutlaka görünmesi gerekiyorsa swap seçin; metin hemen görünür, font gelince değişir. Hız ve kararlılık öncelikliyse optional seçin; font çok kısa sürede gelmezse tarayıcı o sayfa görüntülemesinde yedekte kalır. Gövde metni için çoğu projede optional ya da fallback iyi sonuç verir. Başlık fontu için ise swap ile birlikte yedek font ayarı yapmanızı öneririz.

font-display değerleri karşılaştırma tablosu

Aşağıdaki tablo MDN ve web.dev açıklamalarını tek yerde toplar. Süreler tarayıcıya göre değişebileceği için kesin milisaniye yerine göreli ifadeler kullandık.

web.dev rehberi performans için optional değerini, metnin hızlı görünüp web fontunu da kullanması gereken durumlar için swap değerini önerir. Bizim deneyimimiz de bu yöndedir.

Alt küme (subset) ile web fontları nasıl küçülür?

Alt küme (subset), font dosyasından sitenizde hiç kullanılmayan glifleri çıkarma işlemidir. Sonuçta yalnız gerekli harfleri, rakamları ve işaretleri içeren daha küçük bir dosya elde edersiniz. web.dev rehberi bu iş için subfont ve glyphhanger gibi açık kaynak araçları anar.

Türkçe bir site için alt küme hazırlarken şu karakterleri asla unutmayın:

• Küçük ve büyük ç, ğ, ı, İ, ö, ş, ü harfleri.
• Türk lirası simgesi, yüzde, derece ve para birimi işaretleri.
• Tırnak, kesme işareti ve kısa çizgi gibi tipografik işaretler.
• İngilizce ya da Almanca sürüm varsa ä, ß gibi harfler.
• Formlarda kullanıcının yazabileceği özel karakterler.

En sık hata, alt kümeyi yalnız İngilizce karakterlerle yapmaktır. Bu durumda tarayıcı ğ ya da ş harfini yedek fonttan çizer. Böylece kelimenin ortasında farklı görünen harfler oluşur. Bu nedenle alt kümeyi oluşturduktan sonra tüm Türkçe harfleri içeren bir test sayfasında mutlaka kontrol edin. Ayrıca kullanıcı yorumları gibi dinamik içerik varsa alt kümeyi biraz geniş tutun.

unicode-range Türkçe karakterlerde nasıl çalışır?

unicode-range, bir font dosyasının hangi karakter aralığını kapsadığını tarayıcıya söyleyen tanımlayıcıdır. Tarayıcı sayfada o aralıkta bir karakter görmezse dosyayı hiç indirmez. Dolayısıyla tek bir büyük dosya yerine, örneğin temel Latin ve genişletilmiş Latin olarak iki küçük dosya sunabilirsiniz.

Burada Türkçeye özgü bir tuzak vardır. Temel Latin aralığı ş, ğ ve ı harflerini içermez; bu harfler genişletilmiş Latin aralığındadır. Neredeyse her Türkçe sayfada bu harfler geçtiği için ikinci dosya da hemen her sayfada iner. Yani Türkçe sitede bölmenin kazancı sınırlı kalabilir. Ancak çok dilli sitelerde, örneğin Kiril ya da Yunan alfabesi kullanan sürümler varsa, unicode-range gerçekten fark yaratır.

web.dev rehberi önemli bir ayrıntıya da dikkat çeker: preload işlemi unicode-range bildirimlerini dikkate almaz. Yani bir alt küme dosyasını önceden yüklerseniz, sayfa o karakterleri kullanmasa bile dosya iner. Bu yüzden preload'u yalnız gerçekten her sayfada gereken dosya için kullanın.

Preload ve preconnect ne zaman işe yarar?

Preload, tarayıcıya bir kaynağı CSS'i beklemeden erkenden indirmesini söyleyen bağlantı ipucudur. Font zincirin geç halkası olduğu için, en kritik font dosyasını preload ile öne çekmek LCP'yi iyileştirebilir. Ancak web.dev'in uyardığı gibi preload, diğer kaynakların bant genişliğini de paylaşır. Her fontu önceden yüklerseniz görselleri ve stilleri geciktirirsiniz.

Preconnect ise dosyayı değil bağlantıyı erkene alır. Font başka bir alan adındaysa DNS, TCP ve TLS adımlarını önceden tamamlar. Google Fonts örneğinde stil dosyası bir alan adından, font dosyaları başka bir alan adından gelir. web.dev, font dosyalarının CORS ile yüklendiğini, bu yüzden font alan adı için preconnect bağlantısına crossorigin özniteliği eklenmesi gerektiğini belirtir.

Kısa kuralımız şudur: Fontları kendi sunucunuzda barındırıyorsanız preconnect gereksizdir, çünkü bağlantı zaten açıktır. Web fontları bu durumda sayfayla aynı bağlantıdan gelir. Bu durumda yalnız ilk ekranda görünen başlık fontu için tek bir preload yeterlidir. Üçüncü taraf kaynak kullanıyorsanız preconnect ekleyin, preload'u ise ölçerek karar verin.

Fontları yerel barındırmak mı, Google Fonts kullanmak mı daha hızlı?

Kesin bir kazanan yoktur. web.dev rehberi, kendi sunucunuzda barındırmanın üçüncü taraf fontlardan her zaman daha hızlı olmadığını açıkça söyler. Yerel barındırmada önce bir CDN (içerik dağıtım ağı) ve HTTP/2 kullandığınızı doğrulamanızı, ardından alt küme ve WOFF2 uygulamanızı önerir.

Eskiden üçüncü taraf fontların bir avantajı vardı: ziyaretçi başka sitede aynı fontu indirmişse önbellekten gelirdi. Ancak modern tarayıcılar önbelleği siteye göre böldüğü için bu avantaj büyük ölçüde ortadan kalktı. Böylece ek alan adı bağlantısı daha belirgin bir maliyete dönüştü.

Web fontları konusunda bizim pratikteki tercihimiz çoğu kurumsal projede yerel barındırmadır. Çünkü dosyayı kendi alan adınızdan sunduğunuzda ek bağlantı kurulmaz, önbellek sürelerini siz belirlersiniz ve alt kümeyi tam istediğiniz gibi hazırlarsınız. Üstelik bir sonraki bölümde anlatacağımız gizlilik tartışmasının da dışında kalırsınız. Yine de sunucunuz yavaşsa ve CDN yoksa ölçmeden karar vermeyin.

Google Fonts ve GDPR tartışması ne anlatıyor?

Tartışmanın özü şudur: Fontu üçüncü taraf sunucudan yüklediğinizde ziyaretçinin tarayıcısı o sunucuya bağlanır ve IP adresi gibi teknik veriler karşı tarafa ulaşır. Avrupa Birliği'nin GDPR (Genel Veri Koruma Tüzüğü) çerçevesinde IP adresi kişisel veri sayılabildiği için, bu aktarımın hukuki dayanağı Avrupa'da, özellikle Almanya'da tartışma konusu oldu.

Bu konu hukuki bir yorumdur ve buradaki bilgiler hukuki danışmanlık değildir. Kendi durumunuz için bir avukata ya da veri koruma uzmanına danışın. Teknik tarafta ise sade bir çıkış yolu vardır: fontları kendi sunucunuzdan sunmak. Bu durumda ziyaretçi font için üçüncü taraf sunucuya bağlanmaz. Genel uyum adımları için KVKK ve GDPR uyumlu web sitesi rehberimize bakabilirsiniz.

Dikkat etmeniz gereken bir nokta daha vardır. Fontu yerel barındırdığınızı düşünürken bir eklenti, tema ya da harita bileşeni aynı fontu yine dış kaynaktan çağırabilir. Bu yüzden geliştirici araçlarının ağ sekmesinde font isteklerini filtreleyin ve hangi alan adından geldiklerine bakın. Örneğin WordPress sitelerde bu tür gizli çağrılara sık rastlıyoruz.

Değişken fontlar web fontları için avantaj mı?

Değişken font (variable font), birden çok stili tek dosyada toplayan ve stiller arasında kesintisiz geçiş sağlayan font türüdür. web.dev değişken font rehberi, beş kayıtlı ekseni şöyle sıralar: ağırlık (wght), genişlik (wdth), eğim (slnt), optik boyut (opsz) ve italik (ital). Tasarımcılar bunlara özel eksenler de ekleyebilir.

Avantaj, kullandığınız stil sayısına bağlıdır. Sitede altı farklı ağırlık kullanıyorsanız tek değişken dosya, altı ayrı isteğin yerini alır. Ancak web.dev aynı rehberde değişken fontların çoğu zaman tek stilli dosyalardan büyük olduğunu da belirtir. Yani yalnız normal ve kalın kullanan bir site için iki statik dosya daha hafif kalabilir.

Karar için şu soruları sorun:

• Sitede kaç farklı ağırlık ve genişlik gerçekten kullanılıyor?
• Tasarım ara ağırlıklara, örneğin 450 ya da 650 değerlerine ihtiyaç duyuyor mu?
• Değişken dosyanın sıkıştırılmış boyutu, statik dosyaların toplamından küçük mü?
• Dosyaya alt küme uygulayabiliyor musunuz?

Bu soruların çoğuna evet diyorsanız değişken font iyi bir seçimdir. Aksi halde iki statik WOFF2 dosyası daha akılcıdır.

Yedek font ve size-adjust ile kaymayı nasıl azaltırsınız?

Yedek font (fallback font), web fontu gelene kadar ya da hiç gelmezse tarayıcının kullandığı sistem yazı tipidir. Kayma, yedek ile web fontu arasındaki ölçü farkından doğar. Bu farkı küçültmek için @font-face içinde size-adjust tanımlayıcısını kullanabilirsiniz. web.dev rehberi bu tanımlayıcıyı yedek ve web fontu arasındaki kaymayı azaltmak için önerir.

Yöntem kısaca şöyledir. Arial gibi yaygın bir sistem fontunu yerel kaynak olarak gösteren ikinci bir @font-face kuralı yazarsınız. Ardından size-adjust ile bu yedeği, web fontunun genişliğine yaklaştıracak bir yüzdeyle büyütür ya da küçültürsünüz. İsterseniz ascent-override ve descent-override ile satır yüksekliğini de eşitlersiniz. Böylece font değiştiğinde paragraflar neredeyse aynı yerde kalır.

Örnek senaryo: Başlık fontu dar, yedek font ise geniş. Mobilde iki satırlık başlık yedekle üç satıra çıkıyor ve font gelince iki satıra iniyor. Altındaki düğme her açılışta zıplıyor. size-adjust ile yedeği daraltınca başlık baştan iki satır kalıyor. Bu ayar birkaç satır CSS'tir, ancak CLS üzerinde belirgin bir fark yaratabilir.

Sistem fontu yığını ne zaman daha mantıklı?

Sistem fontu yığını (system font stack), ziyaretçinin cihazında zaten yüklü yazı tiplerini sırayla listeleyen bir font-family tanımıdır. Hiçbir dosya inmediği için en hızlı seçenektir. Örneğin yönetim panelleri, iç araçlar ve yoğun veri tabloları için çoğu zaman en doğru tercihtir.

Ancak sistem fontları marka karakteri taşımaz ve cihaza göre farklı görünür. Bu nedenle bizim önerimiz karma bir yaklaşımdır: başlıklarda marka fontunu kullanın, gövde metninde sistem fontunu kullanın. Böylece marka algısını korursunuz, en çok metni içeren alan ise hiç beklemeden görünür.

Hangi yaklaşımı seçeceğiniz okunabilirlik kararıyla da ilgilidir. Yazı tipi seçerken neye bakmanız gerektiğini web tipografisi seçim rehberimizde anlattık. Burada yalnız şunu vurgulayalım: hız ile marka arasında seçim yapmak zorunda değilsiniz, doğru dağılım ikisini de korur.

İkon fontları ve gereksiz ağırlıklar neden sorun çıkarır?

İkon fontu, simgeleri harf gibi bir font dosyasında saklayan yöntemdir. Çoğu paket yüzlerce ikon içerir, oysa siteler genellikle yalnız birkaçını kullanır. Ayrıca ikon fontu gelmezse ekranda anlamsız kareler ya da harfler görünür. Ekran okuyucular da bu karakterleri yanlış okuyabilir.

Bu nedenle ikonlar için satır içi SVG ya da tek tek SVG dosyaları çoğu zaman daha iyi sonuç verir. Yalnız kullandığınız simgeleri taşırsınız ve her birine anlamlı bir erişilebilir ad verebilirsiniz.

Gereksiz ağırlık sorunu da benzerdir. Tasarım dosyasında ince, normal, orta, yarı kalın, kalın ve siyah ağırlıklar tanımlıdır. Ancak canlı sitede çoğu zaman yalnız ikisi ya da üçü kullanımdadır. Bu yüzden ekibimiz web fontları için her projede CSS'teki font-weight değerlerini tarar ve kullanılmayan ağırlıkları paketten çıkarır. Bu basit temizlik bazen tek başına toplam font boyutunu yarıya indirir; kesin oran projeye göre değişir.

Font performansını nasıl ölçersiniz?

Ölçmeden yaptığınız optimizasyon tahminden ibarettir; web fontları için de durum aynıdır. İlk adım tarayıcı geliştirici araçlarının ağ sekmesidir: yalnız font türünü filtreleyin, kaç dosya indiğini, boyutlarını ve hangi alan adından geldiklerini not edin. İkinci adım Lighthouse raporudur. Raporun nasıl okunacağını Lighthouse ile performans testi rehberimizde adım adım anlattık.

Ölçerken şu noktalara bakın:

• Font dosyaları ilk ekranı çizen istekler arasında ne zaman başlıyor?
• LCP öğesi metin mi, yoksa görsel mi?
• Yavaş ağ simülasyonunda metin kaç saniye görünmez kalıyor?
• Font geldiğinde sayfada kayma oluşuyor mu?
• Aynı font iki farklı kaynaktan iniyor mu?

Laboratuvar ölçümü yön gösterir, ancak gerçek kullanıcı verisi kararı verir. Search Console'daki Core Web Vitals raporu ve sahadaki veriler, değişikliğinizin gerçek ziyaretçide işe yarayıp yaramadığını gösterir. Hızlı bir genel tarama için SEO analiz aracımızı da kullanabilirsiniz.

Örnek senaryo: kurumsal bir sitede font diyetini nasıl uygularsınız?

Aşağıdaki akış gerçek bir müşteri vakası değil, sık karşılaştığımız durumları birleştiren örnek bir senaryodur. Bir kurumsal site iki yazı tipi ailesi kullanıyor. Başlık ailesinden dört, gövde ailesinden beş stil iniyor. Fontlar üçüncü taraf sunucudan geliyor ve font-display tanımlı değil.

1. Ekip önce ağ sekmesinde dokuz font isteğini ve toplam boyutu kaydediyor.
2. CSS taramasıyla yalnız beş stilin gerçekten kullanıldığını buluyor.
3. Lisansı kontrol edip fontları WOFF2 olarak yerel sunucuya taşıyor.
4. Türkçe ve İngilizce karakterleri içeren bir alt küme hazırlıyor.
5. Başlık fontuna swap, gövde fontuna optional atıyor.
6. Başlık için size-adjust ile ayarlı bir yedek tanımlıyor.
7. Yalnız ilk ekrandaki başlık fontuna preload ekliyor.
8. Lighthouse ve saha verisiyle önceki ölçümleri karşılaştırıyor.

Bu senaryoda beklenen sonuç, daha az istek, daha küçük toplam boyut ve daha kararlı bir düzendir. Ancak kazancın büyüklüğü sunucuya, temaya ve içeriğe bağlıdır; burada bir rakam vaat etmiyoruz. Önemli olan sıradır: önce ölçüm, sonra temizlik, en son ince ayar.

Hızlı font yükleme kontrol listesi

Yeni bir site kurarken ya da mevcut siteyi iyileştirirken bu listeyi sırayla uygulayın:

• Kullanılan aile ve stil sayısını en aza indirin; çoğu site için iki aile ve üç dört stil yeterlidir.
• Yalnız WOFF2 formatı sunun.
• Türkçe karakterleri içeren bir alt küme hazırlayın ve test edin.
• Her @font-face kuralına bilinçli bir font-display değeri yazın.
• Lisans izin veriyorsa fontları kendi alan adınızdan sunun.
• Üçüncü taraf kaynak kullanıyorsanız crossorigin ile preconnect ekleyin.
• Yalnız ilk ekrandaki kritik font için preload kullanın.
• size-adjust ile yedek fontu web fontuna yaklaştırın.
• İkon fontu yerine SVG simgeler kullanın.
• Font dosyalarına uzun önbellek süresi verin.
• Eklenti ve temaların gizli font çağrılarını ağ sekmesinden kontrol edin.
• Değişiklikten önce ve sonra Lighthouse ile saha verisini karşılaştırın.

Bu listeyi kendi sitenizde uygulamak zaman alıyorsa, web tasarım hizmetimiz kapsamında font kurulumunu baştan hız odaklı yapıyoruz. Sitenizin yapısını paylaşırsanız size kapsamlı bir teklif hazırlarız.

Web fontları konusunda sık yapılan hatalar nelerdir?

Sahada en çok gördüğümüz hatalar birbirine benzer. Birincisi, yazı tipi ailesinin tamamını, tüm stilleriyle eklemektir. İkincisi, web fontları için font-display değerini hiç yazmamaktır; bu durumda davranışı tarayıcı belirler. Üçüncüsü, aynı fontu hem tema hem eklenti üzerinden iki kez yüklemektir.

Dördüncü hata, her font dosyasına preload eklemektir. Bu ayar kritik kaynakları önceliklendirmek yerine sırayı tıkar. Beşincisi, alt kümeyi Türkçe karakterleri unutarak oluşturmaktır. Altıncısı ise yerel barındırmaya geçip önbellek başlıklarını ayarlamamaktır; böylece tarayıcı her ziyarette dosyayı yeniden doğrulamak zorunda kalır.

Son olarak, tasarım aşamasını hızdan bağımsız düşünmek de bir hatadır. Font kararı, tasarımın ilk gününde performans bütçesiyle birlikte verilmelidir. Bu yüzden biz font seçimini, kaç stil kullanılacağını ve yükleme stratejisini aynı toplantıda konuşuruz. E-ticaret sitelerinde bu kararın özel ayrıntıları için yazımıza bakabilirsiniz.

Font kararını tasarım sürecinin neresinde vermelisiniz?

En doğru an, tasarımın başladığı gündür. Font seçimi bittikten sonra hız düşünülürse ya tasarım bozulur ya da hız kaybolur. Bu nedenle tasarım rehberinde yazı tipiyle birlikte izinli stil sayısını, yükleme yöntemini ve yedek fontu da yazın. E-ticaret font seçimi yazımız bu kararı mağaza açısından ele alıyor.

Tasarımcı ile geliştiricinin ortak bir dili olmalıdır. Örneğin tasarımcı yeni bir ağırlık eklemek istediğinde bunun bir dosya daha anlamına geldiğini bilmelidir. Geliştirici de marka fontunu sistem fontuyla değiştirmeden önce tasarım ekibine danışmalıdır. Böylece iki taraf da kararın ortağı olur.

Yeni sitenizi baştan hızlı ve tutarlı kurmak istiyorsanız, web tasarım ekibimizden teklif isteyebilirsiniz. Font, görsel ve kod kararlarını tek bir performans bütçesinde topluyoruz.

Sonuç: hızlı font yükleme için hangi sırayı izlemelisiniz?

Kısacası web fontları kendi başına düşman değildir; kontrolsüz yükleme düşmandır. Önce ölçün ve gerçekten kullanılan stilleri belirleyin. Ardından WOFF2 ve alt küme ile dosyaları küçültün. Sonra font-display, preload ve yedek font ayarıyla bekleme süresini yönetin. Son olarak gizlilik tarafını değerlendirip yerel barındırmayı düşünün.

Bu sırayı izlerseniz hem marka kimliğinizi korur hem de ziyaretçinize boş ya da zıplayan bir ekran göstermezsiniz. Üstelik her adım ölçülebilir olduğu için, yaptığınız değişikliğin işe yarayıp yaramadığını rapor üzerinden görebilirsiniz.