Object Cache WordPress untuk Publisher: Redis, Memcached, dan Cara Mempercepat Situs Tanpa Mengubah Tampilan

Situs WordPress yang lambat jarang disebabkan oleh satu hal saja. Sering kali penyebabnya adalah database yang dipanggil berulang-ulang untuk hal yang sama: opsi situs, data postingan, metadata, daftar istilah taksonomi, dan transient dari plugin. WordPress sebenarnya sudah punya mekanisme untuk mengurangi panggilan itu, yaitu object cache. Masalahnya, object cache bawaan WordPress tidak persisten — ia hanya hidup selama satu request, lalu dibuang. Setiap pengunjung baru memaksa server mengulang seluruh pekerjaan dari nol.

Di sinilah persistent object cache masuk: dengan Redis atau Memcached sebagai penyimpanan belakang, hasil query yang sudah dihitung sekali bisa dipakai kembali oleh request berikutnya, tanpa menyentuh database. Untuk situs publisher yang halamannya dinamis — dashboard admin yang sibuk, halaman arsip, pencarian internal, dan request REST API — perbedaan ini terasa nyata. Artikel ini menjelaskan cara kerja object cache WordPress, kapan ia benar-benar membantu, perbedaan Redis dan Memcached, serta langkah aman mengaktifkannya tanpa mengubah tampilan situs dan tanpa mengganggu iklan AdSense.

Poin Kunci

• Object cache bawaan WordPress (kelas WP_Object_Cache) hanya menyimpan data di memori PHP selama satu request, lalu dibuang — ia berguna untuk deduplikasi di dalam satu kali pemuatan halaman, bukan antar pengunjung.
• Persistent object cache membuat data hasil wp_cache_set() bertahan antar request dengan menyimpannya di Redis atau Memcached, lewat satu file drop-in bernama wp-content/object-cache.php.
• Object cache mempercepat request yang sampai ke PHP; ia bukan pengganti page cache, karena page cache menjawab request tanpa menjalankan PHP sama sekali.
• Redis adalah pilihan default yang paling aman untuk kebanyakan publisher: drop-in-nya aktif dipelihara, mendukung persistensi, dan punya kebijakan eviction yang fleksibel; Memcached masuk akal bila sudah terpasang dan sudah melayani hal lain di server yang sama.
• Tanpa persistent object cache, transient disimpan sebagai baris di tabel wp_options — pada situs dengan banyak plugin, ini bisa menjadi bottleneck database.
• Sejak WordPress 6.1, layar Site Health memberi rekomendasi memakai persistent object cache, tetapi rekomendasi itu hanya memeriksa ada-tidaknya drop-in, bukan mengukur performa situs Anda.
• Selalu cadangkan situs dan uji di staging sebelum mengaktifkan object cache; drop-in yang salah konfigurasi bisa membuat situs tidak bisa diakses sama sekali.

Daftar Isi

1. Apa Itu Object Cache WordPress dan Mengapa Bawaan WordPress Tidak Cukup
2. Perbedaan Object Cache, Page Cache, dan Opcode Cache
3. Kapan Publisher Butuh Persistent Object Cache — dan Kapan Tidak
4. Redis vs Memcached vs APCu: Mana yang Cocok untuk Publisher
5. Cara Kerja Drop-in object-cache.php
6. Cara Mengaktifkan Redis Object Cache di WordPress
7. Transient dan wp_options: Efek Samping yang Sering Terlewat
8. Pengaturan Penting: Eviction Policy, TTL, dan Key Salt
9. Cara Mengukur Apakah Object Cache Benar-Benar Membantu
10. Masalah Umum dan Cara Memperbaikinya
11. Object Cache dan Iklan AdSense: yang Perlu Diperhatikan
12. Checklist Sebelum dan Sesudah Mengaktifkan Object Cache
13. FAQ
14. Kesimpulan
15. Sumber resmi yang dirujuk

Apa Itu Object Cache WordPress dan Mengapa Bawaan WordPress Tidak Cukup

Setiap kali WordPress membangun sebuah halaman, ia melakukan puluhan hingga ratusan pencarian kecil ke database: membaca opsi situs, mengambil data postingan dan metadata-nya, memuat istilah kategori dan tag, memeriksa data pengguna, dan menjalankan query dari plugin. Tanpa cache, pencarian yang sama bisa diulang berkali-kali dalam satu request. Object cache adalah lapisan yang menyimpan hasil pencarian itu di memori, dengan pasangan kunci dan nilai, agar pencarian kedua untuk data yang sama tidak perlu kembali ke database.

