Optimasi gambar WordPress.

Optimasi gambar adalah salah satu hal dengan “imbalan tertinggi” dalam kinerja WordPress: struktur halaman yang sama, tema yang sama, selama ukuran, dimensi, format, dan cara penyampaian gambar dilakukan dengan benar, pengalaman memuat biasanya langsung meningkat.

Namun, mengoptimalkan gambar juga sangat mudah membuat segalanya “semakin rumit”, bukan karena tekniknya terlalu sulit, tetapi karena informasinya terlalu terfragmentasi:
Kamu sudah membaca beberapa artikel dan tahu tentang “kompresi”, “WebP/AVIF”, dan “loading gambar tertunda”. Lalu kamu lihat deskripsi plugin yang mengatakan “100 kredit gratis per bulan”, “20MB gratis”, dan “1 kredit per gambar”. Akhirnya kamu semakin bingung — apakah ini cukup gratis? Bagaimana cara penagihannya? Mungkinkah kamu salah paham tentang “hal yang sama”? Dan yang terpenting:Apakah itu benar-benar efektif setelah kamu menyelesaikannya?

Artikel ini hanya melakukan tiga hal:

1. \nBerikut ini adalah instruksi yang dapat kamu ikuti:Peta rute.(Apa yang harus dilakukan terlebih dahulu, dan apa yang harus dilakukan setelahnya.)
2. Jelaskan secara rinci solusi yang ingin Anda pilih (perbedaan antara gratis dan berbayar, serta siapa yang cocok untuk masing-masing solusi tersebut).
3. Tulis terlebih dahulu kesalahan yang paling umum (untuk menghindari kamu harus mencari dan memeriksa di mana-mana setelah menyelesaikannya).

1. Lapisan dasar: Apa yang disertakan oleh WordPress, dan apa yang tidak disertakan?

Jika Anda tidak terlebih dahulu memahami apa yang sudah dilakukan oleh WordPress Core, maka Anda akan mudah mengalami dua situasi berikut:

• Tidak memanfaatkan “kemampuan gratis” yang seharusnya dinikmati, malah menghabiskan waktu/uang untuk mengulangi hal yang sudah ada.
• Saya pikir WordPress akan “secara otomatis mengonversi semua gambar lama menjadi WebP/AVIF”, tetapi ternyata tidak.

WordPress inti sudah memiliki kemampuan-kemampuan penting ini secara built-in:

• Gambar responsif (srcset/sizes)Sejak WordPress 4.4, inti akan mengekspor gambar. srcset 与 sizesDan, menggunakan gambar-gambar multi-ukuran yang dihasilkan saat mengunggah, memungkinkan browser untuk memilih sumber daya yang paling cocok untuk dimuat berdasarkan kondisi layar.
• Pengurangan pemalasan asli.Sejak WordPress 5.5, pemuatan malas asli untuk gambar diaktifkan secara default, menggunakan standar HTML. loading Implementasi atribut.
• Mendukung unggahan WebP.Sejak WordPress 5.8, Anda dapat mengunggah dan menggunakan WebP sama seperti JPEG/PNG (asalkan lingkungan host mendukung WebP).
• Mendukung unggahan AVIF.Mulai dari WordPress 6.5, Anda dapat mengunggah dan menggunakan AVIF seperti halnya JPEG/PNG (yang juga tergantung pada dukungan lingkungan host).

Namun, perhatikan:
“Mendukung unggahan/penggunaan” ≠ “konversi otomatis/pengiriman otomatis”.
Artinya: Meskipun Anda sudah menggunakan WP 6.5, JPG/PNG di perpustakaan media Anda tidak akan otomatis berubah menjadi WebP/AVIF; Anda juga tidak akan secara otomatis mendapatkan tautan lengkap “mengekspor AVIF/WebP sesuai kemampuan browser, dan kembali ke gambar asli untuk browser yang tidak mendukungnya” — bagian ini biasanya membutuhkan plugin atau layanan tambahan.

2. Peta rute: Optimisasi gambar dalam 5 langkah.

Apa yang harus dilakukan, mengapa, dan apa yang dianggap sebagai hasil yang memuaskan, serta apa kesalahan umum yang sering terjadi.

2.1 Pertama, pastikan “ukuran”-nya benar (yang paling mudah diabaikan, tetapi memberikan manfaat terbesar).

Banyak situs web yang lambat bukan karena kompresi yang tidak dilakukan, tetapi karena hal lain.Saya mengunduh gambar yang ukurannya jauh lebih besar dari area yang ditampilkan.：
Misalnya, jika halaman hanya menampilkan lebar 900px, tetapi Anda meminta pengunjung untuk mengunduh gambar asli dengan ukuran 3000px, browser hanya akan “mengunduhnya terlebih dahulu dan kemudian mengecilkannya untuk ditampilkan”. Hal ini akan membuang-buang bandwidth, meningkatkan waktu dekode, dan memperlambat waktu tampilan pertama.

Untuk WordPress 4.4+.Mekanisme gambar responsif.（srcset/sizesHal tersebut justru untuk mengatasi masalah ini.

Apa yang dianggap sebagai nilai yang memuaskan?

• Saat membuka halaman di ponsel, ukuran gambar yang diunduh harus jelas lebih kecil daripada di desktop.
• Ukuran sumber daya yang dimuat oleh gambar yang sama berbeda pada perangkat yang berbeda (dan bukan mengunduh gambar asli secara permanen).

Perangkap paling umum:

• Beberapa tema / pembangun menggunakan gambar sebagai latar belakang CSS, atau mengekspornya dengan cara yang disesuaikan, yang mungkin mengakibatkan masalah. srcsetHal itu mengakibatkan gambar-gambar besar terus muncul.
• Kamu menggunakan tautan eksternal ke gambar, blok gambar pihak ketiga, dan mungkin juga menghindari sistem multi-ukuran yang dihasilkan oleh perpustakaan media.

