Sıfırdan Site Kurarken Görsel Altyapısını Doğru Tasarlama
Yeni bir web sitesi projesinde ilk iki haftada alınan kararlar, sonraki yıllara uzanır. Hangi framework seçildiği, veritabanı yapısı, URL şeması - bunlar kodla değişir. Görsel altyapısı farklı bir kategoride durur: görseller yüklenmiş, URL'leri arama motorlarına indekslenmiş, önbelleğe alınmış ve çoğu zaman içerik editörlerinin alışkanlıklarına işlenmiş haldeyken sistemi değiştirmek, teknik bir güncelleme değil, içerik migrasyonuna dönüşür.
Görsel altyapısını baştan doğru kurmak karmaşık bir sistem tasarımı gerektirmez. Dört temel kararı - depolama yeri, format standardı, işleme hattı ve dosya adlandırma - projenin başında net tutmak, sonraki her optimizasyon adımını kolaylaştırır. Karar verilmeyen yerlerde birikim başlar: uyumsuz formatlar, farklı kaynaklardan çekilen görseller, tutarsız boyutlar. Her biri kendi başına küçük bir sorun; birikerek yönetilemez hale gelir.
Sıfırdan başlıyorsanız bu kararları şimdi almanın maliyeti düşük, sonra almanın maliyeti yüksek. Her kararı ne zaman işe yarar, ne zaman gereksiz, ne zaman ters etki yapar perspektifinden ele almak gerekir - çünkü projenin ölçeği cevapları değiştirir.
Görsel depolama mimarisi: erken seçim, uzun bağlılık
Görselleri nerede barındıracağınız, sitenin geri kalanını doğrudan etkiler. Üç temel seçenek vardır: aynı sunucu (origin), nesne depolama (object storage - S3, R2, Backblaze B2 gibi) ya da bağımsız bir CDN üzerinden servis. Seçim, URL yapısını da belirler; ve URL yayına girdikten sonra değiştirmek anlık bir güncelleme değildir.
Aynı sunucuda depolama küçük projeler için hızlı başlangıç sağlar. Trafik büyüdüğünde görsel istekleri uygulama sunucunuzu yorar; ama küçük bir kurumsal site, bu yükü hiç yaşamayabilir. Nesne depolama, görselleri uygulama katmanından ayırır; CDN önüne geçirildiğinde dağıtık servis de mümkün olur. CDN-öncelikli yaklaşımda görsel en yakın düğümden sunulur, gecikme düşer; ama yönetim bir katman daha karmaşıklaşır.
Projenin ölçeği bu kararı belirler. On sayfası olan bir kurumsal site için nesne depolama artı CDN kurulumu, getirdiği yönetim yükünü karşılamayacak kadar erken olabilir. Günde yüzlerce ürün fotoğrafı yüklenen bir e-ticaret sitesi için ise aynı kurulum baştan zorunludur; sonradan geçiş yaptığınızda tüm ürün URL'leri değişir ve indekslenmiş bağlantılar etkilenir.
Depolama mimarisi seçilince URL yapısı da şekillenir. cdn.siteniz.com/urunler/kirmizi-canta-800w.webp gibi bir adres, içinde depolama kararını, boyutu ve formatı barındırır. Bu URL'nin parçalarından biri sonradan değişirse yönlendirme (redirect) zinciri başlar; zincir uzadıkça yük de artar.
Format standardını baştan belirlemek
WebP (Web Picture), günümüzde tüm modern tarayıcılarda desteklenir ve çoğu JPEG kaynağından daha küçük dosya boyutu üretir. Yeni bir proje için varsayılan format olarak seçmek makuldür; eski tarayıcı desteği gerekiyorsa picture elementi ile JPEG geri dönüşü eklenebilir.
AVIF, sıkıştırma açısından WebP'nin önünde, ama kodlama süresi daha uzun ve eski tarayıcı desteği daha kısıtlı. Fotoğraf ağırlıklı içerik üretiyorsanız ve görsel dönüşümünü otomatik yapan bir servis kullanıyorsanız AVIF anlamlı bir seçenek olur. Her görseli manuel dışa aktarıyorsanız ek karmaşıklık getirir, kazanım belirsizleşir.
PNG, şeffaflık gerektiren varlıklar - logo, ikon, arayüz elemanı - için yerini korur. SVG, basit ikonlar ve illüstrasyonlar için dosya boyutu ve ölçeklenebilirlik açısından öne çıkar; burada formatlar arasında rekabet değil, içerik türüne göre atama vardır. Aynı siteye her ikisi de girer, ayrı rollerde.
Format standardı kararında esas soru şudur: içerik ekibi görselleri hangi formatta yükleyecek ve sistem bunları otomatik olarak dönüştürecek mi? İkincisi mümkünse standart JPEG veya PNG kabul edip çıkışta WebP üretmek, editörler için en az sürtüşmeli çalışma biçimidir. Dönüşüm otomatik değilse editöre WebP yükleme talimatı verilmeli ve bu kural proje başında belgelenmeli.
Otomatik işleme hattı: kurmanın doğru zamanı
Görsel işleme hattı (image pipeline), yükleme anında veya derleme (build) sırasında görselleri otomatik boyutlandıran, sıkıştıran ve format dönüşümü yapan sistemdir. Büyük ölçekli projelerde bu hattın yokluğu bir boşluk, küçük projelerde erken kurulması bir yük olabilir.
İşe yaradığı durumlar bellidir. İçerik yöneticileri farklı boyutlarda, farklı kalitelerde görseller yüklüyorsa; her ürün için birden fazla boyut - küçük resim, orta, tam - gerekiyorsa; görsel sayısı elle yönetilemez bir eşiği geçmişse pipeline vazgeçilmez olur. E-ticaret ve haber sitelerinde bu koşulların tamamı baştan mevcuttur; pipeline ilk günden kurulabilir.
Gereksiz kaldığı durumlar da vardır. Görseller seyrek güncelleniyor ve sayısı azdır; içerik ekibi zaten optimizasyon yapıyor; statik site jeneratörü kullanıyorsanız derleme sırasında çalışan hafif bir araç yeterlidir. Sistem kurmak, sistemi yönetmek anlamına da gelir; küçük projede bu yönetim maliyeti geri dönüş sağlamaz.
Ters etki yapabildiği durumlar ise dikkat ister. Yanlış yapılandırılmış bir işleme hattı her yüklemeyi aşırı sıkıştırabilir, renk profillerini bozabilir veya orijinal dosyanın üzerine yazabilir. Kayıpsız arşiv (lossless archive) saklanmadan yapılan otomatik sıkıştırma, orijinali geri almanın imkansız olduğu bir duruma yol açar. Hattı kurarken orijinali ayrı bir depoda saklamak, sonraki optimizasyon döngüleri için zemin hazırlar.
Dosya adlandırma ve klasör yapısı
Görsel dosya adları, arama motorlarının dosyayı yorumlamasında rol oynar. IMG_4521.jpg ile pembe-keten-gomlek-on-cephe.webp aynı içeriği taşısa da ikincisi okunabilir sinyal verir. Ama adlandırma yalnızca arama görünürlüğü meselesi değildir; CDN önbelleği, versiyon yönetimi ve programatik erişim için de belirleyicidir.
İyi bir adlandırma politikası URL-güvenli karakterler kullanır - kısa çizgi, boşluk yok - içerik türünü ve boyutu yansıtır, değişmez (immutable) bir yapı ya da versiyon hash'i taşır. Örneğin urun-abc-800w.webp ve urun-abc-1600w.webp, aynı ürünün iki farklı boyutudur; boyut, ismin parçasıdır. CDN önbelleği bu dosya adına göre çalışır; adı değiştirmeden içeriği değiştirirseniz eski versiyon önbellekte yaşamaya devam eder, yeni içerik bazı kullanıcılara geç ulaşır.
Klasör yapısı içerik türüne göre ayrılmalıdır: /urunler/, /blog/, /statik/ gibi. Tüm görselleri tek klasöre koymak, ölçek büyüdüğünde yönetimi güçleştirir; daha önemlisi, farklı önbellek politikası uygulamayı engeller. Ürün görselleri sık güncellenir, logo nadiren değişir; ayrı klasörler bu ikisi için farklı önbellek süresi atamanıza olanak tanır.
Adlandırma kuralını projenin başında belgelemek, editör değişimlerinde ve ekip büyümelerinde tutarlılığı korur. Sonradan standartlaştırmak varolan dosyaları yeniden adlandırmayı, tüm referansları güncellemeyi ve önbelleği temizlemeyi gerektirir - üç ayrı adım, üç ayrı hata riski.
Responsive görsel altyapısı ve srcset planı
srcset ve sizes nitelikleri, tarayıcının görüntü alanına (viewport) göre doğru boyutu seçmesini sağlar. Bu sistemin çalışması için hangi boyutların üretileceğine önceden karar vermek gerekir; aksi halde pipeline neyi üretecek, srcset neyi listeleyecektir?
Tipik bir responsive görsel stratejisi üç ila beş kesme noktası (breakpoint) belirler: küçük ekran, orta ekran, geniş ekran, yüksek yoğunluklu ekran. Her kesme için ayrı bir dosya üretilir; bunların hepsi depolama alanı tutar ve pipeline'ın bilmesi gereken boyutlardır. Kesme noktaları layout kararlarıyla örtüşmeli; dolayısıyla responsive görsel stratejisi, frontend geliştirmeyle paralel kurulur.
sizes niteliği doğru yazılmazsa tarayıcı yanlış boyut seçer - fazla büyük dosya çeker veya düşük kaliteli görsel gösterir. Bu niteliğin değeri CSS düzeninizle uyumlu olmalıdır; layout değiştiğinde sizes de güncellenmeli. Projenin başında bir kez doğru ayarlamak, her layout güncellemesinde tekrar düzeltmekten çok daha az iş getirir.
Art direction - farklı ekran boyutlarında farklı kırpma veya kompozisyon - daha az sıkça gerekir ve picture elementi ile çözülür. Her görsel için art direction planlamak bakım yükünü artırır; yalnızca hero banner veya kampanya görselleri gibi öne çıkan öğelerde uygulanır. Genele yaymak, getirdiğinden fazla karmaşıklık üretir.
Geç kalan kararların yeniden yapılandırma maliyeti
Görsel altyapısının sonradan değiştirilmesi neden farklı bir karmaşıklık taşır? Görseller içeriğe gömülüdür. Bir veritabanında saklanan blog yazısı içinde onlarca görsel URL bulunabilir; depolama adresi değiştiğinde bu URL'lerin tamamının güncellenmesi gerekir. Eski URL'ler ise arama motoru indeksinde, harici sitelerden gelen bağlantılarda ve sosyal medya paylaşımlarında yaşamaya devam eder.
Yeniden adlandırma veya taşıma işlemi tek seferlik bir görev olmaz. 301 yönlendirme yazmak, önbelleği temizlemek, CDN'de yeni dosyaların yayılmasını beklemek, eski yönlendirmeleri ne kadar süre tutacağınıza karar vermek - bunların her biri ayrı bir adımdır. Operasyonel yük, görseller ne kadar erken indekslenmiş ve ne kadar geniş yayılmışsa o kadar büyür.
Format dönüşümü görece daha temiz bir migrasyon sağlar çünkü eski formatları aynı URL altında sunmaya devam edebilirsiniz. Ama toplu dönüşüm yine de zaman ve geçici depolama gerektirir. Pipeline değişikliği, özellikle üzerine yazma mantığını değiştiriyorsa, varolan arşiv dosyalarını etkiler ve orijinalleri kaybetme riski doğar.
Görsel altyapısında baştan net kararlar almak, dört soruya cevap vermek demektir: görseller nereden servis edilecek, hangi format standart olacak, yükleme işlemi otomatize edilecek mi ve dosyalar nasıl adlandırılacak? Bu cevaplar projenin ölçeğine göre değişir; küçük bir kurumsal site için basit cevaplar yeterlidir, büyük içerik siteleri için her karar katman taşır.
Altyapı kararlarını ertelemek kısa vadede hız kazandırmış gibi görünür. Her yüklenen görsel bu kararlardan birine örtük biçimde bağlanır; sistem büyüdükçe örtük kararlar görünür olur ve yeniden yapılandırma talebi kaçınılmaz gelir. Proje başında bir sayfa teknik not, ilk görsel yüklendiğinde hangi sisteme düştüğünüzü belirsiz bırakmak yerine netlik sağlar.