Cara Cek Ukuran Opsi Autoload di wp_options yang Bikin Admin WordPress Lemot

Keluhan ini sering muncul: halaman depan WordPress terasa cepat karena sudah di-cache, tapi begitu masuk wp-admin, setiap klik terasa berat. Padahal jumlah pengunjung biasa saja dan resource hosting belum mentok. Salah satu penyebab yang sering terlewat ada di tabel wp_options, tepatnya di opsi yang ditandai autoload. Artikel ini disusun sebagai tanya-jawab dari pertanyaan yang biasanya muncul saat kita mulai menelusuri masalah ini.

Apa itu opsi autoload, dan kenapa bisa bikin lemot?

Tabel wp_options adalah tempat WordPress, tema, dan plugin menyimpan pengaturan. Tiap baris punya option_name, option_value, dan kolom autoload. Kalau autoload aktif, opsi itu ikut diambil sekaligus di awal setiap request lewat satu query, lalu disimpan di memori supaya pemanggilan get_option() berikutnya tidak perlu ke database lagi. Idenya bagus untuk opsi kecil yang hampir selalu dipakai, seperti URL situs atau daftar plugin aktif. Masalahnya, banyak plugin ikut menyimpan data besar dengan autoload aktif: cache internal, log, hasil scan, statistik, atau pengaturan yang ditulis ulang terus. Lebih parah lagi, saat plugin dihapus, datanya sering tertinggal. Akhirnya setiap request harus menarik, mengirim, dan meng-unserialize data dalam jumlah besar yang sebagian besar tidak pernah dipakai. Unserialize di sini artinya mengubah teks yang tersimpan di database kembali menjadi array atau object PHP.

Kenapa yang terasa lemot justru dashboard, bukan halaman depan?

Halaman depan biasanya dilayani page cache, baik dari plugin, web server, maupun CDN. Selama halaman diambil dari cache, PHP dan WordPress tidak benar-benar berjalan, jadi beban autoload tidak terasa. Di wp-admin, page cache hampir selalu dimatikan. Setiap klik menjalankan WordPress dari awal, termasuk memuat seluruh opsi autoload. Dashboard juga sering memicu request AJAX di belakang layar, misalnya heartbeat atau widget dari plugin. Masing-masing request itu ikut memuat autoload. Dari sisi support, pola ini cukup khas: TTFB di wp-admin tinggi secara konsisten di semua halaman, bukan cuma di satu menu tertentu. TTFB (time to first byte) adalah waktu sampai byte pertama respons diterima browser. Kalau situs memakai persistent object cache seperti Redis atau Memcached, seluruh autoload biasanya disimpan sebagai satu item cache. Itu membantu, tapi tidak menghapus masalahnya. Data besar tetap harus ditransfer dan di-unserialize di setiap request. Di Memcached, item yang melewati batas ukuran item (umumnya 1 MB secara default) bisa gagal disimpan, sehingga WordPress kembali mengambilnya dari database terus.

Berapa ukuran autoload yang masih wajar?

Tidak ada angka resmi yang berlaku untuk semua situs, karena ini tergantung jumlah plugin dan spesifikasi server. Patokan yang cukup praktis datang dari WordPress sendiri: sejak versi 6.6, Site Health punya pemeriksaan ukuran opsi autoload dan memberi peringatan kalau totalnya melewati sekitar 800 KB. Jadi cara pertama yang paling mudah adalah membuka Tools > Site Health dan melihat apakah peringatan itu muncul. Aturan praktisnya begini. Situs dengan beberapa ratus KB autoload biasanya masih normal. Kalau totalnya sudah di kisaran beberapa MB, hampir pasti ada data yang tidak seharusnya di-autoload. Yang lebih penting daripada total adalah komposisinya: satu atau dua opsi yang sangat besar jauh lebih mudah ditangani daripada ribuan opsi kecil.

Bagaimana cara mengukur total autoload dan menemukan opsi terbesar?

Kalau ada akses SSH dan WP-CLI, jalankan perintah dari direktori instalasi WordPress. Perintah di bawah ini read-only kecuali dua baris terakhir, yang mengubah data dan baru dipakai di langkah berikutnya.

BASH

# Cek prefix tabel (default biasanya wp_)
wp db prefix

# Total byte semua opsi autoload
wp option list --autoload=on --format=total_bytes

# 20 opsi autoload terbesar (ganti wp_ sesuai prefix)
wp db query "SELECT option_name, LENGTH(option_value) AS bytes FROM wp_options WHERE autoload IN ('yes','on','auto-on','auto') ORDER BY bytes DESC LIMIT 20;"

# --- Mengubah data: backup dulu sebelum menjalankan ini ---
wp db export sebelum-autoload.sql
wp option set-autoload nama_opsi no

