Clouder

Cara Mempercepat Website WordPress dan Lolos Core Web Vitals

Oleh Tim Clouder ·

Website WordPress Anda terasa lambat, skor PageSpeed Insights merah, dan Search Console melaporkan URL "Perlu ditingkatkan". Mencari cara mempercepat website WordPress biasanya berujung pada daftar 30 plugin optimasi yang malah saling bertabrakan. Pendekatan yang lebih efektif: ukur dulu metrik yang benar, temukan penyebab terbesarnya, lalu perbaiki dari lapisan paling bawah (server) ke atas (tema dan konten).

Panduan ini memakai Core Web Vitals sebagai patokan, karena metrik inilah yang dipakai Google untuk menilai pengalaman pengguna nyata. Anda akan mempelajari ambang batas LCP, INP, dan CLS, cara membaca data PageSpeed Insights dengan benar, serta langkah optimasi yang berdampak paling besar, mulai dari TTFB dan cache hingga gambar dan audit plugin.

Core Web Vitals: LCP, INP, dan CLS beserta ambang batasnya

Core Web Vitals terdiri dari tiga metrik. Sejak Maret 2024, INP menggantikan FID sebagai metrik interaktivitas. Ambang berikut bersumber dari web.dev dan dinilai pada persentil ke-75 kunjungan, dipisahkan antara mobile dan desktop. Artinya, 75% kunjungan harus memenuhi angka "baik" agar halaman dianggap lolos.

Largest Contentful Paint (LCP) — kecepatan muat

Waktu sampai elemen terbesar di layar (biasanya gambar hero, banner, atau judul besar) selesai ditampilkan.

  • Baik: 2,5 detik atau kurang
  • Perlu ditingkatkan: lebih dari 2,5 detik hingga 4 detik
  • Buruk: lebih dari 4 detik

Interaction to Next Paint (INP) — responsivitas

Seberapa cepat halaman merespons klik, ketukan, dan ketikan sepanjang kunjungan, diwakili oleh salah satu interaksi paling lambat.

  • Baik: 200 milidetik atau kurang
  • Perlu ditingkatkan: lebih dari 200 ms hingga 500 ms
  • Buruk: lebih dari 500 ms

Cumulative Layout Shift (CLS) — stabilitas visual

Seberapa banyak elemen bergeser tiba-tiba saat halaman dimuat, misalnya tombol yang turun karena iklan baru muncul di atasnya.

  • Baik: 0,1 atau kurang
  • Perlu ditingkatkan: lebih dari 0,1 hingga 0,25
  • Buruk: lebih dari 0,25

Core Web Vitals adalah bagian dari sinyal page experience Google. Pengaruhnya pada ranking nyata tetapi tidak mengalahkan relevansi konten. Dampak yang lebih langsung justru pada bisnis: pengunjung mobile cenderung meninggalkan halaman yang lambat sebelum sempat melihat produk Anda.

Cara mengukur kecepatan website WordPress dengan benar

Data lapangan vs data lab di PageSpeed Insights

Saat Anda memasukkan URL ke PageSpeed Insights, ada dua bagian yang sering tertukar:

  • Data lapangan (field data) di bagian atas berasal dari Chrome User Experience Report (CrUX): pengalaman pengguna Chrome sungguhan selama 28 hari terakhir. Inilah yang dipakai untuk penilaian Core Web Vitals.
  • Data lab (skor 0–100 dari Lighthouse) adalah simulasi satu kali muat dengan perangkat dan jaringan yang diperlambat. Berguna untuk diagnosis, tetapi bukan nilai yang dipakai Google.

Website kecil sering tidak punya cukup trafik untuk muncul di CrUX. Dalam kondisi itu, andalkan data lab dan laporan Core Web Vitals di Search Console (yang mengelompokkan URL serupa), serta ukur sendiri dengan library web-vitals atau panel Performance di Chrome DevTools.

Kebiasaan mengukur yang baik

  • Uji halaman yang penting, bukan hanya beranda: halaman produk, artikel populer, halaman checkout.
  • Fokus pada hasil mobile. Mayoritas pengunjung di Indonesia memakai ponsel, dan hasil mobile hampir selalu lebih buruk.
  • Ulangi pengujian lab 3 kali dan lihat kecenderungannya. Skor Lighthouse bisa bergeser beberapa poin antarpengujian.
  • Setelah perbaikan, data lapangan butuh hingga 28 hari untuk mencerminkan perubahan sepenuhnya.