WordPress menyediakan lapisan ini lewat kelas WP_Object_Cache dan fungsi-fungsi wp_cache_get(), wp_cache_set(), wp_cache_add(), dan wp_cache_delete(). Hampir semua operasi inti WordPress melewati API ini sebelum menyentuh database: get_option(), get_post_meta(), pencarian istilah, dan sejak WordPress 6.1, hasil query WP_Query juga ikut di-cache. Artinya, object cache bukan fitur tambahan — ia sudah bekerja di setiap instalasi WordPress, dan plugin yang ditulis dengan baik memanfaatkannya untuk menyimpan hasil perhitungan mahal.

Cara kerja WP_Object_Cache bawaan

Implementasi bawaan WP_Object_Cache sangat sederhana: ia menyimpan data dalam array PHP biasa di memori. Ketika kode memanggil wp_cache_set('kunci_saya', $data_mahal, 'grup_saya', 3600), data tersimpan di array tersebut dan bisa diambil kembali dengan wp_cache_get() selama request yang sama masih berjalan. Inilah yang membuat lima puluh panggilan get_option('siteurl') dalam satu pemuatan halaman hanya menghasilkan satu query database, bukan lima puluh.

Kelemahan implementasi ini ada pada satu kata: bawaan. Array PHP itu dibuat dari nol di awal setiap request dan dibuang begitu PHP selesai bekerja. Pengunjung berikutnya — bahkan pengunjung yang meminta halaman yang persis sama satu detik kemudian — memulai dengan cache kosong dan mengulang seluruh query dari database. Inilah yang dimaksud dengan non-persistent: cache-nya tidak bertahan antar request.

Untuk situs kecil dengan traffic rendah, ini bukan masalah besar. Database MySQL atau MariaDB modern sanggup menjawab ratusan query per halaman tanpa terasa lambat. Masalah muncul ketika situs tumbuh: puluhan plugin aktif, ribuan postingan, arsip yang dalam, widget yang menjalankan query kompleks, dan pengguna yang sedang login di wp-admin. Pada titik itu, query yang diulang-ulang menjadi beban nyata, dan waktu respons server (TTFB) mulai merangkak naik.

Masalahnya: cache hilang setiap request

Bayangkan sebuah halaman arsip kategori yang menampilkan 10 artikel, masing-masing dengan penulis, kategori, tag, jumlah komentar, dan gambar unggulan. WordPress dan tema akan menjalankan query untuk postingan, lalu query untuk metadata setiap postingan, lalu query untuk istilah, lalu query untuk data penulis. Dengan object cache non-persistent, semua hasil itu memang di-cache — tetapi hanya untuk request itu. Begitu halaman selesai dikirim, cache ikut hilang. Pengunjung berikutnya mengulang proses yang sama persis.

Persistent object cache memutus pola ini. Dengan penyimpanan belakang eksternal, nilai yang disimpan lewat wp_cache_set() tetap ada setelah request selesai, dan request berikutnya bisa mengambilnya lewat soket memori, bukan lewat SQL. Hasilnya: lebih sedikit query database, beban CPU database lebih ringan, dan TTFB yang lebih stabil pada jam-jam sibuk.

Perbedaan Object Cache, Page Cache, dan Opcode Cache

Kata “cache” di WordPress merujuk pada tiga lapisan yang berbeda, dan mencampuradukkannya adalah sumber kesalahpahaman yang paling umum. Ketiganya mempercepat bagian yang berbeda dari alur request, dan situs publisher yang sehat biasanya memakai ketiganya sekaligus.

Page cache adalah lapisan paling atas. Jika page cache mengenai (cache hit), server mengembalikan HTML yang sudah jadi tanpa menjalankan PHP dan tanpa menyentuh database — ini yang tercepat. Object cache bekerja satu tingkat di bawahnya: ketika page cache tidak mengenai (cache miss) dan PHP harus berjalan, object cache membuat eksekusi PHP itu lebih cepat dengan menyajikan query database dari memori. Opcode cache bekerja di tingkat paling bawah, memastikan PHP tidak mengompilasi ulang file yang sama berulang kali.

Implikasinya penting untuk ekspektasi Anda. Object cache tidak akan membuat halaman yang sudah di-cache oleh page cache menjadi lebih cepat, karena halaman itu tidak pernah sampai ke PHP. Manfaatnya muncul pada request yang memang harus menjalankan PHP: pengguna yang login, halaman keranjang dan checkout, wp-admin, pencarian internal, request REST API, dan halaman yang sengaja dikecualikan dari page cache. Jika hampir seluruh traffic Anda adalah pengunjung anonim yang membaca artikel — dan page cache Anda bekerja dengan baik — dampak object cache pada kecepatan halaman depan bisa jadi kecil. Tetapi dampaknya pada beban server dan pada kecepatan dashboard admin tetap nyata.

