<picture> Etiketi Ne Zaman Kullanılır?

<picture> etiketi hangi problemi çözer?

Standart img etiketi bir kaynağa bakar. srcset ile birlikte çalıştığında o kaynağın farklı genişlik varyasyonlarını da yönetebilir. Ama burada temel fikir aynıdır: aynı görsel ailesi, farklı boyutlarda teslim edilir. <picture> ise bu akışı bir adım ileri taşır ve tarayıcıya “koşula göre başka bir source ailesine geçebilirsin” der. Yani mesele sadece dosyanın genişliği değil, hangi dosya grubunun seçileceğidir.

Bu yüzden <picture> etiketi responsive görselin genel çözümü değil, daha spesifik bir seçim mekanizmasıdır. Tarayıcı, üstteki source etiketlerini sırayla değerlendirir; uygun ilk koşulu bulduğunda o kaynağı kullanır. Hiçbiri uymuyorsa en alttaki img fallback olarak devreye girer. Yapının özü budur. Karmaşık görünen kısım bu seçimin genişlikten mi, medya sorgusundan mı, yoksa format desteğinden mi tetiklendiğini temiz kurgulamaktır.

Pratikte bunu iki örnek iyi anlatır. Birincisi, modern tarayıcıya AVIF ya da WebP verip desteklemeyen tarayıcıya JPEG bırakmak istersiniz. İkincisi, masaüstünde yatay kadraj kullandığınız hero görselini mobilde daha dar ve merkez odaklı bir kırpımla göstermek istersiniz. Her iki durumda da aynı görsel davranmıyordur; dolayısıyla tek srcset zinciri yetersiz kalır.

srcset ile <picture> arasındaki fark nedir?

Bu ikisini rakip gibi görmek yanlış olur. Çoğu zaman birlikte çalışırlar. srcset boyut seçimini yapar; <picture> ise hangi kaynak ailesinin oyuna gireceğine karar verir. Yani <picture> kullanmak çoğu zaman srcset ihtiyacını ortadan kaldırmaz. Aksine, source etiketlerinin içinde yine srcset bulunur.

Buradaki en büyük yanlış anlama, “responsive görsel yapıyorsam <picture> şart” düşüncesi. Hayır. Responsive kelimesi tek başına bu etiketi zorunlu kılmaz. Eğer tek ihtiyacınız uygun genişlikte dosya seçtirmekse, önce sade çözümün sınırlarını sonuna kadar kullanın. Çünkü her yeni source, test edilmesi gereken yeni davranış demektir.

Bir başka karışıklık da format fallback ile art direction’ı aynı şey sanmaktır. İkisi de <picture> ile çözülebilir; ama amaçları farklıdır. Format fallback, aynı görselin farklı dosya türleriyle teslimidir. Art direction ise aynı görsel fikrinin farklı kırpım veya farklı kompozisyonla sunulmasıdır. Aynı etiket içinde çözülmeleri, aynı problem oldukları anlamına gelmez.

Format fallback için ne zaman mantıklıdır?

<picture> etiketinin en temiz kullanım alanlarından biri budur. Destekleyen tarayıcılara AVIF veya WebP, desteklemeyenlere JPEG bırakabilirsiniz. Bu yapı özellikle haber siteleri, blog kapakları ve büyük görsel yüzeylerde anlamlıdır. Çünkü dosya boyutu ile görünür kalite dengesini daha iyi kurma şansınız olur. Format tarafındaki kararın teknik arka planını ayrıca AVIF ve WebP karşılaştırmasında değerlendirmiştik; burada odak, o kararın HTML’de nasıl taşındığıdır.

Bu noktada önemli olan şey, formatları sırf popüler olduğu için üst üste yığmamak. Eğer kaynak zincirinizde gerçekten AVIF varyasyonu yoksa source type="image/avif" eklemek kozmetik hareket olur. Önce dosya ailesini üretmeniz gerekir. Bu hazırlık aşamasında ana sitedeki resim dönüştürme aracını kullanmak pratik olabilir; ama araçtan gelen dosyaları yine gerçek yerleşimde test etmek gerekir. Araç üretir, nihai kararı proje verir.

