Web Sitesi Görsel Optimizasyonu

Görüntü optimizasyonu WordPress performansının en “ödüllendirici” yönlerinden biridir: aynı sayfa yapısı ve tema için, görüntü boyutu, boyutları, biçimlendirmesi ve dağıtımı doğru olduğu sürece, yükleme deneyimi hemen iyileşecektir.

Ancak görüntü optimizasyonu, teknik olarak çok zor olduğu için değil, bilgi çok parçalı olduğu için karmaşa yaratmanın da en kolay yoludur:
Birkaç makale okuyorsunuz, “sıkıştırma”, “WebP/AVIF”, “tembel yükleme” olduğunu biliyorsunuz ve sonra eklenti tanıtımına bakıp “her ay ücretsiz! Ayda 100 kredi”, “Ücretsiz 20MB”, “Resim başına 1 kredi”, ama okudukça kafam daha da karışıyor-- Ücretsiz olması yeterli mi? Ücret nasıl düşülür? “Aynı şeyi” yanlış mı anladınız? Ve en önemlisi:Bunu yaptıktan sonra gerçekten etkili oldu mu, olmadı mı?

Bu makale sadece üç şey yapıyor:

1. Size bir çalıştırılabiliryol haritası (ayrıca şekil)(Önce ne yapmalı, sonra ne yapmalı)
2. Hangi seçeneği tercih edeceğiniz konusunda net olun (ücretsiz/ücretli arasındaki fark nedir ve her biri kimler için uygundur)
3. En yaygın tuzakları önceden yazın (böylece işiniz bittiğinde sorun gidermek için etrafta arama yapmak zorunda kalmazsınız)

1. Alt Satır: WordPress Nelerle Geliyor ve Nelerle Gelmiyor?

Önce WordPress çekirdeğinin zaten ne yaptığını bulmazsanız, iki şeyden birini yapmak kolaydır:

• Yararlanmanız gereken “boş kapasiteyi” kullanmak yerine, çarkı tekrar tekrar inşa etmek için zaman harcıyor / para harcıyorsunuz.
• WordPress'in “tüm eski görüntüleri otomatik olarak WebP/AVIF'e dönüştüreceğini” sanıyordum, ama öyle değilmiş!

WordPress çekirdeğinde bu temel özellikler yerleşik olarak bulunur:

• Duyarlı görseller (srcset/sizes): WordPress 4.4'ten itibaren, çekirdek, aşağıdakiler için görüntü çıktısı verecektir srcset 与 sizesve tarayıcının ekran koşullarına göre yüklemek için daha uygun bir kaynak seçmesine izin vermek için yükleme sırasında oluşturulan çok boyutlu görüntüleri kullanır.
• Yerel tembel yükleme: WordPress 5.5 ve sonrası, HTML standartlarını kullanarak varsayılan olarak görüntülerin yerel olarak tembel yüklenmesini sağlar. loading öznitelik uygulaması.
• WebP yükleme desteği: WordPress 5.8'den beri WebP'yi JPEG/PNG olarak yükleyebilir ve kullanabilirsiniz (barındırma ortamının WebP'yi desteklemesi şartıyla).
• AVIF yükleme desteği: WordPress 6.5 ve sonrası AVIF'i JPEG/PNG olarak yükleyebilir ve kullanabilir (barındırma desteğine de bağlıdır).

Ama dikkat et:
“Yükleme/kullanım desteği” ≠ “Otomatik dönüştürme/otomatik teslimat”.
Yani: WP 6.5“te olsanız bile, medya kitaplığınızdaki JPG/PNG'ler kendi başlarına WebP/AVIF'e dönüşmeyecektir; otomatik olarak tam ”tarayıcının özelliklerine göre AVIF/WebP çıktısı ve desteklenmeyen tarayıcılar için orijinal görüntüye geri dönüş" bağlantısını almayacaksınız! --Bu kısmın genellikle bir eklenti veya hizmet tarafından düzeltilmesi gerekir.

2. Yol Haritası: 5 adımda görüntü optimizasyonu

Ne yapmalı, neden yapmalı, kalifiye olmak için ne yapmalı ve tipik bir çukur nedir.

2.1 Önce “boyutu” doğru belirlemek (en çok gözden kaçan ama en çok ödüllendiren)

Birçok istasyonun yavaş olmasının nedeni sıkıştırma işleminin yapılmaması değilGörüntüleme alanının çok ötesine uzanan büyük bir görüntü indirildi：
Örneğin, sayfa aslında sadece 900 piksel genişliğindeyse ve ziyaretçiden orijinal 3000 piksel resmi indirmesini isterseniz, tarayıcı sadece “indirir ve sonra küçültür”. Bu da bant genişliğini boşa harcar, kod çözme süresini uzatır ve ilk ekranı yavaşlatır.

WordPress 4.4+Duyarlı Görüntü Mekanizması（srcset/sizes) tam da bu sorunu ele almak üzere tasarlanmıştır.

Pas olarak ne sayılıyorsa onu yapın:

• Bir sayfayı cep telefonunda açarken, indirilen görüntünün boyutu masaüstündekinden önemli ölçüde daha küçük olmalıdır
• Aynı görüntü farklı cihazlarda farklı kaynak boyutlarıyla yüklenir (her zaman orijinal görüntüyü indirmek yerine)

En yaygın tuzaklar:

• Diyagramları CSS arka plan görüntüleri olarak ele alan veya bunları özel bir şekilde çıktılayan temalar / oluşturucular vardır. srcsetSonuç olarak ortaya büyük bir resim çıktı.
• Harici olarak bağlanmış görüntü yataklarını, üçüncü taraf görüntü bloklarını kullanabilir ve ayrıca medya kütüphanesi tarafından oluşturulan çoklu boyut sistemini atlayabilirsiniz

---

