Görsel Optimizasyonu

TL;DR — Görsel optimizasyonu, sayfaların hızlı yüklenmesi için resimlerinizi küçültmek anlamına gelir; görünümlerini bozmadan. WebP gibi modern bir format kullanın, dosyayı sıkıştırın ve ekranda göründüğünden çok daha büyük bir resim sunmayın. İnsanların en çok bozduğu kural: sayfanızın en üstündeki büyük görsel hemen yüklenmeli — o görseli asla “tembel yükleme” yapmayın. Bunu iyi yapmak sıralamanızı sihirli bir şekilde yükseltmez ve geçer bir hız puanı da garanti etmez — sadece sayfalarınızı hızlı yapar ve önemli olan hızdır; bu yüzden öncesi ve sonrası gerçek sonuçlarınızı kontrol edin.

Görsel optimizasyonu aslında ne yapar

Görseller neredeyse her zaman bir web sayfasındaki en ağır öğedir. Google’ın kendi belgeleri, görsellerin “genel sayfa boyutuna en büyük katkıyı sağladığını ve bu durumun sayfaları yavaş ve pahalı hale getirebileceğini” söyler. Bu yüzden onları optimize etmek gerçekten tek bir şeyle ilgilidir: ziyaretçinizin indirmek zorunda olduğu baytları kesmek, böylece sayfanız hızlı görünür.

İnsanları şaşırtan kısım: formatın kendisi bir sıralama artışı değildir. JPEG’lerinizi WebP’ye geçirmek tek başına konumlarınızı yükseltmez. Yaptığı şey dosyaları küçültmek, bu da sayfayı hızlandırır ve hız yardımcı olan şeydir. Bu, daha geniş Görsel SEO merkezinin kardeş makalesidir — o, alt metni, dosya adlarını ve görsel aramayı kapsar; bu ise uygulamalı “hızlı yükle” rehberidir.

Önemli olan birkaç şey

• Modern bir format kullanın. WebP ve AVIF, eski JPEG ve PNG’lere göre dosyaları daha kötü görünmeden çok daha küçük yapar. WebP bugün güvenli varsayılandır.
• Sıkıştırın. Bir WebP bile çok büyük olabilir. Görselleri bir sıkıştırıcıdan geçirin ve dosyanın küçük ama yine de iyi göründüğü noktayı bulun.
• Küçük bir alana dev bir görsel sunmayın. Bir resim yalnızca 500 piksel genişliğinde gösteriliyorsa, 3 000 piksellik bir dosyaya ihtiyacınız yok — bu boşa indirmedir.
• Sayfanın altındaki görselleri tembel yükleme yapın. loading="lazy" eklemek, tarayıcıya bir görsele yaklaşana kadar beklemesini söyler. Sayfa altı görseller için harikadır.
• Büyük üst görseli asla tembel yükleme yapmayın. Sayfa ilk yüklendiğinde insanların gördüğü en büyük görsel, Google’ın hızınızı ölçtüğü görseldir. O hemen yüklenmelidir.

Çoğu insanın yanlış yaptığı şey

Her şeyi tembel yükleme yapıyorlar — üstteki kahraman görsel dahil. Kulağa akıllıca geliyor (“daha az şey yükle!”) ama ters: üstteki görsel, sayfa hızı puanınızın ölçüldüğü görseldir, bu yüzden onu geciktirmek puanınızı kötüleştirir. Onu hemen yükleyin ve tarayıcıya önemli olduğunu söyleyin. Bunun tam olarak nasıl yapılacağını Gelişmiş sekmesinde açıklıyorum.

Kesin sürümü mü istiyorsunuz — tam Google alıntıları, WebP-vs-AVIF ödünleşimleri, boyutlandırma matematiği ve fetchpriority hilesi — Gelişmiş sekmesine geçin.

TL;DR — Görsel optimizasyonu, sayfa hızı / Core Web Vitals disiplinidir, doğrudan bir sıralama kaldıracı değildir. Biçim seçimi (WebP, AVIF) baytları küçültür ancak SEO artışı sağlamaz — Mueller bunu üç ayrı şekilde söyledi; ayrıca yalnızca sıkıştırma oranını değil, şeffaflığı, animasyonu ve mevcut tarayıcı desteğini de göz önünde bulundurun. En değerli kural: LCP görselinizi asla geç yüklemeyin (genellikle hero); bu, optimize ettiğiniz metriği geciktirir. Ona loading="eager" + fetchpriority="high" verin, ancak öncelik ipuçları yalnızca keşif/çekme zamanlaması darboğazına yardımcı olur, her LCP sorununa değil. Yerel loading="lazy", ilk görünüm alanının dışındaki görseller içindir — sabit bir “kat altı” piksel çizgisi değil. Sıkıştırmanın evrensel bir “doğru” kalitesi yoktur — her görsel türü için test edin. Doğru boyutlar = işlenen kapsayıcı boyutu × cihaz piksel oranı ve bu kapsayıcı boyutu, duyarlı düzenle birlikte değişir; bu nedenle bir srcset/sizes aralığı (yanlış bir sizes değeri sessizce büyük boyutlu bir görsel indirir) ve bir <picture> geri dönüşü sağlayın. Görseller, web’deki en yaygın LCP öğesidir; bu nedenle bu makale Web Performansı ile çapraz listelenir — ancak bunların hiçbiri geçerli bir Core Web Vitals puanı, bir sıralama değişikliği veya daha fazla trafik garanti etmez; öncesini ve sonrasını ölçün.