Kapan Publisher Butuh Persistent Object Cache — dan Kapan Tidak

Tidak semua situs butuh persistent object cache, dan memasangnya tanpa alasan yang jelas hanya menambah satu komponen yang bisa rusak. Gunakan panduan berikut untuk memutuskan.

Anda kemungkinan besar membutuhkannya bila:

• Dashboard wp-admin terasa lambat, terutama saat menyimpan postingan, membuka daftar postingan, atau mengelola media.
• Situs memakai banyak plugin yang gemar memakai transient — misalnya plugin SEO, plugin caching, atau Action Scheduler pada WooCommerce — sehingga tabel wp_options membengkak.
• Ada bagian situs yang dinamis dan tidak bisa di-page-cache: area anggota, formulir, pencarian, atau halaman dengan konten yang berubah per pengguna.
• Server sering mencapai batas koneksi database atau CPU database tinggi pada jam sibuk, padahal traffic belum luar biasa besar.
• Anda menjalankan multisite, di mana grup cache global seperti pengguna dan opsi situs dipakai bersama di seluruh jaringan.
• Layar Site Health menampilkan rekomendasi persistent object cache dan Anda sudah memeriksa bahwa sebagian traffic memang menjalankan PHP.

Anda kemungkinan besar belum membutuhkannya bila:

• Situs masih kecil, traffic rendah, dan page cache sudah menangani hampir semua request anonim dengan baik.
• Hosting Anda adalah shared hosting tanpa akses memasang Redis atau Memcached, dan penyedia hosting tidak menyediakannya — memaksakan solusi berbasis file di shared hosting sering menimbulkan masalah baru.
• Satu-satunya keluhan adalah skor PageSpeed pada halaman artikel yang sudah di-cache; masalah itu hampir selalu ada di lapisan page cache, gambar, atau JavaScript, bukan object cache.
• Anda belum pernah mengukur TTFB dan jumlah query per halaman; tanpa angka dasar, Anda tidak akan tahu apakah perubahan ini membantu atau tidak.

Aturan praktisnya sederhana: persistent object cache membantu request yang menjalankan PHP. Semakin besar porsi traffic yang menjalankan PHP, semakin besar manfaatnya. Jika Anda ragu, ukur dulu — bagian pengukuran di artikel ini menjelaskan caranya — sebelum memutuskan.

Redis vs Memcached vs APCu: Mana yang Cocok untuk Publisher

Tiga mesin penyimpanan yang paling sering dipakai sebagai backend object cache adalah Redis, Memcached, dan APCu. Ketiganya bisa bekerja, tetapi karakteristiknya berbeda dan pilihan yang salah akan terasa di kemudian hari.

Untuk kebanyakan publisher, Redis adalah pilihan default yang paling aman. Alasannya bukan karena Redis selalu lebih cepat — pada volume get dan set yang dihasilkan satu request WordPress, Redis dan Memcached praktis tidak bisa dibedakan pada satu host yang sama. Alasannya adalah ekosistem: drop-in Redis untuk WordPress dipelihara secara aktif, dokumentasinya lengkap, dan fitur seperti persistensi serta kebijakan eviction memberi ruang untuk mengatur perilaku cache saat memori penuh. Memcached masuk akal hanya bila ia sudah terpasang, sudah melayani hal lain di server yang sama, dan sudah terhubung ke drop-in yang Anda percaya.

APCu layak disebut agar tidak tertukar: ia menyimpan data di memori proses PHP, sehingga tidak dibagikan antar proses dan tidak bertahan antar request pada setup PHP-FPM yang umum. APCu berguna untuk opcode dan cache lokal, tetapi bukan jawaban untuk persistent object cache WordPress.

Satu catatan tentang Docket Cache dan solusi berbasis file: ada drop-in yang menyimpan objek sebagai file PHP di disk. Pendekatan ini bisa bekerja pada hosting tanpa Redis, tetapi kinerjanya bergantung pada kecepatan disk dan tidak secepat penyimpanan di memori. Anggap ini sebagai jalan tengah bila hosting Anda tidak menyediakan Redis atau Memcached, bukan sebagai pilihan pertama.

Cara Kerja Drop-in object-cache.php

Kunci seluruh mekanisme persistent object cache adalah satu file: wp-content/object-cache.php. File ini disebut drop-in, dan ia bukan plugin biasa.

WordPress memeriksa keberadaan file ini sangat awal dalam proses loading, sebelum plugin dimuat. Jika file ada, WordPress memuatnya sebagai pengganti implementasi WP_Object_Cache bawaan, dan seluruh panggilan wp_cache_*() dialihkan ke backend yang didefinisikan di file itu — Redis, Memcached, atau penyimpanan lain. Hanya boleh ada satu drop-in object cache dalam satu waktu; dua drop-in yang berebut akan saling menimpa.

