Yazı Tipi Yükleme Etkisini Azaltmanın Yeni Bir Yolu: CSS Yazı Tipi Tanımlayıcıları

Yazı tipi yükleme, uzun zamandır web performansının bir baş belası olmuştur ve burada gerçekten iyi bir seçenek yoktur. Web yazı tiplerini kullanmak istiyorsanız, seçenekleriniz temel olarak, metnin yazı tipi indirilene kadar gizlendiği Görünmez Metin Flash (aka FOIT) veya başlangıçta geri dönüş sistemi yazı tipini kullandığınız ve ardından onu yeni sürüme yükselttiğiniz Stilsiz Metin Flash (FOUT) seçenekleridir. indirildiğinde web yazı tipi. Dürüst olmak gerekirse, hiçbiri gerçekten tatmin edici olmadığı için hiçbir seçenek gerçekten “kazanmadı”.

font-display Bunu Çözmesi Gerekmiyor muydu?

@font-face için font-display özelliği bu seçeneği web geliştiricisine verirken, daha önce tarayıcı buna karar vermişti (geçmişte IE ve Edge FOUT'u tercih ederken, diğer tarayıcılar FOIT'i tercih ediyordu). Ancak, bunun ötesinde, sorunu gerçekten çözmedi.

Birkaç site font-display: swap bu ilk çıktığında ve hatta Google Fonts onu 2019'da varsayılan haline getirdi. Buradaki düşünce, performansın metni olabildiğince hızlı göstermesinin daha iyi olduğuydu. yedek yazı tipindedir ve ardından nihayet indirildiğinde yazı tipini değiştirmek için.

O zamanlar ben de bunu destekliyordum, ancak web yazı tipi indirildiğinde ve yazı tipleri arasındaki farklılıklar nedeniyle karakterler genişlediğinde (veya daraldığında) "hidrasyon etkisinden" giderek daha fazla hayal kırıklığına uğradım. Smashing Magazine, çoğu yayıncı gibi, web yazı tiplerini kullanır ve aşağıdaki ekran görüntüsü, ilk oluşturma (yedek yazı tipleriyle) ve son oluşturma (web yazı tipleriyle) arasındaki farkı gösterir:

Şimdi, yan yana konulduğunda, web yazı tipleri çok daha güzel ve Smashing Magazine markasına uyuyor. Ancak, iki yazı tipiyle metin düzeninde oldukça fark olduğunu da görüyoruz. Yazı tipleri çok farklı boyutlardadır ve bu nedenle ekran içeriği değişir. Önemli Web Verileri ve Kümülatif Düzen Değişikliklerinin (haklı olarak!) kullanıcılara zararlı olarak kabul edildiği bu çağda, font-display: swap bu nedenle kötü bir seçimdir.

font-display: block block'a geri döndüm çünkü baktığım sitelerde metin kaymasını oldukça sarsıcı ve sinir bozucu buluyorum. block kaymaları durdurmadığı doğru olsa da (yazı tipi hala görünmez metinde işlenir), en azından kullanıcı tarafından daha az fark edilir hale getirir. Ayrıca, kendi kendine barındırılan alt küme yazı tipleriyle mümkün olduğunca küçük yaptığım yazı tiplerini önceden yükleyerek yazı tipi yükleyerek optimize ettim - bu nedenle ziyaretçiler genellikle yedek yazı tiplerini yalnızca küçük bir süre için gördüler. Bana göre, swap “blok süresi” çok kısaydı ve dürüst olmak gerekirse, ilk renderin doğru olması için biraz daha beklemeyi tercih ederim.

font-display: optional FOIT ve FOUT'u Çözebilir - Bir Maliyetle

Diğer seçenek font-display: optional . Bu seçenek, temel olarak web yazı tiplerini isteğe bağlı hale getirir veya başka bir deyişle, yazı tipi sayfanın ihtiyaç duyduğu anda orada değilse, o zaman onu asla değiştirmemek tarayıcıya bağlıdır. Bu seçenekle, temelde yalnızca önceden indirilmiş yazı tiplerini kullanarak hem FOIT hem de FOUT'tan kaçınırız .

Web yazı tipi mevcut değilse, yedek yazı tipine geri döneriz, ancak sonraki sayfada gezinme (veya bu sayfanın yeniden yüklenmesi) yazı tipini kullanır - o zamana kadar indirmeyi bitirmiş olması gerektiği gibi. Ancak, web yazı tipi site için o kadar önemsizse, onu tamamen kaldırmak iyi bir fikir olabilir - bu, web performansı için daha da iyidir!

İlk izlenimler önemlidir ve bu ilk yükün web yazı tipleri olmadan tamamen olması biraz fazla gibi görünüyor. Ben de düşünüyorum - bu arada bunu destekleyecek kesinlikle hiçbir kanıt yok! — insanlara, belki de bilinçaltında, web sitesinde bir şeylerin "yanlış" olduğu ve insanların web sitesini nasıl kullandığını etkileyebileceği izlenimini vereceği.