Görsel optimizasyonunun optimize ettiği şey (efsaneyi baştan ortadan kaldırın)

Her şeyden önce en büyük efsaneyi ortadan kaldırayım: görsel biçimi bir hız kaldıracıdır, bir sıralama kaldıracı değildir. WebP veya AVIF’e geçmek size bir sıralama artışı kazandırmaz. Size daha küçük dosyalar kazandırır, bu da size daha hızlı bir sayfa kazandırır ve bu da Core Web Vitals’ı besler — ve arama sistemlerinin kullandığı kısım budur. Zincir gerçek ancak dolaylıdır ve bunu “yeni nesil biçimler daha iyi sıralanır” şeklinde özetlemek, çoğu rakip rehberin yanıldığı yerdir.

Google’ın belgeleri, görsellerin hız için neden önemli olduğu konusunda açık sözlüdür: görseller “genel sayfa boyutuna en büyük katkıyı sağlayan öğelerdir ve bu da sayfaları yavaş ve pahalı yükleyebilir” ve öneri, “yüksek kaliteli ve hızlı bir kullanıcı deneyimi sağlamak için en son görsel optimizasyonu ve duyarlı görsel tekniklerini uygulayın” şeklindedir (Google Search Central — Görseller). Çerçeveye dikkat edin: hızlı kullanıcı deneyimi, dosya biçimi için bir sıralama ödülü değil.

Görsel SEO’nun genel ne/neden kısmı için — alt metin, dosya adları, görsel site haritaları, yapılandırılmış veri, görsel arama sıralaması — bu, ana Görsel SEO merkezinin işidir. Bu makale, kurallara uygun nasıl kısmıdır: biçimler, sıkıştırma, boyutlandırma ve yükleme stratejisi.

Herkesin ihlal ettiği kuralla başlayın: LCP görselinizi asla geç yüklemeyin

Bu sayfadan tek bir şey alacaksanız, bunu alın. En Büyük İçerikli Boyama (LCP) öğesi — yüklemede görünüm alanında boyanan en büyük şey — web.dev’e göre “bir görsel veya bir web yazı tipidir” (LCP’yi optimize edin), ve çoğu sayfada bu bir görseldir: hero, öne çıkan görsel, ürün görseli. web.dev, kuralı Google’ın herhangi bir şeyi ifade ettiği kadar açık sözlü bir şekilde ifade eder:

“Never lazy-load your LCP image, as that will always lead to unnecessary resource load delay, and will have a negative impact on LCP.” (çeviri) «LCP görselinizi asla geç yüklemeyin, çünkü bu her zaman gereksiz kaynak yükleme gecikmesine yol açar ve LCP üzerinde olumsuz bir etkiye sahip olur.»

Bu, çoğu “sadece geç yüklemeyi kullan” tavsiyesinin tamamen gözden kaçırdığı inceliktir. Geç yükleme harikadır — kat altındaki görseller için. Bunu LCP görseline uyguladığınızda, iyileştirmeye çalıştığınız tek metriği aktif olarak geciktirirsiniz. web.dev’in geç yükleme rehberi aynı şeyi diğer yönden söyler: “Sayfa yüklendiğinde görünüm alanında olması muhtemel görselleri, özellikle LCP görsellerini geç yüklemeyin” (Tarayıcı düzeyinde geç yükleme).

Aynı argümanı kendi Ahrefs’teki LCP makalemde de yaptım: en büyük öğe “genellikle bir öne çıkan görsel veya belki <h1> etiketi olacaktır,” ve çözümler bundan çıkar. “Görsele ihtiyacınız yoksa, en etkili çözüm ondan tamamen kurtulmaktır. Görsele sahip olmanız gerekiyorsa, boyutunu ve kalitesini mümkün olduğunca küçük tutacak şekilde optimize etmenizi öneririm.” “Hemen ihtiyacınız olmayan görselleri tembel yüklemelisiniz” — ancak bunun tersi, bir nedenden dolayı büyük harflerle yazdığım kesin bir kuraldır: “Katlanma çizgisinin üzerindeki görselleri tembel yüklemeyin!”

LCP görselinde fetchpriority="high"

Hero görselini tembel yüklememek gerekli ama yeterli değildir. LCP görselinin mümkün olduğunca erken yüklenmesini sağlamak için tarayıcıya önceliğini bildirin. web.dev’den:

“Hangi kaynakların en önemli olduğunu tarayıcıya fetchpriority özniteliğini kullanarak bildirebilirsiniz… Sayfanızın LCP öğesi olması muhtemel bir fetchpriority=\"high\" öğesinde <img> ayarlamak iyi bir fikirdir.”

<img src="/hero.webp" alt="…" fetchpriority="high" width="1200" height="675">

LCP yazımda fetchpriority="high" özelliğini aynı şekilde tanımlıyorum — “<img> veya <link> etiketlerinde kullanılabilir ve tarayıcılara görseli erken getirmelerini söyler” — ve bunu, ana HTML gelmeden önce getirmeyi başlatmanın tamamlayıcı bir yolu olarak Early Hints (bir 103 yanıtı) ile eşleştiriyorum. Yani LCP tarifi şudur: eager yükleme + fetchpriority="high" (+ yığınınız destekliyorsa Early Hints). Sayfadaki diğer her şey tembel yüklenebilir.

