Teknik

09 Temmuz 2026 · 8 dk okuma

Görsel optimizasyonu: WebP, lazy load ve CDN

E-ticarette sayfa ağırlığının çoğu görsellerden gelir. WebP ve AVIF seçimi, srcset ile doğru boyutlandırma, lazy load'un LCP tuzağı ve CDN önbelleğiyle ürün sayfalarını hafifletmenin pratik yolu.

Görsel optimizasyonu: WebP, lazy load ve CDN

Mağazanızın bir ürün sayfası ilk açılışta kaç megabayt veri indiriyor? Çoğu mağaza sahibi bu soruyu yanıtlayamaz; ölçenler ise indirilen verinin büyük bölümünün görsellerden geldiğini görür. Görsel, e-ticarette hem sayfanın en ağır yükü hem de ürünü satan asıl unsurdur: silemezsiniz, hafifletmek zorundasınız. Bu rehberde görselin dört katmanını ele alıyoruz — hangi formatta kodlandığı, hangi boyutta sunulduğu, hangi sırayla yüklendiği ve nereden dağıtıldığı. Yolda, iyi niyetle yapılan tek bir ayarın sayfayı hafifletirken nasıl yavaşlattığını da göreceksiniz.

Önce ölçün: sayfanızın görsel bütçesi ne kadar?

Tarayıcınızın geliştirici araçlarında ağ sekmesini açın, önbelleği devre dışı bırakıp ürün sayfanızı yenileyin, listeyi görsellere filtreleyip boyuta göre sıralayın. Bir dakikalık bu iş, sonraki bütün kararlarınızın zeminini kurar. İki sayıyı not edin: sayfanın toplam görsel ağırlığı ve tek başına en büyük görselin boyutu. İkincisi genellikle sayfanın LCP öğesidir, yani kullanıcının "sayfa açıldı" hissini belirleyen görseldir.

Ölçüm yapan hemen herkes benzer tabloyla karşılaşır: makineden çıktığı hâliyle yüklenmiş, ekranda avuç içi kadar yer kaplayan dev bir ürün fotoğrafı; kategori ızgarasındaki onlarca küçük kutuya ürün sayfası için üretilmiş büyük dosyaların basılması; kullanıcının yalnızca ilkini gördüğü, beşi birden inen bir slider. Bunlar tasarım hatası değil, süreç hatasıdır.

Ardından sayfa tipi başına bir görsel bütçesi belirleyin: ana sayfa, kategori ve ürün sayfası için ayrı ayrı "bu sayfa şu ağırlığı geçmesin" deyin. Bütçe, "biraz daha büyük olsun, güzel görünüyor" tartışmasını kapatan tek şeydir. Testi de ofis internetinde değil, kısıtlanmış mobil bağlantıda yapın. Ölçümün genel çerçevesini Core Web Vitals rehberimizde bulabilirsiniz.

Format kararı: JPEG'i hangi sırayla bırakmalı?

Aynı fotoğrafı modern bir formatta kodlamak, tek satırlık değişiklikle elde edilebilecek en büyük kazançtır: gözle fark edilir kayıp olmadan dosya küçülür. Sıralama şudur — WebP katalogun tamamı için güvenli varsayılan, AVIF ise en çok görüntülenen sayfaların büyük görselleri için bir üst basamaktır. Buna karşılık fotoğrafı PNG olarak yayınlamak, gereksiz ağırlığın en yaygın kaynağıdır.

Formatı iki yoldan sunabilirsiniz. Birincisi, <picture> öğesiyle kaynakları açıkça sıralamak: önce AVIF, sonra WebP, en sonda JPEG. Kontrolü size verir ama şablonları kalabalıklaştırır. İkincisi, sunucunun ya da görsel CDN'inin tarayıcının Accept başlığına bakıp tek adresten uygun formatı döndürmesidir; şablon sade kalır, ancak önbelleğin yanlış varyantı paylaşmaması için doğru yanıt başlıkları gerekir. Küçük katalogda birinci yol, büyük katalogda ikinci yol daha az bakım ister.