Karena dimuat sangat awal, drop-in punya dua konsekuensi praktis. Pertama, ia tidak muncul di daftar plugin biasa dan tidak bisa diaktifkan atau dinonaktifkan dari layar Plugin; pengelolaannya dilakukan lewat plugin pendamping (misalnya Redis Object Cache) atau lewat WP-CLI. Kedua, drop-in yang salah — misalnya berisi kredensial Redis yang keliru atau kode yang tidak kompatibel dengan versi PHP Anda — dapat membuat situs tidak bisa diakses sama sekali, bahkan sebelum halaman error sempat tampil. Inilah alasan mengapa cadangan dan staging bukan formalitas, melainkan syarat.

Fungsi wp_using_ext_object_cache() adalah cara resmi memeriksa apakah drop-in eksternal aktif: ia mengembalikan true bila drop-in sudah mendaftarkan dirinya sebagai cache eksternal. Pemeriksaan inilah yang dipakai oleh Site Health sejak WordPress 6.1 untuk menampilkan rekomendasi persistent object cache. Perlu dipahami bahwa pemeriksaan itu hanya mengecek satu boolean — ada atau tidaknya drop-in — bukan mengukur apakah situs Anda lambat, berapa banyak traffic yang menjalankan PHP, atau apakah database Anda sedang tertekan. Rekomendasi itu adalah petunjuk umum, bukan diagnosis.

Satu detail teknis lain yang perlu diketahui: grup cache. Sebagian besar grup bersifat per-situs, tetapi grup yang didaftarkan lewat wp_cache_add_global_groups() — seperti pengguna, metadata pengguna, dan opsi situs — dibagikan ke seluruh situs dalam jaringan multisite. Pada instalasi multisite, ini berarti satu cache Redis bisa melayani banyak situs sekaligus, dengan kunci yang dibedakan lewat key salt.

Cara Mengaktifkan Redis Object Cache di WordPress

Langkah-langkah berikut memakai plugin Redis Object Cache (gratis, oleh Till Krüss) sebagai contoh, karena ini jalur yang paling umum dan terdokumentasi. Prinsipnya sama untuk Object Cache Pro atau plugin lain: pasang backend Redis, pasang drop-in, lalu verifikasi.

Prasyarat server

Sebelum menyentuh WordPress, pastikan tiga hal tersedia di server:

1. Redis berjalan dan bisa diakses PHP. Pada VPS, ini berarti memasang paket Redis dan memastikan servicenya aktif. Pada managed hosting, periksa apakah penyedia hosting menyediakan Redis — banyak host menawarkannya sebagai fitur paket tertentu, dan sebagian sudah mengaktifkan Object Cache Pro secara otomatis pada paket yang lebih besar.
2. Ekstensi PHP yang cocok. Redis Object Cache bekerja dengan ekstensi PhpRedis atau dengan klien Predis. PhpRedis umumnya lebih cepat; periksa ketersediaannya lewat php -m atau halaman info PHP di hosting Anda.
3. Cadangan lengkap dan akses staging. Cadangkan file dan database sebelum memulai. Jika memungkinkan, lakukan seluruh langkah ini di staging terlebih dahulu, lalu ulangi di situs live setelah terbukti berhasil.

Jika hosting Anda adalah shared hosting tanpa Redis dan tanpa akses memasang service, berhentilah di sini: persistent object cache berbasis Redis bukan untuk setup itu. Tanyakan kepada penyedia hosting apakah mereka menyediakan Redis atau Memcached; bila tidak, fokuskan upaya pada page cache dan optimasi database, yang memberi hasil lebih besar pada shared hosting.

Instalasi plugin Redis Object Cache

1. Di wp-admin, buka Plugin → Tambah Baru, cari “Redis Object Cache”, lalu instal dan aktifkan plugin karya Till Krüss.
2. Buka Pengaturan → Redis. Anda akan melihat status koneksi dan tombol Enable Object Cache.
3. Klik tombol tersebut. Plugin akan menulis file wp-content/object-cache.php — drop-in yang menghubungkan WordPress ke Redis.
4. Alternatif lewat WP-CLI: wp plugin install redis-cache --activate, lalu wp redis enable. WP-CLI juga berguna untuk memeriksa status drop-in dengan wp plugin list --status=dropin.

Jangan menyalin file object-cache.php secara manual dari sumber yang tidak tepercaya. Plugin yang menulis drop-in untuk Anda memastikan versi file cocok dengan versi plugin dan dengan versi WordPress Anda. Drop-in yang disalin tangan dan tertinggal versinya adalah sumber masalah yang sulit dilacak.