fetchpriority ve preload’u darboğaza özgü araçlar olarak ele alın, garantili bir çözüm olarak değil. LCP görseli geç keşfedildiğinde veya geç getirildiğinde yardımcı olurlar; yavaş bir sunucu yanıtı, görselin önündeki işlemeyi engelleyen bir kaynak veya gerçekten aşırı büyük bir dosya için hiçbir şey yapmazlar. Bir öncelik ipucunun tek başına sayıyı değiştireceğini varsaymadan önce gerçekte hangi darboğaza sahip olduğunuzu doğrulayın (PageSpeed Insights veya Lighthouse, LCP’yi alt parçalarına ayırır).

Yerel loading="lazy" — katlanma çizgisinin altında ücretsiz, basit ve doğru

İlk görünüm alanında olmayan her görsel için yerel tembel yükleme, performanstaki en kolay kazanımdır. web.dev: “Özel tembel yükleme kodu yazmanıza veya ayrı bir JavaScript kitaplığı kullanmanıza gerek kalmadan görselleri tembel yüklemek için loading özniteliğini kullanabilirsiniz.”

<img src="/below-the-fold.webp" alt="…" loading="lazy" width="800" height="600">

Bunu güvenli kılan iki şey:

• Sabit bir “katlanma çizgisi” yerine ilk görünüm alanına dayandırın. “Katlanma çizgisi” sabit bir piksel sayısı değildir — görünüm alanı boyutu ve düzeniyle değişir. Asıl test, görselin sayfa ilk boyandığında görünme olasılığının olup olmadığıdır. Görünen her şey — ve özellikle LCP görseli — loading="eager" (varsayılan) alır, asla lazy almaz.
• JS hileleri yerine yerel özniteliği tercih edin. Gerçek URL’yi data-src içinde gizleyen ve src sunmayan JavaScript tembel yükleyiciler hiç dizine eklenmeme riski taşır. Yerel loading="lazy" (veya temiz bir IntersectionObserver) src’yi tarayıcılara görünür tutar. Üst Görsel SEO merkezi bu dizine ekleme uyarısını tam olarak ele alır.

Modern biçimler: WebP vs. AVIF vs. JPEG/PNG

Biçimler, efsaneleri çürütmenin en önemli olduğu yerdir, bu yüzden her birinin size ne kazandırdığı konusunda kesin olalım — bu baytlardır, sıralamalar değil.

• WebP — “genellikle JPEG, PNG veya GIF’ten daha iyi sıkıştırma sunar, hem kayıplı hem de kayıpsız sıkıştırma sağlar” (web.dev — Görsel performansı). JPEG’ten yaklaşık %25–35 daha küçüktür ve neredeyse evrensel tarayıcı desteğine sahiptir. Bugün fotoğraflar için güvenli varsayılan.
• AVIF — “hem kayıplı hem de kayıpsız sıkıştırmayı destekler ve testler bazı durumlarda JPEG’e kıyasla %50’den fazla tasarruf göstermiştir.” En iyi sınıf sıkıştırma, biraz daha az evrensel destek, bu yüzden WebP veya JPEG yedeğiyle eşleştirin.
• JPEG — fotoğraflar için evrensel yedek.
• PNG — şeffaflık veya keskin kenarlı grafikler gerektiğinde.
• SVG — logolar ve simgeler: vektör, sonsuz ölçeklenebilir, küçük.

Hangi formatı seçeceğiniz, yalnızca hangisinin en iyi sıkıştırdığına değil, görselin ne yapması gerektiğine de bağlıdır: şeffaflık, animasyon ve bir tarayıcının veya aracın belirli bir kombinasyonu ne kadar tutarlı desteklediği, yukarıdaki ham boyut tasarruflarının yanı sıra seçimi etkileyen tüm faktörlerdir — özellikle animasyonlu herhangi bir şey için, bir formatı varsayılan olarak benimsemeden önce ihtiyacınız olan tam özellik için güncel desteği kontrol edin.

Google Arama, bir <img> src içinde referans verilen “BMP, GIF, JPEG, PNG, WebP, SVG ve AVIF” formatlarını destekler. Modern formatı <picture> kullanarak zarif bir geri dönüşle sunun:

<picture>
  <source srcset="/photo.avif" type="image/avif">
  <source srcset="/photo.webp" type="image/webp">
  <img src="/photo.jpg" alt="…" width="1200" height="800" loading="lazy">
</picture>

Alttaki <img src> sizin güvenlik ağınızdır — eski tarayıcılar ve tarayıcılar ona geri döner ve Google’ın gerçekten dizine eklediği URL budur.

Format sıralamaları etkiler mi? (Hayır — ve Mueller bunu üç şekilde söyledi)

Bu, tüm konu boyunca çekmeye değer tek efsane yıkıcı ipliktir. Üç ayrı, bağımsız zamanlı John Mueller açıklaması da aynı sonuca varıyor — format tarama/dizinleme mekaniklerini ve sayfa ağırlığını etkiler, asla doğrudan sıralamayı etkilemez:

1. AVIF SEO artışı sağlamaz. Google yerel AVIF desteğini ekledikten sonra Mueller, AVIF kullanmanın diğer desteklenen formatlara göre bir “SEO artışı” sağlamadığını doğruladı (SE Roundtable kapsamı).
2. WebP “iyi”dir. “WebP görselleri Görsel Arama için iyidir” — dikkat çekici bir şekilde “iyi”, “daha iyi” değil (SE Roundtable kapsamı).
3. WebP dizinleme tuhaflıkları formata özgü değildir. İnsanlar WebP dosyalarının GSC’de “Tarandı – şu anda dizine eklenmedi” olarak göründüğünü gördüğünde, Mueller’ın noktası görüntü dosyalarının HTML sayfaları olarak dizine eklenmediğiydi ve fenomenin WebP ile sınırlı olduğuna inanmıyordu (SEJ kapsamı).