Daftar nilai ('yes','on','auto-on','auto') dipakai karena WordPress 6.6 mengganti nilai autoload dari yes/no menjadi beberapa varian baru. Situs yang sudah lama berjalan bisa berisi campuran nilai lama dan baru, jadi query perlu mencakup semuanya. Kalau tidak punya SSH, query SELECT yang sama bisa dijalankan di tab SQL phpMyAdmin. Untuk melihat totalnya, ganti bagian kolom dengan SUM(LENGTH(option_value)) lalu hapus ORDER BY dan LIMIT. Hasil query biasanya langsung bercerita. Perhatikan prefix di option_name. Kebanyakan plugin memakai prefix yang mirip nama plugin, jadi dari situ kita bisa menebak asal data. Opsi yang namanya diawali _transient_ atau _site_transient_ adalah transient, yaitu data cache sementara yang disimpan plugin di database.

Opsi mana yang aman dimatikan autoload-nya?

Kandidat paling jelas adalah sisa plugin yang sudah tidak terpasang. Cocokkan prefix opsi besar dengan daftar plugin aktif. Kalau pluginnya sudah lama dihapus, data itu tidak dipakai siapa pun dan tidak perlu dimuat di setiap request. Kandidat berikutnya adalah data yang jelas bukan pengaturan, misalnya log, hasil scan, antrean, atau cache internal plugin yang ukurannya ratusan KB. Data seperti itu jarang dibutuhkan di setiap halaman. Yang sebaiknya tidak disentuh adalah opsi inti WordPress, seperti siteurl, home, active_plugins, template, stylesheet, rewrite_rules, dan wp_user_roles (nama yang terakhir mengikuti prefix tabel). Opsi cron juga sering muncul di daftar teratas. Kalau ukurannya besar, itu tanda event terjadwal menumpuk, misalnya karena WP-Cron tidak berjalan normal. Mematikan autoload tidak menyelesaikan masalah itu, jadi akar masalahnya harus dicari secara terpisah. Untuk opsi milik plugin yang masih aktif, pertimbangkan trade-off-nya. Mematikan autoload tidak menghapus data. Kalau plugin tetap memanggil get_option(), WordPress akan mengambilnya lewat satu query tambahan saat dibutuhkan. Jadi biasanya tidak ada yang rusak, cuma ada sedikit query ekstra di halaman yang memang memakainya. Tapi kalau opsi itu dibaca di hampir semua halaman, mematikan autoload tidak banyak membantu. Di kasus seperti itu, pilihan yang lebih masuk akal biasanya mengatur ulang plugin, misalnya membatasi log, atau mencari plugin pengganti.

Bagaimana cara menonaktifkan autoload dengan aman, dan apakah lebih baik dihapus saja?

Urutan yang aman kira-kira begini:

Backup database dulu, misalnya dengan wp db export seperti di contoh di atas, atau lewat fitur backup di panel hosting.
Ubah satu opsi atau satu kelompok opsi sekaligus, jangan semuanya dalam sekali jalan. Dengan begitu, kalau ada fitur yang berubah perilaku, penyebabnya mudah dilacak.
Pakai wp option set-autoload. Nilai yang diterima tergantung versi WP-CLI, jadi cek dulu dengan wp help option set-autoload.
Kalau situs memakai persistent object cache, kosongkan cache-nya (misalnya dengan wp cache flush) supaya perubahan langsung terbaca.
Ukur ulang total autoload, lalu bandingkan TTFB di wp-admin sebelum dan sesudah perubahan.

Tanpa WP-CLI, perubahan bisa dilakukan dengan UPDATE langsung di phpMyAdmin. Ubah kolom autoload pada baris yang dituju menjadi off untuk WordPress 6.6 ke atas, atau no untuk versi lama. Developer yang lebih nyaman lewat kode bisa memakai wp_set_option_autoload(), yang tersedia sejak WordPress 6.4. Soal hapus atau matikan autoload, aku cenderung memilih mematikan autoload dulu, kecuali datanya jelas sisa plugin yang sudah dihapus. Mematikan autoload mudah dibalikkan dan tidak menghilangkan pengaturan. Menghapus opsi milik plugin aktif bisa membuat pengaturannya kembali ke default. Untuk transient yang sudah kedaluwarsa, menghapusnya aman karena plugin akan membuat ulang kalau perlu. Perintah wp transient delete --expired bisa dipakai untuk itu. Catatan lain soal performa WordPress, seperti cara membaca slow query dan memisahkan masalah plugin dari masalah server, ada di Catatan Praktis WordPress Performance & Debugging untuk Troubleshooting Sehari-hari. Jadi, kalau wp-admin terasa berat di semua halaman sementara halaman depan normal, cek autoload sebelum menyalahkan server atau menaikkan paket hosting. Ukur totalnya, lihat 20 opsi terbesar, cocokkan prefix-nya dengan plugin yang masih aktif, lalu matikan autoload satu per satu setelah backup. Pekerjaannya biasanya selesai dalam beberapa menit, dan hasilnya langsung bisa diukur.