Temel yapı genelde şu şekildedir:

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

Burada dikkat edilmesi gereken iki şey var. Birincisi, en alttaki img etiketi asla boş bırakılmamalı; bu, gerçek fallback’tir. İkincisi, source etiketlerinde de boyut mantığı korunmalıdır. Sadece dosya formatı değişip genişlik planı rastgele kalırsa, etiket doğru görünür ama teslimat dağılır. Aynı dosya ailesi içinde disiplin yoksa, <picture> size mucize sağlamaz.

Art direction gerektiğinde neden daha kritik hale gelir?

Art direction, responsive görsel tarafının en çok ihmal edilen ama en görünür alanlarından biridir. Masaüstünde yatay ve geniş anlatıma sahip bir hero görseliniz olabilir. Aynı görsel mobilde dar bir alan içinde gösterildiğinde, kadrajın kenarlarındaki bilgiler kaybolur ve asıl vurgu küçülür. Burada sorun dosya boyutu değildir; kompozisyon bozuluyordur. Bu tip durumda yalnızca srcset eklemek çözüm olmaz çünkü tarayıcı hâlâ aynı görsel ailesinin varyasyonlarını seçmektedir.

<picture> burada farklı medya koşullarına farklı görseller bağlamanıza izin verir. Mobil için daha merkezli, daha dar kırpılmış bir görsel; masaüstü için daha geniş kompozisyon sunabilirsiniz. Bu, özellikle ürün tanıtım alanları, yazı üst kapakları ve görseldeki ana nesnenin konumu kritik olduğunda işe yarar. Aynı bakış açısını her ekranda korumaya çalışmak yerine, her ekran için en doğru anlatımı seçmiş olursunuz.

Örnek olarak aşağıdaki kurgu, mobilde farklı kırpım kullanan bir hero için mantıklıdır:

<picture>
  <source
    media="(max-width: 767px)"
    srcset="/img/hero-mobile-640.webp 640w, /img/hero-mobile-960.webp 960w"
    sizes="100vw">
  <source
    media="(min-width: 768px)"
    srcset="/img/hero-desktop-960.webp 960w, /img/hero-desktop-1600.webp 1600w"
    sizes="(max-width: 1200px) 92vw, 1100px">
  <img
    src="/img/hero-desktop-1600.webp"
    alt="Ana görsel"
    width="1600"
    height="900">
</picture>

Burada dikkat: mobil varyasyonun sadece daha küçük dosya olması yetmez. Gerçekten farklı kadraj gerekip gerekmediğine bakılmalıdır. Eğer aynı kompozisyon her ekranda iş görüyorsa art direction zinciri gereksiz yük olur. Sırf “mobil için ayrı versiyon hazırlamış olalım” mantığı, tasarım ekibiyle editör tarafında sürekli fazladan iş üretir.

picture yapısını gereksiz yere büyüten hatalar neler?

<picture> etiketindeki hatalar çoğu zaman sessizdir. Sayfa açılır, görsel görünür ve ekip her şeyin yolunda olduğunu sanır. Oysa tarayıcı hiç beklenmeyen kaynağı seçiyor olabilir. Birinci hata source sırasını yanlış kurmaktır. Tarayıcı yukarıdan aşağı ilk eşleşen kaynağı alır. Daha genel medya sorgusunu üste koyup daha dar koşulu alta atarsanız, alttaki kural çoğu zaman hiç çalışmaz.

İkinci büyük hata, her görsel problemi için aynı kalıbı kopyalamaktır. Örneğin kart görselinde yalnızca format fallback gerekirken art direction zinciri de eklenir. Sonra başka bir sayfada mobil kırpım gerekirken format fallback hiç yoktur. Yani etiket artar ama düşünme azalır. Her görsel yüzeyinin görevi farklıysa HTML yapısı da aynı şablon olmak zorunda değildir.

