Pengoptimalan Gambar Situs Web

Pengoptimalan gambar adalah salah satu aspek yang paling “bermanfaat” dalam performa WordPress: untuk struktur halaman dan tema yang sama, selama ukuran, dimensi, pemformatan, dan pengiriman gambar sudah tepat, pengalaman pemuatan akan meningkat dengan segera.

Tetapi, pengoptimalan gambar juga merupakan cara termudah untuk membuat kekacauan, bukan karena secara teknis terlalu sulit, tetapi karena informasinya terlalu terfragmentasi:
Anda membaca beberapa artikel, mengetahui tentang “kompresi”, “WebP/AVIF”, “pemuatan malas”, dan kemudian melihat pengenalan plugin dan mengatakan “gratis setiap bulan! 100 kredit per bulan”, “Gratis 20MB”, “1 kredit per gambar”, tetapi semakin banyak saya membaca, semakin bingung saya - Apakah cukup gratis? Bagaimana cara memotong biayanya? Apakah Anda salah memahami “hal yang sama”? Dan yang paling penting:Apakah hal itu benar-benar berpengaruh setelah Anda melakukannya atau tidak?

Artikel ini hanya membahas tiga hal:

1. Memberi Anda sebuah file yang dapat dieksekusipeta jalan (lihat juga gbr.)(Apa yang harus dilakukan pertama kali, apa yang harus dilakukan kedua kali)
2. Perjelas pilihan yang Anda inginkan (apa perbedaan antara gratis/berbayar dan untuk siapa pilihan tersebut cocok)
3. Tuliskan jebakan yang paling umum sebelumnya (sehingga Anda tidak perlu mencari-cari untuk memecahkan masalah setelah selesai)

1. Intinya: Apa yang Dilengkapi WordPress dan Apa yang Tidak

Jika Anda tidak terlebih dahulu mengetahui apa yang sudah dilakukan oleh WordPress core, Anda dapat melakukan salah satu dari dua hal berikut ini:

• Alih-alih menggunakan “kapasitas gratis” yang seharusnya Anda nikmati, Anda justru menghabiskan waktu/membayar uang untuk membangun roda berulang kali.
• Saya pikir WordPress akan “secara otomatis mengonversi semua gambar lama ke WebP/AVIF”, tetapi ternyata tidak!

WordPress core memiliki kemampuan utama yang sudah terpasang di dalamnya:

• Gambar responsif (srcset/ukuran)Pada WordPress 4.4, inti akan menampilkan gambar untuk srcset 与 sizesdan memanfaatkan gambar multi-ukuran yang dihasilkan selama pengunggahan untuk memungkinkan browser memilih sumber daya yang lebih sesuai untuk dimuat berdasarkan kondisi layar.
• Pemuatan malas asliWordPress 5.5 dan seterusnya memungkinkan pemuatan gambar secara default, menggunakan standar HTML. loading implementasi atribut.
• Dukungan untuk mengunggah WebPSejak WordPress 5.8, Anda dapat mengunggah dan menggunakan WebP sebagai JPEG/PNG (asalkan lingkungan hosting Anda mendukung WebP).
• Dukungan untuk mengunggah AVIFSejak WordPress 6.5, Anda dapat mengunggah dan menggunakan AVIF sebagai JPEG/PNG (juga tergantung pada dukungan hosting).

Tapi perhatikan:
“Dukungan untuk pengunggahan/penggunaan” ≠ “Konversi otomatis/pengiriman otomatis”.
Dengan kata lain: meskipun Anda sudah menggunakan WP 6.5, JPG/PNG dalam pustaka media Anda tidak akan berubah menjadi WebP/AVIF dengan sendirinya; Anda tidak akan secara otomatis mendapatkan tautan “output AVIF/WebP sesuai dengan kemampuan browser dan kembali ke gambar asli untuk browser yang tidak didukung” secara penuh! --Bagian ini biasanya perlu ditambal oleh sebuah plugin atau layanan.

2. Peta jalan: Pengoptimalan gambar dalam 5 langkah

Apa yang harus dilakukan, mengapa, apa yang harus dilakukan untuk memenuhi syarat, dan apa itu lubang yang khas.

2.1 Mendapatkan “ukuran” yang tepat terlebih dahulu (yang paling sering diabaikan, tetapi paling bermanfaat)

Banyak stasiun yang lambat bukan karena kompresi tidak dilakukan, tetapiMengunduh gambar besar yang melampaui area tampilan：
Sebagai contoh, jika halaman sebenarnya hanya selebar 900px, dan Anda meminta pengunjung untuk mengunduh gambar asli berukuran 3000px, browser hanya “mengunduhnya dan kemudian mengecilkannya”. Hal ini memboroskan bandwidth, meningkatkan waktu penguraian dan memperlambat layar pertama.

WordPress 4.4+Mekanisme Gambar Responsif（srcset/sizes) didesain untuk mengatasi masalah ini.

Lakukan apa yang dianggap sebagai operan:

• Apabila membuka halaman di ponsel, ukuran gambar yang diunduh harus jauh lebih kecil daripada di desktop
• Gambar yang sama dimuat dengan ukuran sumber daya yang berbeda pada perangkat yang berbeda (alih-alih selalu mengunduh gambar asli)

Jebakan yang paling umum:

• Ada tema/bangun yang memperlakukan diagram sebagai gambar latar belakang CSS, atau menampilkannya dengan cara khusus yang dapat mem-bypass srcsetHasilnya adalah gambaran besar dari
• Anda menggunakan alas gambar yang ditautkan secara eksternal, blok gambar pihak ketiga, dan juga dapat memintas sistem multi-ukuran yang dihasilkan oleh pustaka media

---