FormatNerede kullanılırDikkat
WebPTüm ürün ve kategori görselleriKalite ayarını ürün tipine göre kalibre edin
AVIFHero ve büyük ürün görselleriKodlaması yavaş; toplu dönüşümü kuyruğa alın
PNGKeskin kenar ve şeffaflıkFotoğraf için kullanmayın
SVGLogo, ikon, ödeme rozetleriDışarıdan gelen dosyayı temizleyin
Video / animasyonlu WebPHareketli ürün tanıtımıGIF'in yerini alır; sessiz döngü kurun

Sunulan boyut: srcset olmadan format kazancı erir

Format değiştirmek işin görünen yüzü; asıl israf boyuttadır. Çok geniş bir görseli WebP'ye çevirseniz bile, ekranda kapladığı alanın kat kat üstünde piksel indirtiyorsanız kazancın büyük kısmını başlangıçta harcarsınız. Kural basittir: tarayıcıya, o ekranda göstereceği boyuta en yakın dosyayı verin. Bunun için her görselden bir varyant merdiveni üretin — telefondan masaüstüne birkaç genişlik yeter — ve srcset ile listeleyin. Yüksek yoğunluklu ekranlar için iki katına kadar çıkmak makul; ötesi gözle ayırt edilmezken dosyayı ciddi biçimde büyütür.

En sık yapılan hata, srcset yazıp sizes yazmayı unutmaktır. sizes verilmediğinde tarayıcı görselin ekran genişliğinin tamamını kaplayacağını varsayar ve kategori ızgarasındaki küçük bir karta masaüstü boyutunda dosya indirir. Ekibin "optimize ettik" sanıp sonuç alamamasının en yaygın nedeni budur. Ayar en çok, görsel yoğunluğu en yüksek sayfalar olan kategori sayfalarında işe yarar.

İki tamamlayıcı alışkanlık: mobilde kadraj değişiyorsa (masaüstünde geniş, telefonda kare kırpım) bunu CSS ile kırpmak yerine <picture> içinde farklı kaynaklarla çözün. Ve her görsele genişlik-yükseklik değeri ya da en-boy oranı verin; bu tek satır, sayfa yüklenirken içeriğin zıplamasını ve müşterinin yanlış butona basmasını engeller.

Lazy load'un LCP tuzağı: ilk görsel asla ertelenmez

Ekran dışındaki görselleri ertelemek, tarayıcıların yerleşik loading="lazy" desteğiyle artık tek öznitelikten ibarettir. Kolay olduğu için de sık suistimal edilir: şablona "bütün görsellere ekle" denir ve sayfa hafiflerken hız metrikleri kötüleşir. Çünkü ertelenen görsel, tarayıcının erken tarama aşamasında değil, düzen hesaplandıktan sonra ve düşük öncelikle indirilmeye başlar. Ana ürün fotoğrafınız ekranın tam ortasındayken ertelendiğinde, sayfa hafifler ama kullanıcı boş kutuya bakmaya devam eder. Doğru kurgu üç maddedir:

  1. İlk ekranda görünen görseller ertelenmez. Ürün sayfasında galerinin ilk fotoğrafı, kategori sayfasında ızgaranın ilk sırası, ana sayfada hero görseli normal yüklenmelidir. Kaç kartın ilk ekrana girdiğini masaüstüne göre değil telefona göre kararlaştırın.
  2. LCP adayına öncelik verin. En büyük görselin yüksek öncelikle indirilmesini işaretleyin; görsel bir slider ya da JavaScript bileşeninin içinde geç keşfediliyorsa ayrıca önden yüklenmesini sağlayın.
  3. Gerisini erteleyin, ama erken tetikleyin. Yükleme, görsel tam ekrana girdiği anda başlarsa kullanıcı kaydırırken gri kutular görür; tetikleme eşiğini ekranın biraz dışına alın.