2.2 Sıkıştırma (KB'yi düşürün, ancak kaliteyi “ezmeyin”)

Sıkıştırmanın özü “ne kadar küçük o kadar iyi” değil, “fark çıplak gözle zar zor görülebilir, ancak hacim düşüşü barizdir”.

Kurallar aşağıdaki gibidir:

• Fotoğraflar/canlı çekimler (insanlar, ürünler, manzaralar): Öncelikli kayıplı sıkıştırma (maksimum kazanç)
• Arayüzün ekran görüntüleri / metin ağırlıklı görüntüler: Bulanık metni önlemek için sıkıştırma daha muhafazakar olmalıdır
• Logo/İkon: Öncelikli SVG veya gizli kayıpsız (kayıplı kenar yapıştırması kolaydır)

Pas olarak ne sayılıyorsa onu yapın:

• Çoğu sayfada görüntü boyutunda önemli ölçüde azalma
• Görünür gürültü, çamurlu kenarlar, renk bloğu kırılmaları, bulanık metin yok

---

2.3 WebP / AVIF (format stratejisi: eşit tanım için daha küçük)

WordPress yükleme işlemini zaten destekliyor WebP (5,8) vs. AVIF (6,5)。
Ancak Yeni Nesil Format'ın gerçekten işe yaraması için genellikle iki şeyin çözülmesi gerekir:

1. Geçmiş medya kitaplıklarını toplu dönüştürme(Aksi takdirde yalnızca “daha sonra yüklenen yeni resimler” için optimizasyon yapmış olursunuz)
2. Orijinal görüntünün bir kopyasının oluşturulup oluşturulmayacağı veya değiştirilip değiştirilmeyeceği(Bu riskli bir dönüm noktasıdır; daha sonra Plus WebP'nin “Orijinal Görüntüyü Değiştir ve Sil” özelliğine odaklanacağız)

Önerilen yazı stili:

• WebP: genellikle varsayılan olarak tercih edilir (daha kararlı uyumluluk)
• AVIF: daha ileri bir sıkıştırma yönü, büyük görüntüler/ilk ekran büyük görüntüleri/albüm görüntüleri için uygundur (ancak dahaÇevresel desteğe bağımlılık）

---

2.4 Tembel yükleme doğru kullanılmalıdır (herkese uyan tek bir boyut değil)

WordPress 5.5 ve sonrasıVarsayılan tembel yüklemeResim.
İlk işleme sırasında bant genişliği kullanımını azaltır:

• “Ekran dışı kaynaklar” için tembel yükleme”
• İlk ekrandaki en kritik büyük görüntü (ve çoğu durumda ilk ekrandaki kilit görüntü) genellikle gecikmeli yükleme için uygun değildir

---

2.5 Teslimat Katmanı: CDN / Fotoğraf CDN

Sıkıştırma, boyutlandırma ve biçimlendirme “sığan daha küçük dosyalar” sorununu çözer.
Ancak, görüntüler her zaman kaynaktan uzak bir mesafeden çekiliyorsa, ağ gecikmesi yine de deneyimi önemli ölçüde etkileyecektir. İşte bu noktada “dağıtım katmanı” çözümü (CDN/görüntü CDN) devreye girer.

İki tipik yön:

• Cloudflare Lehçe：Cloudflare DokümantasyonuPolonyalı sıkıştırma yöntemleri (kayıpsız/kayıplı/WebP) tanıtılmakta ve aşağıdaki yöntemlerle sıkıştırma yapıldığından bahsedilmektedir format=auto WebP/AVIF formatına izin verilir.
• Jetpack Site Hızlandırıcı：Jetpack DokümantasyonuGörüntüleri optimize edeceğini ve bunları statik kaynaklarla birlikte ağı üzerinden dağıtacağını açıklayın.

Görüntü optimizasyonu, daha küçük ve daha uygun hale getirmekten sorumludur.CDN Daha yakın ve daha istikrarlı hizmet sunmaktan sorumludur

3. Seçim: sadece iki ana güzergah

Görüntü optimizasyonunda en yaygın başarısızlık “eklenti olmaması” değil, mükerrer işlemeye yol açan çok fazla eklentidir:
A sıkıştırıyor, B sıkıştırıyor, A WebP/AVIF'e dönüştürüyor, B dönüştürüyor, A URL'leri değiştiriyor, B yeniden yazıyor - istasyonda neler olup bittiğini bile anlayamıyorsunuz.

Kurallar:

İzlenecek tek bir yol var: ya tamamen ücretsiz yerel ya da üçünün bulutta sıkıştırılması.

• Rota A (tamamı ücretsiz yerel):Artı WebP veya AVIF + EWWW Görüntü İyileştirici(ya da sadece bir tane)
• Rota B (bulut sıkıştırma üçlü seçeneği):ShortPixel / Imagify / TinyPNG

---

3.1 Rota A: Tam Ücretsiz Yerel (Artı WebP veya AVIF veya EWWW)

Bu rota şu özelliklerle karakterize edilir:

• “Aylık/sayfa başına” üçüncü taraf sıkıştırma hizmetlerine güvenmezsiniz (bazı özellikler isteğe bağlı hizmetler olarak sunulabilir).
• Maliyet: Toplu işleme CPU/IO'da daha fazla sunucu gerektirebilir ve “strateji ve riske” daha fazla dikkat etmenizi gerektirir.”

3.1.1 Artı WebP veya AVIF: Çekirdek “üret/değiştir ”dir, geleneksel “sıkıştırma aracı” değildir.”

• Tam hacimli görüntüler oluştururken:Orijinal görüntü dosyası kimliğinin üzerine WebP/AVIF yazılır, orijinal dosya silinir ve içerikteki URL değiştirilir.。
• Eklenti WP-CLI komutları sağlar ve şunu hatırlatır: Çok sayıda dosya olduğunda WP-CLI daha güvenilirdir.

Bu, “sizin için sessizce bir WebP oluşturmak” yerine, birVarlık taşıma(Özellikle “Orijinal görüntüyü değiştir ve sil” seçeneğini açarsanız).

İki model arasındaki farklar

Mod 1: Orijinal görüntüyü koru + WebP/AVIF kopyası oluştur (daha kararlı)

• Artıları: Uyumluluk sorunları durumunda geri dönmek daha kolay
• Maliyet: Disk kullanımı artacaktır (orijinal görüntü + yeni format + çok boyutlu küçük resimler)

Mod 2: Orijinal görüntüyü değiştirin ve silin (daha agresif)

• Artıları: diskler o kadar hızlı genişlemez; istasyon referansları doğrudan yeni formata gider
• Risk: “Varlıkları değiştiriyorsunuz + referansları değiştiriyorsunuz”, bu da uyumluluk sorunlarını gidermeyi daha pahalı hale getiriyor (özellikle bazı harici sistemler veya tema mantıkları orijinal dosya adına/yola/formata bağlıysa).

Artı WebP veya AVIF'in Tipik Tuzakları

1. Tüm kitaplığı değiştirdikten sonra, bazı sayfa görüntüleri anormal şekilde görüntüleniyor.
   Bunun nedeni genellikle görüntünün “bozuk” olması değil, URL değiştirme, önbelleğe alma, küçük resim politikası vb. zincirindeki bazı bağlantıların doğru olmamasıdır.
2. Küçük resim sayısı arttıkça, değişikliğin kapsamı da artar
   WordPress bir resim yüklemek için birden fazla boyut oluşturur; temalar/pluginler de daha fazla boyut ekleyebilir. Tam değiştirme, çok büyük bir dosya koleksiyonunu değiştirebileceğiniz anlamına gelir.
3. Sadece format geçişi yapmak, birimin her zaman en küçük birim olacağı anlamına gelmez
   WebP/AVIF genellikle daha küçüktür, ancak “boyut stratejisi” ve “sıkıştırma stratejisi” hala kritik öneme sahiptir. Plus WebP'yi “bir tık daha hızlı” olarak düşünmeyin.

---

3.1.2 EWWW Görüntü İyileştirici: serbest yerel sıkıştırmanın temsilcisi

EWWW eklenti sayfası çok iyi konumlandırılmış:

• Sunucunuzda bir dizi araç (jpegtran, optipng, pngout, pngquant, gifsicle, cwebp, vb) kullanılarak optimize edilebilir
• Daha yüksek sıkıştırma veya daha fazla CPU tasarrufuna ihtiyacınız varsa, CPU tüketen işlemleri sunucusuna (isteğe bağlı) da yükleyebilirsiniz.

EWWW Rota A'da nasıl bir rol üstlenmelidir?

Plus WebP'yi bir “format taşıma/değiştirme stratejisi” olarak kullanıyorsanız, EWWW daha uygun olacaktır:

• Sıkıştırma ve Hacim Optimizasyonu(özellikle JPG/PNG gibi ham kaynakların ağırlığının azaltılması)
• Geçmiş medya kütüphanesinin toplu optimizasyonu(“URL değiştirme” yerine “hacim azaltmayı” hedefleme)

Tipik EWWW Çukuru

1. Toplu optimizasyon sırasında yüksek sunucu yükü
   Yerel sıkıştırma CPU/IO tükettiğinden, çözüm “kullanmayın” değil, “toplu iş, düşük tepe, gerekirse boşaltma/bulut seçeneği” şeklindedir.
2. “Bir WebP üretilir” ifadesi, ön ucun bir WebP üretmesi gerektiği anlamına gelmez.
   Birçok eklenti bu yanlış anlamadan muzdariptir: üretim başka bir şeydir, dağıtım stratejileri (yeniden yazmalar, resim etiketleri, önbellek vuruşları, vb.
3. Diğer eklentilerle aynı şeyi tekrar tekrar yapmak
   Eğer A yolunu seçerseniz, ShortPixel/Imagify/TinyPNG türü bulut sıkıştırmasını üst üste bindirmemeye çalışın; eğer B yolunu seçerseniz, Plus WebP değiştirme mantığını açmayın. Temel prensip:Sona giden bir yol.

---

3.2 Rota B: Bulut Sıkıştırma Üçlü Seçimi (ShortPixel / Imagify / TinyPNG)

Bu rota, “sunucu kaynaklarından tasarruf etmek isteyen, daha az çabayla toplu iş yapmak isteyen ve kredi başına / hacim başına faturalandırmayı kabul eden” kişiler için uygundur.
Ancak bulut sıkıştırma ile ilgili en yanıltıcı nokta şudur:Ücretsiz krediler “ücretsiz çarşaflar” kadar basit değildir!.. Küçük resim boyutlarının sayısı, WebP/AVIF oluşturulup oluşturulmadığı ve tekrar tekrar yeniden basınçlandırılıp basınçlandırılmadığı tüketimi önemli ölçüde etkileyebilir.

Aşağıda ücretsiz/ücretli konusunda neler olup bittiği, kredilerin nasıl düşüldüğü, hangi tuzaklara düşme olasılığının yüksek olduğu ve hangi site türlerinin uygun olduğu açıklanacaktır.

---

3.2.1 ShortPixelAyda 100 ücretsiz kredi, ancak krediler küçük resimler ve WebP/AVIF büyütmeler tarafından tüketilir.

Ücretsiz/ücretli konusunda neler oluyor?

ShortPixel eklentisinin açıklamasında açıkça belirtilmiştir:

• Aylık 100 ücretsiz kredi
• Ayrıca “Ekstra Sınırsız Aylık Krediler” de vardır (eklenti sayfası ilgili fiyatlar hakkında bilgi verir)
• “Süresi asla dolmayan tek seferlik kredi paketleri” olarak da mevcuttur (başlangıç fiyat bilgisi ile birlikte)

İpucu:

• Ücretsiz: hafif siteler veya testler için ayda belirli miktarda kredi verin
• Tek kullanımlık paketler: Stoklarını bir kerede temizlemek isteyen büyük medya kütüphanelerine sahip siteler için uygundur (bir kez satın alın ve kullanın, genellikle süresi dolmaz).
• Aylık/Sınırsız: sürekli güncellenen görüntülere ve uzun vadeli istikrarlı optimizasyona sahip siteler için uygundur

ShortPixel'in resmi KB'si de “Tek Seferlik Paket vs Sınırsız Aylık” konusunda bir güncelleme yaptı.açık açıklama: Sınırsız Aylık, sabit bir CDN tahsisatla sınırsız kredi sunan aylık (veya yıllık) bir ödemedir; süresi dolmayan tek seferlik krediler, bunları gerektiği gibi kullanmanız için size daha fazla kontrol sağlar.

Sonuç olarak: ShortPixel kredileri nasıl hesaplanır?

ShortPixel Resmi Belgeleri KB çok açık sözlüydü:

• WordPress, bir resim yüklediğinizde birden fazla küçük resim oluşturur;
• Her küçük resim optimizasyonu bir kredi olarak sayılır；
• Bir WebP veya AVIF oluşturmayı seçersenizOrijinal görüntünün ve küçük resmin her WebP/AVIF sürümü ek bir kredi tüketir.；
• Kredi tüketimini azaltmak için belirli küçük resimlerin optimize edilmesini engelleyebilirsiniz.

Krediler Örnek：

Diyelim ki 1 resim yüklediniz ve tema/eklenti 8 küçük resim oluşturdu:

• Yalnızca orijinal görüntüyü + küçük resimleri optimize edin: 1 (orijinal) + 8 (küçük resimler) = 9 kredi
• Ayrıca WebP/AVIF oluşturmak istiyorsanız: yukarıdaki 9'un her biri için bir yeni nesil sürüm daha → +9 kredi.
  Başka bir deyişle, “1 resim” olduğunu düşündüğünüz şey aslında “2 haneli krediye” yakın bir miktar tüketebilir.

Evet:“Ücretsiz 100 kredi”, “ücretsiz 100 resim” ile aynı şey değildir.

ShortPixel'in en yaygın tuzakları

1. Ücretsiz 100 kredi hızla tükeniyor
   Temel neden: çok sayıda küçük resim + WebP/AVIF oluşturmak için ekstra krediler.
   öneri：

• Önce site küçük resimlerinin sayısını değerlendirin
• Gereksiz küçük resim boyutlarını hariç tutun (yalnızca gerçekten kullanılacak boyutları optimize edin)
• Tekrarlanan deneme yanılma tüketiminden kaçınmak için sıkıştırma stratejisini toplu olarak çalıştırmadan önce belirleyin

2. Diğer dönüştürücü eklentilerini aynı anda istifleme
   Artı WebP değiştirmeleriniz varsa ve ShortPixel yeni nesil etiketler oluşturuyor/ekliyorsa, mantık yığılır ve sorun gidermesi zorlaşır. B rotası için, ShortPixel'in bunu tek başına yapmasına izin verin.
3. Yüklersem “WebP/AVIF ön planda” olur diye düşünmüştüm.”
   ShortPixel eklenti sayfasıWebP/AVIF'i dönüştürdüğünden ve yeni nesil görüntüleri ön sayfaya ekleyebildiğinden (örneğin etiketleyerek) bahsetti.
   Ancak bunu yaptıktan sonra sonuçları doğrulamak yine de önemlidir.

---

3.2.2 ImagifyÜcretsiz: 20MB/ay; kota “orijinal görüntü boyutu + küçük resim sayısına” göre düşülür, yeniden presleme için tekrarlanan kesintiler yapılacaktır.

Serbest miktar ve konumlandırma

Imagify Resmi Fiyat SayfasıYazı açık:Ücretsiz Hesap Aylık 20MB Kota。
Eklenti sayfası ayrıca WebP/AVIF'i sıkıştırabildiğini, yeniden boyutlandırabildiğini ve dönüştürebildiğini açıkça belirtiyor.

Kota nasıl düşülür?

Imagify Resmi Belgeleri “Kota Kullanımı Nasıl Hesaplanır?”, kesinti mekanizmasını çok net bir şekilde ortaya koymaktadır:

• Küçük resim sayısı tüketimi etkilerÖrneğin, 10 küçük resim boyutunuz varsa, 1 resmi optimize etmek 11 resmi optimize etmeye dönüşür (orijinal + 10 küçük resim) ve bunların tümü kota tüketimine katkıda bulunur.
• Orijinal belgenin boyutuna göre kota kesintisi: Örneğin, Imagify'a 100KB'lık bir resim gönderirseniz, 100KB kotadan düşülecektir.
• Sıkıştırma seviyesini değiştirmek ve yeniden optimize etmek kotayı tekrar tüketecektir。
• Aynı API Anahtarı birden fazla site için kullanılabilir, ancak kotalar bunlar arasında paylaşılır.

Bu, Imagify'ın “temel anlayış biçimi ”dir:
Daha çok bir trafik paketi gibidir: gönderdiğiniz kadar kesinti yapar; ne kadar çok küçük resminiz varsa, o kadar çok kesinti yapar; ve tekrar tekrar basarsanız kesintiyi tekrarlarsınız.

Okunması kolay Imagify kota örneği

Diyelim ki 800KB'lık orijinal bir resim yüklediniz ve site 8 küçük resim oluşturdu.

• Imagify, “orijinal görüntü + 8 küçük resim” (hepsini optimize etmeyi seçerseniz) içerecek şekilde optimize eder, bu da bu tek işlemin “tüm bu dosyaların orijinal boyutunun toplamına” yakın bir kota tükettiği anlamına gelir.
  Bu yüzden bazı siteler “20MB'nin hızlı tükendiğini” düşünüyor: Imagify yeterli olmadığından değil, bir seferde çok fazla resim yüklediğinizden, çok fazla küçük resim yüklediğinizden ve muhtemelen sıkıştırma seviyelerini tekrar tekrar denediğinizden.

Imagify'ın en yaygın tuzakları

1. Ücretsiz 20MB “Tam saha geçmişi envanteri” yapmak için yeterli değil”
   20MB genellikle hafif güncellemelerle test etmek için daha uygundur; medya kitaplığınız zaten büyükse, bir kerelik bir temizleme muhtemelen bir yükseltme gerektirecektir.
2. Sıkıştırma seviyelerinin tekrar tekrar ayarlanması kota tüketiminin tekrarlanmasına neden olur
   Imagify şunu açıkça belirtiyorYeniden optimizasyon kotayı tekrar tüketecektir.
   Bu sayfada “stratejiyi” netleştirmenizi öneririm:

• Sıkıştırma seviyesini ve görünüm ve hissi belirlemek için az sayıda resimle başlayın
• Stratejiyi belirleyin ve ardından toplu olarak çalıştırın
  Tüm kütüphane üzerinde tekrarlanan deneme ve hatalardan kaçının

3. Birden fazla sitenin API Anahtarı paylaşması “açıklanamayan kota düşüşüne” yol açıyor.”
   Aynı API Anahtarını birden fazla istasyon için kullanırsanız kota paylaşılır.
   Bu nedenle, ekip/çok istasyonlu senaryolarda, kontrol edilemeyen bütçelerden kaçınmak için hangi istasyonların paylaşıldığı ve hangilerinin bireysel olarak kullanıldığı konusunda net olmak en iyisidir.

---

3.2.3 TinyPNG(Tiny Compress Images): ücretsiz 500 kredi/ay; WebP/AVIF'e geçişte “boyut başına 1 kredi düşülecektir”.”

Ücretsiz krediler ve faturalandırma fikirleri

TinyPNG'nin WordPress eklenti sayfası çok açık:

• Aylık 500 kredi ücretsiz
• “Genel WordPress Kurulumu” bölümünde, muhtemelen Yaklaşık 100 görüntü/ay
• Ancak AVIF veya WebP dönüştürme etkinleştirilmişse:Her görüntü boyutu ek bir kredi tüketirYani muhtemelen sadece sıkıştırılabilir ve dönüştürülebilir Yaklaşık 50 görüntü/ay(kaç tane küçük resim boyutuna sahip olduğunuza bağlı olarak).

Bu arada Tinify (TinyPNG/TinyJPG'nin geliştiricileri) da kendi API Fiyatlandırma SayfasıAçıklama: Kaydolun ve ayda 500 ücretsiz kompresyon alın; bundan sonra, başarılı kompresyon sayısına göre faturalandırılacaksınız, zorunlu abonelik yok.

TinyPNG'nin anlaşılma şeklini bir cümle ile özetleyin:
Kredileri sayar; ne kadar çok küçük resim boyutunuz varsa ve ne kadar çok WebP/AVIF açtıysanız, krediler o kadar hızlı tüketilir.

TinyPNG kredileri için okunması kolay örnekler

Sitenizin her resim için 8 küçük resim boyutu oluşturduğunu varsayalım:

• Yalnızca sıkıştırma: orijinal + 8 küçük resim → 9 kredi gereklidir
• WebP/AVIF dönüşümü açıksa: boyut başına bir ekstra kredi → muhtemelen neredeyse iki katı!
  Bu, eklenti sayfasındaki açıklamaya karşılık gelir: açıldıktan sonra ücretsiz miktar yaklaşık “100 kart/ay ”dan “50 kart/ay ”a değişir.

TinyPNG'nin en yaygın tuzakları

1. Düşünce 500 kredi = 500 resim
   Öyle değil. “Resim boyutu/değişkeni” tarafından tüketilir. Eklenti sayfasında açıkça “Dönüşümler her resim boyutu için ek 1 kredi düşer” uyarısı yer almaktadır.
2. Temalar/e-ticaret eklentileri çok fazla boyut üretiyor ve ücretsiz krediler önemli ölçüde düşüyor
   Ne kadar çok boyut varsa, kredilerin ölçeklendirilmesi ve tüketilmesi o kadar kolay olur.
3. Dönüşümü etkinleştirdikten sonra, kredilerin aniden kullanılmadığını görüyorsunuz.
   Bu bir hata değil, faturalandırma mekanizması.
   Strateji Tavsiyesi:

• Serbest aşama esas olarak sıkıştırma ve ağırlık azaltma için kullanılıyorsa, yalnızca sıkıştırma ile başlayabilir ve site yapınızın kararlı olduğundan ve gerçekten yeni nesle ihtiyacınız olduğundan emin olduğunuzda dönüştürmeyi açabilirsiniz.

4. Alt senaryo önerisi: farklı saha türlerinin nasıl seçileceği

Ayrıca WordPress, içerik siteleri, e-ticaret siteleri, portföyler ve üyelik siteleri görseller için aynı “baskı noktalarına” sahip değildir.

4.1 İçerik siteleri/bloglar (çok sayıda makale grafiği, orta sıklıkta güncelleme)

Öncelikli Tavsiyeler:

1. Boyutlandırma Stratejisi (Adım 1)
2. Sıkıştırma (Adım 2)
3. WebP (Adım 3)

Daha uygun bir rota:

• Kaydetmek istediğiniz: Route B Üçlü Seçim (ShortPixel / Imagify / TinyPNG)
• Serbest kalmak istiyorsanız: Rota A (Artı WebP + EWWW), ancak riski değerlendirmek için “muhafazakar mod (orijinal görüntüyü silmeden)” ile başlamanız önerilir.

Tipik çukur:

• Makale sayfasının ilk görüntüsü çok büyük, uygunsuz tembel yükleme stratejisiİlk ekranı yavaşlatır

4.2 E-ticaret/ürün sitesi (birçok küçük resim, birçok resim çeşidi, önce kararlılık)

E-ticarette sorun büyük olasılıkla “sıkıştırma etkisinin iyi olmaması” değil, “optimize edilmiş bazı boyutların doğru olmaması, küçük resimlerin eksik olması, ön bileşenlerin resmi alamamasıdır”.

Öncelikli Tavsiyeler:

1. Önce istikrar: muhafazakar sıkıştırma stratejisi, hemen tam bir kütüphane değişimi yapmayın
2. Küçük resim boyutlarını değerlendirme: e-ticaret temaları genellikle daha fazla boyut üretir ve tüketim miktarı artar (ShortPixel/TinyPNG özellikle dikkat çekicidir)
3. Parti öncesi küçük ölçekli doğrulama yapın (çok kritik)

Daha uygun bir rota:

• B Rotası daha sorunsuz olma eğilimindedir: ShortPixel/Imagify/TinyPNG'nin tümü toplu iş yapabilir ve kota mekanizmasını anlamanız ve maliyeti önceden değerlendirmeniz çok önemlidir
• Rota A iyidir, ancak Plus WebP'nin “kimliklerin üzerine yaz/orijinal görüntüleri sil/URL'leri değiştir” davranışına karşı daha dikkatli olun: bu bir varlık taşıma işlemidir ve hemen her şeyi değiştirmeniz önerilmez.

4.3 Portföy/fotoğraf istasyonu (tek görüntü kalitesine duyarlı, büyük görüntüler, yüksek görüntüleme talepleri)

Öncelikli Tavsiyeler:

1. Boyut stratejisi (ekran alanı kontrolü)
2. Sıkıştırma stratejisi (ayrıntıları ezmektense daha büyük olmak daha iyidir)
3. WebP/AVIF (büyük resim sahne kazançları açıktır, ancak görünümü doğrulayın)

Daha uygun bir rota:

• Imagify: Kotayı “orijinal resmin boyutuna” göre düşürün, bu tür bir siteyi “bütçe kontrollü” yapmak daha kolaydır (her büyük resim için ne kadar düşeceğinizi bilirsiniz), ancak tekrarlanan baskılardan kaçının.
• ShortPixel: Küçük resim boyutu çok fazla değilse, krediler de çok sezgiseldir; ancak çok sayıda boyut + yeni nesil üretirseniz, kredi tüketimi artacaktır ve önceden planlamanız gerekir.

5. Kota/fatura karşılaştırması: “ücretsiz yeterli değildir” perspektifini ortaya koymak

Hangisi daha iyi bir anlaşma ve ücretsiz ne kadar sürecek?

5.1 Üç Ters İbraz Modeli

• ShortPixel(krediler): Krediler “orijinal resim + küçük resim sayısına” dayanmaktadır; oluşturulan her bir WebP/AVIF sürümü için ek krediler düşülecektir.
• Imagify(MB kota): Kotayı “orijinal dosya boyutuna” göre düşer; ne kadar çok küçük resim, o kadar çok kesinti; yeniden bastırmak tekrar düşecektir.
• TinyPNG(krediler): Aylık 500 kredi; WebP/AVIF dönüşümünü etkinleştirmek her görüntü boyutu için ek kredi düşer.

5.2 Hızlı tahmin yöntemleri

Bunu şu şekilde tahmin edebilirsiniz:

1. Rastgele bir “sık yüklediğiniz orijinal resim” bulun ve ne kadar büyük olduğuna bakın (örneğin 300KB / 1MB / 3MB).
2. Sitenizin kaç küçük resim boyutu oluşturduğuna bağlı olarak (örn. 5 / 10 / 20)
3. WebP/AVIF oluşturmak isteyip istemediğinize karar verin (evet/hayır)

Ardından tüketimi anlamak için aşağıdaki “zihinsel matematiği” kullanın:

• ShortPixel: ≈ (1 + küçük resim sayısı) görüntü başına kredi; WebP/AVIF üretiliyorsa, ≈ tekrar iki katına çıkar (yeni nesil sürüm de kredi aldığından)
• Imagify: Her görüntü ≈ (orijinal boyut + her küçük resim boyutu) kotadan düşer; sıkıştırma seviyesini değiştirin ve yeniden sıkıştırın tekrar düşecektir.
• TinyPNG: 500 kredi ücretsiz; siteniz resim başına çok fazla boyut üretiyorsa ve dönüşüm etkinse, ücretsiz kredi sayısı önemli ölçüde düşer (eklenti sayfası “~100 kredi/ay” ile “~50 kredi/ay” arasında görsel bir beklenti verir)

6. Risk uyarıları

Risk 1: Birden fazla eklentinin aynı şeyi tekrar tekrar yapmasına izin vermeyin

Bu en yaygın “felaket kaynağı ”dır.”

• Rota A:Artı WebP veya AVIF + EWWW(İşgücünü ikisi arasında bölüştürün, benzer dönüşümleri ve teslimatları aynı anda yapmayın veya yalnızca birini kurun)
• Rota B: ShortPixel / Imagify / TinyPNG üç tane seçin(yeni nesil ile sıkıştırmak için birini seçin)

Risk 2: Ayrıca WebP'nin “Kimliğin Üzerine Yaz / Orijinal Görüntüyü Sil / URL'yi Değiştir” özelliği bir varlık taşıma işlemidir.

Vurgular eklenmiştir:Artı WebP Açıklama, tam üretimin orijinal görüntü kimliğinin üzerine yazdığını, orijinal dosyayı sildiğini ve içerik URL'sini değiştirdiğini açıkça belirtmektedir.
Bu, “herhangi bir zamanda geri çekilebilecek küçük bir ayar” değil, varlık düzeyinde bir değişiklik olduğu anlamına gelir.

Önerilen strateji şu olmalıdır:

• Önce küçük bir test (birkaç düzine ila birkaç yüz)
• Ön uç ekranının, küçük resimlerin ve önbellek güncellemelerinin düzgün çalıştığını onaylayın
• Tam kütüphane işlemlerini yeniden gözden geçirin

Risk 3: Bulut sıkıştırma “ücretsiz kredilerinin” gerçek tüketimi, küçük resim sayısına ve yeni nesil seçime bağlıdır.

• ShortPixel: Küçük resimler ve yeni nesil, kredileri önemli ölçüde etkiler.
• TinyPNG: WebP/AVIF etkinleştirildiğinde her görüntü boyutu için ek bir kredi düşülür.
• Imagify: Orijinal resmin boyutuna göre düşülür, ne kadar çok küçük resim düşülürse, ağır baskı kesintiyi tekrarlayacaktır!

Risk 4: “WebP/AVIF oluşturuldu” ifadesi “WebP/AVIF ön ofis tarafından teslim ediliyor” anlamına gelmez”

Birçok kişi dönüşümden sonra “daha hızlı değil” hissine kapılıyor çünkü ön uç hala JPG/PNG çıktısı veriyor (önbelleğe alma/yeniden yazma/etiketleme/tarayıcı görüşmesi doğru yerde değil).

7. Yapıldıktan sonra yürürlüğe girdiğinin nasıl doğrulanacağı

4 çok basit doğrulama noktası:

1. Aynı sayfanın ikinci kez yenilenip yenilenmediği ve daha tutarlı ve daha hızlı yüklenip yüklenmediği(Önbelleğe alma ve çalışıp çalışmadığına dair fiziksel anlamda optimizasyon)
2. Cep telefonlarına ve masaüstü bilgisayarlara yüklenen görüntülerin boyutları önemli ölçüde farklı mı(duyarlı) srcset/sizes (çalışsınlar ya da çalışmasınlar)
3. Birkaç görüntüyü nokta atışı kontrol edin: WebP veya AVIF dosyalarının/kaynaklarının mevcut olup olmadığı(Site gerçekten yeni̇-gen）
4. Birkaç görüntüyü örnekleyin: gözle görülür şekilde çamurlu olup olmadıklarını, metnin bulanık olup olmadığını görmek için yakınlaştırın(sıkıştırılmış kütle aşırı değildir)

Bunların dördü de eşleşirse, seçtiğiniz rota çalıştırılmış demektir. Sıradaki. CDN “Teslimat Katmanı”genel olarak daha istikrarlı olacaktır.

8. Eylem için tavsiyeler

1. Önce rotanızı seçin:

• Mümkün olduğunca özgür olmaya çalışıyorum.: Artı WebP veya AVIF + EWWW (veya bunlardan sadece biri)
• Sunucu kaynaklarından tasarruf etmek istiyorsanız, daha fazla gönül rahatlığı için kredi başına ödeme yapın: ShortPixel / Imagify / TinyPNG - birini seçin!

2. Önce küçük bir test yapın (birkaç düzine)
3. Göndermeden önce sorun olmadığından emin olun
4. Teslimat istikrarında daha fazla iyileştirme yapılması gerekmektedir:okuyun CDN Hızlanma

ortak sorunlar

1. Kaç tane eklenti yüklemem gerekiyor? Hepsini yükleyebilir miyim?

Sadece tek bir rotadan gitmeye çalışın.

• Rota A: Artı WebP veya AVIF + EWWW Görüntü İyileştirici (veya bunlardan sadece biri)
• Rota B: ShortPixel / Imagify / TinyPNG - birini seçin!
  Aynı istasyonda aynı anda birden fazla eklentinin “sıkıştırma / WebP / AVIF aktarımı / URL değiştirme / teslim yeniden yazma” yapmasına izin verin, gittikçe daha kaotik hale gelme olasılığı en yüksek, ancak aynı zamanda kontrol edilmesi en zor olanıdır.

2. WordPress zaten WebP/AVIF'i desteklemiyor mu? Hala bir eklentiye ihtiyacım var mı?

Ayrılması gerekiyor:
“Yükleme/kullanım desteği” ≠ “Otomatik dönüştürme/otomatik teslimat”.
WordPress 6.5 ayrıca eski JPG/PNG'leri otomatik olarak WebP/AVIF'e toplu olarak dönüştürmez ya da sizin için “AVIF/WebP'yi tarayıcı özellikli ve geri dönüşlü olarak dışa aktarma” işlemini otomatik olarak yapmaz. Geçmiş medya kitaplığının çalışması için genellikle bir eklenti veya hizmet gerekir.

3. Görüntü optimizasyonunda en “ödüllendirici” adım nedir?

Genellikle Önce “boyutları” doğru ayarlayın (srcset/sizes).。
Birçok site sıkıştırma olmadığı için değil, sayfa yalnızca 900 piksel olduğu ve kullanıcıdan 3000 piksellik bir resim indirmesi istendiği için yavaştır. Sıkıştırma KB'lerden tasarruf sağlar, ancak “yanlış boyut” boş yere birkaç kat daha fazla veri indirmenize neden olur.

4. Orijinal görüntüyü değil de “küçük olanı” sonsuza kadar yüklediğimden nasıl emin olabilirim?

İki olguya bakın:

• Bir sayfayı cep telefonunda açarken, indirilen görüntünün boyutu masaüstündekinden belirgin şekilde daha küçüktür
• Aynı görüntü farklı cihazlarda farklı kaynak boyutlarında yüklenir
  Orijinal görüntü sonsuza kadar indiriliyorsa, bunun yaygın bir nedeni temanın/kurucunun görüntüyü CSS arka plan görüntüsü veya özel çıktı olarak ele alması ve medya kütüphanesinin srcset ile çoklu boyutlandırmasını atlamasıdır.

5. “WebP/AVIF oluşturuldu” ifadesi ön ucun WebP/AVIF üretmesi gerektiği anlamına mı geliyor?

Eşit değil.
Oluşturma işlemi sadece “dosya katmanı” için yapılır; ön yüzün gerçekten WebP/AVIF sunup sunmayacağı yeniden yazmalara, resim etiketleme politikalarına, önbellek vuruşlarına, yürürlükteki tarayıcı anlaşmasına vb. bağlıdır. İşiniz bittiğinde, “kaynak türleri için birkaç görüntüyü yerinde kontrol ettiğinizden” emin olun.

6. Artı WebP veya AVIF'in nesi bu kadar tehlikeli? Tüm kütüphaneyi tek bir tıklamayla çalıştırabilir miyim?

Risk noktası “sıkıştırma” değilVarlık göçü seviyelerindeki değişiklikler：

• Tam üretim, orijinal görüntü dosyası kimliğinin üzerine yazabilir, orijinal dosyayı silebilir ve içerikteki URL'yi değiştirebilir.
  NEDENİTüm kütüphanenin hemen değiştirilmesi önerilmez: Önce küçük ölçekte test edin (onlarca ~ yüzlerce) + mevcut yedeklere sahip olun, ardından tam kütüphane işlemeyi düşünün.

7. Plus WebP'nin iki modu arasındaki seçim nedir: orijinal görüntüyü sakla ve orijinal görüntüyü değiştir ve sil?

Anlaşılması kolay:

• Mod 1: Orijinal görüntüyü koru + WebP/AVIF kopyası oluştur (daha kararlı): Geri alma için uygun, ancak disk artar (orijinal görüntü + yeni format + çok boyutlu küçük resimler).
• Mod 2: Orijinal görüntüyü değiştirin ve silin (daha agresif)Diskler şişkinliğe daha az eğilimlidir, ancak “varlıkları değiştiriyorsunuz + referansları değiştiriyorsunuz”, bu da uyumluluk sorunlarını gidermeyi daha pahalı hale getiriyor.
  Site ne kadar karmaşıksa (e-ticaret/çoklu eklenti/çoklu boyut), daha istikrarlı bir modelle başlamak o kadar tavsiye edilir.

8. EWWW Image Optimizer ücretsiz yerel sıkıştırma yeterli mi? Sunucuyu bunaltacak mı?

EWWW daha çok bir “yerel kompresör ”dür: CPU/IO tüketir.
Toplu optimizasyon sırasında yükün artması yaygındır, bu “işe yaramadığı” anlamına gelmez, daha ziyade stratejinin doğru olması gerektiği anlamına gelir: toplu iş, düşük tepe noktaları ve gerekirse boşaltma/bulut seçenekleri.
Tasarruf arıyorsanız veya sunucu kaynaklarınız kısıtlıysa, Rota B daha sunucu dostudur.

9. ShortPixel'in 100 ücretsiz kredisi/ay, neden birkaç fotoğrafta bitmiş gibi hissediyorum?

yüzünden krediler “resim sayısı” değildir.”Yeni nesil, yeni nesil ile birlikte bir küçük resimle büyütülecektir:

• Orijinal resim + her küçük resim kredi olarak sayılır
• Bir WebP/AVIF oluşturulursa, ilgili her sürüm için ek bir kredi tüketilir.
  Yani “1 resim” olarak düşündüğünüz şey aslında “2 haneli krediye” yakın tüketebilir. shortPixel

10. Imagify'ın ücretsiz 20MB/ay'ı da neden çabuk bitiyor?

Imagify daha çok bir “trafik paketi” gibidir:

• Gönderdiğin gibi.Orijinal dosya boyutukotaların düşülmesi
• Ne kadar çok küçük resminiz varsa, o kadar çok tüketirsiniz
• Yeniden optimize etmek için sıkıştırma seviyesini değiştirmek kotayı tekrar tüketecektir
• Birden fazla site için aynı API Anahtarı, kota paylaşımı
  Yani “20MB yakında tükenecek” genellikle çok büyük resimlerden, çok fazla küçük resimden veya tekrarlanan deneme ve hatalardan kaynaklanır.

11. TinyPNG 500 kredi/ay için ücretsiz, eklenti neden sadece 100 kredi/ay ve sonra WebP/AVIF ile 50 kredi/ay olduğunu söylüyor?

Çünkü TinyPNG kredileri de “size/variant” ile büyütülür:

• Normal bir WordPress kurulumu muhtemelen ayda yaklaşık 100 sayfa sıkıştırır.
• AVIF veya WebP dönüştürmeyi etkinleştirin:Her görüntü boyutu ek bir kredi tüketirYani muhtemelen ayda yalnızca 50 görüntüyü sıkıştırabilir ve dönüştürebilirsiniz (küçük resim boyutlarının sayısına bağlı olarak).
  Yani 500 kredi ≠ 500 resim.

12. Sitemde kaç tane küçük resim var? Neden bu kadar önemli?

WordPress bir resim yüklemek için birden fazla boyut oluşturur; temalar/eklentiler (özellikle e-ticaret) daha fazla boyut ekleyebilir.
Bulut sıkıştırma kredileri/kotaları genellikle “orijinal + küçük resimler birlikte” şeklindedir, bu nedenle ne kadar çok küçük resminiz varsa o kadar az ücretsiz kredi kullanmanız gerekir.

13. Tembel yükleme her zaman daha mı hızlıdır? Neden bazı insanlar tembel yüklemenin işleri yavaşlattığını söylüyor?

Tembel yükleme “ekran dışı kaynaklar” için uygundur.
Eğer ilk ekrandaki en kritik büyük görselin yüklenmesi de gecikirse, ilk ekran deneyimini yavaşlatabilir. WordPress 5.5“ten beri varsayılan tembel yükleme iyidir, ancak ”tek beden herkese uyar" yapmayın.

14. A veya B güzergahında seyahat ediyorum. CDN / Resim CDN'ye ne zaman ihtiyacım var?

Sıkıştırma, boyutlandırma ve biçimlendirme “sığan daha küçük dosyalar” sorununu çözer;
CDN Çözüm, daha yakın ve daha istikrarlı。
Görüntüler kaynak siteden uzak bir mesafeden çekildiğinde önemli bir gecikmeye neden oluyorsa, CDN/görüntüleri CDN (örneğin Cloudflare Polish / Jetpack Site Accelerator) ile desteklemek genel olarak daha kararlı olacaktır, okuyun WordPress CDN Hızlandırma。

15. İşim bittiğinde “gerçekten çalıştığını” doğrulamamın en kolay yolu nedir?

Zaman açısından en verimli doğrulama yöntemi:

• Aynı sayfanın ikinci kez yenilenip yenilenmediği ve daha tutarlı ve daha hızlı yüklenip yüklenmediği
• Cep telefonlarına ve masaüstü bilgisayarlara yüklenen görüntülerin boyutları belirgin şekilde farklı mı (srcset/sizes devreye giriyor mu)
• Birkaç görüntüyü nokta atışı kontrol edin: WebP veya AVIF dosyalarının/kaynaklarının mevcut olup olmadığı
• Birkaç görüntüyü örnekleyin: gözle görülür şekilde çamurlu olup olmadıklarını, metnin bulanık olup olmadığını görmek için yakınlaştırın