Membuat Gambar WordPress Cepat: Web Vitals dan WebP

Terakhir diperbarui: June 28, 2026

Ini adalah pendamping yang berfokus pada kecepatan untuk panduan optimasi gambar WordPress saya untuk tahun 2026 . Panduan itu membahas pengaturan secara luas: plugin, srcset, CDN, dan htaccess. Yang ini mempersempit fokus ke satu pertanyaan: bagaimana cara membuat gambar WordPress cukup cepat sehingga Core Web Vitals berubah menjadi hijau? Saya mengukur setiap langkah di blog saya sendiri yang banyak menggunakan media, dan keberhasilan berikut adalah hal-hal yang benar-benar memindahkan Largest Contentful Paint dari 3.8s menjadi 1.1s.

Jawaban singkat: apa yang membuat gambar WordPress cepat?

Kompres setiap gambar ke WebP sebelum unggah, batasi lebar tampilannya agar browser tidak pernah mengunduh file 4000px untuk slot 400px, lakukan lazy-load pada semua konten di bawah lipatan (below the fold), dan pasang CDN di depan /wp-content/uploads/. Di blog saya sendiri, keempat langkah ini memangkas total berat gambar sebesar 84 persen dan menurunkan LCP mobile dari 3.8s menjadi 1.1s. Largest Contentful Paint pada blog WordPress hampir selalu adalah sebuah gambar, jadi inilah tempat kecepatan itu berada.

Mengapa gambar WordPress mendominasi Core Web Vitals Anda?

Core Web Vitals menilai kecepatan yang dirasakan, dan yang paling sering gagal di WordPress adalah Largest Contentful Paint, yang untuk situs konten biasanya adalah gambar hero atau gambar inline pertama. Saya menjalankan PageSpeed Insights pada 40 postingan saya sendiri dan elemen LCP adalah gambar di 37 di antaranya.

Gambar juga mendorong metrik lain secara tidak langsung:

• Hero berukuran 4MB memblokir LCP sampai selesai diunduh pada jaringan Slow 4G.
• Pergeseran tata letak (Layout shift) melonjak ketika gambar tiba tanpa lebar dan tinggi.
• INP menderita ketika antrian gambar raksasa melumpuhkan main thread saat parsing.

Google mengukur ini dari pengguna Chrome nyata dan menggabungkannya menjadi sinyal peringkat pencarian, didokumentasikan di web.dev fast loading guidance. Perbaikannya jarang ada pada server. Itu hampir selalu pada gambar-gambarnya.

Berapa banyak berat gambar yang bisa Anda pangkas?

Saya mencatat angkanya di satu blog sebelum dan setelah optimasi. Postingan yang sama, konten yang sama, hanya gambarnya yang berubah.

Penurunan dari 9.4MB menjadi 1.1MB bukanlah kasus khusus. Ini adalah apa yang terjadi ketika Anda berhenti mengirimkan JPEG tanpa kompresi pada resolusi asli. Pengungkit terbesar tunggal adalah format dan dimensi, yang dijelaskan dalam panduan optimize images for web speed metrik demi metrik.

Apa itu LCP dan mengapa hampir selalu gambar?

Largest Contentful Paint menandai momen elemen terlihat terbesar dirender. Pada blog WordPress, elemen itu adalah foto hero, gambar unggulan (featured image), atau gambar inline besar pertama — bukan teks. Sampai gambar itu diunduh, didekodekan, dan dilukis, halaman tersebut dibaca sebagai "masih memuat" oleh pengguna dan Google.

Tiga hal memperpanjang LCP gambar, dan saya memeriksa ketiga-tiganya dalam setiap audit:

• File terlalu besar untuk viewport yang diisinya.
• Gambar LCP secara keliru di-lazy-load, sehingga dimulai terlambat.
• Tidak ada CDN, jadi file tersebut melakukan perjalanan dari satu asal (origin) di sisi dunia lain.

Dua hal terakhir adalah kesalahan konfigurasi yang dapat Anda perbaiki dalam hitungan menit. Yang pertama adalah kebiasaan mengunggah, dibahas dalam image file size guide.

Format gambar mana yang tercepat untuk WordPress?

WebP. Ukurannya 25 hingga 35 persen lebih kecil dari JPEG pada kualitas visual yang setara, dan core WordPress telah mendukung pengunggahannya sejak versi 6.5. AVIF mengompresi sekitar 20 hingga 30 persen lebih kecil lagi, tetapi dukungan browser dan CDN masih tidak merata, jadi saya memperlakukannya sebagai lapisan peningkatan (enhancement layer) daripada dasar.

Saya mengompres ke WebP sebelum unggah dan membiarkan CDN menegosiasikan AVIF ke browser yang mendukungnya. Untuk perbandingan trade-off format secara mendalam, JPG PNG WebP comparison adalah referensi yang saya kirimkan kepada orang.

Bagaimana cara menyajikan ukuran gambar yang tepat untuk setiap perangkat?

Ini adalah keberhasilan yang sering dilewatkan orang. WordPress secara otomatis menghasilkan ukuran thumbnail, medium, large, dan intermediate, dan mengeluarkan srcset, tetapi hanya jika tema Anda memanggil wp_get_attachment_image() alih-alih melakukan hardcoding tag <img>. Ponsel seharusnya tidak pernah mengunduh file 2560px.

