Hero Görseli Nasıl Optimize Edilir?

Hero görseli neden diğer görsellerden daha kritiktir?

Sayfa içi sıradan bir içerik görseli biraz geç gelse kullanıcı çoğu zaman bunu tolere eder. Ama hero görseli ilk ekranda yer aldığı için hem algısal hız hem teknik metrik üzerinde doğrudan etkilidir. LCP adayı çoğu içerik sayfasında ya hero başlığıdır ya da hero görselidir. Büyük ve geç gelen bir görsel, bütün sayfanın geç yüklenmiş gibi hissedilmesine yol açar. Bu yüzden hero optimizasyonu bir ayrıntı değil, öncelik konusudur.

Bir başka fark da şudur: Hero görseli çoğu zaman diğer görsellerden daha büyük alanda gösterilir. Doğal olarak daha yüksek çözünürlük isteyen tek medya öğesi gibi görünür. Fakat birçok projede bu ihtiyaç abartılır. Tasarım dosyasında 2400 piksel genişlikte hazırlanan görselin gerçek yerleşimde 1280 pikseli geçmediği durumlar çok yaygındır. Tasarım kaynağını doğrudan yayın kaynağı yapmak, hero alanında en pahalı hatalardan biridir.

Hero alanı ayrıca içerik mimarisiyle de iç içedir. Başlık metni, açıklama, butonlar ve bazen arama kutusu aynı blokta bulunduğu için, burada yaşanan yavaşlık veya kayma tüm açılışı bozar. Bu yüzden CLS tarafındaki yer rezervasyonu da hero için ayrıca önem kazanır. Görsel geç geldiğinde sadece görsel değil, yanında duran tüm içerik etkilenir.

İlk karar: gerçekten ne kadar büyük olmalı?

Hero görseli optimizasyonunda en çok kazanç sağlayan adım çoğu zaman dosyayı yeniden boyutlandırmaktır. Çünkü gereksiz büyük dosyayı ne kadar sıkıştırırsanız sıkıştırın, hâlâ gereksiz büyük dosya olarak kalır. Önce gerçek gösterim genişliğini bulun. Sayfa en geniş haldeyken hero görseli kaç piksel alana yayılıyor? İçerik alanı 1040 piksel civarında sınırlandığı halde 2200 piksel genişliğinde dosya taşımak çoğu zaman anlamsızdır.

Pratikte pek çok içerik sayfası için 1200 ile 1600 piksel aralığı iyi başlangıç noktasıdır. Elbette bu sabit kural değildir; tam genişlik landing kurguları ya da görsel ağırlıklı tasarımlar daha geniş kaynak isteyebilir. Ama klasik blog ve rehber yapılarında 2400 veya 3000 piksel dosyalar çoğu zaman savunulamaz. Görsel gerçekten bu kadar büyük gösterilmiyorsa, kalite değil israf taşıyorsunuzdur.

Bu ilk adımda ana sitedeki resim optimizasyonu aracını kullanarak farklı kalite ve çıktı ağırlıklarını hızlıca karşılaştırabilirsiniz. Yine de araç çıktısını doğrudan kabul etmek yerine, hedef genişliği ve sayfadaki gerçek kullanım alanını ayrıca kontrol etmek gerekir. En iyi sıkıştırma ayarı, yanlış piksel boyutunu telafi etmez.

Hero görseli için karar sırası genelde şöyle kurulmalıdır:

• Önce gerçek gösterim genişliğini bulun.
• Sonra bu genişliğe uygun 2 veya 3 aday üretin.
• Daha sonra format ve kalite testine geçin.
• En son preload veya öncelik ayarı gerekip gerekmediğine bakın.

Bu sıralamayı tersine çevirmek çok yaygındır. İnsanlar önce AVIF mi WebP mi tartışır, sonra dosyanın zaten gereksiz büyük olduğunu fark eder. Oysa ilk kazanç çoğu zaman format değil, boyut disiplininden gelir.

Format seçimi nasıl yapılmalı?

