srcset Nedir? Responsive Görseller Nasıl Kurulur?

srcset aslında hangi problemi çözer?

Tek bir görsel dosyasını bütün ekranlara aynı şekilde göndermek çoğu içerik sitesinde israf üretir. Örneğin makale gövdesinde en fazla 760 piksel genişlikte gösterilen bir görseliniz varsa, telefonda bu görsel çoğu zaman 360 ile 420 CSS piksel arasında yer kaplar. Yine de sayfaya yalnızca 1600 piksel genişliğinde tek dosya koyarsanız, tarayıcı o dosyayı indirir ve küçültülmüş halde gösterir. Kullanıcı küçük bir görsel görür, ama indirdiği kaynak masaüstü seviyesindedir.

srcset bu noktada aynı içeriğin farklı ölçülerini tanımlamanıza izin verir. Tarayıcı, bulunduğu cihazda hangisinin daha mantıklı olduğuna kendisi karar verir. Bu, özellikle kart görselleri, yazı içi görseller ve hero alanları için önemlidir. Çünkü bu yüzeylerde aynı görsel farklı sayfa şablonlarında, farklı kolon genişliklerinde ve farklı piksel yoğunluklarında görünür.

Bu yapı yalnızca performans için kurulmaz. Gereğinden büyük dosya indirildiğinde sadece ağ yükü artmaz; decode süresi de uzar. Özellikle ilk ekranda yer alan görseller LCP adayına dönüşüyorsa, birkaç yanlış görsel kararı birikir ve sayfa olduğundan daha ağır hissedilir. Kaynak dosyayı küçültmek önemli bir adımdır; fakat tek başına yeterli değildir. Kaynak doğru boyutlandırılmadıysa sıkıştırılmış büyük dosya yine büyük dosyadır.

Tarayıcı doğru kaynağı nasıl seçer?

srcset tek başına “şu cihazda şu dosyayı kullan” komutu vermez. Tarayıcıya olası seçenekleri sunar. Seçim ise üç ana verinin birleşimiyle yapılır: srcset içindeki aday genişlikleri, sizes içindeki yerleşim ipucu ve cihazın piksel yoğunluğu. Burada çoğu karışıklığın sebebi, geliştiricinin yalnızca aday genişliklerine odaklanıp yerleşimdeki gerçek slot genişliğini ihmal etmesidir.

Genişlik tanımlayıcılarıyla çalışırken en yaygın kurulum şu mantığa dayanır: “Bu görsel kimi zaman tam genişlik, kimi zaman daha dar bir kolon içinde duruyor; o halde birkaç makul aday üreteyim ve tarayıcı seçim yapsın.” Bu noktada sizes tarayıcıya “bu görsel tipik olarak şu koşulda şu genişlikte görünür” der. Eğer sizes verilmezse ve w tanımlayıcıları kullanılıyorsa, tarayıcı çoğu zaman görseli 100vw gibi geniş varsayarak gereğinden büyük aday seçebilir.

Aşağıdaki örnek makale gövdesinde yer alan, mobilde tam genişliğe yakın, geniş ekranda ise yaklaşık 760 pikselde sınırlanan bir görsel için mantıklı bir başlangıçtır:

<img
  src="/img/ornek-1280.webp"
  srcset="
    /img/ornek-480.webp 480w,
    /img/ornek-768.webp 768w,
    /img/ornek-1280.webp 1280w"
  sizes="(max-width: 767px) 100vw, (max-width: 1100px) 92vw, 760px"
  width="1280"
  height="820"
  alt="Ürün fotoğrafı">

Bu örnekte tarayıcı önce sizes ile görselin sayfada yaklaşık ne kadar alan kaplayacağını hesaplar. Sonra cihazın piksel yoğunluğunu da hesaba katar. Mesela 390 CSS piksel genişliğinde ve cihaz piksel oranı 3 olan bir telefonda, teorik ihtiyaç 1170 piksele kadar çıkabilir. Bu yüzden tarayıcının her zaman en küçük adayı seçmesini beklemek doğru değildir. Bazen daha yüksek aday seçmesi tam olarak istenen davranıştır.