2.2 Kompresi (menurunkan KB, tetapi tidak “menghancurkan” kualitasnya)

Inti kompresi bukanlah “semakin kecil semakin baik”, tetapi “perbedaannya nyaris tidak terlihat secara kasat mata, tetapi penurunan volumenya terlihat jelas”.

Aturannya adalah sebagai berikut:

• Foto/bidikan langsung (orang, produk, lanskap)Kompresi lossy prioritas (penguatan maksimum)
• Tangkapan layar antarmuka / gambar yang penuh teksKompresi harus lebih konservatif untuk menghindari teks yang kabur
• Logo/IkonSVG Prioritas atau lossless yang tersembunyi (lossy mudah untuk ditempelkan di tepi)

Lakukan apa yang dianggap sebagai operan:

• Pengurangan ukuran gambar yang signifikan pada sebagian besar halaman
• Tidak ada noise yang terlihat, tepi berlumpur, blok warna pecah, teks buram

---

2.3 WebP / AVIF (strategi format: lebih kecil untuk definisi yang sama)

WordPress sudah mendukung pengunggahan WebP (5,8) vs AVIF (6,5)。
Tetapi untuk membuat Format Generasi Berikutnya benar-benar berfungsi, dua hal biasanya harus diselesaikan:

1. Cara mengonversi pustaka media historis secara batch(Kalau tidak, Anda hanya mengoptimalkan untuk “gambar baru yang diunggah nanti”)
2. Apakah akan menghasilkan salinan atau mengganti gambar asli(Ini adalah titik rawan; kita akan fokus pada “Ganti dan Hapus Gambar Asli” dari Plus WebP nanti)

Gaya penulisan yang disarankan:

• WebP: umumnya lebih disukai sebagai default (kompatibilitas yang lebih stabil)
• AVIF: arah kompresi lebih lanjut, cocok untuk gambar besar/gambar besar layar pertama/gambar album (tetapi lebihKetergantungan pada dukungan lingkungan）

---

2.4 Pemuatan malas harus digunakan dengan benar (tidak satu ukuran untuk semua)

WordPress 5.5 dan seterusnyaPemuatan malas defaultGambar.
Ini mengurangi penggunaan bandwidth selama rendering awal:

• Pemuatan malas untuk “sumber daya di luar layar”
• Gambar besar yang paling penting pada layar pertama (dan dalam banyak kasus, gambar utama pada layar pertama) sering kali tidak cocok untuk pemuatan yang tertunda

---

2.5 Lapisan Pengiriman: CDN / Foto CDN

Kompresi, ukuran, dan pemformatan memecahkan masalah “file yang lebih kecil yang sesuai”.
Namun demikian, jika gambar selalu diambil dari jarak jauh dari sumbernya, latensi jaringan masih dapat memengaruhi pengalaman secara signifikan. Di sinilah solusi “lapisan pengiriman” (CDN/gambar CDN) hadir.

Dua arah yang khas:

• Cloudflare Polish：Dokumentasi CloudflareMetode kompresi Polandia (lossless/lossy/WebP) diperkenalkan, dan disebutkan bahwa kompresi dengan format=auto Format WebP/AVIF diperbolehkan.
• Akselerator Situs Jetpack：Dokumentasi JetpackJelaskan bahwa ini akan mengoptimalkan gambar dan mendistribusikannya melalui jaringan bersama dengan sumber daya statis.

Optimalisasi gambar bertanggung jawab untuk membuat gambar menjadi lebih kecil dan lebih sesuai.CDN Bertanggung jawab untuk memberikan hasil yang lebih dekat dan lebih stabil

3. Pilihan: hanya dua rute utama

Kegagalan yang paling umum dalam pengoptimalan gambar bukanlah “tidak ada plugin”, tetapi terlalu banyak plugin yang menyebabkan pemrosesan ganda:
A sedang mengompresi, B sedang mengompresi, A sedang mengonversi ke WebP/AVIF, B sedang mengonversi, A sedang mengubah URL, B sedang menulis ulang - Anda bahkan tidak tahu apa yang sedang terjadi di stasiun.

Aturan:

Hanya ada satu rute yang bisa diambil: kompresi lokal gratis atau kompresi awan dari ketiganya.

• Rute A (semua lokal gratis):Ditambah Pengoptimal Gambar WebP atau AVIF + EWWW(atau hanya satu)
• Rute B (opsi tiga kompresi awan):ShortPixel / Imagify / TinyPNG

---

3.1 Rute A: Lokal Gratis Penuh (Ditambah WebP atau AVIF atau EWWW)

Rute ini ditandai dengan:

• Anda tidak bergantung pada layanan kompresi pihak ketiga “per bulan/per lembar” (meskipun beberapa fitur mungkin ditawarkan sebagai layanan opsional).
• Biaya: pemrosesan batch bisa lebih banyak menggunakan server pada CPU/IO, mengharuskan Anda untuk lebih memperhatikan “strategi dan risiko”.”

3.1.1 Ditambah WebP atau AVIFintinya adalah “menghasilkan/mengganti”, bukan “alat kompresi” tradisional.”

• Apabila menghasilkan gambar dengan volume penuh:ID file gambar asli ditimpa oleh WebP/AVIF, file asli dihapus, dan URL dalam konten diganti.。
• Plugin ini menyediakan perintah WP-CLI dan mengingatkan: WP-CLI lebih dapat diandalkan apabila terdapat banyak file.

Ini berarti bahwa alih-alih “diam-diam menghasilkan WebP untuk Anda”, ini bisa menjadiMigrasi aset(Khususnya, jika Anda mengaktifkan opsi “Ganti dan hapus gambar asli”).

Perbedaan antara kedua model

Mode 1: Menyimpan gambar asli + menghasilkan salinan WebP/AVIF (lebih stabil)

• Kelebihan: Lebih mudah untuk kembali jika terjadi masalah kompatibilitas
• Biaya: Penggunaan disk akan meningkat (gambar asli + format baru + gambar mini multi-ukuran)

Mode 2: Mengganti dan menghapus gambar asli (lebih agresif)

• Kelebihan: disk tidak berkembang dengan cepat; referensi stasiun langsung masuk ke format baru
• Risiko: Anda “mengubah aset + mengubah referensi”, yang membuatnya lebih mahal untuk memecahkan masalah kompatibilitas (terutama jika beberapa sistem eksternal atau logika tema bergantung pada nama file/jalur/format asli).

Jebakan Khas Plus WebP atau AVIF

1. Setelah mengganti seluruh pustaka, beberapa gambar halaman ditampilkan secara tidak normal.
   Alasannya biasanya bukan karena gambarnya “rusak”, tetapi karena beberapa tautan dalam rantai penggantian URL, caching, kebijakan thumbnail, dll. tidak benar.
2. Semakin banyak jumlah gambar mini, semakin besar cakupan perubahannya
   WordPress menghasilkan berbagai ukuran untuk mengunggah gambar; tema/plugin juga dapat menambahkan lebih banyak ukuran. Penggantian penuh berarti Anda mungkin mengubah koleksi file yang sangat besar.
3. Hanya dengan melakukan migrasi format, tidak berarti bahwa volumenya selalu menjadi yang terkecil
   WebP/AVIF pada umumnya lebih kecil, tetapi “strategi ukuran” dan “strategi kompresi” tetaplah penting. Jangan menganggap Plus WebP sebagai “satu klik lebih cepat”.

---

3.1.2 Pengoptimal Gambar EWWWperwakilan dari kompresi lokal gratis

Halaman plugin EWWW diposisikan dengan sangat baik:

• Ini dapat dioptimalkan pada server Anda menggunakan berbagai alat (jpegtran, optipng, pngout, pngquant, gifsicle, cwebp, dll)
• Anda juga dapat melepaskan pemrosesan yang memakan CPU ke servernya (opsional) jika Anda membutuhkan kompresi yang lebih tinggi atau penghematan CPU yang lebih banyak.

Peran apa yang harus diambil oleh EWWW dalam Rute A?

Jika Anda menggunakan Plus WebP sebagai “strategi migrasi/penggantian format”, maka EWWW lebih cocok:

• Kompresi dan Pengoptimalan Volume(terutama pengurangan berat sumber daya mentah seperti JPG/PNG)
• Optimalisasi batch perpustakaan media historis(menargetkan “pengurangan volume” dan bukan “penggantian URL”)

Lubang Khas EWWW

1. Peningkatan beban server selama pengoptimalan batch
   Karena kompresi lokal memakan CPU/IO, solusinya bukanlah “jangan gunakan”, tetapi “batch, low peak, opsi offload/cloud jika perlu”.
2. “Sebuah WebP dihasilkan” tidak berarti bahwa frontend harus menghasilkan WebP.
   Banyak plugin yang mengalami kesalahpahaman ini: pembuatan adalah satu hal, strategi pengiriman (penulisan ulang, tag gambar, hit cache, dll.) adalah hal lain.
3. Melakukan hal yang sama berulang-ulang dengan plugin lain
   Jika Anda memilih rute A, cobalah untuk tidak menghamparkan jenis kompresi awan ShortPixel/Imagify/TinyPNG; jika Anda memilih rute B, jangan nyalakan logika penggantian Plus WebP. Prinsip inti:Satu rute menuju akhir.

---

3.2 Rute B: Pilihan Tiga Kompresi Awan (ShortPixel / Imagify / TinyPNG)

Rute ini cocok untuk orang-orang yang “ingin menghemat sumber daya server, ingin melakukan batch dengan sedikit usaha, dan menerima penagihan per kredit/per volume”.
Tetapi hal yang paling menyesatkan tentang kompresi awan adalah:Kredit gratis tidak sesederhana “lembaran gratis”!.. Jumlah ukuran thumbnail, apakah WebP/AVIF dibuat atau tidak, dan apakah WebP/AVIF berulang kali ditekan ulang atau tidak, dapat memengaruhi konsumsi secara signifikan.

Berikut ini akan dijelaskan: apa yang terjadi dengan gratis/berbayar, bagaimana kredit dikurangi, jebakan apa yang paling mungkin terjadi, dan jenis situs apa yang sesuai.

---

3.2.1 ShortPixel100 kredit gratis/bulan, tetapi kredit dikonsumsi oleh thumbnail dan pembesaran WebP/AVIF.

Apa yang terjadi dengan gratis/berbayar

Deskripsi plugin ShortPixel secara jelas menyatakan:

• 100 kredit gratis per bulan
• Ada juga “Kredit Bulanan Ekstra Tak Terbatas” (halaman plugin memberikan informasi tentang harga yang sesuai)
• Juga tersedia sebagai “paket kredit satu kali yang tidak pernah kedaluwarsa” (dengan informasi harga awal)

Tip:

• Gratis: memberikan sejumlah kredit per bulan untuk situs ringan atau pengujian
• Paket sekali pakai: cocok untuk situs dengan perpustakaan media besar yang ingin menghabiskan stoknya sekaligus (beli sekali dan gunakan, biasanya tidak kedaluwarsa).
• Bulanan/Tak Terbatas: cocok untuk situs dengan gambar yang terus diperbarui dan pengoptimalan yang stabil dalam jangka panjang

KB resmi ShortPixel juga telah memberikan pembaruan tentang “Paket Satu Kali vs Bulanan Tanpa Batas”.penjelasan eksplisitUnlimited Monthly adalah pembayaran bulanan (atau tahunan) yang menawarkan kredit tak terbatas dengan jatah CDN yang tetap; kredit satu kali yang tidak kedaluwarsa, sehingga Anda memiliki kontrol lebih besar untuk menggunakannya sesuai kebutuhan.

Intinya: bagaimana kredit ShortPixel dihitung?

Dokumentasi Resmi ShortPixel KB sangat blak-blakan:

• WordPress menghasilkan beberapa gambar mini saat Anda mengunggah gambar;
• Setiap pengoptimalan gambar mini dihitung sebagai kredit；
• Jika Anda memilih untuk menghasilkan WebP atau AVIF, makaSetiap versi WebP/AVIF dari gambar asli dan gambar mini menggunakan kredit tambahan.；
• Anda dapat mengecualikan thumbnail tertentu agar tidak dioptimalkan untuk mengurangi konsumsi kredit.

Contoh Kredit：

Katakanlah Anda mengunggah 1 gambar dan tema/plugin menghasilkan 8 gambar mini:

• Optimalkan hanya gambar asli + gambar mini: 1 (gambar asli) + 8 (gambar mini) = 9 kredit
• Jika Anda juga ingin membuat WebP/AVIF: satu versi generasi berikutnya untuk masing-masing dari 9 versi di atas → +9 kredit.
  Dengan kata lain, apa yang Anda anggap sebagai “1 gambar”, sebenarnya bisa menghabiskan hampir “2 digit kredit”.

Jadi:“Gratis 100 kredit” tidak sama dengan “gratis 100 gambar”.

Jebakan paling umum dari ShortPixel

1. 100 kredit gratis cepat habis
   Akar masalah: banyak thumbnail + kredit tambahan untuk menghasilkan WebP/AVIF.
   saran：

• Tentukan jumlah thumbnail situs terlebih dahulu
• Kecualikan ukuran gambar mini yang tidak perlu (hanya mengoptimalkan ukuran yang benar-benar akan digunakan)
• Tentukan strategi kompresi sebelum menjalankannya secara massal untuk menghindari konsumsi coba-coba yang berulang-ulang

2. Menumpuk plug-in konverter lain secara bersamaan
   Jika Anda memiliki penggantian Plus WebP dan ShortPixel menghasilkan/menyisipkan tag generasi berikutnya, logikanya akan menumpuk dan menjadi lebih sulit untuk dipecahkan. Untuk rute B, biarkan ShortPixel melakukannya sendiri.
3. Saya pikir, jika saya memasangnya, maka akan terlihat “WebP/AVIF di latar depan”.”
   Halaman plugin ShortPixelDisebutkan bahwa ini mengonversi WebP/AVIF dan dapat menambahkan gambar generasi berikutnya ke halaman depan (mis. dengan menandai).
   Tetapi tetap penting untuk memverifikasi hasilnya setelah melakukannya.

---

3.2.2 MembayangkanGratis: 20MB/bulan; kuota dikurangi sesuai dengan “ukuran gambar asli + jumlah thumbnail”, pengurangan akan dilakukan berulang kali untuk pengepresan ulang.

Jumlah dan posisi gratis

Halaman Harga Resmi ImagifyTulisannya jelas:Gratis Kuota Bulanan Akun 20MB。
Halaman pluginnya juga menjelaskan bahwa ia dapat mengompres, mengubah ukuran, dan mengonversi WebP/AVIF.

Bagaimana cara pemotongan kuota?

Membayangkan Dokumentasi Resmi “Bagaimana Penggunaan Kuota Dihitung?” menguraikan mekanisme pemotongan dengan sangat jelas:

• Jumlah gambar mini memengaruhi konsumsiMisalnya, jika Anda memiliki 10 ukuran gambar mini, mengoptimalkan 1 gambar berarti mengoptimalkan 11 gambar (gambar asli + 10 gambar mini), yang semuanya berkontribusi pada konsumsi kuota.
• Pengurangan kuota sesuai dengan ukuran dokumen asliSebagai contoh, jika Anda mengirim gambar 100KB ke Imagify, 100KB akan dipotong dari kuota.
• Mengubah tingkat kompresi dan mengoptimalkan kembali akan menghabiskan kuota lagi。
• API Key yang sama dapat digunakan untuk beberapa situs, tetapi kuota dibagi di antara mereka.

Ini adalah “cara inti pemahaman” Imagify:
Ini lebih seperti paket lalu lintas: paket ini memotong sebanyak yang Anda kirim; semakin banyak gambar mini yang Anda miliki, semakin banyak pula yang dipotong; dan Anda akan mengulangi pemotongan jika Anda berulang kali menekannya.

Contoh kuota Imagify yang mudah dibaca

Katakanlah Anda mengunggah gambar asli berukuran 800KB dan situs ini menghasilkan 8 gambar mini.

• Imagify mengoptimalkan untuk menyertakan “gambar asli + 8 gambar mini” (jika Anda memilih untuk mengoptimalkan semuanya), yang berarti bahwa tindakan tunggal ini menghabiskan kuota yang hampir sama dengan “ukuran asli dari gabungan semua file ini”.
  Itulah mengapa beberapa situs merasa bahwa “20MB cepat habis”: bukan karena Imagify tidak cukup, tetapi karena Anda mengunggah terlalu banyak gambar dalam satu waktu, terlalu banyak gambar mini, dan Anda mungkin mencoba tingkat kompresi berulang kali.

Jebakan Imagify yang paling umum

1. Gratis 20MB Tidak cukup untuk melakukan “inventarisasi historis di seluruh lokasi”
   20MB biasanya lebih cocok untuk pengujian dengan pembaruan ringan; jika perpustakaan media Anda sudah besar, pembersihan satu kali mungkin memerlukan peningkatan.
2. Penyesuaian tingkat kompresi yang berulang-ulang mengakibatkan duplikasi konsumsi kuota
   Imagify memperjelas bahwaPengoptimalan ulang akan menghabiskan kuota lagi.
   Saya sarankan Anda menjelaskan “strategi” pada halaman ini:

• Mulailah dengan sejumlah kecil gambar untuk menentukan tingkat kompresi dan tampilan serta nuansa
• Tentukan strategi dan kemudian jalankan secara massal
  Hindari mencoba-coba berulang kali pada perpustakaan lengkap

3. Beberapa situs yang berbagi API Key menyebabkan “pengurangan kuota yang tidak dapat dijelaskan”.”
   Jika Anda menggunakan API Key yang sama untuk lebih dari satu stasiun, maka kuota akan dibagi.
   Jadi, dalam skenario tim/multi stasiun, yang terbaik adalah memperjelas: stasiun mana yang digunakan bersama dan mana yang digunakan secara individual untuk menghindari anggaran yang tidak terkendali.

---

3.2.3 TinyPNG(Gambar Kompres Kecil): gratis 500 kredit/bulan; beralih ke WebP/AVIF akan “mengurangi 1 kredit per ukuran”.”

Kredit gratis dan ide penagihannya

Halaman plugin WordPress TinyPNG sangat jelas:

• Gratis 500 kredit per bulan
• Di “Instalasi WordPress Umum”, Anda mungkin dapat mengompres file Kira-kira 100 gambar/bulan
• Namun demikian, jika konversi AVIF atau WebP diaktifkan:Setiap ukuran gambar menggunakan kredit tambahanJadi, mungkin ini hanya dapat dikompresi dan dikonversi Kira-kira 50 gambar/bulan(tergantung pada berapa banyak ukuran gambar mini yang Anda miliki).

Sementara itu, Tinify (pengembang TinyPNG/TinyJPG) juga telah membuat Halaman Harga APIDeskripsi: Daftar dan dapatkan 500 kompresi gratis per bulan; setelah itu, Anda akan ditagih berdasarkan jumlah kompresi yang berhasil, tidak ada langganan wajib.

Rangkum cara TinyPNG dipahami dalam satu kalimat:
Sistem ini menghitung kredit; semakin banyak ukuran thumbnail yang Anda miliki dan semakin banyak WebP/AVIF yang Anda aktifkan, semakin cepat kredit dikonsumsi.

Contoh kredit TinyPNG yang mudah dibaca

Misalkan situs Anda menghasilkan 8 ukuran gambar mini untuk setiap gambar:

• Hanya kompresi: asli + 8 thumbnail → diperlukan 9 kredit
• Jika konversi WebP/AVIF diaktifkan: satu kredit tambahan per ukuran → mungkin hampir dua kali lipat!
  Hal ini sesuai dengan deskripsi pada halaman plugin: setelah mengaktifkannya, jumlah gratis berubah dari sekitar “100 kartu/bulan” menjadi “50 kartu/bulan”.

Jebakan paling umum dari TinyPNG

1. Pemikiran 500 kredit = 500 gambar
   Sebenarnya tidak. Ini dikonsumsi oleh “ukuran/variasi gambar”. Halaman plugin dengan jelas memperingatkan bahwa “Konversi mengurangi 1 kredit tambahan untuk setiap ukuran gambar”.
2. Plugin tema/e-commerce menghasilkan terlalu banyak ukuran dan kredit gratis menurun secara signifikan
   Semakin banyak ukuran yang tersedia, semakin mudah kredit ditingkatkan dan dikonsumsi.
3. Setelah mengaktifkan konversi, Anda mendapati bahwa kredit tiba-tiba tidak terpakai.
   Ini bukan bug, ini adalah mekanisme penagihannya.
   Saran Strategi:

• Jika fase bebas terutama digunakan untuk kompresi dan pengurangan berat, Anda dapat memulai dengan kompresi saja, dan kemudian mengaktifkan konversi ketika Anda yakin bahwa struktur situs Anda sudah stabil dan Anda benar-benar membutuhkan generasi berikutnya.

4. Rekomendasi sub-skenario: bagaimana memilih berbagai jenis situs

Selain itu, WordPress, situs konten, situs e-commerce, portofolio, dan situs keanggotaan tidak memiliki “titik tekanan” yang sama untuk gambar.

4.1 Situs konten/blog (banyak grafik artikel, frekuensi pembaruan sedang)

Rekomendasi Prioritas:

1. Strategi Penentuan Ukuran (Langkah 1)
2. Kompresi (Langkah 2)
3. WebP (Langkah 3)

Rute yang lebih cocok:

• Ingin menyimpan: Rute B Pilihan Tiga (ShortPixel / Imagify / TinyPNG)
• Jika Anda ingin bebas: Rute A (Plus WebP + EWWW), tetapi disarankan untuk memulai dengan “mode konservatif (tanpa menghapus gambar asli)” untuk menilai risikonya.

Lubang yang khas:

• Gambar pertama halaman artikel sangat besar, strategi pemuatan malas yang tidak tepatMemperlambat layar pertama

4.2 Situs e-commerce/produk (banyak gambar mini, banyak varian gambar, utamakan stabilitas)

E-commerce kemungkinan besar masalahnya bukan “efek kompresi tidak bagus”, tetapi “dioptimalkan beberapa ukuran yang tidak tepat, thumbnail yang hilang, komponen depan tidak bisa mendapatkan gambar”.

Rekomendasi Prioritas:

1. Stabilitas pertama: strategi kompresi konservatif, jangan langsung melakukan penggantian pustaka penuh
2. Mengevaluasi ukuran gambar mini: tema e-commerce biasanya menghasilkan lebih banyak ukuran, dan jumlah konsumsi diperbesar (ShortPixel/TinyPNG sangat mencolok)
3. Lakukan validasi skala kecil sebelum batch (sangat penting)

Rute yang lebih cocok:

• Rute B cenderung lebih mudah: ShortPixel/Imagify/TinyPNG bisa digunakan secara bersamaan, dan Anda harus memahami mekanisme kuota dan menilai biayanya terlebih dahulu
• Rute A baik-baik saja, tetapi lebih berhati-hati dengan perilaku “menimpa ID/menghapus gambar asli/mengganti URL” dari Plus WebP: ini adalah migrasi aset, dan tidak disarankan untuk mengganti semuanya secara langsung.

4.3 Portofolio/stasiun fotografi (sensitif terhadap kualitas gambar tunggal, gambar besar, tuntutan tinggi untuk dilihat)

Rekomendasi Prioritas:

1. Strategi ukuran (kontrol area tampilan)
2. Strategi kompresi (lebih baik lebih besar daripada menghancurkan detailnya)
3. WebP/AVIF (keuntungan pemandangan gambar besar terlihat jelas, tetapi verifikasi tampilannya)

Rute yang lebih cocok:

• Membayangkan: Kurangi kuota sesuai dengan “ukuran gambar asli”, situs semacam ini lebih mudah untuk melakukan “budget-controlled” (Anda tahu berapa banyak yang harus dikurangi untuk setiap gambar besar), tetapi hindari penindasan yang berulang-ulang.
• ShortPixelJika ukuran thumbnail tidak banyak, kredit juga sangat intuitif; tetapi jika Anda menghasilkan banyak ukuran + next-gen, konsumsi kredit akan diperbesar, dan Anda harus merencanakannya terlebih dahulu.

5. Perbandingan kuota/penagihan: menempatkan “gratis saja tidak cukup” ke dalam perspektif

Mana yang lebih baik dan berapa lama penawaran gratis ini akan bertahan?

5.1 Tiga Model Pengisian Ulang

• ShortPixel(kredit)Kredit berdasarkan “gambar asli + jumlah thumbnail”; kredit tambahan akan dikurangi untuk setiap versi WebP/AVIF yang dihasilkan.
• Membayangkan(Kuota MB): Memotong kuota sesuai dengan “ukuran file asli”; semakin banyak thumbnail, semakin banyak pemotongan; menekan ulang akan mengurangi kuota lagi.
• TinyPNG(kredit)500 kredit per bulan; mengaktifkan konversi WebP/AVIF akan mengurangi kredit tambahan untuk setiap ukuran gambar.

5.2 Metode estimasi cepat

Anda bisa memperkirakannya seperti ini:

1. Temukan “gambar asli yang sering Anda unggah” secara acak, dan lihat seberapa besar ukurannya (misalnya, 300KB / 1MB / 3MB).
2. Tergantung pada berapa banyak ukuran gambar mini yang dihasilkan situs Anda (misalnya 5 / 10 / 20)
3. Tentukan apakah Anda ingin membuat WebP/AVIF (ya/tidak)

Kemudian gunakan “matematika mental” berikut ini untuk memahami konsumsi:

• ShortPixelKredit (1 + jumlah thumbnail) per gambar; jika menghasilkan WebP/AVIF, ≈ dua kali lipat lagi (karena versi next-gen juga mengambil kredit)
• MembayangkanSetiap gambar ≈ (ukuran asli + setiap ukuran thumbnail) mengurangi kuota; ubah tingkat kompresi dan kompres ulang akan mengurangi kuota lagi.
• TinyPNGGratis 500 kredit; jika situs Anda menghasilkan banyak ukuran per gambar, dan konversi diaktifkan, jumlah kredit gratis turun secara signifikan (halaman plugin memberikan ekspektasi visual “~100 kredit/bulan” vs “~50 kredit/bulan”)

6. Peringatan risiko

Risiko 1: Jangan biarkan beberapa plugin melakukan hal yang sama berulang kali

Ini adalah “sumber bencana” yang paling umum.”

• Rute A:Ditambah WebP atau AVIF + EWWW(Membagi pekerjaan di antara keduanya, jangan melakukan konversi dan pengiriman yang serupa secara bersamaan, atau hanya memasang salah satunya saja)
• Rute B: ShortPixel / Imagify / TinyPNG pilih tiga(pilih salah satu untuk dikompresi dengan generasi berikutnya)

Risiko 2: Plus WebP “Menimpa ID / Menghapus Gambar Asli / Mengganti URL” adalah migrasi aset.

Penekanan ditambahkan:Ditambah WebP Deskripsi secara jelas menyatakan bahwa pembuatan penuh menimpa ID gambar asli, menghapus file asli, dan mengganti URL konten.
Ini berarti bahwa ini bukan “pengaturan kecil yang dapat ditarik kapan saja”, tetapi perubahan tingkat aset.

Strategi yang disarankan adalah:

• Uji coba kecil terlebih dahulu (beberapa lusin hingga beberapa ratus)
• Konfirmasikan bahwa tampilan frontend, gambar mini, dan pembaruan cache semuanya berfungsi dengan baik
• Mempertimbangkan kembali pemrosesan pustaka lengkap

Risiko 3: Konsumsi nyata “kredit gratis” kompresi awan bergantung pada jumlah gambar mini dan pilihan generasi berikutnya.

• ShortPixelGambar kecil dan generasi berikutnya secara signifikan memengaruhi kredit.
• TinyPNGMengaktifkan WebP/AVIF akan mengurangi kredit tambahan untuk setiap ukuran gambar.
• Membayangkan: dikurangi menurut ukuran gambar aslinya, semakin banyak gambar mini yang dikurangi, tekanan yang berat akan mengulangi pengurangan!

Risiko 4: “WebP/AVIF yang dihasilkan” tidak berarti “WebP/AVIF dikirimkan oleh front office”

Banyak orang merasa “tidak lebih cepat” setelah konversi karena frontend masih menghasilkan JPG/PNG (caching/penulisan ulang/negosiasi browser tidak di tempat yang tepat).

7. Bagaimana cara memverifikasi bahwa hal tersebut telah berlaku setelah dilakukan

4 poin validasi yang sangat sederhana:

1. Apakah halaman yang sama di-refresh untuk kedua kalinya dan dimuat secara lebih konsisten dan lebih cepat(Menyimpan dan mengoptimalkan indera fisik apakah berfungsi atau tidak)
2. Apakah ukuran gambar yang dimuat pada ponsel dan desktop berbeda secara signifikan(responsif) srcset/ukuran (apakah berfungsi atau tidak)
3. Periksa beberapa gambar: apakah ada file/sumber daya WebP atau AVIF(Apakah situs tersebut benar-benar menggunakan generasi berikutnya）
4. Contoh beberapa gambar: perbesar untuk melihat apakah gambar tersebut tampak berlumpur, apakah teksnya kabur(massa yang dikompresi tidak berlebihan)

Jika keempatnya cocok, maka rute yang Anda pilih telah dijalankan. Selanjutnya. CDN “Lapisan Pengiriman”secara keseluruhan akan lebih stabil.

8. Rekomendasi untuk tindakan

1. Pilih rute Anda terlebih dahulu:

• Berusaha sebebas mungkin.Ditambah WebP atau AVIF + EWWW (atau hanya salah satunya)
• Ingin menghemat sumber daya server, bayar dengan jumlah yang lebih mengkhawatirkanShortPixel / Imagify / TinyPNG - pilih salah satu!

2. Lakukan tes kecil terlebih dahulu (beberapa lusin)
3. Pastikan semuanya baik-baik saja sebelum Anda membuat batch
4. Diperlukan peningkatan lebih lanjut dalam stabilitas pengiriman:baca Akselerasi CDN

masalah umum

1. Berapa banyak plug-in yang harus saya instal? Dapatkah saya menginstal semuanya?

Cobalah untuk mengambil hanya satu rute.

• Rute A: Ditambah WebP atau AVIF + Pengoptimal Gambar EWWW (atau hanya salah satunya)
• Rute B: ShortPixel / Imagify / TinyPNG - pilih salah satu!
  Di stasiun yang sama pada saat yang sama, biarkan lebih dari satu plug-in melakukan “kompresi / transfer WebP / AVIF / ubah URL / penulisan ulang pengiriman”, yang paling mungkin menjadi semakin kacau, tetapi juga yang paling sulit untuk diperiksa.

2. Bukankah WordPress sudah mendukung WebP/AVIF? Apakah saya masih membutuhkan plugin?

Ini perlu dipisahkan:
“Dukungan untuk pengunggahan/penggunaan” ≠ “Konversi otomatis/pengiriman otomatis”.
WordPress 6.5 juga tidak secara otomatis mengonversi JPG/PNG lama ke WebP/AVIF, dan juga tidak secara otomatis melakukan proses “mengekspor AVIF/WebP ke peramban yang dapat digunakan dan mengembalikannya” untuk Anda. Biasanya diperlukan sebuah plugin atau layanan untuk membuat pustaka media historis berfungsi.

3. Apa langkah yang paling “bermanfaat” dalam pengoptimalan gambar?

Biasanya Dapatkan “ukuran” dengan benar terlebih dahulu (srcset/sizes).。
Banyak situs yang lambat bukan karena tidak memiliki kompresi, tetapi karena halamannya hanya berukuran 900px dan pengguna diminta untuk mengunduh gambar berukuran 3000px. Kompresi menghemat KB, tetapi “ukuran yang salah” akan membuat Anda mengunduh beberapa kali lebih banyak data secara percuma.

4. Bagaimana saya bisa yakin bahwa saya memuat “yang lebih kecil” dan bukan gambar aslinya untuk selamanya?

Lihatlah dua fenomena:

• Apabila membuka halaman pada ponsel, ukuran gambar yang diunduh terasa lebih kecil daripada di desktop
• Gambar yang sama dimuat dengan ukuran sumber daya yang berbeda pada perangkat yang berbeda
  Jika gambar asli diunduh selamanya, alasan umumnya adalah tema/pembangun memperlakukan gambar sebagai gambar latar belakang CSS atau keluaran khusus, melewati multi-ukuran pustaka media dengan srcset.

5. Apakah “WebP/AVIF yang dihasilkan” berarti bahwa frontend harus menghasilkan WebP/AVIF?

Tidak sama.
Pembuatan hanyalah “lapisan file” yang dilakukan; apakah frontend benar-benar memberikan WebP/AVIF tergantung pada penulisan ulang, kebijakan penandaan gambar, hit cache, negosiasi peramban yang berlaku, dan seterusnya. Setelah selesai, pastikan untuk “memeriksa beberapa gambar untuk jenis sumber daya”.

6. Plus Apa yang berbahaya dari WebP atau AVIF? Dapatkah saya menjalankan seluruh perpustakaan dalam satu klik?

Titik risikonya bukanlah “kompresi”, melainkanPerubahan tingkat migrasi aset：

• Pembuatan penuh dapat menimpa ID file gambar asli, menghapus file asli, dan mengganti URL dalam konten.
  alasan mengapaTidak disarankan untuk mengganti seluruh perpustakaan secara langsungUji dalam skala kecil terlebih dahulu (puluhan ~ ratusan) + memiliki cadangan yang tersedia, kemudian pertimbangkan pemrosesan perpustakaan penuh.

7. Apa pilihan di antara dua mode Plus WebP: mempertahankan gambar asli vs. mengganti dan menghapus gambar asli?

Mudah dipahami:

• Mode 1: Menyimpan gambar asli + menghasilkan salinan WebP/AVIF (lebih stabil)Nyaman untuk rollback, tetapi disk naik (gambar asli + format baru + thumbnail multi-ukuran).
• Mode 2: Mengganti dan menghapus gambar asli (lebih agresif)Disk tidak terlalu rentan terhadap bloat, tetapi Anda “mengubah aset + mengubah referensi”, yang membuatnya lebih mahal untuk memecahkan masalah kompatibilitas.
  Semakin kompleks situs (e-commerce/multi-plugin/multi-besar), semakin direkomendasikan untuk memulai dengan model yang lebih stabil.

8. Apakah kompresi lokal gratis EWWW Image Optimizer sudah cukup? Apakah akan membebani server?

EWWW lebih merupakan “kompresor lokal”: ia memakan CPU/IO.
Adalah hal yang umum jika beban meningkat selama pengoptimalan batch, yang bukan berarti “tidak berhasil”, melainkan bahwa strateginya harus tepat: opsi batch, low peak, dan offloading/cloud jika perlu.
Jika Anda mencari penghematan, atau jika Anda kekurangan sumber daya server, Rute B lebih ramah server.

9. Kredit gratis 100 kredit/bulan dari ShortPixel, mengapa saya merasa seperti hilang dalam beberapa gambar?

karena kredit bukanlah “jumlah gambar”.”Generasi berikutnya akan diperbesar oleh gambar mini dengan generasi berikutnya:

• Gambar asli + setiap gambar mini dihitung sebagai kredit
• Jika WebP/AVIF dibuat, kredit tambahan dikonsumsi untuk setiap versi yang sesuai.
  Jadi, apa yang Anda kira sebagai “1 gambar”, sebenarnya bisa menghabiskan hampir “2 digit kredit”. shortPixel

10. Imagify gratis 20MB/bulan, mengapa juga cepat habis?

Imagify lebih seperti “paket lalu lintas”:

• Seperti yang Anda kirimkan.Ukuran file aslipengurangan kuota
• Semakin banyak gambar mini yang Anda miliki, semakin banyak yang Anda konsumsi
• Mengubah tingkat kompresi untuk mengoptimalkan kembali akan menghabiskan kuota lagi
• Kunci API yang sama untuk beberapa situs, berbagi kuota
  Jadi, “20MB akan segera habis” sering kali disebabkan oleh gambar yang terlalu besar, terlalu banyak gambar mini, atau coba-coba yang berulang-ulang.

11. TinyPNG gratis untuk 500 kredit/bulan, mengapa plugin mengatakan hanya sekitar 100 kredit/bulan dan kemudian 50 kredit/bulan dengan WebP/AVIF?

Karena kredit TinyPNG juga diperbesar oleh “ukuran/varian”:

• Instalasi WordPress biasa mungkin mengompres sekitar 100 lembar/bulan.
• Aktifkan konversi AVIF atau WebP:Setiap ukuran gambar menggunakan kredit tambahanJadi, Anda mungkin hanya bisa mengompres dan mengonversi sekitar 50 gambar/bulan (tergantung pada jumlah ukuran thumbnail).
  Jadi, 500 kredit ≠ 500 gambar.

12. Berapa banyak gambar mini yang ada di situs saya? Mengapa ini sangat penting?

WordPress menghasilkan berbagai ukuran untuk mengunggah gambar; tema/plugin (terutama e-commerce) dapat menambahkan lebih banyak ukuran.
Kredit/kuota kompresi awan biasanya berupa “asli + thumbnail bersamaan”, jadi semakin banyak thumbnail yang Anda miliki, semakin sedikit kredit gratis yang harus Anda gunakan.

13. Apakah pemuatan malas selalu lebih cepat? Mengapa beberapa orang mengatakan bahwa malas memuat memperlambat segalanya?

Pemuatan malas cocok untuk “sumber daya di luar layar”.
Jika layar pertama dari gambar besar yang paling penting juga tertunda pemuatannya, dapat memperlambat pengalaman layar pertama. WordPress 5.5 sejak default lazy loading tidak masalah, tetapi jangan “satu ukuran untuk semua”.

14. Saya bepergian di Rute A atau B. Kapan saya memerlukan CDN / Gambar CDN?

Kompresi, ukuran, dan pemformatan memecahkan masalah “file yang lebih kecil yang sesuai”;
CDN Solusinya adalah memberikan hasil yang lebih dekat dan lebih stabil。
Ketika gambar ditarik dari jarak jauh dari situs sumber yang menghasilkan latensi yang signifikan, maka melengkapi CDN/gambar dengan CDN (mis. Cloudflare Polish / Jetpack Site Accelerator) secara keseluruhan akan lebih stabil, baca Akselerasi WordPress CDN。

15. Apa cara termudah bagi saya untuk memverifikasi bahwa “ini benar-benar berhasil” setelah saya selesai?

Metode verifikasi yang paling efisien dari segi waktu:

• Apakah halaman yang sama di-refresh untuk kedua kalinya dan dimuat secara lebih konsisten dan lebih cepat
• Apakah ukuran gambar yang dimuat pada ponsel dan desktop berbeda secara nyata (apakah srcset/sizes ikut berperan)
• Periksa beberapa gambar: apakah ada file/sumber daya WebP atau AVIF
• Contoh beberapa gambar: perbesar untuk melihat apakah gambar tersebut tampak berlumpur, apakah teksnya kabur