Aynı Görselin Farklı Boyutlarını Nasıl Planlamalı?
Bir ürün fotoğrafı çekildi. Aynı görsel sayfanın hero bölümünde tam genişlikte görünecek, listing sayfasında küçük bir kart olacak, sosyal medya paylaşımında OG görseli olarak kullanılacak, mobilde daha dar bir alanda sergilenecek. Tek bir fotoğraf, dört farklı bağlam — ve her bağlamın farklı boyut ihtiyacı var. Peki bu varyantları kaç tane üretmek gerekiyor, hangisi hangi ekran için, hepsini önceden mi üretmeli yoksa talep anında mı?
Bu soruların cevabı proje tiplerine göre farklılaşıyor. Statik siteler bütün varyantları önceden üretip dosya sisteminede tutar; görsel CDN kullanan projeler tek orijinal dosyadan URL parametresiyle her boyutu anında üretir; CMS tabanlı projeler ise çoğunlukla platform tarafından belirlenen sabit bir boyut setine bağlıdır. Hangi yol seçilirse seçilsin, temelde aynı kararlar alınmak zorundadır: hangi kırılma noktaları, retina için ne yapılacak, dosyalar nasıl adlandırılacak.
İyi bir boyut planlaması, tarayıcının doğru görseli seçmesini kolaylaştırır. srcset mekanizması tarayıcıya birden fazla boyut seçeneği sunar; tarayıcı ekran genişliğine, piksel yoğunluğuna ve ağ koşullarına göre en uygun versiyonu seçer. Fakat bu seçim ancak anlamlı boyut aralıklarıyla sunulduğunda verimli çalışır — çok az varyant büyük dosya transferine, çok fazla varyant ise gereksiz üretim yüküne neden olur.
Aynı görsel, farklı bağlam: ihtiyacı doğru okumak
Bir görselin kaç farklı boyutta üretileceğini belirlemek için önce o görselin sitede hangi rolleri üstleneceğini saptamak gerekiyor. Her rol, farklı bir boyut aralığına işaret ediyor.
Hero görseli genellikle tam ekran genişliğinde ya da neredeyse tam genişlikte görünüyor. Masaüstünde 1200–1600 piksel, mobilde 375–768 piksel aralığında. Bu bağlamda en geniş versiyonun kaliteli olması kritik; LCP skoru doğrudan bu görseli etkiliyor. Thumbnail veya kart görsel ise çok daha küçük — genellikle 300–500 piksel arası yeterli. Aynı fotoğrafı bu iki bağlamda aynı boyutla sunmak, ya listing sayfasında gereksiz büyük dosya transferine ya da hero'da net olmayan bir görüntüye yol açıyor.
OG görseli farklı bir kategori. Sosyal medya platformları ve mesajlaşma uygulamaları bu görseli kendi sunucularından çekip yeniden işliyor; boyut ve oran beklentileri kesin. 1200×630 piksel standart boyut olmakla birlikte, görsel aynı zamanda sitenin hero bölümünde de kullanılıyorsa oran uyumsuzluğu sorun çıkarabilir. Bu yüzden OG görseli çoğu zaman ayrı bir kırpma olarak üretilmesi gereken özel bir varyant.
Bütün bu bağlamları listelemek boyut planlamasının ilk adımı. Bir görsel için şu soruları yanıtlamak planın çerçevesini çiziyor: Bu görsel hero'da mı görünecek? Thumbnail olarak da kullanılacak mı? OG görseli olarak paylaşılacak mı? Mobilde farklı kırpma mı gerekiyor? Her "evet" yanıtı bir boyut varyantı anlamına geliyor.
srcset için boyut planlaması: hangi kırılma noktaları seçilmeli
srcset için boyut aralığı seçimi çoğu zaman sezgisel yapılıyor ve sonuç ya çok az ya da çok fazla varyantla bitiyor. Pratik bir yaklaşım, hedef görüntüleme genişliklerini tespit etmekten geçiyor.
Bir hero görseli için 400w, 800w, 1200w ve 1600w gibi dört varyant çoğu senaryoyu karşılamaya yeterli. 400w mobil küçük ekranlar için, 800w büyük mobil ve dar tablet için, 1200w standart masaüstü için, 1600w ise geniş ekranlar veya retina masaüstü için. Bu dört adım arasındaki atlamalar —her biri yaklaşık iki kat— tarayıcının anlamlı bir seçim yapabilmesi için yeterli farkı sağlıyor. Çok sık aralıklarla üretilen versiyonlar arasında tarayıcı pratik bir seçim yapamıyor çünkü dosya boyutları birbirine çok yakın.
Thumbnail için ise çoğunlukla iki varyant yeterli: 300w ve 600w. 600w retina ekranlarda 300px'lik gösterim alanı için kullanılıyor. Arada bir boyut daha eklemek performans farkını nadiren gerekçelendiriyor. CLS sorununu önlemek için her varyantın width ve height attribute'larının oranını korumak da bu noktada önem kazanıyor — farklı boyutlarda farklı oran kullanmak sayfa kaymasına neden olabilir.
sizes attribute buradaki denklemi tamamlıyor. Tarayıcıya "bu görsel 100vw genişlikte gösterilecek" ya da "(max-width: 768px) 100vw, 50vw" gibi bilgi vermek, hangi srcset varyantının seçileceğini doğrudan etkiliyor. Yanlış sizes değeri, doğru varyantları sunuyor olsanız bile tarayıcının yanlış seçim yapmasına yol açabiliyor.
Retina ihtiyacı: her boyut için 2x üretmek zorunlu mu?
Retina ekranlar standart piksel yoğunluğunun iki katına çıkıyor; bu demek oluyor ki 400px genişliğinde gösterilecek bir görsel, retina ekranda gerçekte 800 fiziksel piksel kullanıyor. Görseli 400px'te sunarsanız tarayıcı ölçeklendiriyor ve bulanık görünüyor. Bu nedenle çoğu srcset yaklaşımı retina için 2x boyutunu da üretiyor.
Fakat her görsel için her boyutu 2x üretmek her zaman gerekli değil ve bu kararı bağlam belirliyor. Thumbnail'lar küçük ve detay düşük olduğundan 2x farkı çoğu zaman göze çarpmıyor — özellikle insan yüzü veya ince çizgi içermeyen görsellerde. Hero görseli ise tam tersi: büyük yüzeyde ve yüksek dikkat çeken konumda, retina farkı net biçimde hissediliyor. Marka görselleri, ürün detayları ve metin içeren görseller retina varyantından en çok faydalanan kategoriler.
Pratikte makul bir denge şöyle çalışıyor: hero görseli için 1x ve 2x üretin; thumbnail için yalnızca bir üst boyutu sunun ve tarayıcının ölçekleme yapmasına izin verin. Thumbnail'ı 600w üretip 300px'te göstermek, 1.5x–2x retina için yeterince keskin bir sonuç üretiyor ve ayrı 2x varyant üretme ihtiyacını ortadan kaldırıyor. Bu yaklaşım dosya sayısını yarıya indirirken görsel kalitede anlamlı bir kayıp yaratmıyor.
Dosya adlandırma ve organizasyon
Birden fazla boyut varyantı üretildiğinde dosya adlandırması anlamlı olmak zorunda. Karmaşık bir arşivde hangi dosyanın ne olduğunu anlamak, bir sorun çıktığında doğru dosyayı bulmak ve eski varyantları temizlemek, iyi bir adlandırma konvansiyonuna bağlı.
Yaygın bir yaklaşım, boyutu veya bağlamı dosya adına eklemek. urun-foto-800w.webp, urun-foto-1200w.webp, urun-foto-thumb.webp gibi isimler hem boyutu hem de bağlamı hemen yansıtıyor. Alternatif olarak bağlam odaklı isimlendirme de kullanılıyor: urun-foto-hero.webp, urun-foto-kart.webp, urun-foto-og.webp. Bu ikinci yöntem boyutu gizliyor ama bağlamı açık tutuyor — hangisinin tercih edileceği ekibin önceliğine göre değişiyor.
Varyantları aynı klasörde tutmak organizasyonu basit tutuyor fakat kalabalıklaşıyor. Alternatif olarak her orijinal görsel için bir alt klasör açmak — örneğin img/urun-foto/hero.webp, img/urun-foto/thumb.webp — klasörü düzenli tutuyor ama URL yapısını karmaşıklaştırıyor. Büyük arşivlerde dosya sayısı yönetilemez hale geldiğinde bu organizasyon daha anlamlı; küçük projelerde tek klasör ve anlamlı dosya adları yeterli.
Adlandırma konvansiyonu ne olursa olsun, tüm ekibin aynı sistemi kullandığından emin olmak kritik. İçerik ekibi farklı, geliştirici farklı bir sistem kullanırsa, CMS'ten yapılan yüklemeler farklı bir isimlendirmeyle geliyor — ve bu karmaşa zamanla temizlemesi zor bir arşive dönüşüyor.
CDN ile dinamik boyutlandırma: statik üretim yerine
Görsel CDN kullanan projelerde boyut varyantlarını önceden üretmek çoğunlukla gereksiz. Cloudflare Image Resizing, Imgix, Cloudinary gibi servisler tek bir orijinal dosyadan URL parametresiyle her boyutu talep anında üretiyor: img.example.com/urun-foto.jpg?w=800, img.example.com/urun-foto.jpg?w=400. İlk talep origin'e gidip boyutlandırıp önbelleğe alıyor; sonraki talepler kenar sunucusundan karşılanıyor.
Bu yaklaşımın avantajları belirgin: yeni bir boyut ihtiyacı çıktığında dosya sisteminede dokunulmadan yalnızca URL parametresi güncelleniyor, orijinal dosya korunuyor ve depolama alanı şişmiyor. srcset'e hâlâ ihtiyaç var — tarayıcıya boyut seçeneklerini hâlâ bildirmek gerekiyor — ama bu seçenekler CDN URL'leri olarak tanımlanıyor. Toplu dönüştürme akışı kurmaya gerek kalmıyor.
Dezavantajı ise maliyet ve bağımlılık. Görsel CDN servisleri ücretli, vendor'a bağımlılık artıyor ve CDN'in erişemeyeceği durumda orijinal büyük dosya sunuluyor. Küçük projeler için bu trade-off genellikle CDN lehine — işletme kolaylığı ve performans kazancı maliyeti gerekçelendiriyor. Büyük ve kritik projelerde ise CDN servisinin SLA'sı ve fallback stratejisi dikkatle değerlendirilmesi gereken bir konu.
Boyut planlaması, bir görselin ömrü boyunca verilen tüm teknik kararları etkiliyor. Başlangıçta biraz zaman harcayıp hangi bağlamların hangi boyutları gerektirdiğini belgelemek, sonradan çıkan "bu görsel neden bu kadar büyük" veya "mobilde neden bulanık" sorularının önüne geçiyor. Genellikle 3–4 boyut varyantı çoğu senaryoyu karşılamaya yeterli; daha fazlası nadiren anlamlı bir performans farkı yaratıyor.
CDN yoksa statik üretim, CDN varsa dinamik boyutlandırma mantıklı bir başlangıç noktası sunuyor. Her iki durumda da temel adımlar aynı: bağlamları listele, her bağlam için bir boyut aralığı belirle, retina kararını bağlama göre ver, dosyaları tutarlı biçimde adlandır. Bu çerçeve bir kez kurulduğunda yeni görseller için boyut kararı neredeyse otomatik hale geliyor.