Sıkıştırma ve kalite: evrensel bir “doğru” ayar yoktur

Görsel kılavuzlarındaki en yaygın kötü tavsiye, tek bir “%80’e sıkıştır” maddesidir. web.dev böyle sihirli bir sayının olmadığını açıkça belirtir:

“Sıkıştırırken, tüm durumlar için uygun evrensel bir ayar yoktur. Önerilen yaklaşım, görüntü kalitesi ve dosya boyutu arasında iyi bir denge bulana kadar farklı sıkıştırma seviyeleriyle denemeler yapmaktır.”

Pratikte: görsel türüne göre test edin. Fotoğraflar agresif kayıplı sıkıştırmayı iyi tolere eder; metin içeren grafikler, logolar ve ekran görüntüleri hızla bozulma gösterir ve genellikle kayıpsız veya daha yüksek kalite ayarı ister. Tek bir kaydırıcıya güvenmek yerine, aynı görseli iki veya üç kalite seviyesinde dışa aktarın ve görüntüleme boyutunda gözle inceleyin — orijinalden görsel olarak ayırt edemediğiniz en küçüğü sizin cevabınızdır. Bu gerçek bir iş akışıdır, “TinyPNG’den geçir ve umut et” değil.

Doğru boyutlar: kapsayıcı boyutu × cihaz piksel oranı

“Sadece küçült” kural değildir — işlenen boyut × cihaz piksel oranı (DPR) ile eşleştirmek kuraldır. web.dev’den:

“500 piksel x 500 piksellik bir kapsayıcıda görüntülenen bir görsel, 500 piksel x 500 pikselde en uygun şekilde boyutlandırılır.”

“Cihazın DPR’si 2 ise ve görsel 500 piksel x 500 piksellik bir kapsayıcıda görüntüleniyorsa, kare 1000 piksellik bir görsel… artık en uygun boyuttur.”

Yani 2× (Retina sınıfı) bir ekrandaki 500×500’lük bir kapsayıcı, 1 000×1 000’lik bir kaynak ister. Bundan daha büyüğe giderseniz, algılanabilir bir kazanç olmadan bayt israf edersiniz; daha küçüğe giderseniz, yüksek DPR’li ekranlarda yumuşak görünür. Bu yüzden bir aralık boyut sunar ve tarayıcının srcset + sizes kullanarak seçmesine izin verirsiniz:

<img
  src="/photo-800.webp"
  srcset="/photo-400.webp 400w, /photo-800.webp 800w, /photo-1600.webp 1600w"
  sizes="(max-width: 600px) 100vw, 500px"
  alt="…" width="800" height="600" loading="lazy">

Tarayıcı, konteyner genişliğini (sizes) ve kendi DPR değerini okur, ardından srcset içinden doğru adayı seçer — yukarıdaki DPR matematiğinin responsive teslim versiyonu. Google, responsive görseller için <picture> veya srcset önerir ve “her zaman src özniteliğini kullanarak bir yedek URL belirtin.” der.

sizes değerini yanlış ayarlarsanız hiçbir şey sizi uyarmaz. Beyan ettiğiniz değer, görselin gerçekte nasıl genişlikte görüntülendiğiyle eşleşmiyorsa — düzen veya CSS değişikliğinden sonra yaygın bir hata — tarayıcının bunu bilme yolu yoktur ve sadece verdiğiniz hatalı sayıya dayanarak bir aday seçer; bu da genellikle düzenin ihtiyaç duyduğundan daha büyük bir dosya indirmesi anlamına gelir. Bu, yukarıdaki format ve sıkıştırma çalışmasını sessizce boşa çıkarır. Bunu yakalamanın tek güvenilir yolu: DevTools’un Network panelini açın, görsel isteğini bulun ve teslim edilen dosyanın boyutlarını konteynerin gerçek görüntülenen genişliğiyle karşılaştırın.

Yukarıdaki 500×500 örneği açıklayıcıdır, site genelinde sabitlenecek bir sayı değildir — aynı hero görseli mobilde masaüstünden farklı bir genişlikte görüntülenebilir, bu nedenle “konteyner boyutu” sabit kalmak yerine responsive düzeninizle birlikte hareket eder. Bu yüzden tek bir “optimal” boyut dışa aktarıp işi bitirmek yerine bir srcset aralığı sunarsınız.

Bunların hepsi neden Core Web Vitals ile bağlantılı

Yukarıdaki her tekniği birbirine bağlayan ortak nokta LCP’dir. Görseller, web’deki en yaygın LCP öğesidir ve LCP, üç Core Web Vitals’tan biridir. Google’ın hedefi: “LCP, 2,5 saniye içinde gerçekleşmelidir” mobil ve masaüstünde sayfa yüklemelerinin 75. yüzdelik diliminde (web.dev — Vitals). Core Web Vitals “tüm web sayfalarına uygulanır, tüm site sahipleri tarafından ölçülmelidir ve tüm Google araçlarında yüzeye çıkarılacaktır.”