Hero görseli çoğu zaman fotoğrafik karakter taşır. Bu nedenle ilk aday çoğu senaryoda WebP olur. Yeterli kaliteyi daha düşük ağırlıkla taşımak için iyi denge sunar. Bazı projelerde AVIF daha düşük boyut verebilir; fakat dekodlama maliyeti, üretim akışı ve fallback yapısı da hesaba katılmalıdır. Format seçimi sadece en küçük dosyayı bulmak değildir, sayfa tipine uygun teslimatı seçmektir.

Eğer görselin karakteri yumuşak geçişler, fotoğrafik alan derinliği ve geniş ton farkları taşıyorsa WebP çoğu zaman güvenli ilk seçimdir. Keskin metinler, mikroskobik detaylar veya karmaşık grafik katmanlar varsa dosya formatı ayrıca test edilmelidir. Bu noktada WebP’nin ne zaman mantıklı olduğu ve AVIF ile farkı birlikte düşünülmelidir.

Hero alanı için tek bir formatı dogma haline getirmek iyi fikir değildir. Bazı ekipler “her şeyi AVIF yapalım” rahatlığına geçiyor, bazıları ise güvenli diye her şeyi JPG bırakıyor. İki uç da zayıf. Hero gibi kritik alanda en sağlıklı yaklaşım, bir veya iki örnek üzerinde görsel kaliteyi ve gerçek dosya davranışını birlikte test etmektir. Çünkü burada kullanıcı ilk bakışta fark edilen kalite ile aktarım maliyeti aynı anda değerlendirilir.

İlk ekran görseline lazy vermek neden pahalı hatadır?

Çoğu durumda hayır. İlk ekranda görünen hero görselini loading="lazy" ile işaretlemek en sık yapılan performans hatalarından biridir. Mantık ilk bakışta cazip gelebilir: “Görsel ağırsa tembel yükleyelim.” Ama sayfa açıldığında zaten görünür olan bir öğeyi tembel yüklemek, tam tersine kullanıcının gördüğü kısmı geciktirir. Özellikle LCP adayı hero görselse bu yaklaşım çoğu zaman doğrudan zararlıdır.

Hero görseli için genelde beklenen davranış şu kombinasyondur: yer rezervasyonu baştan verilir, görsel öncelikli şekilde yüklenir, gereksiz büyük olmayan bir kaynak sunulur ve gerekiyorsa fetchpriority="high" kullanılır. Bunun aksine lazy loading, tarayıcıya “bunu sonra düşün” mesajı verir. Sayfanın en görünür medya öğesi için bu çoğu zaman yanlış öncelik sinyalidir.

İstisna olabilir mi? Evet. Örneğin mobilde hero alanı ilk ekranın altında kalıyorsa veya sayfa açılışında önce başka bir medya öğesi görünüyorsa karar değişebilir. Ama klasik açılış yapısında büyük hero görseli için default yaklaşım lazy değildir. Bu yüzden CLS ve ilk ekran istikrarı konuşulurken lazy loading kararı ayrıca gözden geçirilmelidir.

preload ve fetchpriority ne zaman gerekir?

Hero görseli kritik kaynaktır diye her projede otomatik preload kullanmak doğru değildir. Önce tarayıcının zaten ne kadar erken gördüğüne bakmak gerekir. Eğer HTML içinde yukarıda yer alan, bloklanmayan ve açıkça görünür bir hero görseli varsa tarayıcı çoğu zaman onu zaten erken keşfeder. Bu durumda gereksiz preload eklemek ağ yarışını büyütebilir.

Buna karşılık bazı durumlarda preload gerçekten işe yarar. Örneğin hero görseli CSS arka planıyla geliyorsa, ya da karmaşık bileşen zinciri yüzünden geç keşfediliyorsa, tarayıcının onu daha erken istemesi için preload gerekebilir. Aynı mantık fetchpriority için de geçerlidir. İlk ekranın ana medya öğesiyse ve başka ağır isteklerle yarışıyorsa, yüksek öncelik sinyali mantıklı olabilir.

Sağlıklı yaklaşım şu sırayla ilerler:

<link
  rel="preload"
  as="image"
  href="/img/hero-1280.webp"
  imagesrcset="/img/hero-768.webp 768w, /img/hero-1280.webp 1280w"
  imagesizes="(max-width: 767px) 100vw, 1100px">

<img
  src="/img/hero-1280.webp"
  srcset="/img/hero-768.webp 768w, /img/hero-1280.webp 1280w"
  sizes="(max-width: 767px) 100vw, 1100px"
  width="1280"
  height="800"
  fetchpriority="high"
  alt="Hero görseli">

Ama bu örnek evrensel reçete değildir. Eğer preload eklendiğinde başka kritik CSS ya da font isteği zarar görüyorsa, fayda yerine sürtünme üretmiş olursunuz. Hero optimizasyonunda ince ayarların hepsi ölçümle anlam kazanır; ezbere eklenen her öznitelik iyileştirme değildir.

Hero için kaç kaynak adayı gerçekten yeterlidir?

Hero görseli için tek büyük dosya göndermek artık çoğu projede savunulamaz. Mobilde 390 piksel genişlikte görünen alan için 1800 piksel kaynak indirmek gereksiz pahalıdır. Bu yüzden hero alanında da srcset planı gerekir. Ama burada amaç onlarca varyasyon üretmek değil, gerçek yerleşime göre birkaç güçlü aday belirlemektir.

Tipik bir içerik veya araç sayfasında 768 ve 1280 gibi iki güçlü aday çoğu zaman yeterli olabilir. Daha geniş tasarımlarda 1600 piksel varyasyon da gerekebilir. Önemli olan her adayı gerçekten ihtiyaç duyulan slot genişliğine göre üretmektir. Retina cihaz var diye sonsuz genişlik seti kurmak, build sürecini şişirir ve cache maliyetini artırır.

Eğer mobil ve masaüstünde aynı kompozisyon korunuyorsa standart img + srcset yapısı yeterlidir. Farklı kırpım gerekiyorsa ancak o zaman picture etiketi devreye girer. Hero optimizasyonunda bu ayrım önemlidir; çünkü gereksiz karmaşık markup, ekip için yeni hata yüzeyi üretir.

Hero alanında CLS nasıl engellenir?

Hero optimizasyonu yalnızca LCP meselesi değildir. Eğer görselin yeri baştan ayrılmamışsa, dosya hızlı inse bile içerik aşağı kayabilir. Bu yüzden width, height ya da kapsayıcı aspect-ratio bilgisi hero alanında zorunlu düşünülmelidir. Özellikle başlık ve CTA butonları aynı blokta duruyorsa, geç açılan bir görsel bütün açılışı oynatır.

Pratikte iki yaklaşım öne çıkar. İlki, görsel etiketine gerçek oran bilgisini vermektir. İkincisi, hero kapsayıcısını CSS tarafında baştan tanımlamaktır. Tasarım türüne göre biri diğerinden daha iyi olabilir. Metin odaklı bir hero’da kapsayıcı oranı daha güvenli olabilir; tam fotoğraf ağırlıklı düzende ise görselin kendi oranını taşımak daha doğal kalabilir. Burada amaç her durumda aynı değil, açılışın stabil olmasıdır.

Hero alanı bazen arka plan görseliyle kurulur. Bu durumda da sorun bitmez. CSS arka planı görünür olsa bile, kapsayıcının yüksekliği sonradan belirleniyorsa kullanıcı yine kayma görür. Yani teknik tercihiniz img ya da background-image olabilir; ama yer rezervasyonu her iki durumda da ayrı düşünülmelidir.

En sık görülen yanlış hero stratejileri

Birinci strateji, masaüstü tasarım görselini olduğu gibi web’e koymaktır. Tasarım dosyasında keskin ve etkileyici görünür; ama sayfaya geldiğinde çoğu zaman gereksiz ağırdır. İkinci strateji, her şeyi otomatik çözecek tek bir CDN parametresine güvenmektir. Dinamik dönüştürme faydalıdır, ama kaynak planı ve kalite kontrolü yapılmadan tek başına sihir üretmez.