Bu nedenle, web yazı tiplerini hiç kullanmama veya sistem yazı tiplerini kullanma seçeneği de dahil olmak üzere tüm yazı tipi seçeneklerinin dezavantajları vardır (ki bu sınırlayıcıdır - ama belki de pek çok kişinin düşündüğü kadar sınırlayıcı değildir!).

Fallback Yazı Tipinizi Yazı Tipinize Daha Yakın Hale Getirme

Web yazı tipi yüklemenin kutsal kâsesi, fark edilebilir kaymayı mümkün olduğunca azaltmak için yedek yazı tipini gerçek web yazı tipine yaklaştırmak ve böylece swap kullanımının daha az etkili olması olmuştur. Geçişlerden asla tamamen kaçınamayacak olsak da, yukarıdaki ekran görüntüsünden daha iyisini yapabiliriz. Monica Dinculescu'nun Font Style Matcher uygulaması, yazı tipi yükleme makalelerinde sıklıkla alıntılanır ve burada nelerin mümkün olabileceğine dair harika bir fikir verir. Ne kadar farklı olduklarını görmek için aynı metni iki farklı yazı tipinde kaplamanıza ve yazı tipi ayarlarını daha yakın hizalanacak şekilde ayarlamanıza yardımcı olur:

Ne yazık ki, yazı tipi stili eşleşmesiyle ilgili sorun, bu CSS stillerinin yalnızca yedek yazı tiplerine uygulanamamasıdır, bu nedenle web yazı tipi yükleri