Yani görsel optimizasyonu ayrı bir sıralama faktörü değildir — sıralama sistemlerinin kullandığı bir sayfa deneyimi sinyaline (Core Web Vitals) katkıda bulunan bir unsurdur. Bu ayrım doğru çerçevedir ve bu makalenin hem Görsel SEO kümesinde hem de Web Performans kümesinde yer almasının nedeni budur. Metriğin kendisiyle ilgili derinlemesine bilgi için Web Performans bölümündeki Core Web Vitals ve LCP konularına bakın.

Açıkça belirtmeye değer bir uyarı daha: bu sayfadaki hiçbir düzeltme hiçbir şeyi garanti etmez. Görsel baytları LCP’nin yalnızca olası bir bileşenidir — web.dev’in LCP alt parçalarına ilişkin kendi dökümü, görselden önce sunucu yanıt süresi ve render’ı engelleyen kaynaklar gibi şeyleri içerir; bunların hiçbirine format veya sıkıştırma dokunmaz — ve görsel boyutları CLS’ye yalnızca bir girdidir, belirli bir puanın garantisi değildir. Bir hero görselini küçültmek ölçülebilir şekilde yardımcı olabilir, hiçbir şey yapmayabilir veya (gerçek darboğaz başka bir şeyse) sayıyı zar zor hareket ettirebilir. Görselleri optimize etmek ayrıca kendi başına geçerli bir Core Web Vitals değerlendirmesini, bir sıralama değişikliğini, daha fazla trafiği, daha fazla dönüşümü veya bir AI arama alıntısını garanti etmez — bunlar görsel baytlarından çok daha fazlasına bağlıdır. Her görsel düzeltmesini bir hipotez olarak ele alın, kesin bir sonuç olarak değil: LCP ve CLS’yi öncesinde ve sonrasında, laboratuvarda ve sahada ölçün ve optimizasyonun “işe yaradığı” varsayımının değil, bu verilerin bir şeyi hareket ettirip ettirmediğini size söylemesine izin verin.

Yaygın uygulama tuzakları

• CSS arka plan görselleri dizine eklenmez. Geliştiriciler bazen düzen kolaylığı için bir <img> etiketini background-image ile değiştirir. Google “can find images in the src attribute of <img> element (even when it’s a child of other elements, such as the <picture> element)” (çeviri) «Google, <img> öğesinin src özniteliğindeki görselleri bulabilir (bu, <picture> öğesi gibi diğer öğelerin alt öğesi olsa bile)» ancak “doesn’t index CSS images.” (çeviri) «CSS görsellerini dizine eklemez.» Görselin görsel aramada çıkmasını istiyorsanız, onu bir <img> etiketinde tutun. (Bu, performansla ilgilidir, ancak hata yaygın olduğu için belirtmekte fayda var.)
• Mevcut dosyaları toplu olarak yeniden adlandırmayın bir performans/SEO “yenilemesi” için. Mueller, Google’ın sistemlerinin yeniden adlandırılan görselleri yeniden işlemesinin “a lot of time” (çeviri) «çok zaman» aldığını ve bağlamınız zaten iyiyse etkisinin minimum olduğunu söyledi — ana Görsel SEO merkezi bunu ayrıntılı olarak ele alıyor.
• Eksik genişlik/yükseklik. Tarayıcının görsel yüklenmeden önce yer ayırabilmesi için her zaman width ve height (veya CSS aspect-ratio) değerlerini ayarlayın — bu, görsel kaynaklı düzen kaymasını azaltır, ancak CLS’ye katkıda bulunan birkaç girdiden yalnızca biridir, belirli bir puanın garantisi değildir.

Hızlı tarif

• Hero / LCP görseli: modern format, doğru boyut, loading="eager", fetchpriority="high".
• Katlamanın altındaki her şey: loading="lazy".
• WebP/AVIF’i bir <picture> src yedeğiyle sunun.
• Kapsayıcı × DPR’ye göre boyutlandırın; srcset ile bir sizes aralığı teslim edin.
• Görsel türüne göre sıkıştırın — 2–3 kalite seviyesini test edin, tek bir kaydırıcıya güvenmeyin.
• Her zaman width/height ayarlayın.

Görsel SEO’nun geri kalanı için — alt metni, dosya adları, görsel site haritaları, yapılandırılmış veriler ve görsel arama sıralaması — Görsel SEO merkezine geri dönün.

AI özeti

Gelişmiş sürümün yoğunlaştırılmış bir değerlendirmesi:

• Görsel optimizasyonu = hız, sıralama kaldıracı değil. Format seçimi (WebP/AVIF) baytları küçültür → daha hızlı sayfa → daha iyi Core Web Vitals. Formatın kendisi için doğrudan bir sıralama artışı yoktur — Mueller bunu üç ayrı şekilde doğruladı (AVIF “no SEO boost,” (çeviri) «SEO artışı yok» WebP “fine,” (çeviri) «iyi» WebP dizine ekleme tuhaflıkları formata özgü değildir).
• 1 numaralı kural: LCP görselinizi asla tembel yüklemeyin. Sayfa ilk boyandığında görünür olması muhtemel görsel (genellikle hero) LCP’nizi zamanlar; tembel yüklemek, düzeltmeye çalıştığınız metriği geciktirir. Ona loading="eager" + fetchpriority="high" verin (isteğe bağlı olarak Early Hints) — ancak öncelik ipuçları yalnızca bir keşif/çekme zamanlaması darboğazını düzeltir, her LCP sorununu değil (bir ipucunun tek başına yardımcı olacağını varsaymadan önce LCP’nin alt bölümlerini kontrol edin).
• Yerel loading="lazy" ücretsiz ve doğrudur — ilk görünüm alanı dışındaki görseller için, sabit bir “katlamanın altı” piksel çizgisi değil. URL’yi data-src içinde gizleyen JS tembel yükleyicilerinden kaçının.
• Formatlar: WebP güvenli varsayılandır (JPEG’den ~%25–35 daha küçük); AVIF bir yedekle daha da sıkıştırır (bazı testlerde %50+). Seçim ayrıca yalnızca sıkıştırma oranına değil, şeffaflığa, animasyona ve mevcut tarayıcı/araç desteğine de bağlıdır. Google’ın dizine eklediği bir <picture> yedeğiyle <img src> üzerinden sunun.
• Sıkıştırma: evrensel bir “doğru” kalite yoktur — görsel türüne göre test edin (fotoğraflar sert sıkıştırır; metin/grafikler hızla bozulur).
• Boyutlandırma: doğru boyut = işlenen kapsayıcı boyutu × cihaz piksel oranı (2× DPR’de 500px kapsayıcı = 1 000px kaynak) — ve bu kapsayıcı boyutu da duyarlı düzene göre değişir, bu nedenle tek bir sabit dışa aktarma yerine srcset + sizes ile bir aralık teslim edin. Yanlış bir sizes değeri, tarayıcının sessizce aşırı büyük bir adayı indirmesine neden olur.
• Neden önemli: görseller en yaygın LCP öğesidir; LCP hedefi 75. yüzdelik dilimde 2,5 saniyedir. Bu yüzden bu, Web Performansı ile çapraz listelenir — ancak LCP’nin görsel baytlarının tek başına düzeltmediği başka alt bölümleri de vardır (sunucu yanıt süresi, işlemeyi engelleyen kaynaklar).
• Garantiler yok: görselleri optimize etmek, geçen bir Core Web Vitals puanını, bir sıralama değişikliğini, daha fazla trafiği, daha fazla dönüşümü veya bir yapay zeka arama alıntısını kendi başına garanti etmez. LCP/CLS’yi laboratuvarda ve sahada, öncesinde ve sonrasında ölçün.
• Tuzaklar: CSS background-image dizine eklenmez; dosyaları toplu olarak yeniden adlandırmayın; her zaman width/height ayarlayın — düzen kaymasını azaltabilir ancak belirli bir CLS puanını garanti etmez.

Resmi dokümantasyon

Birincil kaynak dokümantasyonu, arama motorları ve Chrome ekibinden.

Google / web.dev

• Image performance (web.dev “Learn Performance”) — formatlar, “evrensel sıkıştırma ayarı yoktur” noktası ve DPR boyutlandırma matematiği.
• Browser-level image lazy loading (web.dev) — yerel loading="lazy" nasıl çalışır ve “görünüm alanındaki / LCP görsellerini tembel yüklemeyin” istisnası.
• Optimize LCP (web.dev) — fetchpriority, LCP kaynağının bir görsel veya yazı tipi olması ve “LCP görselinizi asla tembel yüklemeyin.”
• Fetch Priority API (web.dev) — LCP görselleri için fetchpriority="high" açıklamasının tamamı.
• Web Vitals (web.dev) — Core Web Vitals tanımları ve LCP ≤ 2,5 sn / 75. yüzdelik eşiği.
• Google Images best practices — desteklenen formatlar, <img>/<picture> dizinleme (CSS arka planları değil), responsive görseller ve yedek-src önerisi.

Bing / Microsoft

• Bing, Google’ınki kadar ayrıntılı, görsel optimizasyonuna özel bir teknik rehber yayınlamaz; ilgili yönlendirme, sayfa hızını (görsel ağırlığı dahil) bir husus olarak ele alan genel Bing Webmaster Guidelines içinde yer alır. Bunu, var olmayan bir Bing “alıntısı” uydurmak yerine dürüstçe belirtiyorum.
• Bing Visual Search — nesne düzeyinde görsel arama; format/sıkıştırmanın sayfa hızı etkilerinden ayrı olarak görsel keşfi ile ilgilidir.

Kaynaktan alıntılar

Google’ın Chrome ekibinden ve Arama Savunucularından kayıtlara geçen açıklamalar. Bir sayfa metni açığa çıkardığında, bağlantı alıntılanan pasaja atlayan bir derin bağlantıdır.

web.dev (Google Chrome ekibi) — LCP kuralları

• “Never lazy-load your LCP image, as that will always lead to unnecessary resource load delay, and will have a negative impact on LCP.” (çeviri) «LCP görselinizi asla tembel yüklemeyin, çünkü bu her zaman gereksiz kaynak yükleme gecikmesine yol açar ve LCP üzerinde olumsuz bir etkiye sahip olur.» Alıntıya git
• “Don’t lazy-load images that are likely to be in-viewport when the page loads, especially LCP images.” (çeviri) «Sayfa yüklendiğinde görünüm alanında olması muhtemel görselleri, özellikle LCP görsellerini tembel yüklemeyin.» Alıntıya git
• “It’s a good idea to set fetchpriority=\"high\" on an <img> element if you think it’s likely to be your page’s LCP element.” (çeviri) «Sayfanızın LCP öğesi olması muhtemel bir <img> öğesinde fetchpriority=\"high\" ayarlamak iyi bir fikirdir.» — web.dev, Optimize LCP.

web.dev (Google Chrome ekibi) — formatlar, sıkıştırma, boyutlandırma