Mulai dari server: TTFB, lokasi server, dan versi PHP

Time to First Byte (TTFB) adalah waktu sampai browser menerima byte pertama dari server. TTFB bukan Core Web Vitals, tetapi semua metrik lain menunggu TTFB. Jika server butuh 1,5 detik hanya untuk mulai menjawab, mustahil mencapai LCP 2,5 detik di jaringan seluler. Sebagai patokan kasar, web.dev menyarankan TTFB sekitar 0,8 detik atau kurang.

Cek TTFB dari terminal:

curl -o /dev/null -s -w "TTFB: %{time_starttransfer}s\n" https://tokoanda.id/

Lokasi server dan latensi

Setiap koneksi HTTPS baru butuh beberapa kali bolak-balik antara browser dan server. Jika pengunjung Anda di Indonesia tetapi server di Amerika Serikat, setiap bolak-balik bisa memakan lebih dari 200 ms; dari server di Indonesia atau Singapura, angkanya jauh lebih kecil. Untuk website yang targetnya pasar lokal, lokasi server adalah optimasi termurah. Pertimbangan ini dibahas lebih lengkap di cara memilih hosting.

Versi PHP dan OPcache

WordPress ditulis dengan PHP, dan setiap versi mayor PHP 8 membawa peningkatan performa serta perbaikan keamanan. Gunakan versi PHP 8 yang masih mendapat dukungan aktif atau security update, setelah memastikan tema dan plugin Anda kompatibel (uji dahulu di staging).

OPcache menyimpan hasil kompilasi skrip PHP di memori, sehingga file tidak perlu di-parse ulang di setiap request. Di sebagian besar hosting, OPcache sudah aktif. Jika Anda mengelola server sendiri, pengaturan dasar berikut biasanya cukup:

opcache.enable=1
opcache.memory_consumption=128
opcache.max_accelerated_files=10000
opcache.validate_timestamps=1
opcache.revalidate_freq=60

Sumber daya dan isolasi akun

Pada shared hosting, website lain di server yang sama bisa ikut memengaruhi kecepatan jika sumber daya tidak dibatasi per akun. Pilih hosting yang mengisolasi setiap website di bawah user Linux sendiri dengan kuota CPU, RAM, disk, dan inode yang jelas. Kuota inode juga penting untuk WordPress, karena cache dan thumbnail menghasilkan ribuan file kecil; baca penjelasan kapasitas dan inode.

Caching: optimasi dengan dampak terbesar

Tanpa cache, setiap kunjungan membuat WordPress menjalankan PHP dan puluhan query database untuk menghasilkan halaman yang sama. Ada beberapa lapisan cache, dan masing-masing menyelesaikan masalah berbeda.

Page cache

Menyimpan halaman HTML yang sudah jadi, lalu menyajikannya langsung tanpa menjalankan PHP. Ini biasanya menurunkan TTFB paling drastis. Pilihannya:

  • Cache di level server (misalnya FastCGI cache Nginx atau LiteSpeed Cache di server LiteSpeed) — paling cepat karena tidak menyentuh PHP sama sekali.
  • Plugin page cache seperti WP Super Cache, W3 Total Cache, atau WP Rocket — membuat file HTML statis dari dalam WordPress.

Pakai satu solusi page cache saja. Dua plugin cache aktif bersamaan adalah penyebab umum halaman rusak dan konten basi. Kecualikan halaman keranjang, checkout, dan akun WooCommerce dari page cache.

Object cache

Menyimpan hasil query database di memori (Redis atau Memcached). Paling terasa untuk halaman yang tidak bisa di-cache penuh: dashboard admin, toko online dengan pengguna login, dan forum.

Browser cache

Header Cache-Control membuat browser menyimpan file statis (gambar, CSS, JS, font) sehingga kunjungan berikutnya tidak mengunduh ulang. Contoh Nginx:

location ~* \.(css|js|webp|avif|jpg|png|svg|woff2)$ {
    expires 30d;
    add_header Cache-Control "public";
}