Konfigurasi wp-config.php

Untuk instalasi standar di satu server, plugin biasanya bekerja tanpa konfigurasi tambahan. Namun ada beberapa konstanta wp-config.php yang berguna pada setup yang lebih kompleks — misalnya bila Redis berjalan di host atau port yang berbeda, bila satu Redis dipakai beberapa situs, atau bila Anda ingin membatasi masa hidup kunci:

define( 'WP_REDIS_HOST', '127.0.0.1' );
define( 'WP_REDIS_PORT', 6379 );
define( 'WP_REDIS_PASSWORD', 'kata-sandi-redis-anda' );
define( 'WP_REDIS_MAXTTL', 3600 );
define( 'WP_CACHE_KEY_SALT', 'bangekomedia_' );

WP_CACHE_KEY_SALT penting bila satu instance Redis dipakai bersama oleh beberapa situs WordPress: salt membedakan kunci antar situs agar tidak saling menimpa. WP_REDIS_MAXTTL membatasi masa hidup maksimum sebuah kunci, sehingga data basi tidak bertahan tanpa batas. Jangan menulis kredensial Redis di file yang bisa diakses publik, dan jangan pernah membagikan isi wp-config.php Anda kepada siapa pun.

Verifikasi

Setelah mengaktifkan, verifikasi bahwa cache benar-benar bekerja, bukan sekadar terlihat aktif:

1. Di Pengaturan → Redis, status harus menunjukkan koneksi berhasil dan object cache aktif.
2. Buka Perkakas → Kesehatan Situs. Rekomendasi “Anda sebaiknya menggunakan persistent object cache” seharusnya hilang.
3. Lewat WP-CLI, jalankan wp cache type. Hasilnya harus menunjukkan backend Redis, bukan “Default”. Bila hasilnya masih “Default” padahal drop-in tercantum di wp plugin list --status=dropin, berarti drop-in gagal terhubung — periksa host, port, dan kredensial Redis.
4. Uji situs seperti pengunjung biasa: buka beberapa halaman, simpan sebuah postingan, lalu periksa apakah konten baru tampil dengan benar. Cache yang bekerja tetapi menyajikan konten basi sama buruknya dengan cache yang tidak bekerja.
5. Periksa log error PHP setelah aktivasi. Error koneksi Redis yang berulang adalah tanda konfigurasi belum benar.

Transient dan wp_options: Efek Samping yang Sering Terlewat

Salah satu manfaat persistent object cache yang paling terasa justru bukan pada query postingan, melainkan pada transient. Transient API adalah cara WordPress dan plugin menyimpan data sementara dengan masa kedaluwarsa — misalnya hasil panggilan API eksternal, potongan data yang mahal dihitung, atau status pekerjaan latar belakang.

Tanpa persistent object cache, transient disimpan sebagai baris di tabel wp_options. Setiap transient yang dibuat menambah baris, dan setiap transient yang kedaluwarsa tetapi belum dibersihkan tetap menumpuk. Pada situs dengan banyak plugin yang gemar memakai transient — plugin SEO yang menyimpan indexable, plugin caching, Action Scheduler pada WooCommerce — tabel wp_options bisa membengkak hingga ratusan ribu baris, dan query SELECT pada tabel itu menjadi lambat. Inilah salah satu alasan tabel wp_options yang membengkak sering disebut sebagai bottleneck klasik WordPress.

Begitu persistent object cache aktif, WordPress secara otomatis memindahkan transient ke memori Redis atau Memcached. Transient tidak lagi ditulis ke database, tabel wp_options berhenti membengkak karena transient, dan pembacaan transient menjadi jauh lebih cepat. Efek samping ini saja sering cukup untuk membenarkan pemasangan object cache pada situs yang plugin-nya berat.

Namun ada sisi lain yang perlu diingat. Transient yang tersimpan di Redis mengikuti masa hidup dan kebijakan eviction Redis, bukan perilaku database. Bila Redis kehabisan memori dan kebijakan eviction membuang kunci transient lebih awal, plugin yang mengandalkannya harus menghitung ulang — ini normal dan aman, karena transient memang dirancang untuk bisa dihitung ulang. Yang tidak boleh terjadi adalah menyimpan data yang harus permanen di dalam transient; itu kesalahan desain plugin, bukan kesalahan cache.

Satu hal lagi: membersihkan transient kedaluwarsa tetap layak dilakukan secara berkala sebagai perawatan database, terutama bila situs Anda pernah berjalan lama tanpa object cache. Artikel tentang optimasi database WordPress di situs ini menjelaskan langkah-langkahnya.