• “WebP often has better compression than JPEG, PNG, or GIF, offering both lossy and lossless compression.” Jump to quote
• “AVIF supports both lossy and lossless compression, and tests have shown greater than 50% savings when compared to JPEG in some cases.” — web.dev, Image performance.
• “When compressing, there isn’t a universal setting suitable for all cases. The recommended approach would be to experiment with different compression levels until you find a good compromise between image quality and file size.” — web.dev, Image performance.
• “An image displayed in a 500 pixel by 500 pixel container would be optimally sized at 500 pixels by 500 pixels.” … “If the device has a DPR of 2 … then a square 1000 pixel image … is now the optimal size.” — web.dev, Image performance.

Google Search Central — görsellerin hız için neden önemli olduğu

• “images are often the largest contributor to overall page size, which can make pages slow and expensive to load.” (çeviri) «görseller genellikle genel sayfa boyutuna en büyük katkıyı yapar, bu da sayfaların yavaş ve pahalı yüklenmesine neden olabilir.» Alıntıya git

web.dev — Core Web Vitals

• “Core Web Vitals are the subset of Web Vitals that apply to all web pages, should be measured by all site owners, and will be surfaced across all Google tools.” (çeviri) «Core Web Vitals, tüm web sayfalarına uygulanan, tüm site sahipleri tarafından ölçülmesi gereken ve tüm Google araçlarında yüzeye çıkarılacak Web Vitals alt kümesidir.» Alıntıya git

John Mueller, Google — format bir sıralama kaldıracı değildir

• AVIF hakkında: AVIF dosyaları kullanmanın “SEO artışı” yoktur. Kapsam
• WebP hakkında: “WebP images are fine for Image Search.” (çeviri) «WebP görselleri Görsel Arama için uygundur.» Kapsam

Görsel optimizasyon kontrol listesi

Bu geçişi performansa duyarlı herhangi bir sayfada çalıştırın:

• LCP görselini belirlediniz (genellikle kahraman / öne çıkan görsel / ilk ürün çekimi).
• LCP görseli tembel yüklenmiyor — loading="eager" (varsayılan) kullanır.
• LCP görseli fetchpriority="high" kullanır (yığınınız destekliyorsa Early Hints’i düşünün).
• Katlamanın altındaki her görsel loading="lazy" kullanır.
• Modern biçim sunulur (WebP varsayılan, AVIF desteklenen yerlerde) <picture> src yedekli.
• Her görsel kapsayıcısı × cihaz piksel oranına göre boyutlandırılır — 500px yuvalarda 3 000px dosya yok.
• Görsellerin farklı genişliklerde işlendiği yerlerde srcset + sizes ile duyarlı teslimat.
• Sıkıştırma, görsel türü başına test edildi (görüntüleme boyutunda 2–3 kalite seviyesi karşılaştırıldı), tek bir genel ayar değil.
• Yerleşim kaymasını (CLS) azaltmak için her görselde içsel width ve height (veya CSS aspect-ratio) ayarlandı — belirli bir puanın garantisi değil.
• Hiçbir içerik görseli yalnızca CSS background-image içinde yaşamıyor (bunlar dizine eklenmez).
• Tembel yükleme yerel özniteliği (veya temiz IntersectionObserver) kullanır, URL’yi data-src içinde gizleyen bir JS hilesi değil.
• LCP, sahada doğrulandı (CrUX / PageSpeed Insights), 75. yüzdelik dilimde ≤ 2,5s hedefleniyor.

Görsel optimizasyonu hile sayfası

Kaldıraçlar — her biri ne yapar ve en iyi uygulama

Hızlı bilgiler

• Format bir hız kaldıracıdır, sıralama kaldıracı değildir — Mueller: AVIF “SEO artışı” sağlamaz; WebP “iyidir.”
• WebP JPEG’den yaklaşık %25–35 daha küçüktür; AVIF testlerde genellikle %50+ daha küçüktür.
• En yüksek değerli tek kural: LCP görselinizi asla geç yüklemeyin.
• LCP hedefi: 75. yüzdelik dilimde (mobil + masaüstü) ≤ 2,5s.
• Desteklenen formatlar: BMP, GIF, JPEG, PNG, WebP, SVG, AVIF.
• Doğru boyut = oluşturulan kapsayıcı boyutu × cihaz piksel oranı.

LCP puanınıza mal olan hata

Hero görselini geç yüklemek, bu makalede ele alınan en pahalı hatadır ve geri kalanından önce kendi başına belirtilmeye değer olan hatadır.

• Yanlış: en büyük ekran üstü görsele — genellikle hero, öne çıkan görsel veya ilk ürün fotoğrafı — loading="lazy" (veya bir JS geç yükleyici) uygulamak. Neden yanlış: bu görsel neredeyse her zaman LCP öğenizdir ve web.dev, geç yüklemenin “her zaman gereksiz kaynak yükleme gecikmesine yol açacağını ve LCP üzerinde olumsuz bir etkisi olacağını” açıkça belirtir. İyileştirmeye çalıştığınız metriği geciktirirsiniz. Bunun yerine yapın: LCP görseline loading="eager" (varsayılan) ve fetchpriority="high" verin ve loading="lazy" özelliğini ekran altındaki her şey için saklayın.

Tek bir genel sıkıştırma ayarına güvenmek