---

2.2 Kompresi (mengurangi ukuran KB, tetapi tidak merusak kualitasnya).

Inti dari kompresi bukanlah “semakin kecil semakin baik”, tetapi “hampir tidak terlihat oleh mata manusia, tetapi ukurannya menurun secara signifikan”.

Aturannya adalah sebagai berikut:

• Foto/gambar nyata (orang, produk, pemandangan): Kompresi dengan kerugian prioritas (manfaat maksimal)
• Screenshot antarmuka / gambar dengan banyak teks.: Kompresi harus lebih konservatif, untuk menghindari teks yang terlihat buram.
• Logo/Ikon: Prioritaskan SVG atau hati-hati dengan gambar lossless (gambar lossy cenderung memiliki tepi yang kabur)

Apa yang dianggap sebagai nilai yang memuaskan?

• Sebagian besar gambar di halaman tersebut memiliki ukuran yang jauh lebih kecil.
• Tidak ada noise yang jelas, tepi kabur, pemisahan blok warna, atau teks yang kabur.

---

2.3 WebP / AVIF (Strategi format: ukuran lebih kecil dengan kualitas yang sama)

WordPress sudah mendukung unggahan. WebP (5.8) dan AVIF (6.5)。
Namun, untuk benar-benar menggunakan “format generasi berikutnya”, biasanya harus mengatasi dua hal:

1. Bagaimana cara mengonversi media sejarah secara massal?(Jika tidak, kamu hanya akan mengoptimalkan “gambar baru yang diunggah di masa mendatang”).
2. Apakah itu menghasilkan salinan, atau mengganti gambar aslinya?(Ini adalah titik kritis risiko; nantinya akan dibahas secara detail tentang “ganti dan hapus gambar asli” di Plus WebP.)

Cara yang direkomendasikan untuk menulisnya:

• WebP: Umumnya digunakan sebagai pilihan default (dengan kompatibilitas yang lebih baik)
• AVIF: Arah kompresi yang lebih lanjut, cocok untuk gambar besar/gambar utama/gambar album (tetapi lebih\nMengandalkan dukungan lingkungan.）

---

2.4 Lazy loading harus digunakan dengan benar (jangan terapkan secara membabi buta).

Mulai WordPress 5.5Memuat malas secara default.Gambar.
Ini dapat mengurangi penggunaan bandwidth pada rendering awal:

• Lazy loading cocok untuk “sumber daya di luar layar”.”
• Gambar besar yang paling penting di layar pertama (yang sering kali merupakan gambar utama di layar pertama) biasanya tidak cocok untuk diunduh nanti.

---

2.5 Lapisan Pengiriman: CDN / CDN Gambar.

Kompresi, ukuran, dan format menyelesaikan masalah “agar file menjadi lebih kecil dan lebih mudah digunakan”.
Namun, jika gambar selalu diambil dari sumber jarak jauh, latensi jaringan akan tetap memengaruhi pengalaman secara signifikan. Dalam hal ini, diperlukan solusi “lapisan pengiriman” (CDN/CDN gambar).

Dua arah yang khas:

• Cloudflare Polandia.：Dokumen Cloudflare.Di sini, kami memperkenalkan metode kompresi untuk bahasa Polandia (tanpa kerugian/dengan kerugian/WebP) dan menyebutkan penggunaannya. format=auto Mengizinkan penggunaan format WebP/AVIF.
• Akelerator Situs Jetpack.：Dokumentasi Jetpack.Jelaskan bahwa itu akan mengoptimalkan gambar dan mendistribusikannya melalui jaringannya bersama dengan sumber daya statis.

Tugas optimisasi gambar adalah membuat gambar menjadi lebih kecil dan lebih sesuai.CDN bertanggung jawab untuk memberikan konten yang lebih dekat dan lebih stabil.

3. Pemilihan tipe: Hanya mengambil dua rute utama.

Kegagalan paling umum dalam mengoptimalkan gambar bukanlah “tidak memasang plugin”, tetapi memasang terlalu banyak plugin yang mengakibatkan pemrosesan berlebihan:
A sedang mengompres, B juga sedang mengompres; A sedang mengonversi ke WebP/AVIF, B juga sedang mengonversi; A sedang mengubah URL, B juga melakukan penulisan ulang - pada akhirnya kamu sendiri tidak bisa menjelaskan dengan jelas apa yang sebenarnya terjadi di situs ini.

Aturan:

Hanya ada satu opsi: pilih antara lokal gratis sepenuhnya, atau kompresi cloud.

• Rute A (sepenuhnya gratis dan lokal):Plus WebP atau AVIF + EWWW Image Optimizer.(Atau pilih hanya salah satunya)
• Rute B (tiga opsi untuk kompresi cloud):\nShortPixel / Imagify / TinyPNG

---

3.1 Rute A: Sepenuhnya gratis untuk lokal (Plus WebP atau AVIF atau EWWW)

Karakteristik dari rute ini adalah:

• Kamu tidak bergantung pada layanan kompresi pihak ketiga yang “berbasis kuota bulanan/berdasarkan jumlah gambar” (tentu saja, beberapa fitur mungkin juga menyediakan layanan opsional).
• Biayanya adalah: pemrosesan batch mungkin lebih membebani CPU/IO server, dan Anda perlu lebih memperhatikan “strategi dan risiko”.”

3.1.1 Plus WebP atau AVIF.Intinya adalah “generasi/penggantian”, ini bukanlah “alat kompresi” dalam arti tradisional.”

• Saat menghasilkan gambar dalam jumlah penuh:ID file gambar asli akan diganti oleh WebP/AVIF, file asli akan dihapus, dan URL di konten juga akan diganti.。
• Plugin ini menyediakan perintah WP-CLI dan memberi peringatan bahwa menggunakan WP-CLI lebih dapat diandalkan saat ada banyak file.

Ini berarti: ini bukan “diam-diam membantumu menghasilkan file WebP”, tetapi mungkin sebuah kesalahan.\nMigrasi aset.(Terutama saat Anda mengaktifkan opsi “Ganti dan Hapus Gambar Asli”).

Perbedaan antara kedua model tersebut.

Model 1: Pertahankan gambar asli + hasilkan salinan WebP/AVIF (lebih stabil)

• Keuntungan: Lebih mudah untuk kembali ke versi sebelumnya jika terjadi masalah kompatibilitas.
• Biayanya: Penggunaan disk akan meningkat (gambar asli + format baru + thumbnail dalam berbagai ukuran).

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

• Keuntungan: Disk tidak akan mengembang terlalu cepat; referensi dalam situs akan langsung berubah ke format baru.
• Risiko: Saat Anda “mengubah aset + mengubah referensi”, biaya untuk mengatasi masalah kompatibilitas akan lebih tinggi (terutama jika sistem eksternal atau logika tema bergantung pada nama file/jalur/format asli).

Plus, kendala umum dengan WebP atau AVIF.

1. Setelah melakukan penggantian seluruh database, beberapa gambar di halaman tampil tidak normal.
   Alasannya biasanya bukan karena “gambar rusak”, tetapi karena ada sesuatu yang salah di sepanjang rantai, seperti penggantian URL, caching, strategi thumbnail, dan lain-lain.
2. Semakin banyak thumbnail, semakin besar ruang lingkup perubahan.
   Di WordPress, mengunggah satu gambar akan menghasilkan beberapa ukuran; tema/plugin juga mungkin menambahkan ukuran lainnya. Penggantian sepenuhnya berarti Anda mungkin harus mengubah sejumlah besar file.
3. Hanya melakukan migrasi format tidak berarti ukurannya pasti minimal.
   WebP/AVIF umumnya lebih kecil, tetapi “strategi ukuran” dan “strategi kompresi” tetap sangat penting. Jangan menganggap Plus WebP sebagai “solusi cepat”.

---

3.1.2 Pengoptimal Gambar EWWW: Perwakilan dari kompresi lokal gratis.

Halaman plugin EWWW memiliki posisi yang sangat jelas:

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

Apa peran EWWW dalam Rute A?

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

• Kompresi dan optimasi ukuran.(Terutama mengurangi ukuran sumber asli seperti JPG/PNG.)
• Optimalkan perpustakaan media historis secara massal.(Dengan tujuan “mengurangi ukuran”, bukan “mengganti URL”)

Perangkap khas EWWW.

1. Saat melakukan optimasi batch, beban server meningkat.
   Karena kompresi lokal memakan CPU/IO. Solusinya bukan “jangan gunakan”, tetapi “batasi penggunaan, lakukan saat tidak sibuk, dan pilih solusi offline/cloud jika perlu”.
2. “WebP telah dihasilkan” tidak berarti bahwa antarmuka pengguna pasti menampilkan WebP.
   Banyak plugin memiliki kesalahpahaman ini: generasi adalah satu hal, sedangkan strategi pengiriman (penulisan ulang, tag gambar, hit cache, dll.) adalah hal lainnya.
3. \nMenyebabkan duplikasi fungsi dengan plugin lain yang melakukan hal yang sama.
   Jika Anda menggunakan rute A, sebaiknya jangan menggunakan kompresi cloud seperti ShortPixel/Imagify/TinyPNG; jika Anda menggunakan rute B, jangan aktifkan logika penggantian Plus WebP. Prinsip utamanya adalah:Ikuti satu rute sampai akhir.

---

3.2 Rute B: Kompresi gambar dari tiga opsi (ShortPixel / Imagify / TinyPNG)

Rute ini cocok untuk orang-orang yang “ingin menghemat sumber daya server, ingin lebih nyaman melakukan pemrosesan batch, dan menerima penagihan berdasarkan kuota/volume”.
Namun, hal yang paling mudah disalahpahami tentang kompresi cloud adalah:Quota gratis tidak sesederhana “jumlah SMS gratis”.Ukuran dan jumlah thumbnail, apakah WebP/AVIF dihasilkan, dan apakah kompresi dilakukan berulang kali, semuanya akan memengaruhi konsumsi secara signifikan.

Berikut ini akan dijelaskan: bagaimana dengan gratis/berbayar, bagaimana kuota dikurangi, kesalahan paling umum, dan jenis situs yang paling cocok.

---

3.2.1 \nShortPixel: 100 kredit gratis/bulan, tetapi kredit akan dikonsumsi oleh thumbnail dan pembesaran WebP/AVIF.

Apa kaitannya dengan gratis/berbayar?

Plugin ShortPixel secara jelas menyatakan dalam deskripsinya:

• 100 kredit gratis setiap bulannya.
• Ada juga “kredit bulanan tambahan tanpa batas” (halaman plugin memberikan informasi harga yang sesuai).
• Mereka juga menyediakan “paket kredit sekali pakai yang tidak kedaluwarsa” (dengan memberikan informasi harga awal).

Petunjuk:

• Gratis: Diberikan kredit tertentu setiap bulannya, yang dapat digunakan untuk situs web ringan atau untuk tujuan pengujian.
• Paket sekali pakai: Cocok untuk situs “dengan perpustakaan media yang besar yang ingin mengosongkan stoknya sekaligus” (dibeli sekali dan digunakan sampai habis, biasanya tidak kedaluwarsa).
• Bulanan/Tak Terbatas: Cocok untuk situs yang terus memperbarui gambar dan melakukan optimasi jangka panjang secara stabil.

KB resmi ShortPixel juga memberikan penjelasan tentang “Paket satu kali vs Paket bulanan tak terbatas”.Menjelaskan dengan jelas.: Paket bulanan tanpa batas dibayar setiap bulan (atau setiap tahun), menyediakan kredit tanpa batas, dan dilengkapi dengan kuota CDN tetap; kredit satu kali tidak kedaluwarsa, sehingga Anda dapat menggunakannya sesuai kebutuhan dengan lebih terkendali.

Yang paling penting: Bagaimana cara menghitung kredit ShortPixel?

Dokumentasi resmi ShortPixel. KB menyatakannya dengan sangat jelas:

• Mengunggah gambar di WordPress akan menghasilkan beberapa thumbnail;
• Setiap optimasi thumbnail akan dihitung sebagai satu kredit.；
• Jika kamu memilih untuk menghasilkan WebP atau AVIF,Setiap versi WebP/AVIF dari gambar asli dan gambar thumbnail akan mengonsumsi satu kredit tambahan.；
• Kamu dapat mengecualikan beberapa thumbnail agar tidak dioptimalkan, untuk mengurangi konsumsi kredit.

Kredit: Contoh：

Asumsikan kamu mengunggah 1 gambar, dan tema/plugin menghasilkan 8 thumbnail:

• Hanya mengoptimalkan gambar asli + gambar thumbnail: 1(gambar asli) + 8(gambar thumbnail) = 9 kredit.
• Jika masih ingin menghasilkan WebP/AVIF: masing-masing dari 9 di atas ditambah satu versi next-gen → +9 kredit lagi
  Artinya, kamu mungkin mengira itu “1 gambar”, tetapi sebenarnya mungkin menghabiskan hampir “2 digit kredit”.

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

Perangkap paling umum dari ShortPixel.

1. Gratis 100 kredit, tapi cepat habis.
   Penyebabnya: banyak thumbnail + kredit tambahan untuk menghasilkan WebP/AVIF.
   saran：

• Pertama, evaluasi jumlah thumbnail situs.
• Menghilangkan ukuran thumbnail yang tidak perlu (hanya mengoptimalkan ukuran yang benar-benar akan digunakan).
• Pertama, tentukan strategi kompresi, lalu jalankan secara batch untuk menghindari membuang-buang waktu dengan mencoba berulang kali.

2. Di sisi lain, gabungkan dengan plugin konversi format lainnya.
   Jika Anda mengaktifkan penggantian Plus WebP dan membiarkan ShortPixel menghasilkan/menyisipkan tag next-gen, logikanya akan tumpang tindih, sehingga sulit untuk menyelidikinya. Untuk itu, pilih opsi B, yaitu membiarkan ShortPixel menanganinya sendiri.
3. Mengira bahwa jika sudah diinstal, maka “antarmuka pengguna pasti menampilkan WebP/AVIF”.”
   Halaman plugin ShortPixel.Di sini disebutkan bahwa ia dapat mengonversi WebP/AVIF dan menambahkan gambar generasi berikutnya ke halaman depan (misalnya melalui tag).
   Namun, setelah selesai, kita tetap harus memverifikasi efeknya.

---

3.2.2 Imagify: Gratis 20MB/bulan; kuota dikurangi berdasarkan “ukuran gambar asli + jumlah thumbnail”, dan kompresi ulang akan mengurangi kuota lagi.

Quota gratis dan lokasi.

Halaman harga resmi Imagify.Ini ditulis dengan sangat jelas:Akun gratis memiliki kuota 20MB per bulan.。
Halaman plugin-nya juga secara jelas menyatakan bahwa ia dapat mengompres, menyesuaikan ukuran, dan mengonversi WebP/AVIF.

Bagaimana cara mengurangi kuota?

Dokumentasi resmi Imagify. “Bagaimana Penggunaan Kuota Dihitung?” Ini menjelaskan mekanisme penagihan dengan sangat jelas:

• Jumlah thumbnail akan memengaruhi konsumsi.Contohnya, jika Anda memiliki 10 ukuran thumbnail, mengoptimalkan 1 gambar akan berarti mengoptimalkan 11 gambar (gambar asli + 10 thumbnail), yang semuanya akan berkontribusi terhadap penggunaan kuota.
• Mengurangi kuota berdasarkan ukuran file asli.Contohnya, jika Anda mengirim gambar berukuran 100 KB ke Imagify, maka 100 KB tersebut akan dikurangkan dari kuota Anda.
• Mengubah tingkat kompresi dan mengoptimalkan ulang akan mengkonsumsi kuota lagi.。
• Kunci API yang sama dapat digunakan untuk beberapa situs, tetapi kuotanya akan dibagi di antara situs-situs tersebut.

Inilah “cara pemahaman inti” dari Imagify:
Ini lebih mirip paket data: kamu mengirim sebanyak apa, mereka mengurangi sebanyak itu; semakin banyak gambar thumbnail, semakin banyak yang dikurangi; jika kamu terus mengkliknya berulang kali, mereka akan terus menguranginya berulang kali.

Contoh kuota Imagify yang mudah dipahami.

Asumsikan Anda mengunggah gambar asli berukuran 800 KB, dan situs tersebut menghasilkan 8 gambar thumbnail.

• Saat mengoptimalkan dengan Imagify, “gambar asli + 8 thumbnail” semuanya akan dimasukkan (jika Anda memilih untuk mengoptimalkan semuanya), yang berarti tindakan ini akan mengonsumsi kuota yang hampir sama dengan “total ukuran asli semua file tersebut”.
  Inilah mengapa beberapa situs merasa “20MB cepat habis”: bukan karena Imagify tidak cukup, tetapi karena gambar yang Anda unggah terlalu besar, terlalu banyak thumbnail, dan Anda mungkin terus mencoba mengurangi tingkat kompresi.

Masalah paling umum dengan Imagify.

1. 20MB gratis tidak cukup untuk melakukan “penghapusan riwayat seluruh situs”.”
   20MB biasanya lebih cocok untuk pengujian dan pembaruan ringan; jika perpustakaan media Anda sudah sangat besar, membersihkan perpustakaan sekaligus kemungkinan besar memerlukan peningkatan.
2. Mengubah level kompresi berulang kali mengakibatkan kuota terkuras berulang kali.
   Imagify menjelaskan dengan jelas.Optimasi ulang akan mengkonsumsi kuota lagi.
   Kami sarankan Anda menulis “strategi” dengan jelas di halaman ini:

• Pertama, gunakan sejumlah kecil gambar untuk menentukan tingkat kompresi dan tampilannya.
• Tentukan strateginya terlebih dahulu, lalu jalankan secara massal.
  Hindari mencoba-coba berulang kali di seluruh database.

3. Kunci API yang digunakan oleh beberapa stasiun mengakibatkan kuota “menurun secara misterius”.”
   Jika Anda menggunakan API Key yang sama di beberapa situs, kuota tersebut akan dibagikan.
   Jadi, dalam skenario tim/stasiun banyak, sebaiknya jelaskan: stasiun mana yang digunakan bersama, dan stasiun mana yang digunakan secara terpisah, untuk menghindari anggaran yang tidak terkendali.

---

3.2.3 TinyPNG(Tiny Compress Images): Gratis 500 kredit/bulan; mengonversi ke WebP/AVIF akan “menghabiskan 1 kredit tambahan untuk setiap ukuran”.”

Quota gratis dan konsep penagihannya.

Halaman plugin WordPress TinyPNG ditulis dengan sangat jelas:

• 500 kredit gratis setiap bulannya.
• Di “Instalasi WordPress biasa”, seharusnya bisa mengompresnya. Sekitar 100 gambar/bulan.
• Namun, jika mengaktifkan konversi AVIF atau WebP:Setiap ukuran gambar akan mengonsumsi satu kredit tambahan.Oleh karena itu, kemungkinan besar hanya bisa dikompresi dan dikonversi. Sekitar 50 gambar/bulan.(Ini tergantung pada berapa banyak ukuran thumbnail yang Anda miliki.)

Sementara itu, Tinify (pengembang TinyPNG/TinyJPG) juga telah meluncurkan \nHalaman penetapan harga API.Catatan: Daftar untuk mendapatkan 500 kompresi gratis per bulan; setelah itu, Anda akan dikenakan biaya berdasarkan jumlah kompresi yang berhasil, tanpa ada kewajiban untuk berlangganan.

Dalam satu kalimat, jelaskan cara TinyPNG memahami sesuatu:
Ini dihitung berdasarkan kredit; semakin banyak ukuran thumbnail, dan semakin banyak Anda mengaktifkan WebP/AVIF, maka semakin cepat kredit Anda habis.

Contoh kredit TinyPNG yang mudah dipahami.

Asumsikan situs Anda menghasilkan 8 ukuran thumbnail untuk setiap gambar:

• Hanya kompresi: gambar asli + 8 thumbnail → membutuhkan 9 kredit.
• Jika mengaktifkan konversi WebP/AVIF: setiap ukuran akan dikenakan biaya kredit tambahan → mungkin hampir dua kali lipat.
  Ini sesuai dengan penjelasan di halaman plugin: Setelah mengaktifkan konversi, batas gratis kira-kira berubah dari “100 foto/bulan” menjadi “50 foto/bulan”.

Masalah paling umum dengan TinyPNG.

1. Aku kira 500 kredit = 500 gambar.
   Tidak. Ini dikonsumsi berdasarkan “ukuran gambar/varian”. Halaman plugin sudah jelas mengingatkan bahwa “konversi akan mengurangi 1 kredit tambahan untuk setiap ukuran gambar”.
2. \nTema/plugin e-commerce menghasilkan terlalu banyak ukuran, dan kuota gratisnya menurun secara signifikan.
   Semakin banyak ukuran, semakin mudah kredit tersebut habis dengan cepat.
3. Setelah mengaktifkan konversi, saya menemukan bahwa batasannya tiba-tiba tidak cukup lagi
   Ini bukan bug, ini mekanisme penagihannya.
   Saran strategi:

• Jika fase gratis terutama digunakan untuk kompresi dan pengurangan ukuran, Anda dapat mulai dengan kompresi saja. Setelah Anda memastikan struktur situs stabil dan Anda benar-benar membutuhkan next-gen, Anda kemudian dapat mengaktifkan konversinya.

4. Rekomendasi berdasarkan skenario: bagaimana memilih antara berbagai tipe situs.

Meskipun semuanya menggunakan WordPress, “tekanan gambar” untuk situs konten, e-commerce, portofolio, dan situs keanggotaan tidak sama.

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

Saran prioritas:

1. Strategi ukuran (Langkah 1)
2. Kompresi (Langkah 2)
3. WebP (Langkah 3)

Rute yang lebih cocok:

• Ingin lebih mudah: Pilih salah satu dari tiga opsi pada Rute B (ShortPixel / Imagify / TinyPNG).
• Jika ingin gratis: Pilih Rute A (Plus WebP + EWWW), tetapi disarankan untuk mulai menilai risikonya dengan “Mode Konservatif (tidak menghapus gambar asli)”.

Perangkap umum:

• Gambar di bagian atas artikel sangat besar, dan strategi lazy loading-nya tidak tepat.Itu akan memperlambat layar pertama.

4.2 E-commerce/Situs Produk (banyak gambar thumbnail, banyak varian gambar, stabilitas menjadi prioritas utama)

Masalah paling umum dalam e-commerce bukanlah “efek kompresi yang buruk”, tetapi “ukuran tertentu yang salah setelah dioptimalkan, thumbnail yang hilang, dan komponen front-end yang tidak bisa mengambil gambar”.

Saran prioritas:

1. Pertama, tetaplah stabil: gunakan strategi kompresi yang lebih konservatif, jangan langsung melakukan penggantian seluruh database.
2. Menilai ukuran thumbnail: Tema e-commerce biasanya menghasilkan lebih banyak ukuran, dan konsumsi kuota akan meningkat (ShortPixel/TinyPNG sangat jelas).
3. Lakukan verifikasi skala kecil terlebih dahulu sebelum melakukan produksi massal (ini sangat penting).

Rute yang lebih cocok:

• Rute B biasanya lebih mudah: ShortPixel/Imagify/TinyPNG semuanya dapat digunakan secara batch. Yang terpenting, Anda harus memahami mekanisme kuota dan menilai biayanya terlebih dahulu.
• Rute A juga bisa, tetapi perlu lebih berhati-hati terhadap perilaku Plus WebP dalam “mengganti ID/menghapus gambar asli/mengganti URL”: ini termasuk migrasi aset, dan tidak disarankan untuk mengganti semuanya sekaligus.

4.3 Portofolio/stasiun fotografi (kualitas gambar tunggal sensitif, gambar besar, dan memiliki tuntutan tinggi terhadap kesan visual)

Saran prioritas:

1. Strategi ukuran (kontrol area tampilan)
2. Strategi kompresi (lebih baik terlalu besar daripada merusak detailnya).
3. WebP/AVIF (manfaatnya sangat jelas untuk gambar besar, tetapi perlu memverifikasi kualitas tampilannya)

Rute yang lebih cocok:

• Imagify: Menggunakan opsi “Ukuran Asli” untuk memotong kuota, situs-situs ini lebih mudah untuk “mengontrol anggaran” (Anda tahu berapa banyak kira-kira yang akan dipotong untuk setiap gambar besar), tetapi hindari terus-menerus menekan gambar tersebut berulang kali.
• \nShortPixelJika ukuran thumbnail tidak banyak, kreditnya juga cukup jelas; tetapi jika Anda menghasilkan banyak ukuran + next-gen, konsumsi kredit akan meningkat, sehingga perlu direncanakan terlebih dahulu.

5. Perbandingan kuota/tagihan: Jelaskan secara detail apakah “gratis itu cukup” atau tidak.

Mana yang lebih menguntungkan, dan berapa lama gratisnya?

5.1 Tiga model penagihan biaya.

• \nShortPixel(Kredit): Kredit dihitung berdasarkan “jumlah gambar asli + thumbnail”; membuat WebP/AVIF akan mengurangi kredit tambahan untuk setiap versi yang sesuai.
• Imagify(Kuota MB): Pengurangan kuota berdasarkan “Ukuran file asli”; semakin banyak gambar thumbnail, semakin banyak pengurangan kuota; kompresi 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 perkiraan cepat.

Kamu bisa memperkirakannya seperti ini:

1. Pilih saja salah satu “gambar asli yang sering kamu unggah”, lalu lihat ukurannya secara kasar (misalnya 300 KB / 1 MB / 3 MB).
2. Lihat berapa banyak ukuran thumbnail yang dihasilkan oleh situs Anda (misalnya, 5 / 10 / 20).
3. Memutuskan apakah kamu ingin menghasilkan WebP/AVIF (ya/tidak)

Kemudian, gunakan “perhitungan mental” di bawah ini untuk memahami konsumsinya:

• \nShortPixel: Setiap gambar≈ (1 + jumlah thumbnail) kredit; jika menghasilkan WebP/AVIF, ≈ dua kali lipat lagi (karena versi generasi berikutnya juga membutuhkan kredit)
• Imagify: Setiap gambar≈ (ukuran gambar asli + ukuran masing-masing gambar thumbnail) akan mengurangi kuota; mengubah tingkat kompresi dan mengompres ulang akan mengurangi kuota lagi
• TinyPNG: 500 kredit gratis; jika situs Anda menghasilkan banyak gambar dengan berbagai ukuran dan mengaktifkan konversi, jumlah kredit gratis akan turun secara signifikan (halaman plugin memberikan ekspektasi intuitif sebesar “sekitar 100 gambar/bulan” dan “sekitar 50 gambar/bulan”).

6. Peringatan Risiko

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

Ini adalah “sumber bencana” yang paling umum.”

• Rute A:Plus WebP atau AVIF + EWWW.(Kedua hal tersebut memiliki tugas yang berbeda, jangan lakukan konversi dan pengiriman yang sama secara bersamaan, atau hanya instal salah satunya saja.)
• Rute B: ShortPixel / Imagify / TinyPNG Pilih salah satu dari tiga.(Pilih salah satu yang bertanggung jawab untuk kompresi dan generasi berikutnya.)

Risiko 2: “Cakupan ID / Hapus gambar asli / Ganti URL” di Plus WebP termasuk dalam migrasi aset.

Sekali lagi:Plus WebP. Deskripsi tersebut secara jelas menyatakan bahwa ketika menghasilkan secara penuh, ID gambar asli akan diganti, file asli akan dihapus, dan URL konten akan diganti.
Ini berarti itu bukan “pengaturan kecil yang dapat dibatalkan kapan saja”, tetapi perubahan pada level aset.

Strategi yang disarankan seharusnya adalah:

• Pertama, lakukan uji coba kecil (dari puluhan hingga ratusan foto).
• Konfirmasi bahwa tampilan halaman depan, thumbnail, dan pembaruan cache semuanya berfungsi normal.
• Pertimbangkan lagi untuk memproses seluruh database.

Risiko 3: Konsumsi sebenarnya dari “kuota gratis” cloud tergantung pada jumlah thumbnail dan pilihan generasi berikutnya.

• \nShortPixel: Thumbnail dan next-gen akan memengaruhi kredit secara signifikan.
• TinyPNG: Mengaktifkan WebP/AVIF akan mengurangi kredit tambahan untuk setiap ukuran gambar.
• Imagify: Dikurangi berdasarkan ukuran gambar asli. Semakin banyak gambar thumbnail, semakin banyak pengurangannya. Kompresi ulang akan mengakibatkan pengurangan berulang.

Risiko 4: “Menghasilkan WebP/AVIF” tidak sama dengan “Menampilkan WebP/AVIF di layar”.”

Banyak orang merasa bahwa “tidak ada perubahan yang cepat” setelah melakukan konversi. Hal ini disebabkan oleh antarmuka pengguna yang masih menghasilkan JPG/PNG (jika salah satu dari cache/tulis ulang/tag/negosiasi browser tidak berjalan dengan baik).

7. Setelah selesai, bagaimana cara memverifikasi apakah itu sudah berlaku?

4 poin verifikasi yang sangat sederhana:

1. Saat halaman yang sama di-refresh untuk kedua kalinya, apakah pemuatannya lebih stabil dan lebih cepat?(Perasaan bahwa caching dan optimasi berfungsi atau tidak)
2. Apakah ukuran gambar yang dimuat di ponsel dan desktop berbeda secara signifikan?\n (Responsif) \nsrcset/ukuran Apakah itu berhasil?
3. Periksa beberapa gambar: apakah ada file/sumber daya WebP atau AVIF?(Apakah situs ini benar-benar digunakan?) Generasi berikutnya）
4. \nPeriksa beberapa gambar secara acak: perbesar untuk melihat apakah gambar tersebut terlihat buram, dan apakah teksnya tidak jelas.(Apakah kualitas kompresinya terlalu tinggi?)

Jika keempat hal ini sesuai, itu berarti rute yang kamu pilih sudah berjalan. Selanjutnya, lakukan hal-hal lainnya. CDN “lapisan pengiriman”, secara keseluruhan akan lebih stabil.

8 Rekomendasi tindakan.

1. Pilih rute terlebih dahulu:

• Aku ingin melakukannya sebisa mungkin secara gratis.+ WebP atau AVIF + EWWW (atau hanya menginstal salah satunya)
• Ingin menghemat sumber daya server dan membayar sesuai batasan, itu lebih praktis.: Pilih salah satu dari tiga opsi, yaitu ShortPixel, Imagify, atau TinyPNG.

2. Pertama, lakukan tes skala kecil (beberapa puluh lembar).
3. Konfirmasi tidak ada masalah, lalu lakukan pemrosesan massal.
4. Perlu meningkatkan stabilitas pengiriman lebih lanjut:\nBaca. Akselerasi CDN.

masalah umum

1. Sebenarnya, berapa banyak plugin yang harus saya instal? Bisakah saya menginstal semuanya?

Cobalah untuk hanya mengikuti satu rute.

• Rute A: Plus WebP atau AVIF + EWWW Image Optimizer (atau hanya menginstal salah satunya)
• Rute B: Pilih salah satu dari tiga opsi, yaitu ShortPixel, Imagify, atau TinyPNG.
  Membiarkan beberapa plugin melakukan “kompresi/konversi WebP/AVIF/ubah URL/penulisan ulang pengiriman” secara bersamaan di stasiun yang sama, sangat mudah membuat keadaan semakin rumit dan sulit untuk menyelidikinya.

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

Perlu dibedakan:
“Mendukung unggahan/penggunaan” ≠ “konversi otomatis/pengiriman otomatis”.
WordPress 6.5 juga tidak akan secara otomatis mengonversi batch JPG/PNG lama menjadi WebP/AVIF, dan juga tidak akan secara otomatis membantu Anda melakukan tautan lengkap “mengeluarkan AVIF/WebP sesuai kemampuan browser dan mundur”. Untuk membuat perpustakaan media lama juga ikut terbarui, biasanya diperlukan plugin atau layanan tambahan.

3. Langkah mana yang paling “menguntungkan” dalam optimasi gambar?

Biasanya, Pertama, pastikan “ukuran”-nya benar (srcset/sizes).。
Banyak situs yang lambat bukan karena tidak terkompresi, tetapi karena halaman hanya menampilkan 900px tetapi meminta pengguna mengunduh gambar asli berukuran 3000px. Kompresi dapat menghemat KB, tetapi “ukuran yang salah” akan membuat Anda mengunduh data beberapa kali lebih banyak dari yang diperlukan.

4. Bagaimana saya bisa memastikan bahwa yang sedang dimuat sekarang bukanlah “yang lebih kecil”, tetapi gambar asli itu sendiri?

Mari kita lihat dua fenomena ini:

• Saat membuka halaman di ponsel, ukuran gambar yang diunduh jelas lebih kecil daripada di desktop.
• Ukuran sumber daya yang dimuat oleh gambar yang sama berbeda pada perangkat yang berbeda.
  Jika Anda selalu mengunduh gambar asli, alasan umumnya adalah tema/pembangun menggunakan gambar tersebut sebagai latar belakang CSS atau output khusus, yang mengabaikan berbagai ukuran dan srcset di perpustakaan media.

5. Apakah “WebP/AVIF telah dihasilkan” berarti bahwa antarmuka pengguna pasti menghasilkan WebP/AVIF?

Itu tidak sama.
Generasi hanya menyelesaikan “lapisan file”; apakah antarmuka pengguna benar-benar mengirimkan WebP/AVIF, tergantung pada penulisan ulang, strategi tag gambar, apakah cache berhasil, dan apakah negosiasi browser berlaku. Setelah Anda selesai, pastikan untuk “memeriksa secara acak jenis sumber daya dari beberapa gambar”.

6. Sebenarnya, apa bahaya dari WebP atau AVIF? Bisakah saya menerapkannya ke seluruh basis data dengan satu klik?

Point risikonya bukanlah “kompresi”, tetapi...Perubahan pada tingkat migrasi aset.：

• Saat menghasilkan secara penuh, mungkin mengganti ID file gambar asli, menghapus file asli, dan mengganti URL dalam konten.
  Jadi,Tidak disarankan untuk mengganti seluruh database sekaligus.: Lakukan pengujian kecil terlebih dahulu (beberapa puluh hingga beberapa ratus gambar) + pastikan ada cadangan yang tersedia, lalu pertimbangkan untuk memproses seluruh database.

7. Bagaimana memilih di antara dua mode WebP: mempertahankan gambar asli vs menggantinya dan menghapus gambar asli?

Mengerti secara sederhana:

• Model 1: Pertahankan gambar asli + hasilkan salinan WebP/AVIF (lebih stabil)Mudah untuk membatalkan perubahan, tetapi ukuran disk akan bertambah (gambar asli + format baru + thumbnail dalam berbagai ukuran).
• Model 2: Mengganti dan menghapus gambar asli (lebih agresif)：Disk tidak mudah mengembang, tetapi jika Anda melakukan “mengubah aset + mengubah referensi”, biaya untuk menyelidiki masalah kompatibilitas akan lebih tinggi.
  Semakin kompleks situsnya (e-commerce/banyak plugin/berbagai ukuran), semakin disarankan untuk memulai dengan mode yang lebih stabil.

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

EWWW lebih seperti “kompresor yang bekerja secara lokal”: akan memakan CPU/IO.
Hal yang umum terjadi adalah peningkatan beban saat melakukan optimasi batch. Ini tidak berarti itu “tidak berhasil”, tetapi strateginya harus tepat: lakukan secara bertahap, pada saat puncak rendah, dan jika perlu, pilih solusi offloading/cloud.
Jika Anda menginginkan pengalaman yang mudah atau jika sumber daya server Anda terbatas, opsi B akan lebih hemat server.

9. ShortPixel memberikan 100 kredit gratis per bulan, jadi mengapa saya merasa hanya beberapa gambar saja yang tersisa?

Karena “Kredit” bukanlah "jumlah gambar".”Ini akan diperkecil menjadi thumbnail dan diperbesar ke generasi berikutnya:

• Gambar asli + setiap thumbnail dihitung sebagai kredit.
• Jika menghasilkan WebP/AVIF, setiap versi yang sesuai akan mengonsumsi kredit tambahan.
  Jadi, kamu mungkin mengira itu “1 gambar”, tetapi sebenarnya itu mungkin menghabiskan hampir “kredit dua digit”. ShortPixel

10. Imagify menawarkan 20MB/bulan secara gratis, lalu kenapa juga cepat habis?

Imagify lebih mirip dengan “paket data”:

• Selain itu, saya ingin mengucapkan terima kasih atas semua bantuan Anda dalam hal ini.Ukuran file asli.\nKuota pengurangan
• Semakin banyak thumbnail, semakin banyak sumber daya yang dikonsumsi.
• Mengubah level kompresi dan mengoptimalkannya kembali akan memakan kuota lagi.
• Menggunakan API Key yang sama untuk beberapa situs, dengan kuota yang dibagikan.
  Jadi, “20MB cepat habis” sering kali disebabkan oleh gambar yang terlalu besar, terlalu banyak gambar pratinjau, atau karena terus-menerus mencoba dan gagal.

11. TinyPNG gratis dengan 500 kredit/bulan, mengapa plugin mengatakan hanya sekitar 100 gambar/bulan, dan setelah mengaktifkan WebP/AVIF, jumlahnya malah menjadi 50 gambar/bulan?

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

• Instalasi WordPress biasa mengompres sekitar 100 gambar per bulan.
• Mengaktifkan konversi AVIF atau WebP:Setiap ukuran gambar akan mengonsumsi satu kredit tambahan.Jadi, kira-kira hanya bisa mengompres dan mengonversi sekitar 50 gambar per bulan (tergantung pada ukuran dan jumlah gambar thumbnail).
  Jadi, 500 kredit ≠ 500 gambar.

12. Sebenarnya, berapa banyak gambar thumbnail yang ada di halaman saya? Mengapa itu sangat berpengaruh?

Di WordPress, mengunggah gambar akan menghasilkan beberapa ukuran; tema/plugin (terutama untuk e-commerce) mungkin juga menambahkan ukuran lainnya.
Kredit/kuota untuk kompresi gambar biasanya dihitung berdasarkan “gambar asli + thumbnail”, jadi semakin banyak thumbnail yang ada, semakin cepat kuota gratis tersebut habis.

13. Apakah lazy loading pasti bisa mempercepat? Mengapa ada yang bilang lazy loading malah memperlambat?

Lazy loading cocok untuk “sumber daya di luar layar”.
Jika gambar besar yang paling penting di layar pertama juga ditunda untuk dimuat, itu mungkin memperlambat pengalaman di layar pertama. Lazy loading secara default tidak masalah di WordPress 5.5, tetapi jangan terapkan secara sembarangan.

14. Jika saya menggunakan rute A atau B, kapan saya perlu menggunakan CDN / CDN gambar?

Kompresi, ukuran, dan format menyelesaikan masalah “file yang lebih kecil dan lebih cocok”;
CDN mengatasi masalah pengiriman yang lebih cepat dan lebih stabil.。
Ketika gambar diambil dari sumber jarak jauh yang mengakibatkan penundaan yang jelas, menggunakan CDN/CDN gambar (seperti Cloudflare Polish / Jetpack Site Accelerator) secara keseluruhan akan lebih stabil. Baca selengkapnya Akselerasi CDN WordPress.。

15. Setelah selesai, metode paling sederhana apa yang bisa saya gunakan untuk memverifikasi apakah itu benar-benar berhasil?

Metode verifikasi paling hemat waktu:

• Saat halaman yang sama di-refresh untuk kedua kalinya, apakah pemuatannya lebih stabil dan lebih cepat?
• Apakah ukuran gambar yang dimuat di ponsel dan desktop sangat berbeda (apakah srcset/sizes berfungsi)?
• Periksa beberapa gambar: apakah ada file/sumber daya WebP atau AVIF?
• \nPeriksa beberapa gambar secara acak: perbesar untuk melihat apakah gambar tersebut terlihat buram, dan apakah teksnya tidak jelas.