Kod miktarı çok büyük değil, ancak yine de olması gerekenden biraz daha fazla çaba gibi geliyor. Zach Leatherman tarafından 2019'daki bu harika konuşmada açıklandığı gibi bunun için JavaScript API'sini kullanmanın başka avantajları ve olasılıkları olsa da - yeniden akışları azaltabilir ve data-server modunu yönetebilir ve bununla birlikte prefers-reduced-motion edebilirsiniz (ancak unutmayın o konuşmadan beri her ikisi de CSS'ye maruz kaldı).

Çeşitli geri dönüş stillerindeki farklılıklar bir yana, halihazırda sahip olduğumuz önbelleğe alınmış yazı tiplerini işlemek de daha zordur. Burada, Smashing Magazine'de, farklı kullanıcıların ve işletim sistemlerinin yüklediği sistem yazı tiplerinden en iyi şekilde yararlanmak için bir dizi geri dönüş deniyoruz:

 font-family: Mija,-apple-system,Arial,BlinkMacSystemFont,roboto slab,droid serif,segoe ui,Ubuntu,Cantarell,Georgia,serif;

Hangi yazı tipinin kullanıldığını bilmek veya her biri için ayrı ayarlara sahip olmak ve bunların doğru uygulanmasını sağlamak hızla oldukça karmaşık hale gelebilir.

Daha İyi Bir Çözüm Geliyor

Bu, bugün itibariyle işlerin nerede durduğuna dair kısa bir özet. Ancak ufukta bir miktar duman görünmeye başlıyor.

Fontlar için CSS "size-adjust" tanımlayıcısı için heyecanlıyım: glifler için bir ölçek faktörü (yüzde) aracılığıyla bir yedek yazı tipini ve birincil web yazı tipini eşleştirerek mizanpaj kaymalarını azaltın.

Bir demo için @cramforce tarafından https://t.co/mdRW2BMg6A adresine bakın (Chrome Canary/FF Nightly with flags) pic.twitter.com/hEg1HfUJlT

— Addy Osmani (@addyosmani) 22 Mayıs 2021

Daha önce de belirttiğim gibi, geri dönüş stili farklılıklarının uygulanmasındaki ana sorun, bunları eklemek ve ardından kaldırmaktı. Tarayıcıya bu farklılıkların yalnızca yedek yazı tipleri için olduğunu söyleyebilseydik ne olurdu?

CSS Fonts Modülü Seviye 5'in bir parçası olarak önerilen yeni bir font tanımlayıcı seti tam olarak bunu yapıyor. Bunlar, tek tek yazı tipinin tanımlandığı @font-face bildirimlerine uygulanır.

Simon Hearne, dört yeni tanımlayıcı içeren yazı tipi-yüz tanımlayıcıları spesifikasyonuna yönelik bu önerilen güncelleme hakkında yazmıştır: ascent-override , descent-override , line-gap-override ve advance-override (düşürüldükten sonra). Özel ve yedek yazı tiplerinizi yüklemek için Simon'ın oluşturduğu F-mods oyun alanıyla oynayabilir, ardından mükemmel bir eşleşme elde etmek için geçersiz kılmalarla oynayabilirsiniz.

Simon'ın yazdığı gibi, bu dört tanımlayıcının birleşimi, web yazı tipiyle eşleşmesi için geri dönüş yazı tipinin düzenini geçersiz kılmamıza izin verdi, ancak bunlar yalnızca dikey aralığı ve konumlandırmayı gerçekten değiştirir. Bu nedenle karakter ve harf aralığı için ek CSS sağlamamız gerekecek.

Ama işler yine değişiyor gibi. Son zamanlarda, glifler için bir ölçek faktörü (yüzde) aracılığıyla bir geri dönüş yazı tipini ve birincil web yazı tipini eşleştirerek düzen kaymalarını azaltmamıza olanak tanıyan yaklaşan size-adjust tanımlayıcısının lehine advance-override kaldırıldı.

O nasıl çalışır? Diyelim ki aşağıdaki CSS'ye sahipsiniz:

 @font-face { font-family: 'Lato'; src: url('/static/fonts/Lato.woff2') format('woff2'); font-weight: 400; } h1 { font-family: Lato, Arial, sans-serif; }

O zaman yapacağınız şey Arial yedek yazı tipi için bir @font-face oluşturmak ve ona ayarlayıcı tanımlayıcıları uygulamaktır. Ardından aşağıdaki CSS parçacığını alacaksınız:

 @font-face { font-family: 'Lato'; src: url('/static/fonts/Lato.woff2') format('woff2'); font-weight: 400; } @font-face { font-family: "Lato-fallback"; size-adjust: 97.38%; ascent-override: 99%; src: local("Arial"); } h1 { font-family: Lato, Lato-fallback, sans-serif; }

Bu, başlangıçta Lato-fallback kullanıldığında (Arial local bir yazı tipi olduğundan ve herhangi bir ek indirme olmadan hemen kullanılabildiğinden), size-adjust ve ascent-override ayarlarının bunu Lato yazı tipine yaklaştırmanıza izin verdiği anlamına gelir. Yazması fazladan bir @font-face bildirimi, ancak kesinlikle daha önce atlamamız gereken çemberlerden çok daha kolay!

Genel olarak, bu spesifikasyona dahil edilen dört ana @font-face tanımlayıcısı vardır: size-adjust , ascent-override , descent-override ve line-gap-override , alt simge, üst simge ve diğer kullanım durumları için hala değerlendirilen birkaç tane daha vardır. .

Malte Ubl, iki yazı tipi ve bu yeni ayarları destekleyen bir tarayıcı ile bu ayarları otomatik olarak hesaplamak için çok kullanışlı bir araç yarattı (birazdan daha fazlası!). Malte'nin belirttiği gibi, bilgisayarlar bu tür şeylerde iyidir! İdeal olarak, ortak yazı tipleri için bu ayarları web geliştiricilerine de gösterebiliriz, örneğin bu ipuçlarını Google Yazı Tipleri gibi yazı tipi koleksiyonlarında verebilir miyiz? Bu kesinlikle benimsenmeyi artırmaya yardımcı olacaktır.

Artık farklı işletim sistemleri biraz farklı yazı tipi ayarlarına sahip olabilir ve bunları tam olarak doğru yapmak temelde imkansız bir iştir, ancak amaç bu değildir. Amaç, font-display: swap artık çok sarsıcı bir deneyim değil, ancak optional veya web fontsuz aşırı uçlara gitmemize gerek yok.

Bunu Ne Zaman Kullanmaya Başlayabiliriz?

Bu ayarlardan üçü, sürüm 87'den beri Chrome'da zaten gönderilmiştir , ancak anahtar size-adjust tanımlayıcısı henüz herhangi bir kararlı tarayıcıda mevcut değildir. Bununla birlikte, Chrome Canary'de olduğu gibi, Firefox'ta bir bayrağın arkasında olduğu için bu, soyut, uzak bir kavram değil, çok yakında ortaya çıkabilecek bir şey.

Şu anda, teknik özellik, henüz gerçek zamanlıya hazır olmadığına dair her türlü sorumluluk reddi ve uyarıya sahip, ancak kesinlikle oraya varmış gibi hissettiriyor. Her zaman olduğu gibi, biz tasarımcılar ve geliştiriciler arasında, onu test eden ve geri bildirimde bulunan ve kullanımını caydıran bir denge var, bu nedenle uygulama, çok fazla insan daha önceki bir taslağı kullandığı için çıkmaza girmez.

Chrome, 20 Temmuz'da piyasaya sürüleceği için Chrome 92'de size-adjust kullanıma sunma niyetlerini belirtti ve muhtemelen neredeyse orada olduğunu gösteriyor.

Yani, henüz tam olarak hazır değil, ancak çok yakın bir zamanda gelecek gibi görünüyor. Bu arada, Chrome Canary'deki demoyu oynayın ve yazı tipi yükleme sorunlarınızı ve bunların neden olduğu CLS etkisini ele almaya biraz daha yaklaşıp yaklaşamayacağını görün.