• Yanlış: içerikten bağımsız olarak her görseli aynı “%80’e sıkıştır” ön ayarından geçirmek. Neden yanlış: web.dev, “tüm durumlar için uygun evrensel bir ayar yoktur” der — fotoğraflar için ayarlanmış bir ön ayar, logoları, ekran görüntülerini ve metin ağırlıklı grafikleri görünür bozulmalara yol açacak şekilde aşırı sıkıştırır. Bunun yerine yapın: aynı görseli iki veya üç kalite seviyesinde dışa aktarın ve gerçek görüntüleme boyutunda karşılaştırın; görsel türüne göre orijinalinden ayırt edemediğiniz en küçüğünü seçin.

Görselleri kapsayıcıya göre değil, sahip olduğunuz dosyaya göre boyutlandırmak

• Yanlış: görseli gerçekte oluşturulduğu yere eşleştirmek yerine, orijinal dosyanın sahip olduğu çözünürlüğü (veya her düzen için tek bir sabit boyutu) sunmak. Neden yanlış: web.dev’in kendi hesaplamasına göre, doğru boyut oluşturulan kapsayıcı boyutu × cihazın piksel oranıdır — 2× DPR’de 500×500’lük bir kapsayıcı, 500×500 değil ve 3 000×3 000 değil, 1 000×1 000’lik bir kaynak gerektirir. Daha büyük yaparsanız görünür bir kazanç olmadan bayt israf edersiniz; daha küçük yaparsanız yüksek DPR’li ekranlarda yumuşak görünür. Bunun yerine yapın: tarayıcının kapsayıcı ve cihaz için doğru adayı seçebilmesi için srcset ile bir sizes aralığı sunun.

Gerçek içerik görsellerini CSS arkasına gizlemek

• Yanlış: düzen kolaylığı için bir <img> öğesini background-image ile değiştirmek. Neden yanlış: Google “CSS görsellerini dizine eklemez” — yalnızca background-image olarak var olan bir içerik görseli, aksi halde tamamen optimize edilmiş olsa bile görsel aramada görünmez. Bunun yerine yapın: içerik görsellerini bir <img> içinde (veya bir <img> içindeki <picture> yedeği olarak) tutun ve CSS arka planlarını yalnızca tamamen dekoratif işlemler için ayırın.

”İşaretlemeden tasarruf etmek” için width/height atlamak

• Yanlış: width etiketlerinde doğal height ve aspect-ratio (veya bir CSS <img>) bırakmamak. Neden yanlış: tarayıcı görsel yüklenmeden önce düzen alanı ayıramaz, bu nedenle her görsel geldiğinde sayfa zıplar — LCP’nin yanında yer alan Core Web Vital olan CLS’ye zarar verir. Bunun yerine yapın: format ve boyut için de optimize ettiğiniz görseller dahil her görselde her zaman width/height (veya aspect-ratio) ayarlayın.

Zihinsel modeller

1. LCP görselinizi asla geç yüklemeyin. Tüm konudaki en yüksek değerli tek kural. Ekran üstündeki en büyük öğe — genellikle bir görsel — LCP’nizin ölçüldüğü şeydir. Geç yüklemek hiçbir şey kazandırmaz; yalnızca optimize ettiğiniz metriği geciktirir. Sayfadaki diğer her şey loading="lazy" için adaydır; LCP görseli asla değildir.

2. Evrensel bir sıkıştırma ayarı yoktur. “Hangi kaliteye sıkıştırmalıyım?” sorusunu site genelinde bir politika değil, görüntü bazında bir soru olarak ele alın. Fotoğraflar agresif kayıplı sıkıştırmayı tolere eder; metin ağırlıklı grafikler ve ekran görüntüleri etmez. İş akışı karşılaştırmalıdır — iki veya üç kalite seviyesinde dışa aktarın ve görüntüleme boyutunda gözle kontrol edin — bir kez ayarlayıp unutacağınız tek bir kaydırıcı değil.

3. Doğru boyut = kapsayıcı boyutu × cihaz piksel oranı. “Daha küçük daha iyidir” kural değildir; eşleştirme kuraldır. Optimum kaynak boyutları, görüntünün gerçekte görüntülendiği boyutun cihazın piksel oranıyla çarpılmasıdır — 2× DPR’de 500×500’lük bir kapsayıcı, 1 000×1 000’lik bir kaynak ister. Bu, her görüntünün dışa aktarma boyutuna karar vermesi gereken tek formüldür ve bu yüzden tek bir sabit dosya yerine srcset aracılığıyla bir aralık sunarsınız.

4. Biçim bir hız kaldıracıdır, sıralama kaldıracı değil. Bu zinciri doğru şekilde kurun: biçim seçimi → daha küçük dosyalar → daha hızlı sayfa → daha iyi Core Web Vitals → sıralama sistemlerinin gerçekten kullandığı bir sinyal. Doğrudan “yeni nesil biçimler daha iyi sıralanır”a atlamak, rakip kılavuzlarının bu konuyu yanlış ele almasının en yaygın yoludur — Mueller, biçimin kendisi için doğrudan bir SEO artışı olmadığını üç ayrı kez söyledi.

Görüntü odaklı sayfa hızı için kalıcı KPI’lar

Bunlar, görüntü optimizasyonu çalışmanızın gerçekten işe yarayıp yaramadığını söyleyen sürekli sayılardır — bu hafta yeniden boyutlandırdığınız veya dönüştürdüğünüz herhangi bir tek görüntüden bağımsız olarak.

Kendinizi test edin: Görüntü Optimizasyonu

Biçimler, sıkıştırma, boyutlandırma ve yükleme stratejisi hakkında beş hızlı soru. Her biri için bir yanıt seçin, ardından kontrol edin.

Değişiklik günlüğü