Yer tutucuya da dikkat edin: doğru en-boy oranına sahip nötr bir zemin çoğu zaman yeterlidir, her görsel için ayrıca bulanık minyatür indirmek tasarruf ettiğiniz baytları geri koyar. Tarayıcının yerleşik çözümü, JavaScript'e bağlı özel yükleyicilere göre bu açıdan hep daha güvenlidir.

Dağıtım katmanı: CDN, önbellek ve varyant disiplini

Görseller değişmeyen, tekrar tekrar istenen dosyalardır; önbelleğe alınmak için biçilmiş kaftandır. Kullanıcıya coğrafi olarak en yakın noktadan sunmak, özellikle farklı bölgelerden trafik alan mağazalarda ilk baytın gelme süresini hissedilir biçimde kısaltır. Uygulama sunucunuzu da görsel servis etmekle meşgul etmeyin: statik dosyalar nesne depolamanın ve CDN'in işidir. Önbellek tarafında pratikte üç karar önemlidir:

  • Uzun ömür ve sürümlü dosya adı. Görsellere kısa ömürlü önbellek vermek yerine uzun süreli ve değişmez olarak işaretleyin; güncelleme gerektiğinde adresteki sürümü değiştirin. Böylece "eski fotoğraf hâlâ görünüyor" sorunuyla uğraşmazsınız.
  • Temizleme yerine sürümleme. Aynı adresin içeriğini değiştirip tüm uç noktalardan önbellek temizlemeye çalışmak, sürüm değiştirmekten hem yavaş hem güvenilmezdir.
  • Sınırlı varyant kümesi. Adres parametreleriyle anlık boyutlandırma yapan görsel CDN'leri pratiktir, ama parametreler serbest bırakılırsa her kombinasyon yeni bir önbellek kaydı üretir: sürekli ıskalayan önbellek ve boşuna çalışan sunucu. İzin verilen genişlikleri sabit bir listeye kilitleyin.

Son bir ayrıntı: görselleri ayrı bir alan adından sunuyorsanız o alana bağlantının sayfa başında önceden kurulmasını sağlayın; aksi hâlde ilk görsel, ad çözümleme ve güvenli bağlantı maliyetini tek başına öder.

Kalite eşiği: ürün görselinde nereye kadar sıkıştırmalı?

Sıkıştırma tek bir küresel ayar değildir. Beyaz fon üzerinde düz renkli bir ürün agresif sıkıştırmayı sorunsuz kaldırır; dokusu yoğun ürünler — kumaş, halı, ahşap, takı, deri — çok daha erken bozulur. Bu yüzden tek bir kalite değerini bütün katalogda uygulamak yerine ürün grubuna göre politika belirleyin. Karar kriteri nettir: farkı, görselin gerçekte gösterildiği boyutta ve gerçek bir telefon ekranında değerlendirin. O boyutta orijinaliyle sıkıştırılmışını ayırt edebiliyorsanız fazla ileri gitmişsinizdir; farkı ancak büyüterek görüyorsanız dosyayı gönül rahatlığıyla yayınlayın.

Üç hataya dikkat edin. Birincisi, zaten sıkıştırılmış dosyayı yeniden sıkıştırmak: her tur kalıcı kayıp bırakır, toplu optimizasyon aracını ikinci kez çalıştırmak kimse fark etmeden katalogu yıpratır. Çözüm, orijinali el değmeden saklayıp varyantları her seferinde ondan türetmektir. İkincisi, üstünkörü çekilmiş bir fotoğrafı sıkıştırmayla kurtarmaya çalışmak: gürültülü ve kötü aydınlatılmış kare hem daha çirkin hem daha zor sıkışır, kaynağı düzeltmek daha ucuzdur ve basit bir ev stüdyosu kurulumu bunun için yeterlidir. Üçüncüsü, metadata temizliğinde fazla hevesli olmak: konum ve cihaz bilgisini silmek doğru, renk profilini de silmek renkleri soluklaştırır. Ekranda görülen renkle kutudan çıkan renk uyuşmadığında faturası doğrudan iade oranına yazılır.