w mi, x mi kullanılmalı?

İki tanımlayıcıyı birbirine karıştırmak kurulumun en sık bozulduğu yerlerden biridir. w tanımlayıcısı görselin gerçek dosya genişliğini belirtir ve akışkan yerleşimlerde tercih edilir. Makale görselleri, kart kapakları ve kolon genişliği değişen görseller için doğru yaklaşım budur. x tanımlayıcısı ise sabit slot genişliğine sahip alanlarda, özellikle aynı boyutta gösterilip yalnızca piksel yoğunluğu değişen örneklerde daha uygundur.

x tanımlayıcısını akışkan yerleşimde kullanmak kısa vadede pratik görünebilir; fakat slot genişliği büyüyüp küçüldükçe karar zayıflar. Tersi de geçerli. Sabit 48 piksel avatar için 320, 640, 960 gibi w adayları üretmek dosya sayısını gereksiz yere artırır. Önce görselin sayfada gerçekten nasıl davranacağını belirlemek gerekir.

Kaynak seti nasıl planlanmalı?

İyi srcset kurulumu tasarım dosyasından değil, gerçek yerleşimden başlar. Önce görselin hangi şablonlarda nerede kullanıldığını çıkarın. Makale gövdesinde en fazla kaç piksel genişliğe ulaşıyor? Kartta kaç kolon içinde yer alıyor? Mobilde tam genişlik mi, yoksa kenar boşlukları nedeniyle biraz daha dar mı kalıyor? Bu sorular net değilse, ürettiğiniz aday seti de rastgele olur.

• Önce gerçek slot genişliklerini belirleyin. Tasarım dosyasındaki teorik değer değil, sayfanın render sonrası davranışı önemlidir.
• Sonra bu slotlara yakın 2 veya 4 makul aday üretin. Çoğu içerik sitesi için her görselde 7 farklı varyasyon gerekmez.
• Her aday için format ve kalite kararını koruyun. Büyük varyasyonu sıkıştırıp küçük varyasyonu unutmak tutarsız teslimat üretir.
• width ve height özniteliklerini atlamayın. Doğru kaynak seçimi başka, yer rezervasyonu başka problemdir.

Örnek bir makale görseli 760 pikseli geçmiyorsa, 480, 768 ve 1280 gibi üç aday çoğu zaman yeterlidir. 1920 ve 2560 varyasyonları otomatik üretmek kulağa güvenli gelse de her proje için mantıklı değildir. Piksel yoğunluğu yüksek cihazlar için biraz üstten aday bırakmak akıllıcadır; ama teoride mümkün olan her genişliği dosyaya çevirmek build sürecini şişirir, kontrol yükünü artırır.

Burada format seçimi de sürecin parçasıdır. Adayları üretirken çoğu içerik görselinde WebP mantıklı varsayılan olabilir. Fakat logo, ikon veya keskin raster grafiklerde aynı yaklaşım her zaman doğru değildir. Responsive teslimat kararı ile format kararı aynı anda düşünülürse, ekip ileride tek bir dosya ailesine körü körüne bağımlı kalmaz.

Kurulumun bozulduğu tipik noktalar

srcset eklendiği halde performans kazanımı görülmüyorsa sebep çoğu zaman etiketin varlığı değil, kurulumun detayıdır. En sık rastlanan hata, farklı dosya adları verip hepsinde aynı geniş kaynağı kullanmaktır. Örneğin 480w ve 768w diye işaretlenen iki dosya gerçekte aynı 1600 piksel kaynaktan otomatik küçültülmemiş olabilir; kimi zaman yalnızca CDN URL parametresi farklıdır ama çıktı yine gereksiz büyük kalır.

