OPcache WordPress menyimpan bytecode hasil kompilasi PHP di memori bersama, sehingga request berikutnya langsung mengeksekusi kode tanpa mengulang baca disk, tokenize, parse, dan compile. Kalau Time to First Byte situsmu tinggi padahal plugin cache sudah aktif, lapisan eksekusi PHP ini sering jadi biang keladinya. Artikel ini menjelaskan mekanisme OPcache, tabel nilai php.ini yang aman sebagai titik awal, langkah konfigurasi dan restart PHP-FPM, plus cara memantau statusnya dari Site Health. Ikuti berurutan dari konsep ke praktik supaya setiap angka yang kamu ubah berdasar pemahaman, bukan tebakan. Kamu juga akan paham bedanya dengan page cache dan object cache supaya tidak salah lapis saat optimasi.
Apa Itu OPcache dan Cara Kerjanya
Setiap request PHP tanpa cache melewati lima tahap: baca file dari disk, tokenize, parse menjadi struktur sintaks, compile menjadi bytecode, lalu execute. Lima tahap ini berulang untuk setiap file pada setiap request, padahal kode WordPress jarang berubah antar request. Di sinilah php opcache wordpress berperan: hasil kompilasi disimpan di shared memory sehingga request berikutnya melewatkan empat tahap pertama dan langsung mengeksekusi bytecode yang sudah jadi. Penghematan terbesar muncul pada situs dengan banyak plugin dan tema, karena ratusan file PHP tidak perlu dikompilasi ulang terus menerus.
Nama OPcache adalah singkatan dari opcode cache, dan bytecode adalah bentuk opcode yang siap dieksekusi mesin virtual PHP. Cache ini hidup di RAM di luar proses request, jadi satu salinan bytecode melayani semua worker PHP-FPM tanpa duplikasi.
OPcache bekerja di lapisan eksekusi PHP, di bawah web server. Kalau kamu juga menimbang tumpukan server, baca perbandingan Nginx vs OpenLiteSpeed untuk WordPress sebelum mengubah konfigurasi runtime.
Optimasi tidak berhenti di lapisan PHP. Protokol HTTP/3 (QUIC) memangkas latensi koneksi, bagian yang tidak dijangkau OPcache.
Tiga Lapisan Cache WordPress yang Sering Tertukar
Page cache menyimpan HTML jadi untuk pengunjung anonim, sehingga request dijawab tanpa menyentuh PHP dan database. OPcache menyimpan bytecode PHP hasil kompilasi, sehingga eksekusi kode lebih cepat untuk semua request, termasuk halaman dinamis. Redis object cache menyimpan hasil query database di memori, sehingga PHP tidak menembak database berulang untuk data yang sama. Ketiganya hidup di lapisan berbeda dan saling melengkapi.
Masalah umum adalah menganggap satu cache menggantikan yang lain. Situs dengan page cache aktif tetap lambat di wp-admin dan checkout karena halaman itu tidak boleh disajikan sebagai HTML statis. Di sisi lain, object cache tidak mempercepat kompilasi tema dan plugin yang berat.
Page cache menyimpan halaman, OPcache menyimpan bytecode, object cache menyimpan data. Tidak ada yang menggantikan, ketiganya melengkapi.
Untuk lapisan data, artikel Redis object cache untuk WordPress membahas penyimpanan hasil query secara mendalam . Diagram berikut memetakan posisi tiap lapisan terhadap request.
Direktif OPcache di php.ini dan Nilainya
Enam direktif berikut adalah titik awal yang aman untuk kebanyakan situs WordPress, bukan angka final untuk semua server. Untuk opcache memory consumption wordpress, memori adalah tuas terbesar: terlalu kecil membuat cache sering dibuang dan CPU kembali sibuk mengompilasi. Direktif interned strings mengatur buffer string yang dipakai ulang antar request, dan situs multibahasa biasanya butuh ruang lebih besar. Salin nilai awal dari tabel, sesuaikan setelah melihat hit rate dan memori terpakai di Site Health. Jangan mengubah dua direktif sekaligus supaya efek tiap perubahan terbaca jelas.
| Direktif | Nilai awal yang umum | Kapan diubah |
|---|---|---|
opcache.memory_consumption |
128M sampai 256M | Saat hit rate turun atau situs punya banyak plugin dan tema |
opcache.max_accelerated_files |
4.000 sampai 10.000 | Saat jumlah file PHP proyek melebihi kapasitas, terutama multisite |
opcache.interned_strings_buffer |
16M sampai 64M | Saat situs multibahasa atau muncul peringatan string buffer penuh |
opcache.validate_timestamps |
1 (dengan revalidate_freq) |
0 hanya untuk produksi yang jarang deploy, konsekuensinya file baru tidak terdeteksi |
opcache.save_comments |
1 | Jangan dimatikan, sebagian plugin WordPress membaca docblock PHP |
opcache.max_wasted_percentage |
10% | Naikkan bila memori sering terbuang sia-sia setelah rebuild cache |
Kapan OPcache Perlu Direset atau Dinonaktifkan
Gejala klasik adalah kode terbaru tidak muncul padahal file sudah diunggah. Penyebabnya biasanya validate_timestamps yang dimatikan atau jeda revalidasi yang terlalu lama, sehingga OPcache tetap menyajikan bytecode lama. Solusinya adalah mereset cache sekali setelah deploy besar, bukan mematikan OPcache permanen. Reset memaksa kompilasi ulang seluruh file, jadi lakukan di jam sepi dan pantau beban CPU sesaat setelahnya.
Matikan OPcache sementara hanya saat debugging masalah yang diduga berasal dari cache basi, misalnya perilaku aneh yang hilang timbul setelah update plugin. Nyalakan kembali segera setelah sesi debug selesai, karena tanpa OPcache setiap request membayar penuh biaya kompilasi. Aturan praktisnya: reset untuk deploy, nonaktif sesaat untuk diagnosis, dan jangan pernah membiarkan situs produksi berjalan lama tanpa bytecode cache. Catat waktu reset agar tim tahu kapan bytecode terakhir dibangun ulang.
Cara Konfigurasi OPcache WordPress di php.ini
Tiga langkah berikut membawa OPcache dari nilai bawaan ke konfigurasi opcache php yang terukur: tentukan nilai direktif sesuai kapasitas server, simpan dan restart PHP-FPM, lalu verifikasi dari Site Health. Siapkan akses SSH atau panel file manager, cadangan salinan php.ini aktif, dan jadwal maintenance singkat. Kerjakan berurutan dan catat tiap nilai yang diubah, karena perubahan tanpa catatan membuat rollback menebak ulang. Jangan menyalin mentah nilai dari forum tanpa menyesuaikan RAM dan jumlah file di servermu. Estimasi waktu total sekitar lima belas menit di luar observasi.
Menentukan Nilai Direktif Kunci
Baca dulu kapasitas RAM server dan hitung jumlah file PHP di folder WordPress, tema, dan plugin. Untuk situs tunggal standar, mulai dari opcache.memory_consumption=128 dan opcache.max_accelerated_files=4000, lalu naikkan bila hit rate rendah atau file melebihi kuota. Situs multisite atau multibahasa biasanya butuh opcache.interned_strings_buffer lebih besar dari bawaan. Catat nilai lama tiap direktif sebelum mengubah, supaya kamu bisa kembali tanpa menebak bila performa justru turun. Bandingkan angka file aktual dengan batas maksimal, lalu beri ruang tumbuh sekitar dua puluh persen untuk plugin baru.
Menyimpan Konfigurasi dan Restart PHP-FPM
Buka berkas php.ini yang dipakai PHP-FPM, bukan versi CLI, lalu tulis nilai yang sudah ditentukan dan simpan. Restart layanan PHP-FPM agar konfigurasi terbaca ulang, misalnya sudo systemctl restart php8.3-fpm di Ubuntu atau perintah setara di distribusi lain. Merestart web server saja tidak cukup karena bytecode tinggal di memori worker PHP-FPM. Tunggu satu menit, pastikan situs tetap terbuka normal, dan baca log PHP bila ada galat startup. Kalau memakai panel hosting, gunakan tombol restart PHP di panel dan konfirmasi versi PHP yang direstart sesuai situsmu.
Verifikasi Status di WordPress Site Health
Masuk ke Tools lalu Site Health di wp-admin dan buka tab Info untuk memastikan OPcache tercatat aktif beserta versi dan memorinya. Alternatifnya, buat berkas phpinfo() sementara di folder privat dan cari blok OPcache, lalu hapus berkas itu segera setelah selesai. Beberapa plugin monitoring menampilkan hit rate dan kunci ter-cache langsung di dasbor. Status dianggap selesai hanya bila tiga hal cocok: nilai sesuai yang ditulis, tidak ada galat startup, dan hit rate bergerak naik setelah beberapa jam traffic. Tangkap layar halaman status sebagai arsip sebelum dan sesudah tuning.
Memantau Status OPcache dari WordPress Site Health
Dua angka yang layak dipantau rutin adalah hit rate dan memori terpakai. Hit rate tinggi dan stabil artinya bytecode dipakai ulang dengan baik, sedangkan hit rate yang merosot menandakan memori kepenuhan atau churn karena reset terlalu sering. Memori terpakai yang terus menempel di batas atas berarti saatnya menaikkan opcache.memory_consumption atau memangkas plugin yang menambah ribuan file.
Beberapa plugin kesehatan OPcache menampilkan grafik hit, miss, dan kunci terbuang langsung di dasbor WordPress. Jadwalkan pengecekan mingguan dan catat angkanya dalam satu lembar sederhana, supaya tren terlihat sebelum pengguna mengeluh.
Kalau situsmu tumbuh ke banyak node, pelajari beda reverse proxy dan load balancer untuk lapisan distribusi agar monitoring cache tidak tertukar dengan masalah jaringan.
OPcache dan JIT: Apa yang Perlu Diketahui Pemula
JIT adalah kompilator tepat waktu yang hadir sejak PHP 8 sebagai lapisan di atas OPcache. OPcache menyimpan bytecode agar tidak dikompilasi ulang, sedangkan JIT melangkah lebih jauh dengan mengompilasi bagian kode yang sering dieksekusi menjadi instruksi mesin. Untuk WordPress biasa yang didominasi operasi database dan pemanggilan plugin, manfaat JIT kecil dan kadang tidak terasa. Justru aplikasi berat komputasi seperti pemrosesan data dan simulasi yang paling diuntungkan.
Saran praktis untuk pemula: pahami dan stabilkan OPcache dulu, dan anggap JIT sebagai materi lanjutan. Menyalakan JIT tanpa pengukuran hanya menambah variabel saat troubleshooting. Fokuskan energi ke hit rate, memori cukup, dan timestamp yang sehat dulu.
Rekomendasi untuk Situs WordPress
Untuk kebanyakan situs, biarkan nilai bawaan yang sehat dan ubah hanya saat ada gejala: hit rate rendah, memori penuh, atau deploy tidak kunjung tampil. Satu situs company profile atau blog dengan plugin wajar jarang butuh tuning ekstrem. Kebalikannya, WooCommerce ramai dan multisite besar layak mendapat alokasi memori lebih lega dan jadwal monitoring rutin. Dokumentasikan setiap perubahan beserta alasannya agar keputusan berikutnya berdasar data. Uji pada traffic nyata, bukan tebakan dari dasbor kosong.
Situs WordPress tunggal yang tidak mau mengurus server cocok memakai Cloud Hosting Mordenhost sebagai layanan terkelola. Kalau kamu ingin mengatur php.ini sendiri di server penuh pengelolaan, Managed VPS mulai Rp950.000 per bulan memberi ruang itu. Diskusikan kebutuhan traffic dan pluginmu lewat WhatsApp Mordenhost atau portal tiket untuk rekomendasi paket yang pas.
Kesimpulan
OPcache menyimpan bytecode di memori bersama sehingga PHP tidak mengulang kompilasi tiap request. Tabel nilai di atas adalah titik awal yang aman, dan monitoring rutin mencegah dugaan keliru saat situs melambat. Kalau fondasi hosting secara umum masih kabur, baca dulu cara kerja hosting dan jenis-jenisnya sebelum mengatur ulang server. Mulai dari default sehat, ubah saat ada gejala, dan catat setiap langkah. Ringkasnya: cache bytecode mempercepat eksekusi, angka tepat lahir dari pengukuran, dan lapisan cache yang benar menghemat waktu debugging setiap hari. Terapkan satu perubahan dalam satu waktu.
Pertanyaan yang Sering Ditanya
Empat jawaban singkat untuk pertanyaan paling umum soal OPcache di WordPress, dirangkum dari kebingungan yang sering muncul saat setup server.
Apakah OPcache memakan banyak RAM?
Tidak harus. Konsumsinya mengikuti nilai opcache.memory_consumption, umumnya puluhan sampai ratusan megabyte. Pantau memori terpakai di Site Health dan naikkan bertahap bila penuh. Sisakan ruang untuk PHP dan database.
Apakah OPcache menggantikan plugin cache?
Tidak. Plugin page cache menghasilkan HTML untuk pengunjung anonim, sedangkan OPcache mempercepat eksekusi kode PHP di semua request. Keduanya bekerja berlapis dan saling melengkapi, bukan saling menggantikan.
Bagaimana cara mengecek OPcache aktif di hosting?
Buka Site Health lalu tab Info, atau buat halaman phpinfo() sementara dan cari blok OPcache. Langkah ini adalah bagian awal cara setting opcache wordpress yang benar sebelum mengubah nilai apa pun.
Apakah sering mereset OPcache berbahaya?
Reset sesekali aman dan memang dibutuhkan setelah deploy besar. Yang merugikan adalah reset berkala tanpa sebab, karena bytecode yang masih berguna ikut dibuang dan CPU kembali sibuk mengompilasi.