Bir başka zayıf alışkanlık da hero görseline metin gömmektir. Bu tasarım kararı bazen görsel boyutunu artırır, farklı kırılımlarda okunabilirliği bozar ve alternatif kırpım ihtiyacını büyütür. Metin görselin parçası olduğunda, sadece dosya optimizasyonu değil bilgi mimarisi de zorlaşır. Çoğu durumda metni HTML içinde tutmak daha esnek ve daha hafif sonuç verir.

Doğru hero kararını gerçek akışta görmek

Hero görseli optimize edildi sanmak kolaydır; gerçekten optimize edildiğini görmek için ölçmek gerekir. İlk bakılacak yer Network panelidir. Sayfa ilk açıldığında hangi hero dosyası iniyor, boyutu ne, ne kadar sürede geliyor ve başka kritik isteklerle nasıl yarışıyor? Bu veri olmadan “daha hızlı oldu” cümlesi çoğu zaman sezgiden ibaret kalır.

İkinci bakılacak yer LCP kaydıdır. LCP adayı gerçekten hero görseli mi, yoksa başlık mı? Eğer hero görseli LCP ise yapılan değişikliğin bu metriğe etkisi özellikle izlenmelidir. Dosya ağırlığı düşmüş olabilir ama preload yüzünden başka kaynakların yükü artmış olabilir. Ya da format küçülmüş ama decode maliyeti beklenenden yüksek çıkmış olabilir. Hero optimizasyonu tek metrikle ölçülmez.

Üçüncü adım göz testidir. Kullanıcıya sayfa açılır açılmaz ne görünüyor? Başlık hemen okunuyor mu, CTA alanı kararlı mı, görsel geç gelip sayfa düzenini sallıyor mu? Özellikle mobil test burada kritik. Çünkü hero alanı mobilde daha dar ve daha sıkışık olduğundan, küçük hatalar çok daha belirgin çıkar. Yani teknik ölçüm ile hissedilen açılış deneyimi birlikte değerlendirilmelidir.

Mobil hero testinde bir ayrıntı daha vardır: masaüstünde dengeli görünen bir kadraj, telefonda ana nesneyi kenara itebilir. Bu durumda yalnızca performans değil, anlatım da zayıflar. Hero optimizasyonu bu yüzden sadece kilobayt hesabı değil, ilk bakışta hangi odağın görüldüğü meselesidir.

Son olarak şu soruyu sormak gerekir: Bu hero görsel gerçekten bu kadar büyük bir alan hak ediyor mu? Bazen en iyi optimizasyon görseli biraz küçültmek, bazen de tamamen daha sade bir açılışa dönmektir. Tasarım kararını sorgulamadan yalnızca dosya sıkıştırmak, sorunun etrafında dolaşmak olabilir.

İlk ekranı bozmadan seçimi daraltmak

Hero görseli için hızlı ama doğru karar vermek istiyorsanız şu sırayı izleyin: Önce gerçekten ilk ekran öğesi mi bakın. Sonra gerçek gösterim genişliğini ölçün. Ardından iki veya üç mantıklı aday üretin. WebP ile başlayın, gerekirse AVIF test edin. Görsel ilk ekrandaysa lazy kullanmayın. Yer rezervasyonunu baştan verin. Sadece ihtiyaç varsa preload veya yüksek öncelik ekleyin.

Bu akış çoğu içerik projesinde yeterince sağlam sonuç verir. Daha karmaşık sayfalarda ek kararlar çıkabilir; ama en pahalı yanlış genelde değişmez: gerçekten göstermeyeceğiniz kadar büyük bir dosyayı ilk ekrana taşımak. Hero alanında iyi seçim çoğu zaman daha gösterişli efektte değil, daha erken görünen ve daha sakin davranan görseldedir.

Kullanıcı bunu teknik terimlerle tarif etmez. Sadece açılışın toplu mu dağınık mı, hazır mı eksik mi hissettirdiğini algılar. Bu yüzden iyi optimize edilmiş hero görseli, daha hafif dosyadan biraz fazlasıdır; sayfanın ilk cümlesi gibi çalışan bir açılış düzenidir.