Üçüncü hata, fallback kalitesini ihmal etmektir. Modern tarayıcılar AVIF ya da WebP alıyor diye JPEG varyasyonunu özensiz hazırlamak doğru değildir. Hâlâ fallback yoluna düşen istemciler vardır; üstelik test, hata ayıklama ve bazı paylaşım yüzeyleri bu dosyalara temas eder. En alttaki kaynak “nasıl olsa nadir” diyerek zayıf bırakılırsa sorun büyüyene kadar fark edilmez.

Dördüncü hata da performansı yalnızca format değişimine bağlamaktır. Bazen ekip AVIF eklediği için işin bittiğini düşünür; ama sizes yanlış kaldığı için tarayıcı yine gereğinden büyük dosyayı seçer. Yani <picture> doğru olsa bile içindeki srcset planı zayıfsa toplam sonuç yine vasat kalır.

Şablon ve medya yönetimi bu yapıyı nerede dağıtır?

CMS kullanan projelerde <picture> kararının yalnızca frontend tarafında verilmesi yetmez. Medya kütüphanesi hangi boyutları üretiyor, editör hangi varyasyonları yüklüyor, şablon hangi oranları çağırıyor; bunların birlikte düşünülmesi gerekir. Özellikle WordPress tabanlı yapılarda otomatik boyut üretimi ve tema içi görsel alanları birbiriyle uyumsuzsa, etiket yapısı doğru olsa bile dosya ailesi zayıf kalabilir.

CDN kullanan projelerde ise başka bir sürtünme vardır. Dinamik dönüştürme çok kolay görünür; bu yüzden ekip sınırsız varyasyon üretmeye başlar. Oysa her yeni kırpım, her yeni format ve her yeni medya koşulu cache davranışını etkiler. Gerçekte kullanılan birkaç kırılım yerine teorik tüm olasılıklar için kaynak üretmek, teslimat mantığını iyileştirmekten çok kontrolü zorlaştırabilir.

Editör disiplini de burada belirleyicidir. İnsanlar tek bir devasa dosya yükleyip sistemin mobil ve masaüstü versiyonları otomatik çözeceğini sanıyorsa, art direction tarafı hep geriden gelir. Çünkü bazı kararlar HTML ile sonradan telafi edilemez. Mobil kırpım gerçekten farklı olacaksa, o varyasyonun içerik üretim aşamasında düşünülmesi gerekir.

Tarayıcının düştüğü source satırını doğrulamak

<picture> etiketinin varlığı tek başına başarı ölçütü değildir. Gerçek test, tarayıcının hangi kaynağı ne zaman seçtiğini görmektir. Bunun için geliştirici araçlarında Network ve Elements panellerine birlikte bakmak gerekir. Sayfayı farklı viewport genişliklerinde açın, cache kapalı yenileyin ve ilgili görsel isteğinin hangi dosyaya düştüğünü izleyin. Masaüstünde beklenen görseli görmek yeterli değildir; mobil kırılım ve yüksek piksel yoğunluklu profil de ayrıca kontrol edilmelidir.

Format fallback testinde tarayıcı desteği kritik noktadır. AVIF destekleyen modern bir Chrome sürümünde ilk kaynağın seçilmesi normaldir. Ama aynı testi farklı motorlarda da düşünmek gerekir. Fallback mantığını gerçekten sınamak için ya uygun test ortamı gerekir ya da geçici olarak belirli source etiketlerini devre dışı bırakıp zincirin aşağı katmanlara düşüp düşmediğine bakılır. Aksi halde kağıt üstünde güvenli görünen bir yapı, pratikte hiç kullanılmayan veya kırık bir fallback zincirine dönüşebilir.