Optimasi gambar: WebP, AVIF, ukuran, dan lazy load

Pada banyak website WordPress, elemen LCP adalah gambar. Mengoptimasi gambar sering kali langsung memindahkan LCP dari "buruk" ke "baik".

Format WebP dan AVIF

WebP dan AVIF menghasilkan file yang jauh lebih kecil daripada JPEG/PNG pada kualitas visual setara, dan keduanya didukung browser modern. WordPress sudah bisa menerima unggahan WebP sejak versi 5.8 dan AVIF sejak versi 6.5 (selama library gambar di server mendukungnya). Plugin konversi gambar bisa mengubah koleksi lama secara massal.

Ukuran yang tepat

  • Jangan mengunggah foto 4000 piksel dari kamera untuk ditampilkan selebar 800 piksel. Perkecil sebelum diunggah.
  • WordPress membuat beberapa ukuran gambar dan atribut srcset, sehingga browser memilih ukuran yang sesuai layar. Pastikan tema memakai fungsi gambar bawaan WordPress, bukan URL gambar penuh yang di-hardcode.

Lazy load yang benar

WordPress menambahkan loading="lazy" secara otomatis pada gambar. Masalahnya, jika gambar hero di bagian atas halaman ikut di-lazy-load, LCP justru melambat. WordPress versi baru sudah berusaha tidak me-lazy-load gambar pertama dan menambahkan fetchpriority="high" pada gambar yang kemungkinan menjadi LCP, tetapi tema atau plugin bisa menimpanya. Periksa elemen LCP di PageSpeed Insights, lalu pastikan gambar itu:

<img src="hero.webp" width="1200" height="600" fetchpriority="high" alt="...">

tanpa loading="lazy".

Cegah layout shift (CLS)

  • Selalu cantumkan atribut width dan height pada gambar dan video agar browser menyiapkan ruangnya.
  • Sediakan ruang tetap untuk slot iklan, banner cookie, dan embed.
  • Untuk web font, gunakan font-display: swap dan host font secara lokal agar tidak menunggu server pihak ketiga.

Audit plugin, tema, dan JavaScript (kunci INP)

INP yang buruk hampir selalu disebabkan oleh JavaScript berlebihan yang membuat main thread browser sibuk. Di WordPress, sumbernya biasanya plugin dan page builder.

Cara mengaudit plugin

  1. Catat semua plugin aktif dan tanyakan: apakah fitur ini masih dipakai? Bisakah digantikan fungsi bawaan WordPress atau tema?
  2. Pasang plugin diagnostik seperti Query Monitor di staging untuk melihat plugin mana yang paling banyak query database atau paling lama dieksekusi.
  3. Di DevTools, buka tab Coverage untuk melihat berapa banyak CSS/JS yang dimuat tetapi tidak dipakai.
  4. Nonaktifkan plugin satu per satu di staging dan ukur ulang.

Tersangka umum: slider di beranda, plugin chat dan popup, pixel pelacakan ganda, plugin social share yang memuat script dari banyak jaringan, serta page builder yang memuat seluruh library di setiap halaman.

Mengurangi beban JavaScript

  • Tunda (defer) script yang tidak dibutuhkan untuk tampilan awal, seperti widget chat atau pelacak.
  • Muat script plugin hanya di halaman yang memerlukannya. Misalnya, script formulir kontak cukup dimuat di halaman kontak.
  • Pertimbangkan tema yang ringan atau tema blok (Full Site Editing) yang memuat CSS sesuai blok yang dipakai.

Ingat bahwa jumlah plugin bukan satu-satunya ukuran. Satu plugin berat bisa lebih merugikan daripada sepuluh plugin kecil yang ditulis dengan baik.

CDN dan pembersihan database

Kapan CDN membantu

CDN menyimpan salinan file statis (dan opsional halaman HTML) di server yang tersebar di banyak kota, sehingga dikirim dari lokasi terdekat pengunjung. CDN paling berguna jika pengunjung Anda tersebar lintas wilayah atau negara, atau jika gambar Anda banyak. Cloudflare menyediakan paket gratis yang bisa dihubungkan dengan mengganti nameserver domain. Jika semua pengunjung berada di Indonesia dan server sudah dekat, dampaknya lebih kecil tetapi tetap membantu mengurangi beban server. Setelah memindahkan nameserver, Anda bisa memverifikasinya dengan alat DNS lookup.