Pengaturan Penting: Eviction Policy, TTL, dan Key Salt

Setelah object cache aktif, tiga pengaturan menentukan apakah cache berperilaku baik saat memori penuh, saat data berubah, dan saat satu Redis dipakai banyak situs.

Eviction policy (kebijakan pengusiran). Redis memiliki batas memori (maxmemory). Saat memori penuh, Redis harus memutuskan kunci mana yang dibuang. Dua kebijakan yang relevan untuk object cache:

Pengaturan yang paling umum untuk Redis yang didedikasikan bagi object cache adalah allkeys-lru. Sebaliknya, noeviction berbahaya: begitu Redis penuh, setiap upaya menulis cache gagal dan situs mulai menampilkan error. Periksa kebijakan ini di konfigurasi Redis Anda (redis.conf atau perintah CONFIG GET maxmemory-policy) sebelum mengaktifkan object cache di situs live.

TTL (time to live). Setiap nilai cache sebaiknya memiliki masa hidup. Tanpa TTL, kunci bisa bertahan selamanya dan menyajikan data basi. WordPress dan plugin yang baik selalu menetapkan TTL saat memanggil wp_cache_set() dengan parameter expire. Konstanta WP_REDIS_MAXTTL memberi batas atas agar tidak ada kunci yang hidup tanpa batas. Untuk konten editorial yang berubah saat postingan disimpan, invalidasi eksplisit lewat wp_cache_delete() pada saat penyimpanan jauh lebih penting daripada TTL yang panjang.

Key salt. Bila satu Redis melayani beberapa instalasi WordPress — misalnya situs live dan staging yang berbagi server — kunci cache dari kedua situs bisa bertabrakan dan saling menimpa. WP_CACHE_KEY_SALT memberi awalan unik pada setiap kunci, sehingga cache staging tidak pernah menyajikan konten live dan sebaliknya. Ini pengaturan kecil yang mencegah kebocoran konten antar lingkungan yang sulit dilacak.

Cara Mengukur Apakah Object Cache Benar-Benar Membantu

Memasang object cache tanpa mengukur sama dengan menebak. Pengukuran yang benar membutuhkan angka sebelum dan sesudah, pada kondisi yang sebanding, dan pada metrik yang tepat.

Metrik yang layak diukur:

• TTFB (Time to First Byte) pada halaman yang menjalankan PHP — misalnya halaman arsip, hasil pencarian, dan wp-admin — diukur beberapa kali dan diambil mediannya, bukan satu kali ukur.
• Jumlah query database per halaman, yang bisa dilihat lewat plugin Query Monitor. Bandingkan jumlah query dan total waktu query sebelum dan sesudah object cache aktif.
• Beban CPU dan memori database pada jam sibuk, bila hosting Anda menyediakan grafik pemakaian.
• Waktu muat wp-admin untuk tugas sehari-hari: membuka daftar postingan, menyimpan artikel, dan memuat editor.

Cara mengukur dengan benar:

1. Ukur dulu kondisi dasar (baseline) sebelum mengaktifkan object cache: catat TTFB dan jumlah query pada 3–5 URL yang mewakili — halaman depan, satu artikel, satu arsip kategori, dan satu halaman wp-admin.
2. Aktifkan object cache, tunggu beberapa menit agar cache terisi (cache yang dingin tidak menunjukkan manfaat apa pun), lalu ukur lagi URL yang sama pada jam yang sebanding.
3. Bandingkan median, bukan nilai terbaik. Satu kali ukur yang cepat bisa disebabkan oleh banyak hal.
4. Periksa hit rate bila plugin Anda menampilkannya: rasio hit yang sehat menandakan cache dipakai, sedangkan rasio miss yang tinggi menandakan kunci sering kedaluwarsa atau eviction terlalu agresif.

Harapan yang realistis: pada situs dengan banyak query per halaman dan traffic yang menjalankan PHP, penurunan jumlah query dan TTFB yang terasa adalah hasil yang wajar. Pada halaman artikel yang sudah di-page-cache untuk pengunjung anonim, jangan berharap ada perubahan — halaman itu memang tidak menyentuh object cache. Bila setelah pengukuran tidak ada perbaikan sama sekali, object cache mungkin bukan bottleneck Anda; kembalikan fokus ke page cache, gambar, dan query yang lambat.

Masalah Umum dan Cara Memperbaikinya

Cara tercepat memulihkan situs bila drop-in bermasalah adalah menghapus file wp-content/object-cache.php lewat FTP atau file manager hosting. WordPress akan otomatis kembali ke implementasi WP_Object_Cache bawaan tanpa perlu mengubah apa pun di database. Inilah mengapa Anda harus selalu tahu cara mengakses file situs di luar wp-admin sebelum memasang drop-in apa pun.