Son olarak galeriyi iki katmana ayırın: listede görünen görsel, gösterildiği boyuta göre üretilmiş hafif varyant olsun; yüksek çözünürlüklü dosya yalnızca kullanıcı yakınlaştırmak istediğinde yüklensin. Böylece detayı merak eden müşteriyi memnun eder, sayfayı ilk açan herkese ağır dosya indirtmemiş olursunuz.

"Görsel optimizasyonunun ölçüsü dosya boyutu değil, müşterinin ekranında gördüğü şeydir: ürünü doğru gösteren en küçük dosya."

Uygulama kontrol listesi

  • Sayfa tipi başına görsel ağırlığı bütçeniz tanımlı mı?
  • Fotoğraflar WebP/AVIF olarak sunuluyor, PNG yalnız şeffaflık için mi?
  • Her görselin varyant merdiveni var mı, srcset ile birlikte sizes yazılmış mı?
  • Bütün görsellerde genişlik-yükseklik ya da en-boy oranı tanımlı mı?
  • İlk ekrandaki görseller ertelenmeden, LCP adayı öncelikli yükleniyor mu?
  • Görseller CDN üzerinden, uzun ömürlü ve sürümlü adreslerle mi dağıtılıyor?
  • Varyantlar her zaman saklanan orijinalden mi üretiliyor?
  • Renk profili korunuyor, yalnızca gereksiz metadata mı siliniyor?

Sık sorulan sorular

WebP mi AVIF mi kullanmalıyım?

İkisi arasında seçim yapmak zorunda değilsiniz. Katalogun tamamı için WebP'yi varsayılan yapın; AVIF'i en çok görüntülenen sayfaların büyük görsellerinde ek varyant olarak devreye alın ve tarayıcı desteklemiyorsa WebP'ye düşsün. AVIF'in kodlaması pahalı olduğundan toplu dönüşümü arka planda kuyruğa alın.

Mevcut binlerce görseli toplu dönüştürürsem adresler değişir mi, SEO'ya zarar verir mi?

Dönüşümü tek seferde tüm katalogda çalıştırmak yerine arka plan kuyruğuyla parça parça yapın ve orijinalleri silmeden saklayın. En güvenli yol, aynı adresi koruyup formatı sunucu tarafında belirlemek ya da eski adresleri kalıcı olarak yönlendirmektir; ölü bağlantı bırakmadığınız sürece görselleriniz arama sonuçlarındaki yerini kaybetmez.

Dosya adı ve alt metni performansı etkiler mi?

Yükleme süresine doğrudan etkisi yoktur; buna karşılık görselin bulunabilirliğini ve erişilebilirliğini belirler. Açıklayıcı bir dosya adı ve ürünü gerçekten tarif eden bir alt metin, görsel aramalarından gelen trafiği besler ve ekran okuyucu kullananlar için sayfayı kullanılabilir kılar. Anahtar kelime yığmadan yazın.

Görsel optimizasyonu tek seferlik bir temizlik değil, yükleme akışına gömülmesi gereken bir süreçtir: her yeni fotoğrafta varyantların otomatik üretilmesi, doğru formatın seçilmesi ve doğru adresten sunulması gerekir. Bunu elle sürdürmek yıpratıcıdır; altyapının işi olmalıdır. Şimşek Software'in e-ticaret altyapısında ürün görselleri, stok ve sipariş yönetiminin geri kalanıyla birlikte tek panelden yönetilir; SEO dostu altyapı, pazaryeri ve kargo entegrasyonları ile sanal POS aynı yerde durur. Çözümlerimizi inceleyebilir, ürün sayfalarınızın nasıl hafifleyeceğini birlikte görmek için demo talep edebilirsiniz.

arrow_back
Önceki Yazı

Tekirdağ'da e-ticaret: köfteden sanayiye dijital görünürlük

Sonraki Yazı

Retargeting kampanyalarıyla kararsız ziyaretçiyi geri getirmek

arrow_forward

Bir sonraki adımı birlikte atalım

Markanıza özel bir demo hesabıyla tüm kurumsal özellikleri keşfedin.