Markup yang dikeluarkan WordPress terlihat seperti ini:

<img
  src="hero-1536x800.webp"
  srcset="hero-768x400.webp 768w,
          hero-1200x628.webp 1200w,
          hero-1536x800.webp 1536w"
  sizes="(max-width: 768px) 100vw, 1200px"
  width="1536" height="800"
  alt="Foto hero Storefront pada lebar penuh">

Cara saya memverifikasinya berfungsi: buka DevTools, batasi ke Slow 4G, muat ulang, dan perhatikan tab Network. Ponsel seharusnya meminta file 768w. Jika setiap perangkat menarik URL yang sama, tema tersebut rusak atau pembuat halaman (page builder) melewati markup responsif. Logika breakpoint berada di panduan responsive image breakpoints.

Bagaimana cara mengaktifkan lazy loading di WordPress?

Sejak WordPress 5.5 setiap <img> mendapatkan loading="lazy" secara default, dan 6.1 menambahkan petunjuk fetchpriority="high" ke gambar besar pertama sehingga tidak lagi melawan lazy loader. Anda jarang membutuhkan plugin untuk ini lagi, yang merupakan kemenangan kecepatan nyata tanpa konfigurasi apa pun.

Dua aturan yang saya terapkan, karena keduanya pernah merugikan LCP saya sebelum saya menyadarinya:

• Jangan pernah melakukan lazy-load pada gambar LCP di atas lipatan (above the fold).
• Selalu atur lebar dan tinggi eksplisit untuk mencegah pergeseran tata letak.

[Dokumentasi lazy-loading WordPress] resmi mencantumkan filter untuk mengecualikan elemen LCP dan melakukan lazy-loading iframe. Untuk jebakan umum, termasuk kesalahan hero, baca tulisan kami tentang lazy load images.

Bagaimana CDN mempercepat gambar WordPress?

CDN menyajikan setiap gambar dari edge terdekat dengan pengunjung dan menghilangkan perjalanan bolak-balik (round-trips) ke origin Anda. Setelah saya memindahkan satu klien dari JPEG yang di-host di origin ke Cloudflare dengan Polish diaktifkan, TTFB gambar turun dari 420ms menjadi 60ms bagi pengunjung di Singapura dan Brasil — dua wilayah di mana laporan PageSpeed mereka berwarna merah.

Apa yang saya konfigurasikan di setiap situs:

• Cloudflare dengan Polish aktif, lossless ditambah WebP.
• Cache semua konten di bawah /wp-content/uploads/.
• Cache browser satu tahun untuk tipe MIME gambar.
• Lapisan AVIF yang dinegosiasikan oleh CDN di atas WebP.

Caching edge paling penting untuk toko WooCommerce yang banyak menggunakan gambar dan blog multi-penulis. Pengaturan lengkap, termasuk cache headers dan aturan pembersihan (purge rules), ada di image CDN guide.

Poin utama: tumpukan kecepatan empat langkah

Jika Anda tidak mengingat hal lain, ingatlah keempat ini, karena mereka bertanggung jawab atas penurunan LCP yang saya ukur:

1. Kompres ke WebP sebelum unggah, di bawah 200KB per gambar.
2. Batasi lebar tampilan dan biarkan srcset menyajikan file yang tepat.
3. Lakukan lazy-load di bawah lipatan (below the fold), jangan pernah pada gambar LCP.
4. Cache gambar di edge CDN dengan TTL satu tahun.

Lakukan ini, dan laporan Core Web Vitals Anda akan berubah menjadi hijau. Melewatkan langkah srcset responsif dan bahkan WebP yang terkompresi sempurna masih akan mengirim file desktop ke ponsel.

Daftar periksa kecepatan sebelum Anda menerbitkan

• Gambar LCP adalah WebP dan di bawah 200KB.
• Gambar LCP memiliki fetchpriority="high", bukan loading="lazy".
• srcset ada dan ponsel memuat file kecil.
• Setiap gambar memiliki lebar dan tinggi eksplisit.
• CDN melakukan cache pada /wp-content/uploads/.
• Cache browser untuk gambar diatur ke satu tahun.
• LCP mobile di bawah 2.5s di PageSpeed.
• CLS di bawah 0.1 tanpa pergeseran akibat gambar.

Satu peringatan nyata: WebP lossy pada kualitas di bawah 70 pada akhirnya akan merugikan Anda dalam fotografi produk dan layar retina tempat tekstur serta detail tepi menjual produk. Saya menyimpan setiap aslinya di penyimpanan cloud dan mengekspor ulang darinya, karena sekali Anda menimpa sumber dengan salinan lossy, detailnya hilang selamanya. Uji pada lima gambar nyata sebelum Anda mengkonversi massal seribu.

Kredit Gambar

• Ruang kerja cerah dengan komputer desktop yang digunakan untuk mengelola situs WordPress — foto oleh SHVETS Production di Pexels
• Kantor rumah yang nyaman dengan laptop terbuka di postingan blog WordPress — foto oleh Pixabay di Pexels
• MacBook menampilkan halaman pencarian Google di meja kayu di luar ruangan — foto oleh Pixabay di Pexels
• Programmer coding di laptop dan monitor di kantor modern — foto oleh Claudio Emanuel di Pexels