İkinci büyük hata, aynı bileşene aşırı sayıda aday eklemektir. Kağıt üzerinde hassas görünür; pratikte dosya üretimini, cache yönetimini ve editör akışını zorlaştırır. Üç ya da dört mantıklı aday çoğu yayın bileşeni için yeterlidir. Yedi aday verip hiçbirini ölçmemek, üç aday verip sonucu izlemeden daha iyi değildir.

Bir başka kritik nokta da arka plan görselleridir. srcset yalnızca <img> ve benzeri görsel elemanlarında çalışır; CSS ile gelen background-image için ayrı çözüm gerekir. Ekip hero alanını görsel etiketi yerine arka plan görseliyle kurduysa, responsive teslimat sorununu başka bir katmanda çözmek zorundadır. Etiketin kendisi doğru olsa bile yanlış bileşen seçimi bazı iyileştirmeleri daha baştan sınırlar.

picture etiketi ne zaman devreye girmeli?

srcset aynı görselin farklı ölçülerini teslim etmek için güçlüdür; fakat her zaman yeterli değildir. Eğer mobilde farklı kırpım, masaüstünde farklı kompozisyon ya da format fallback ihtiyacı varsa picture devreye girer. Yani sorun yalnızca “hangi genişlikte dosya seçilsin” değil, “hangi kaynak ailesi seçilsin” haline gelmişse picture daha doğru araçtır.

Özellikle AVIF veya WebP kullanıp gerektiğinde daha eski formatlara düşmek istediğinizde picture düzenli bir yapı sağlar. Aynı şekilde masaüstünde yatay, mobilde daha dar kırpımlı görsel kullanacaksanız bunu yalnızca srcset ile çözmeye çalışmak doğru olmaz. Çünkü burada piksel yoğunluğu değil, art direction kararı vardır.

<picture>
  <source
    type="image/avif"
    srcset="/img/kapak-480.avif 480w, /img/kapak-960.avif 960w"
    sizes="(max-width: 767px) 100vw, 760px">
  <source
    type="image/webp"
    srcset="/img/kapak-480.webp 480w, /img/kapak-960.webp 960w"
    sizes="(max-width: 767px) 100vw, 760px">
  <img
    src="/img/kapak-960.jpg"
    alt="Kapak görseli"
    width="960"
    height="620">
</picture>

Yine de her görseli otomatik olarak picture içine almak doğru yaklaşım değildir. Aynı tasarım sonucunu yalnızca img + srcset ile çözebiliyorsanız, daha sade yapı daha az hata üretir. Araç seçimi ihtiyaca göre yapılmalı; yalnızca teknik olarak daha güçlü diye daha karmaşık etiket seçilmemelidir.

Otomatik medya sistemleri en çok nerede yanlış seçim yapar?

WordPress ve benzeri sistemler çoğu zaman otomatik srcset üretir. Bu faydalıdır, ama kör güven gerektirmez. Tema görseli gerçekten hangi boyutta kullanıyor, medya kütüphanesi hangi ara boyutları üretiyor, editörler ne büyüklükte kaynak yüklüyor; bunlar kontrol edilmezse otomatik işaretleme de gereksiz büyük adaylar sunabilir. WordPress görsel optimizasyon akışında en sık görülen sorunlardan biri, medya ayarlarının tema bileşenleriyle uyumlu olmamasıdır.

CDN kullanan projelerde ise durum biraz daha farklıdır. Dönüştürme ve yeniden boyutlandırma kenarda yapıldığı için işaretleme sade görünebilir; fakat cache anahtarları, varyasyon üretim mantığı ve kalite ayarları kritik hale gelir. Her istekte dinamik dönüştürme yapmak mümkün olsa bile, hangi boyutların gerçekten kullanıldığını bilmeden sınırsız varyasyon üretmek iyi fikir değildir. Ağ maliyeti ve cache verimi birbirine bağlıdır.

Editör süreçleri de teknik kararın parçasıdır. İnsanlar sürekli 4000 piksel kaynak yükleyip sistemin bunu otomatik çözmesini bekliyorsa, srcset yalnızca hasarı kısmen yönetir. Kaynağın makul tutulması, doğru formatla yüklenmesi ve bileşene uygun kırpılması hâlâ gerekir. Kısacası responsive teslimat, yalnızca geliştirici etiketleriyle değil; medya üretim disipliniyle birlikte iyi sonuç verir.