Art direction tarafında görselin yalnızca yüklendiğini değil, doğru kadrajın seçildiğini de doğrulamak gerekir. Mobil görünümde gerçekten mobil kırpım mı geldi, yoksa masaüstü versiyonu küçültülmüş halde mi kaldı? Bu fark bazen birkaç saniyelik göz kontrolüyle anlaşılır, bazen de URL ve istek detayına bakmadan görünmez. Özellikle CDN parametreleri kullanılıyorsa, isimler benzer olduğundan ekip yanlış dosyanın seçildiğini geç fark edebilir.

Bir de kırılma anlarını test etmek gerekir. Tasarım çoğu zaman 360, 768 ve 1280 gibi birkaç ideal genişlikte düşünülür; oysa gerçek cihaz aralığı daha dağınıktır. 820 piksel civarında tablet görünümü, dar dizüstü penceresi ya da yüksek piksel yoğunluklu küçük telefonlar beklenmedik seçimler yaptırabilir. Bu yüzden yalnızca iki sabit viewport ile karar vermek yeterli değildir. Özellikle media koşulları ve sizes değerleri birbirine yakın sınırlar içeriyorsa, tam geçiş anlarında yanlış kaynak seçimi ortaya çıkar. En çok hata da burada yakalanır; çünkü büyük ekranda ve çok küçük mobilde çalışan yapı, ara genişliklerde sessizce bozulabilir.

Son olarak performans etkisi gözlemlenmelidir. Yeni yapı eklenince sadece kod karmaşıklığı artmış mı, yoksa gerçekten daha mantıklı kaynak mı iniyor? İlk ekrandaki görsel için gereksiz büyük dosya seçilmeye devam ediyorsa, sorun çoğu zaman picture etiketinin yokluğu değil; içindeki sizes planı, medya sorgusu ya da dosya ailesinin kendisidir. Doğrulama yapılmadan “artık modern teslimata geçtik” demek, çoğu projede erken sevinç olur. Özellikle ilk ekran görsellerinde bu fark doğrudan hissedilir. Bazen tek sorun yalnızca yanlış bir medya eşiğidir. Bu hata şaşırtıcı biçimde sık görülür birçok projede, özellikle ara kırılımlarda.

Bazı yüzeylerde daha sade çözüm bırakmak

Bazı projelerde <picture> etiketi teknik olgunluk göstergesi gibi ele alınıyor. Oysa gereksiz kullanılan her yapı, bakım maliyeti demektir. Aynı görselin yalnızca üç genişlik varyasyonu gerekiyorsa ve hepsi aynı kadrajı kullanıyorsa, çoğu zaman img + srcset yeterlidir. Burada sade çözüm daha güvenlidir çünkü hata yüzeyi daha küçüktür.

Küçük kart görselleri, basit içerik fotoğrafları ve sabit kullanım alanları buna iyi örnek verir. Her yerde format fallback zorunlu değildir. Bazı sayfalarda altyapınız zaten tek format zinciriyle sorunsuz çalışıyordur. Her bileşene aynı gelişmiş yapıyı uygulamak, gerçek ihtiyaç ile teknik gösteriş arasındaki çizgiyi bulanıklaştırır.

Doğrulama aşamasında temel test şudur: Eğer <picture> etiketini kaldırıp sade kurguya döndüğünüzde görsel deneyimi bozulmuyorsa, muhtemelen o alan için fazla karmaşık çözüm kurmuşsunuzdur. Etiketin değeri, yalnızca var olmasında değil; kaldırıldığında ne kaybettiğinizde anlaşılır.

Kısacası <picture> etiketi çok yararlı bir araçtır, ama yalnızca doğru yerde. Format fallback ve art direction net biçimde gerekiyorsa güçlüdür. Bunun dışındaki senaryolarda önce sade çözümün sınırlarını zorlamak, çoğu ekip için daha temiz ve daha sürdürülebilir bir yol olur.