Membersihkan database WordPress

Database yang membengkak memperlambat query, terutama di halaman yang tidak ter-cache. Yang biasanya perlu dibersihkan:

  • Revisi post yang menumpuk. Batasi jumlahnya di wp-config.php:
define( 'WP_POST_REVISIONS', 5 );
  • Transient kedaluwarsa dan komentar spam.
  • Opsi autoload yang besar dari plugin yang sudah dihapus. Semua opsi autoload dimuat di setiap request. Cek ukurannya dengan WP-CLI:
wp transient delete --expired
wp db query "SELECT option_name, LENGTH(option_value) AS size FROM wp_options WHERE autoload IN ('yes','on') ORDER BY size DESC LIMIT 10;"

Sesuaikan prefix tabel wp_ dengan milik Anda, dan selalu buat backup database sebelum menghapus apa pun.

Checklist mempercepat website WordPress

  • Ukur LCP, INP, dan CLS di PageSpeed Insights untuk halaman penting, versi mobile.
  • TTFB sekitar 0,8 detik atau kurang; server dekat dengan mayoritas pengunjung.
  • PHP 8 versi yang masih didukung, OPcache aktif.
  • Satu solusi page cache, halaman keranjang/checkout dikecualikan.
  • Object cache (Redis) untuk toko online atau situs dengan banyak pengguna login.
  • Gambar dalam WebP/AVIF, ukuran sesuai tampilan, width dan height tercantum.
  • Gambar LCP tidak di-lazy-load dan memakai fetchpriority="high".
  • Plugin yang tidak dipakai dihapus, bukan sekadar dinonaktifkan.
  • Script pihak ketiga ditunda atau hanya dimuat di halaman yang perlu.
  • CDN aktif jika pengunjung tersebar atau gambar banyak.
  • Revisi dibatasi, transient dan autoload dibersihkan berkala.
  • Ukur ulang setelah setiap perubahan, satu perubahan dalam satu waktu.

Pertanyaan yang sering diajukan

Berapa skor PageSpeed Insights yang dianggap bagus?

Skor 90–100 dari Lighthouse tergolong baik, tetapi skor itu hasil simulasi. Yang lebih penting adalah data lapangan: LCP 2,5 detik atau kurang, INP 200 ms atau kurang, dan CLS 0,1 atau kurang pada persentil ke-75.

Apakah plugin cache saja cukup untuk mempercepat WordPress?

Plugin cache biasanya memberi lonjakan terbesar karena menurunkan TTFB, tetapi tidak memperbaiki gambar yang terlalu besar atau JavaScript yang berat. Untuk lolos Core Web Vitals, cache perlu digabung dengan optimasi gambar dan audit plugin.

Kenapa skor mobile jauh lebih rendah daripada desktop?

Pengujian mobile di Lighthouse mensimulasikan ponsel kelas menengah dengan CPU dan jaringan yang diperlambat. JavaScript yang terasa ringan di laptop bisa memblokir main thread lama di ponsel, sehingga INP dan LCP memburuk.

Apakah shared hosting bisa lolos Core Web Vitals?

Bisa. Banyak website WordPress di shared hosting lolos Core Web Vitals selama server dekat dengan pengunjung, PHP terbaru, cache aktif, dan sumber daya tiap akun terisolasi. VPS baru diperlukan jika trafik atau beban dinamis memang melebihi kuota paket.

Berapa lama perbaikan terlihat di Search Console?

Laporan Core Web Vitals di Search Console berbasis data CrUX 28 hari, jadi perubahan baru terlihat penuh setelah sekitar empat minggu. Data lab di PageSpeed Insights langsung berubah begitu perbaikan diterapkan.

Langkah berikutnya

Kecepatan WordPress dibangun dari fondasi: server yang dekat dengan pengunjung, PHP terbaru, dan cache yang benar. Jika Anda ingin memulai dari fondasi itu, lihat paket hosting kami dengan Nginx, PHP 8, integrasi Cloudflare, dan isolasi per website, atau cek penawaran terbaru di halaman promo.