Bir de kırpım meselesi var. Bazı temalar görseli beklediğiniz oranda göstermediği halde aynı kaynak ailesini kullanmaya devam eder. Sonra editör görselin farklı bölümünün kesildiğini görür, fakat sorun srcset sanılır. Oysa asıl problem yanlış üretilmiş ara boyutlar veya tema tarafındaki oran varsayımı olabilir. Bu yüzden otomatik sistemlerde yalnızca üretilen HTML'ye değil, medya boyut şemasına ve bileşenin gerçekten hangi en-boy oranını kullandığına bakmak gerekir.

Ağ panelinde doğru seçim neye benzer?

Doğrulama yapmadan srcset kurulumu tamamlanmış sayılmaz. Çünkü işaretleme doğru görünse bile tarayıcı bambaşka aday seçiyor olabilir. İlk kontrol yeri geliştirici araçlarındaki Network panelidir. Sayfayı cache kapalıyken yenileyin, ilgili görsel isteğini bulun ve indirilen dosya adını gerçek beklentinizle karşılaştırın. Masaüstünde doğru dosyanın gelmesi, mobil simülasyonda da aynı davranacağı anlamına gelmez.

• Elements panelinde görseli seçip tarayıcının güncel olarak hangi kaynağı kullandığını kontrol edin.
• Farklı viewport genişliklerinde ve en az bir yüksek piksel yoğunluklu cihaz profilinde testi tekrarlayın.
• İlk ekran görsellerinde istek önceliği ile loading davranışını ayrıca gözden geçirin.
• Seçilen kaynak küçüldükçe kalite bozuluyor mu, yalnızca dosya boyutuna değil görünür sonuca da bakın.

Ölçüm yaparken şu yanlış beklentiden kaçınmak gerekir: Tarayıcı her zaman en küçük dosyayı seçmez. Seçmemelidir de. Yüksek piksel yoğunluklu cihazda daha keskin kaynak seçmesi çoğu zaman doğru davranıştır. Mesele en ucuz dosyayı zorla göndermek değil, görüntü kalitesi ile aktarım maliyetini makul bir dengede tutmaktır. Bu nedenle doğrulama sadece kilobayt bakarak değil, gerçek render sonucunu da izleyerek yapılmalıdır.

Bazı yüzeylerde srcset kurmamak neden daha temizdir?

Her görsele otomatik olarak srcset eklemek zorunlu değildir. Sabit boyutlu çok küçük işaretler, vektörle çözülmesi gereken logolar veya tek genişlikte kullanılan bazı yönetim paneli öğeleri için bu yapı gereksiz olabilir. Burada asıl soru şu: Aynı görsel gerçekten farklı slot genişliklerinde mi kullanılıyor? Cevap hayırsa, bazen tek iyi kaynak veya sabit 1x/2x yaklaşımı yeterlidir.

Özellikle ikon ve logo tarafında önce responsive raster teslimat düşünmek yerine, dosyanın doğasının raster mı vektör mü olduğuna bakmak gerekir. Küçük ve çizgisel bir işareti sırf her şeyi tek mantıkla çözmek için srcset ailesine taşımak, basit problemi karmaşık hale getirebilir. Üstelik bu yaklaşım ikon arşivini de gereksiz yere büyütür. Bu tür örneklerde format seçimi responsive kaynaktan daha kritik hale gelir.

Karar çerçevesi kısaca şöyle kurulabilir: Görsel farklı kırılımlarda farklı genişlikte görünüyorsa srcset düşünün. Sabit slotta yalnızca yoğunluk farkı varsa x yaklaşımı yeterli olabilir. Farklı kırpım veya format fallback gerekiyorsa picture kullanın. Hiçbiri yoksa ve dosya zaten küçükse, sade çözüm çoğu durumda pratikte daha iyidir.