Untuk membersihkan seluruh object cache secara manual, gunakan wp cache flush lewat WP-CLI atau tombol flush di halaman pengaturan plugin. Flush adalah operasi yang aman — ia hanya mengosongkan cache, dan cache akan terisi kembali secara bertahap. Jangan melakukan flush berulang kali pada jam sibuk, karena setiap flush memaksa seluruh query dihitung ulang dari database sekaligus.

Object Cache dan Iklan AdSense: yang Perlu Diperhatikan

Publisher yang memonetisasi dengan AdSense sering khawatir cache akan merusak iklan. Kekhawatiran itu masuk akal, tetapi object cache — bila dipasang dengan benar — tidak mengubah iklan yang tampil.

Iklan AdSense dirender di sisi klien lewat JavaScript, dan kode iklan biasanya dimasukkan ke halaman sebagai bagian dari konten atau lewat plugin penempatan iklan. Object cache menyimpan hasil query database, bukan HTML akhir halaman, sehingga ia tidak membekukan atau mengubah kode iklan. Yang perlu diperhatikan adalah interaksi dengan page cache, bukan object cache: halaman yang di-page-cache terlalu lama bisa menampilkan unit iklan yang sudah tidak relevan, dan itu masalah page cache.

Ada tiga hal yang tetap layak diperiksa setelah mengaktifkan object cache:

1. Pastikan iklan tetap tampil setelah aktivasi. Buka beberapa halaman sebagai pengunjung anonim dan periksa unit iklan muncul seperti biasa.
2. Periksa halaman yang dikecualikan dari cache. Bila Anda mengecualikan halaman tertentu dari page cache karena kontennya dinamis, pengecualian itu tetap berlaku; object cache tidak membatalkannya.
3. Jangan meng-cache respons yang mengandung data pengguna. Object cache menyimpan objek berdasarkan kunci dan grup; plugin yang menyimpan data spesifik pengguna tanpa membedakan kunci per pengguna bisa membocorkan data antar pengguna. Ini jarang terjadi pada plugin yang ditulis dengan baik, tetapi layak diwaspadai bila Anda memakai plugin keanggotaan atau personalisasi.

Secara umum, object cache adalah teman AdSense, bukan musuh: situs yang lebih cepat memuat halaman memberi pengalaman membaca yang lebih baik, dan pengalaman membaca yang lebih baik mendukung metrik viewability iklan. Yang merusak pendapatan bukanlah cache, melainkan situs yang lambat dan halaman yang sulit dibaca.

Checklist Sebelum dan Sesudah Mengaktifkan Object Cache

Sebelum aktivasi:

• Cadangan lengkap file dan database sudah dibuat dan sudah diuji bisa dipulihkan.
• Lingkungan staging tersedia, atau setidaknya Anda tahu cara mengakses file lewat FTP bila wp-admin tidak bisa dibuka.
• Redis atau Memcached sudah berjalan dan bisa diakses dari PHP.
• Baseline sudah diukur: TTFB dan jumlah query pada 3–5 URL yang mewakili.
• Jam aktivasi dipilih di luar jam sibuk.

Sesudah aktivasi:

• Status koneksi di halaman pengaturan plugin menunjukkan aktif.
• wp cache type menunjukkan backend Redis, bukan “Default”.
• Rekomendasi persistent object cache di Site Health hilang.
• Beberapa halaman dibuka dan konten baru tampil benar setelah menyimpan postingan.
• Iklan AdSense tampil normal di halaman artikel.
• Pengukuran ulang dilakukan setelah cache hangat, dan hasilnya dicatat.
• Kebijakan eviction Redis diperiksa (allkeys-lru untuk Redis khusus cache).
• WP_CACHE_KEY_SALT ditetapkan bila satu Redis dipakai beberapa situs.

FAQ

Apakah object cache sama dengan plugin caching seperti WP Rocket atau LiteSpeed Cache?

Tidak. Plugin caching umumnya adalah page cache: mereka menyimpan HTML lengkap dan menyajikannya tanpa menjalankan PHP. Object cache menyimpan hasil query database dan bekerja saat PHP memang harus berjalan. Keduanya saling melengkapi, dan situs yang sehat biasanya memakai keduanya.

Apakah saya butuh Redis bila hosting saya sudah menyediakan page cache?

Mungkin tetap butuh, tergantung porsi traffic yang menjalankan PHP. Page cache menangani pengunjung anonim yang membaca artikel. Object cache membantu wp-admin, halaman dinamis, dan request API. Bila dashboard Anda lambat atau tabel wp_options membengkak karena transient, object cache tetap bermanfaat meski page cache sudah ada.

