Çok dilli bir site başlatmak ile onu ölçeklendirmek arasındaki farkı en erken hissettiren şeylerden biri performanstır. İki dil sürümüyle sorunsuz çalışan yapı, beşe geçildiğinde yavaşlamaya başlar; ona ulaşıldığında ise öngörülmemiş darboğazlar gün yüzüne çıkar. Bu yavaşlamanın belirgin bir nedeni çoğu zaman yoktur—bundle yapılandırma hatası, önbellek politikası açığı ya da çeviri paketlerinin yanlış yönetimi birbirinin üstüne binip sessizce büyüyebilir.
Çok dilli performans meselesi, sıradan hız optimizasyonundan farklı bir boyut taşır. Standart bir sitede geliştirici tek bir URL ağacında kararlar alır. Çok dilli yapıda ise her karar dil sayısıyla çarpılır: bir JavaScript paketi kötü yapılandırıldığında bunu beş dil sürümü ayrı ayrı öder. Hata izole değil, çoğaltılmıştır.
Performans ile SEO arasındaki doğrudan ilişki bu noktada açığa çıkar. Google her dil sürümünü bağımsız bir URL olarak değerlendirir; dolayısıyla Türkçe sürüm için ölçülen Core Web Vitals skoru yalnızca Türkçe sıralamayı etkiler. Hız kazanımları veya kayıpları dil sürümleri arasında otomatik aktarılmaz—her sürümün kendi bağlamında izlenmesi gerekir.
Dil sayısı arttıkça yük gerçekte nerede biriküyor?
Dil eklemek sayfanın tamamını ağırlaştırmaz. Hangi bileşenlerin dil sayısıyla doğrusal büyüdüğünü, hangilerinin büyümediğini ayırt etmek, optimize edilecek alanı daraltır. CSS dosyası değişmez; yazı tipi ailesinden renk paletine kadar global stil kuralları dil bağımsızdır. Temel HTML yapısı da sabittir. Asıl olarak üç alan kritik şekilde katlanır: HTML head içindeki hreflang blokları, istemci tarafı çeviri paketleri ve bazı durumlarda dile özgü görseller.
Hreflang, her dil sürümünde tüm sürümleri listeler. Yirmi dil varsa her sayfa head bölümüne yirmi hreflang satırı eklenir. Bu büyüme doğrusaldır ve kaçınılmazdır—protokolün zorunlu kıldığı bir gerekliliktir. JavaScript tarafında ise seçim vardır: çeviri JSON dosyaları tek pakette mi gönderilir, dil başına mı bölünür? Bu kararın boyutu doğrudan kullanıcının ilk yükleme deneyimini belirler.
Görseller bağlamında ise mesele farklıdır. Metin içermeyen görseller tüm dil sürümleri arasında sorunsuz paylaşılabilir. Asıl maliyet; yerelleştirilmiş banner, dile özgü ürün fotoğrafı veya kültürel bağlamda farklılık gösteren içerik medyasından gelir. Bu varlıklar dil başına ayrı dosya demektir ve CDN üzerinde hem depolama hem teslim maliyeti yaratır. Pek çok site bu farklılaşmayı gereğinden erken yapar; metin içermeyen görselleri dile göre kopyalamak çoğunlukla gereksiz bir yüktür.
HTML head şişmesi: hreflang etiket yükü ve gerçek boyutu
Yirmi dil sürümü olan bir sitenin her sayfası, head bölümünde yirmi adet hreflang etiketi taşır. Her satır yaklaşık 80-120 byte ham metin içerir; dolayısıyla yirmi hreflang bloğu 1,6 ile 2,4 KB arasındadır. Sıkıştırılmış biçimde bu değer çok daha düşer—ancak sitede yüzlerce sayfa varsa toplam indeks boyutu anlam kazanmaya başlar. Hreflang yapısını ve doğrulama süreçlerini anlamak için hreflang nedir ve nasıl kullanılır yazısı kapsamlı bir başlangıç sunar.
Asıl soru şudur: bu büyüme render performansını etkiler mi? Head bölümü render-blocking değildir; tarayıcı gövdeyi işlerken paralel olarak head etiketlerini okur. Ancak TTFB'yi etkileyen sunucu tarafı bir boyut vardır. SSR mimarisinde sunucu tüm head içeriğini dinamik olarak üretiyorsa dil sayısı arttıkça bu üretim süresi uzar. Statik üretimde (SSG) ise head derleme aşamasında oluşturulur ve TTFB'ye etkisi sıfıra yakındır.
Pratik bir eşik olarak; otuz dil sürümüne kadar hreflang head şişmesi ölçülebilir bir performans kaybı yaratmaz. Bu etiketleri XML sitemap üzerinden yönetmek, HTML head boyutunu kontrol altında tutmanın alternatif yoludur ve özellikle büyük sitelerde tercih edilir. Derleme maliyeti veya head büyüklüğü kritik bir eşiğe yaklaşıyorsa sitemap tabanlı hreflang yönetimi dikkate değer bir seçenektir.
Çeviri JSON paketleri: lazy loading ne zaman zorunlu hale gelir?
Modern i18n kütüphanelerinin büyük çoğunluğu—react-i18next, vue-i18n, next-intl ve benzerleri—çeviri dosyalarını dil başına bölmeyi destekler. Varsayılan yapılandırmalarda ise zaman zaman tüm dillerin tek pakette sunulduğu görülür. Küçük projelerde bu sorunsuz çalışır; büyük içerik tabanlarında ciddi bir ilk yükleme maliyeti yaratır.
Boyutu somutlaştırmak gerekirse: orta büyüklükte bir sitede dil başına çeviri JSON dosyası 15-40 KB (ham) olabilir. Beş dil varsa ve tüm çeviriler tek pakette gönderiliyorsa kullanıcı 75-200 KB gereksiz veri indirir—bunların büyük çoğunluğunu hiç kullanmayacaktır. Sıkıştırma bu sayıyı düşürür, ancak yanlış mimarinin etkisini tamamen ortadan kaldırmaz.
Lazy loading ile çözüm şudur: kullanıcı sayfayı açtığında yalnızca aktif dile ait çeviri paketi yüklenir. Kullanıcı dil değiştirirse yeni paketin dinamik olarak çekilmesi tetiklenir. Bu yapılandırmanın çerçeveleme kararlarıyla nasıl örtüştüğünü görmek için Next.js i18n SEO rehberi ve Nuxt ile çok dilli SEO kurulumu yazıları ilgili mimari kararları ayrıntılı biçimde ele alır.
Bir uyarı: dil paketini lazy load etmek, dil geçişinde kısa bir gecikme anlamına gelir. Çeviri dosyası yüklenmeden ekranda orijinal anahtarlar veya boş metinler görünebilir. Bu görsel titreşimi engellemek için preload stratejisi kurulabilir: birincil dil eager yüklenir, ikincil diller arka planda prefetch edilir. Bu denge, kullanıcı deneyimini korurken ilk yükleme maliyetini düşürür.
CDN ve önbellek yapılandırması: dil başına cache ayrımı
URL tabanlı dil yapısı—/tr/, /en/, /de/ gibi—CDN önbelleklemesi açısından en temiz çözümdür. Her dil sürümü bağımsız bir URL'ye sahip olduğu için CDN bu URL'leri ayrı nesneler olarak saklar ve herhangi bir ek yapılandırma gerektirmez. Hız ile mimari arasındaki bu ilişkiyi çok dilli URL yapısı nasıl seçilir yazısı daha geniş bir perspektiften ele alır.
Accept-Language başlığına dayalı yönlendirme kullanan yapılarda ise CDN aynı URL için farklı içerikler sunmak zorundadır. Bu durumda Vary: Accept-Language başlığının doğru ayarlanması şarttır; aksi takdirde CDN bir dil sürümünü önbelleğe alıp diğer dil kullanıcılarına da aynı içeriği sunar. Bazı CDN servisleri Vary başlığını görmezden gelir ya da cache etkinliğini ciddi ölçüde düşürür. Bu nedenle Accept-Language bazlı yönlendirme, önbellekleme mimarisini gereksiz yere karmaşıklaştırır ve URL tabanlı yapıya kıyasla CDN verimliliği açısından dezavantajlıdır.
TTL kararı, içerik güncelleme sıklığına göre dil başına değil sayfa türü bazında farklılaştırılabilir. Sık güncellenen haber veya kampanya sayfalarına kısa TTL (1-6 saat) uygulanırken rehber niteliğindeki içerikler 24-72 saat veya daha uzun önbellekte tutulabilir. Güncelleme hızı genellikle dile değil içerik kategorisine bağlıdır; bu ayrımı dil bazında yapmak çoğunlukla gereksiz karmaşıklık ekler. Ancak bir istisna geçerlidir: çok dilli pazarlarda belirli dil sürümleri için promosyon dönemleri farklılaşıyorsa—örneğin Almanca sürüm için yerel bir kampanya aktifken İngilizce sürüm normal akışta devam ediyorsa—o dile özgü önbellek politikası tanımlamak operasyonel bir gerekliliğe dönüşür.
Stale-while-revalidate stratejisi çok dilli yapıda özellikle etkilidir. Kullanıcı isteği anında sayfa CDN'den sunulur, arka planda güncel sürüm hazırlanır ve bir sonraki istekte teslim edilir. Yüksek trafikli dil sürümlerinde bu yaklaşım TTFB'yi belirgin biçimde iyileştirir ve yayınlama sırasında oluşan geçici yavaşlama riskini azaltır.
Render mimarisi: statik ile dinamik arasında ölçek kararı
Modern JavaScript framework kullanan çok dilli siteler için render stratejisi doğrudan performansı belirler. Tamamen statik üretim (SSG), derleme sırasında tüm dil sürümlerini HTML olarak üretir; TTFB sıfıra yakındır. Ancak içerik güncellemelerinde tüm sürümlerin yeniden derlenmesi gerekir. On dil ve binlerce sayfa varsa bu derleme süresi dakikalardan saatlere çıkabilir—özellikle acil düzeltmelerde bu gecikme operasyonel bir sorun yaratır.
Sunucu tarafı render (SSR), içeriği her istek anında üretir. Dil başına ek işlem yükü, sunucu kapasitesiyle doğru orantılıdır. Yüksek trafikli dillerde SSR'ın önbelleğe alınmış yanıtlarla desteklenmesi—Incremental Static Regeneration buna bir örnektir—iki yaklaşım arasında pratik bir denge kurar. Sık güncellenmeyen sayfalar statik, dinamik içerik gerektiren sayfalar sunucu tarafında üretilir.
Dil sayısı arttıkça bu kararın ağırlığı da artar. On iki dil ve beş yüz sayfa kombinasyonu altı bin adet statik sayfa anlamına gelir. Derleme pipeline bu ölçeği kaldıracak şekilde tasarlanmamışsa yayınlama süresi uzar. Bu eşik geçildiğinde ISR veya kısmi statik yeniden üretim stratejilerine geçilmesi kaçınılmaz hale gelir. Headless CMS mimarilerinde render kararının içerik modeli ile nasıl kesiştiğini headless CMS ile çok dilli SEO nasıl yönetilir yazısı daha ayrıntılı inceler.
Performans bütçesi çok dilli projede nasıl uygulanır?
Performans bütçesi, belirli metrikler için kabul edilebilir üst sınırları tanımlar: örneğin LCP 2,5 saniyenin altında, Total Blocking Time 200 ms'nin altında. Tek dilli projede bu bütçe tek bir URL seti üzerinde ölçülür. Çok dilli yapıda ise her dil sürümü ayrı bir ölçüm objesidir—Türkçe sürüm bütçeyi tuttursa da Japonca sürüm farklı bir font yükleme davranışı nedeniyle bu eşiği aşabilir.
Otomatik test pipeline'larında bu ayrımı sağlamak pratik bir yapılandırma gerektirir. Lighthouse CI veya benzer araçlar, dil başına ayrı URL setleri tanımlamanıza izin verir. Başlangıç noktası olarak en yüksek trafikli dil sürümleri önceliklendirilir; yeni bir dil eklenmeden önce o sürümün temel URL'leri test kapsamına alınır. Çok dilli teknik SEO denetiminin genel çerçevesini çok dilli sitede teknik SEO denetim listesi yazısında bulabilirsiniz.
Google Search Console, dil sürümleri arasında Core Web Vitals verisini URL bazında raporlar. Bir dil sürümünde sorun belirdiğinde GSC bunu diğer sürümlerden bağımsız olarak işaretler; bu da sorunu izole etmeyi kolaylaştırır. Ancak GSC'nin bu raporları gecikmeyle güncellediğini ve yalnızca belirli bir eşiğin üzerindeki URL sayısı için anlamlı veri ürettiğini göz önünde bulundurmak gerekir. Küçük dil sürümleri için Search Console verisi yetersiz kalabilir; bu durumlarda doğrudan saha ölçümü daha güvenilir bilgi sağlar.
Dil eklemek tek başına performans sorunlarına yol açmaz. Sorun genellikle her dil sürümüne eşlik eden kararların—bundle yapılandırması, CDN politikası, render stratejisi, görsel yönetimi—sistematik değil reaktif alınmasından doğar. Dört veya beş dile geçerken bu kararları yeniden değerlendirmek, büyüme sonrası yaşanan yavaşlamayı önceden engeller. İki dilde çalışan bir yapı sekize ölçeklendiğinde yeniden değil başından doğru kurulmuş olması gerekir; sonradan düzeltmek hem daha pahalıdır hem de kümülatif teknik borcu çözmek için ciddi zaman gerektirir.
Performans ve çok dilli SEO'nun bu kesişim noktasındaki temel ilke şudur: her dil sürümü bağımsız bir teknik nesnedir. Hız kazanımları veya kayıpları diller arasında otomatik aktarılmaz; doğru mimarinin kurulumu, ölçümün sürekliliği ve bütçe disiplini her sürüm için ayrıca sürdürülmelidir. Çok dilli yapı büyüdükçe bu disiplini elle sürdürmek güçleşir—otomasyon ve sistematik izleme araçları olmadan hangi dil sürümünün hangi nedenle yavaşladığını izlemek yakın olanaksız hale gelir. Bu noktada performans izlemeyi bir altyapı sorunu olarak değil, süregelen bir editorial ve teknik süreç olarak konumlandırmak gerekir.