Saya Kira Masalahnya di Database, Ternyata Bukan

Kalau WordPress admin kamu terasa berat saat edit halaman, kemungkinan besar penyebabnya bukan satu hal tapi kombinasi beberapa faktor yang saling memperparah. Ini cerita dari proyek optimasi yang baru saja saya kerjakan, dan hasilnya cukup signifikan: load time turun dari 7.95 detik ke 1.70 detik, query database turun dari 192 ke 52.

Situasinya

Client punya website industrial yang berjalan di Cloudways. Theme-nya Avada, plugin cukup banyak. Masalah yang dilaporkan: admin backend terasa sangat lambat, terutama halaman daftar pages dan saat edit halaman.

Dari Cloudways support sudah ada petunjuk awal: masalahnya ada di AJAX, terutama dari plugin Avada Core. Di PHP slow log juga sudah kelihatan nama file-nya: fusion-faq.php dan fusion-form-component.php.

Saya mulai investigasi dari staging site supaya tidak ganggu production.

Diagnosis: Pakai Query Monitor

Langkah pertama pasang Query Monitor untuk lihat apa yang sebenarnya terjadi. Hasilnya di halaman edit.php?post_type=page:

• Load time: 7.95 detik
• Memory: 169.7 MB
• Queries: 192

Angka query 192 untuk halaman list pages itu banyak. Tapi setelah saya lihat detail waktunya, total waktu eksekusi query hanya 0.04 detik. Database bukan bottleneck-nya. Masalahnya ada di PHP execution dan AJAX.

Saya cek Network tab di browser DevTools, filter ke /admin-ajax.php. Di halaman editor, ketemu dua AJAX request dari Avada:

• fusion_get_webfonts_ajax — fetch daftar Google Fonts setiap halaman editor dibuka
• fusion_get_widget_form — load semua widget forms Avada

Kedua request ini berat dan dipanggil setiap kali ada yang buka halaman editor. Kalau user buka 3-4 tab sekaligus, CPU langsung 100%.

Fix Pertama: Heartbeat API

WordPress punya fitur Heartbeat API, semacam “detak jantung” yang terus-menerus ping server dari browser. Defaultnya aktif di mana-mana: dashboard, editor, frontend.

Saya pasang plugin Heartbeat Control by WP Rocket dan set:

• WordPress Dashboard: Disable
• Frontend: Disable
• Post editor: Modify, interval 60 detik

Hasilnya langsung kelihatan. Load time turun dari 7.95s ke 1.83s hanya dari perubahan ini.

Fix Kedua: Redis Object Cache

Server di Cloudways ternyata sudah punya Redis running tapi belum dikoneksikan ke WordPress. Redis adalah in-memory cache, hasil query database disimpan di RAM, jadi request berikutnya tidak perlu proses ulang dari MySQL.

Caranya:

1. Pastikan Redis service running di Cloudways lewat menu Manage Services
2. Install plugin Redis Object Cache by Till Krüss di WordPress
3. Masuk ke Settings > Redis > klik Enable Object Cache
4. Untuk konfigurasi koneksi, Cloudways sudah otomatis inject kredensial Redis ke wp-config.php lewat array $_SERVER, tidak perlu tambah define manual

Setelah Redis aktif, query turun dari 192 ke 52. Mayoritas DB query sekarang di-serve dari cache, tidak hit MySQL.

Fix Ketiga: Disable Avada Elements yang Tidak Dipakai

Ini yang paling langsung menyentuh akar masalahnya. Avada punya fitur untuk disable elements yang tidak dipakai. Setiap element yang aktif akan di-load saat fusion_get_widget_form dipanggil, meski element itu tidak pernah dipakai di site tersebut.

Caranya lewat Avada > Performance > Elements.

Dari PHP slow log Cloudways, yang paling bermasalah adalah Avada Form (fusion-form-component.php) dan FAQ (fusion-faq.php). Keduanya di-uncheck. Untuk site industrial seperti ini, kedua element itu memang tidak dipakai sama sekali.

Fix Keempat: Patch di Child Theme functions.php

Meski sudah disable dari UI Avada, AJAX request fusion_get_webfonts_ajax masih tetap berat karena Avada fetch daftar Google Fonts dari external API setiap kali dipanggil tanpa cache. Saya tambahkan beberapa kode di avada-child/functions.php untuk handle ini.

// =============================================
// FIX: Cache Avada AJAX - webfonts & widget form
// Prevents CPU spike from repeated heavy AJAX calls
// =============================================

// 1. Cache fusion_get_webfonts_ajax (12 jam)
add_action( 'wp_ajax_fusion_get_webfonts_ajax', function() {
    $cache_key = 'fusion_webfonts_ajax_cache';
    $cached = get_transient( $cache_key );
    if ( false !== $cached ) {
        header( 'Content-Type: application/json' );
        echo $cached;
        wp_die();
    }
}, 1 );

// Cache hasil webfonts setelah di-fetch
add_filter( 'fusion_webfonts_data', function( $data ) {
    set_transient( 'fusion_webfonts_ajax_cache', wp_json_encode( $data ), 12 * HOUR_IN_SECONDS );
    return $data;
} );

// 2. Backup heartbeat throttle di editor (60 detik)
add_filter( 'heartbeat_settings', function( $settings ) {
    $settings['interval'] = 60;
    return $settings;
} );

// 3. Disable Avada elements lewat filter sebagai backup dari UI setting
add_filter( 'fusion_builder_elements', function( $elements ) {
    $disable = array(
        'fusion_faq',
        'fusion_form',
        'fusion_tb_section',
    );
    foreach ( $disable as $element ) {
        unset( $elements[ $element ] );
    }
    return $elements;
} );

Ada tiga hal yang dilakukan kode ini:

Cache webfonts. fusion_get_webfonts_ajax sebelumnya fetch ulang daftar Google Fonts dari API eksternal setiap request. Dengan transient 12 jam, request kedua dan seterusnya langsung ambil dari cache WordPress, tidak keluar ke internet lagi.

Backup throttle heartbeat. Meski sudah pakai plugin Heartbeat Control, filter ini jadi lapisan kedua supaya interval editor tidak balik ke default kalau plugin suatu saat nonaktif.

Disable elements via filter. Ini backup dari setting UI Avada. Kalau setting di dashboard Avada ter-reset karena update atau alasan lain, filter ini tetap aktif karena ada di functions.php.

Hasil Akhir

Yang Saya Pelajari dari Proyek Ini

Jangan langsung salahkan database. Refleks pertama banyak orang saat WordPress lambat adalah optimasi query. Di kasus ini total waktu query cuma 44ms, database sudah cepat. Masalahnya ada di tempat lain.

Heartbeat API sering diabaikan. Ini salah satu quick win terbesar yang jarang diperhatikan. Dengan satu plugin dan beberapa klik, load time langsung turun drastis.

Avada Builder berat secara default. Semua element di-load meski tidak dipakai. Kalau pakai Avada, luangkan waktu untuk review halaman Performance Wizard dan disable element yang tidak relevan dengan jenis site-nya.

PHP slow log itu sangat membantu. Cloudways menyediakan akses ke PHP slow log dan dari situ langsung kelihatan file mana yang jadi bottleneck. Kalau ada akses ke log ini, selalu mulai investigasi dari sana.

Setting di UI saja tidak cukup. Beberapa perubahan di dashboard Avada bisa ter-reset saat update. Backup penting lewat functions.php supaya fix tetap aktif meski ada perubahan di plugin.