Mengapa Site Health menyarankan persistent object cache padahal situs saya terasa cepat?

Karena pemeriksaan Site Health hanya memeriksa ada-tidaknya drop-in lewat wp_using_ext_object_cache(), bukan mengukur kecepatan situs Anda. Rekomendasi itu bersifat umum dan berada di bawah “Recommended improvements”, bukan “Critical issues”. Bila hampir semua traffic Anda ditangani page cache, mengabaikan rekomendasi itu adalah jawaban yang benar.

Apakah Memcached lebih cepat daripada Redis untuk WordPress?

Pada volume get dan set yang dihasilkan satu request WordPress, keduanya praktis tidak bisa dibedakan pada satu host yang sama. Pilih Redis karena drop-in-nya aktif dipelihara, mendukung persistensi, dan punya kebijakan eviction yang fleksibel — kecuali Memcached sudah terpasang dan sudah melayani hal lain di server Anda.

Apa yang terjadi bila Redis mati atau tidak bisa diakses?

Plugin Redis Object Cache yang ditulis dengan baik akan kembali ke cache bawaan non-persistent bila koneksi gagal, sehingga situs tetap berjalan — hanya lebih lambat. Namun perilaku ini tergantung plugin dan konfigurasi; drop-in yang ditulis buruk bisa membuat situs error. Inilah alasan pengujian di staging penting sebelum aktivasi di situs live.

Apakah object cache bisa membuat konten basi?

Bisa, bila invalidasi tidak berjalan: misalnya postingan baru disimpan tetapi versi lama tetap disajikan. WordPress dan plugin yang baik memanggil wp_cache_delete() saat data berubah, sehingga konten basi jarang terjadi. Bila Anda menemukannya, periksa TTL, lakukan flush sekali, dan periksa apakah ada plugin yang menyimpan data dengan kunci yang tidak pernah dihapus.

Kesimpulan

Object cache bawaan WordPress bekerja, tetapi hanya di dalam satu request. Begitu request selesai, seluruh hasil query yang sudah dihitung dengan susah payah dibuang, dan pengunjung berikutnya mengulang pekerjaan yang sama. Persistent object cache — lewat Redis atau Memcached dan satu file drop-in wp-content/object-cache.php — membuat hasil itu bertahan antar request, mengurangi beban database, dan menstabilkan waktu respons pada jam sibuk.

Untuk kebanyakan publisher, Redis adalah pilihan default yang paling aman: ekosistemnya aktif dipelihara, mendukung persistensi, dan fleksibel dalam mengatur eviction. Memcached tetap valid bila sudah ada di server Anda. Apa pun pilihannya, pasang dengan disiplin: cadangkan dulu, uji di staging, verifikasi bahwa cache benar-benar aktif lewat wp cache type dan Site Health, lalu ukur hasilnya pada metrik yang tepat. Dan ingat batasannya — object cache mempercepat request yang sampai ke PHP; ia bukan pengganti page cache, dan pada halaman artikel yang sudah di-page-cache, dampaknya memang kecil.

Bila setelah pengukuran Anda melihat jumlah query turun dan TTFB lebih stabil, object cache sudah menjalankan tugasnya. Bila tidak ada perubahan, jangan memaksakan: kembalikan fokus ke lapisan yang benar-benar menjadi bottleneck situs Anda.

Sumber resmi yang dirujuk

1. WordPress Developer Resources — WP_Object_Cache (https://developer.wordpress.org/reference/classes/wp_object_cache/)
2. WordPress Developer Resources — Transients API dan Object Cache, serta dokumentasi wp_cache_set(), wp_cache_get(), dan wp_using_ext_object_cache() (https://developer.wordpress.org/apis/handbook/transients/ dan https://developer.wordpress.org/reference/functions/wp_using_ext_object_cache/)
3. WordPress.org — Plugin Redis Object Cache oleh Till Krüss (https://wordpress.org/plugins/redis-cache/)
4. WordPress Developer Resources — Site Health dan rekomendasi persistent object cache sejak WordPress 6.1 (https://developer.wordpress.org/advanced-administration/wordpress/admin/)
5. Docket Cache — Caching in WordPress (lapisan cache, drop-in object-cache.php, dan perilaku transient) (https://docs.docketcache.com/resources/caching-in-wordpress)
6. Cloudways — How to Install and Configure Redis Cache on WordPress (https://www.cloudways.com/blog/install-redis-cache-wordpress/)
7. StackHarbor — WordPress Object Cache: Redis or Memcached, and whether you need one (https://stackharbor.com/en/knowledge-base/wp-object-cache-redis-vs-memcached/)