Çoğu e-pin satıcısı sitesinin yavaş açılmasını hosting'e, PHP sürümüne ya da "şansa" bağlar. Panele girer, önbelleği temizler, bir eklenti daha kurar ve sonuç değişmeyince "herkesin sitesi böyle" diyerek konuyu kapatır. Oysa sorunun büyük kısmı çok daha sıradan bir yerde duruyor: ürün kartlarına yıllar içinde yüklenmiş, hiç elden geçirilmemiş yüzlerce oyun logosu ve kampanya banner'ı.
Bu yazıda teoriyi bir kenara bırakıyoruz. Bir e-pin satış scripti üzerinde görsellerin gerçekte ne kadar yer kapladığını, WebP'ye geçişin neyi değiştirdiğini ve bu geçişi bozmadan yapmak için hangi sırayı izlemen gerektiğini anlatıyorum. Aynı mantık, kullandığın dijital ürün satış yazılımı hangisi olursa olsun çalışır; çünkü tarayıcı senin panelini değil, indirdiği baytları önemsiyor.
Gerçekten görseller mi suçlu, yoksa sunucu mu?
Bunu tahminle değil ölçerek bileceksin. Kategori sayfanı aç, tarayıcının geliştirici araçlarında Network sekmesine geç ve dosya tipine göre sırala. Karşına çıkan tabloda genellikle iki rakam vardır: HTML+CSS+JS toplamı birkaç yüz kilobayt, görseller ise birkaç megabayt. Bir oyun logosunun 900x900 PNG olarak durup kartta 120x120 piksel gösterilmesi, sektörde istisna değil kural. Tarayıcı o dosyanın tamamını indirir, sonra küçültür; yani kullanıcı görmediği piksellerin faturasını mobil veriyle öder.
Sunucun yavaş olabilir, ama 2,4 MB'lık bir vitrini hiçbir sunucu kurtaramaz. Görsel ağırlığı, altyapı yatırımından önce çözülmesi gereken kalemdir. İyi haber şu: bu kalem parayla değil disiplinle çözülüyor.
PNG alışkanlığı nereden geldi ve neden artık pahalı?
E-pin işinde logolar genellikle şeffaf zeminli geldiği için yıllarca PNG standart oldu. PNG kayıpsız çalışır, şeffaflığı korur, her yerde açılır. Sorun şu ki kayıpsız sıkıştırma, fotoğrafik geçişleri ve degrade arka planları olan modern oyun kapaklarında çok verimsizdir. WebP ise hem kayıplı hem kayıpsız modu destekler ve alfa kanalını kaybetmez. Yani şeffaflığı bırakmak zorunda kalmadan PNG'nin yarısı boyutta dosya üretebilirsin.
Pratikte üç ayrı senaryo var: şeffaf küçük logolar için kayıpsız WebP, geniş kampanya banner'ları için kalite 75-82 aralığında kayıplı WebP, ikonlar için ise hiç raster kullanmamak ve SVG'ye geçmek. Bu üç kararı doğru vermek, tek başına sayfa ağırlığını yarıya indirir.
| Görsel tipi | Eski format | Doğru hedef | Ortalama kazanç | Dikkat |
|---|---|---|---|---|
| Oyun logosu (şeffaf, 240px) | PNG-24 | WebP kayıpsız | %35 | Alfa kanalı korunmalı |
| Kategori kapak görseli | JPEG 90 | WebP q78 | %42 | Metin varsa q85 |
| Ana sayfa slider | PNG-24 | WebP q80 + 2 boyut | %55 | srcset zorunlu |
| Ödeme yöntemi ikonu | PNG 64px | SVG | %80 | Tek dosyada sprite |
| Blog içi ekran görüntüsü | PNG-24 | WebP q75 | %60 | Genişlik 1200px'i aşmasın |
| Favicon / uygulama ikonu | PNG çoklu | ICO + 512 PNG | - | WebP'ye çevirme |
Geçişi bozmadan yapmanın sırası nedir?
En sık yapılan hata, tüm klasörü toplu dönüştürüp eski dosyaları silmek. Veritabanındaki yüzlerce kayıt hâlâ .png uzantısına işaret ettiği için vitrin anında boşalır. Doğru yol katmanlı ilerlemek: önce yeni formatı üret, eskiyi yerinde bırak, sonra sunumu değiştir, en son temizlik yap.
Uygulanabilir sıra şöyle: (1) tüm görselleri yedekle, (2) her dosyanın yanına aynı adla .webp üret, (3) şablonda tek
60 ürünlük kategori sayfasında ağırlık dağılımı
- Ürün ve logo görselleri 52%
- Banner ve slider 23%
- Script JS + CSS 15%
- HTML, font, diğer 10%
Boyut küçültmek yetmez: doğru ölçüde servis etmek
Formatı değiştirdin ama 1600 piksellik dosyayı 300 piksellik karta koymaya devam ediyorsan işin yarısını yapmışsın demektir. Her görsel için en az iki, ideal olarak üç varyant üret: kart boyutu, detay sayfası boyutu ve retina karşılığı. Ardından srcset ve sizes ile hangi ekranın hangi dosyayı alacağını tarayıcıya söyle.
İkinci kritik ayar loading="lazy". Vitrinin altındaki 40 ürün ilk açılışta yüklenmek zorunda değil. Ancak ekranın üst kısmındaki ilk 4-6 karta lazy verme; orada tersine fetchpriority="high" istersin. Üçüncüsü de width ve height niteliklerini mutlaka yazmak: boyut belirtilmemiş görsel, yüklendiği anda sayfayı zıplatır ve kullanıcı yanlış butona basar.
Panelden görsel yüklenirken otomatik olarak WebP üretilmesini ve maksimum genişliğin sınırlanmasını sağla. Böylece bir yıl sonra aynı temizliği ikinci kez yapmak zorunda kalmazsın; tek seferlik dönüşüm değil, kalıcı bir kural kurmuş olursun.
CDN ve önbellek: aynı işi iki kez yapmamak
Dönüştürme işlemi CPU harcar. Her istek geldiğinde yeniden dönüştürmek sunucuyu kilitler. Bu yüzden üretilen WebP dosyalarını diske yaz ve bir daha üretme. Önünde CDN varsa görsellere uzun süreli Cache-Control ver, dosya adına sürüm damgası ekle. Böylece görseli güncellediğinde önbelleği tek tek temizlemek yerine yeni adres yayınlarsın.
Dikkat edilecek bir ayrıntı: aynı URL'den tarayıcıya göre farklı format dönüyorsa Vary: Accept başlığı şart. Aksi halde CDN, WebP dosyasını eski bir tarayıcıya servis eder ve kullanıcı bozuk kart görür. Bu tek satırlık eksik, en çok baş ağrıtan hatalardan biridir.
Bunu kendi başına mı kurmalısın, hazır altyapı mı?
Teknik ekibin varsa yukarıdaki adımları elle kurabilirsin. Ama tek başına satış yapan bir işletmeysen, her yeni oyun eklediğinde bu zinciri hatırlamak gerçekçi değil. Pinova gibi hazır bir epin yazılım altyapısında görsel işleme boru hattı zaten ürün ekleme akışının içine gömülüdür: yüklediğin dosya otomatik olarak boyutlandırılır, WebP karşılığı üretilir, şablon doğru varyantı seçer.
Burada satın aldığın şey bir dönüştürücü değil, disiplini yazılıma devretme rahatlığı. Hangi yolu seçersen seç, ölçütün sabit kalsın: kategori sayfası toplam 900 KB'ın altında, en büyük tek görsel 120 KB'ın altında, ilk anlamlı boyama 2,5 saniyenin altında. Bu üç sayıyı tutuyorsan görsel tarafı bitmiştir. Detaylı teknik başlıklara özellikler sayfasından, paket farklarına ise fiyat bölümünden bakabilirsin.
| Kontrol | Nasıl bakılır | Hedef | Durum |
|---|---|---|---|
| Tüm ürün görselleri WebP var mı | Klasör sayımı / panel raporu | %100 | Yapıldı / Eksik |
| picture-source yedeği tanımlı mı | Sayfa kaynağı incele | Her kart | Yapıldı / Eksik |
| width-height nitelikleri yazılı mı | Layout kayması testi | CLS < 0,1 | Yapıldı / Eksik |
| Alt katman lazy yükleniyor mu | Network kayıt sayısı | İlk 6 hariç | Yapıldı / Eksik |
| En büyük görsel boyutu | Network sıralama | < 120 KB | Yapıldı / Eksik |
| Vary Accept başlığı | Yanıt başlıkları | Mevcut | Yapıldı / Eksik |
| Yükleme anında otomatik dönüşüm | Test ürünü ekle | Aktif | Yapıldı / Eksik |
Vitrinin hafif açılsın, kart görselleri kendi kendine hazırlansın
Pinova'da görsel işleme akışı ürün ekleme adımının içinde çalışır; boyutlandırma, WebP üretimi ve varyant seçimi için ayrı bir iş yükü taşımazsın.
Eski PNG dosyalarını silmem gerekir mi?
Hayır, hemen silme. En az bir hafta yedek kaynak olarak dursunlar. Hata kaydında eksik görsel uyarısı görmüyorsan arşiv klasörüne taşıyabilirsin; tamamen silmek için acele etmenin bir faydası yok.
WebP kalite değerini kaça ayarlamalıyım?
Fotoğrafik kapaklarda 78-82 aralığı gözle ayırt edilemeyen sonuç verir. Üzerinde okunacak metin bulunan banner'larda 85'e çık. Şeffaf küçük logolarda kayıplı mod yerine kayıpsız modu tercih et.
AVIF'e geçmem daha mantıklı olmaz mı?
AVIF daha küçük dosya üretir ama dönüştürme süresi çok daha uzundur ve bazı eski cihazlarda sorun çıkarır. Önce WebP'yi tam kur, kazancı al; AVIF'i sonradan üçüncü bir kaynak olarak ekleyebilirsin.
Görselleri dönüştürünce arama sıralamam etkilenir mi?
Dosya adı ve alt metni koruduğun sürece olumsuz etki olmaz, aksine hız kazancı olumlu yansır. Dikkat edeceğin tek nokta, görsel adreslerini değiştirdiysen eski adresten yenisine yönlendirme bırakmak.
Görsel optimizasyonu, bir dijital ürün satış scripti üzerinde en hızlı geri dönen işlerden biridir: bir günlük çalışma, aylarca sürecek bir hız kazancına dönüşür. Bu akışın hazır kurulu hâlini kendi gözünle görmek istersen canlı demo üzerinden bir ürün ekleyip yüklediğin görselin arka planda nasıl işlendiğine bakabilirsin; teoriyi okumaktan daha ikna edici oluyor.