Çok dilli performans.
Çok dilli bir sitede performansın en büyük değişkeni yazı tipi alt kümeleridir: her dil farklı karakterler gerektirir ve gereksiz karakterler her sayfada indirilir.
Çok dilli olmak performansa doğrudan bir maliyet getirmiyor — dil başına ayrı sayfalar üretiliyor ve her kullanıcı yalnız kendi dilindeki sayfayı indiriyor. Ama bir kalem var ki dikkat edilmezse tüm dillerde birden ağırlık ekliyor: yazı tipi dosyaları.
Bir yazı tipi dosyası varsayılan olarak binlerce karakter taşıyabiliyor. Türkçe, İngilizce ve Almanca için gereken karakter kümesi bunun küçük bir bölümü — ve gereksiz olanlar her sayfada, her kullanıcı için indiriliyor.
Alt küme
Çözüm alt küme üretmek: yazı tipi dosyası yalnız gereken karakterlerle yeniden üretiliyor. Kazanç genelde dramatik — tam bir dosyanın küçük bir yüzdesine inebiliyor.
Hangi alt kümenin gerektiği dillere bağlı. Türkçe için latin ve genişletilmiş latin kümeleri gerekiyor: genişletilmiş küme, Türkçenin noktasız ı, ğ ve ş harflerini içeriyor. Almanca için umlautlar ve eszett aynı kümelerde bulunuyor.
Bu sitede iki yazı tipi ailesi de latin ve genişletilmiş latin alt kümesiyle üretiliyor — Kiril, Yunan ve Vietnamca kümeleri hiç inmiyor. İkisi de değişken yazı tipi, yani tek dosya tüm ağırlıkları ve genişlikleri taşıyor.
- Yalnız gereken kümeleri üret — kullanılmayan alfabeler her sayfada indirilmesin.
- Değişken yazı tipi kullan — altı ağırlık altı dosya yerine tek dosya.
- Dil başına ayrı dosya sunma — kullanıcı dil değiştirdiğinde yeniden indirme olur.
- Aile sayısını sınırla — her aile ek bir istek ve ek bir takas riski.
- Kendi sunucunda barındır — harici host ek bağlantı maliyeti ve gizlilik riski.
Üçüncü madde bir ödünleşim içeriyor: dil başına ayrı dosya, o dilde gereksiz karakterleri tamamen çıkarır ama kullanıcı dil değiştirdiğinde yeni bir dosya iner. Üç dili de latin tabanlı bir sitede tek dosya daha verimli; Kiril ya da Arap alfabesi eklendiğinde denklem değişir.
Diğer kalemler
Yazı tipinin dışında çok dilliliğin performans etkisi sınırlı ama iki nokta dikkat gerektiriyor.
Birincisi metin uzunluğu: Almanca metin daha uzun, dolayısıyla Almanca sayfa biraz daha ağır. Fark küçük ve genelde sıkıştırma tarafından yutuluyor — ama uzun metin daha çok düzen hesabı da demek ve çok uzun sayfalarda ölçülebilir hâle geliyor.
İkincisi görsel içeriği: metin içeren görseller her dil için ayrı üretilmek zorunda ve bu, hem üretim yükü hem depolama demek. Bu, metin içeren görsellerden kaçınmak için performans dışında bir gerekçe daha — erişilebilirlik ve makine-okunurluk gerekçelerine ek olarak.
Bu sitede metin içeren görsel yok; tüm metin metin olarak yazılıyor. Sosyal paylaşım kartları bir istisna ama onlar tarayıcıda üretiliyor ve sayfaya inmiyor.
Ölçüm ve bütçe
Çok dilli bir sitede performans bütçesi dil başına ayrı ölçülmeli. Aynı sayfanın Almanca sürümü daha uzun metin taşıyor, farklı bir yazı tipi genişliği kullanıyor ve bazen farklı görseller içeriyor — üçü de ağırlığı değiştiriyor.
- Her dil ayrı ölçülmeli — tek dilde ölçüp diğerlerini varsaymak yanıltır.
- Yazı tipi alt kümesi doğrulanmalı — dosyada gereksiz alfabe var mı?
- Aile sayısı sınırlı mı — her aile ek istek ve ek takas riski.
- Metin uzunluğu farkı ölçüldü mü — en uzun dil bütçeyi belirler.
- Görseller dil bağımsız mı — metin içeren görsel her dilde ayrı üretim demek.
Dördüncü madde bir ilke içeriyor: bütçe en uzun dile göre konur. Türkçeye göre ayarlanmış bir bütçe Almancada kırılıyorsa bütçe yanlış konmuş demektir.
Bu sitede iki yazı tipi ailesi latin ve genişletilmiş latin alt kümesiyle üretiliyor, ikisi de değişken ve kendi sunucusundan sunuluyor. Ölçülen JavaScript toplamı gzip sonrası 83,7 kilobayt — dilden bağımsız, çünkü kod dilden bağımsız.
Ve bir mimari not: bu sitede sayfalar önceden üretilip dosya olarak sunuluyor, dolayısıyla dil sayısı sunucu maliyetini artırmıyor. Üç dil üç kat sayfa demek ama üç kat işlem demiyor — her sayfa zaten bir dosya.
Dil sayısı ne zaman maliyet olur
Statik üretimde dil sayısı sunucu maliyeti üretmiyor ama üretim süresi ve depolama üretiyor. Üç dilde elli sayfa, yüz elli dosya demek — ve her build hepsini yeniden üretiyor.
Bu, küçük ölçekte fark etmiyor. Bu sitede elli sekiz sayfa saniyeler içinde üretiliyor. Ama bin sayfalık bir site yedi dilde yedi bin dosya demek ve o ölçekte üretim süresi bir sorun hâline gelebiliyor — özellikle her küçük değişiklikte tam yeniden üretim yapılıyorsa.
Çözüm artımlı üretim: yalnız değişen sayfalar yeniden üretiliyor. Bu sitede benzer bir mantık lastmod defteri için zaten kurulu — her sayfanın çıktısı parmak izleniyor ve damga yalnız iz değiştiğinde ilerliyor. Aynı iz, artımlı üretim için de kullanılabilir.
Ve bir son not: dil sayısı arttıkça sitemap, RSS ve harita dosyaları da çoğalıyor. Bu sitede üç dil için üç ayrı RSS beslemesi üretiliyor ve hepsi tek bir üreticiden çıkıyor — elle yönetilmesi mümkün olmayan bir yük, otomasyonla görünmez hâle geliyor.
Kapanışta bir çerçeve: çok dilli olmanın performans maliyeti, doğru kurulduğunda neredeyse sıfır. Maliyet üreten şey dil sayısı değil, dillerin nasıl sunulduğu — yazı tipi alt kümesi, metin içeren görseller ve dinamik üretim. Üçü de tasarım aşamasında verilen kararlar ve üçü de sonradan düzeltilmesi pahalı.
Son bir ölçüm önerisi: her dil sürümünün ağırlığı ayrı raporlanmalı ve aralarındaki fark izlenmeli. Fark beklenenden büyükse bir yerde dile özgü bir yük var demektir — genelde metin içeren bir görsel ya da o dile özgü bir kaynak.
Bu sitede sayfa ağırlıkları üretim çıktısında dil dil listeleniyor ve fark küçük kalıyor; en büyük sapma Almanca sayfalarda ve sebebi bilinen bir sebep — metin uzunluğu.