Kalau kamu baru pasang Cloudflare di situs WordPress dan berharap skor PageSpeed langsung melompat cuma dengan mengaktifkan semua toggle yang kelihatan “berhubungan dengan kecepatan”, saya punya kabar kurang enak: sebagian toggle itu justru bikin situsmu lebih lambat. Bukan sedikit — beberapa di antaranya bisa menambah dua detik penuh waktu blocking di browser pengunjung, dan kamu tidak akan tahu penyebabnya kalau cuma lihat dashboard Cloudflare yang isinya centang hijau di mana-mana.

Cloudflare itu produk yang aneh dari sisi UX: dia menaruh fitur security dan fitur performance bersebelahan, dengan nama yang sama-sama terdengar teknis dan meyakinkan, padahal efeknya ke pengunjung situsmu bisa berlawanan arah. Bot Fight Mode kedengarannya seperti hal bagus untuk keamanan — dan memang begitu — tapi dia melakukannya dengan cara menyuntikkan script yang menghabiskan waktu CPU pengunjung sebelum halaman bisa diklik. Rocket Loader kedengarannya seperti solusi ajaib untuk JavaScript yang lambat, padahal caranya justru mematikan mekanisme Back-Forward Cache di browser modern.

Tulisan ini bukan daftar “10 setting Cloudflare wajib aktif” generik yang biasa kamu temukan di hasil pencarian. Ini hasil ngoprek langsung setting per setting, dicek efeknya satu-satu, dengan alasan kenapa direkomendasikan atau tidak — termasuk kapan justru sebaiknya kamu skip sebuah fitur meskipun kelihatannya menarik.

Kenapa Cloudflare Saja Tidak Otomatis Bikin Cepat

Ini kesalahan paling umum: orang pasang Cloudflare, ganti nameserver, lalu menganggap tugas selesai. Padahal secara default, banyak fitur performance di Cloudflare itu off, dan beberapa fitur yang on secara default justru bukan yang paling optimal untuk kombinasi WordPress + shared hosting.

Cloudflare pada dasarnya cuma proxy — dia duduk di antara pengunjung dan servermu. Kalau kamu tidak memberitahu dia aturan main yang jelas (halaman mana yang boleh di-cache, berapa lama, kapan harus dilewati), dia akan mengambil keputusan default yang aman tapi generik: bekerja untuk semua jenis situs, tapi optimal untuk tidak satu pun.

Jadi sebelum masuk ke daftar setting, satu hal yang perlu dipahami dulu: Cloudflare punya dua sistem cache yang berbeda dan sering bikin bingung. Ada Cache Level (pengaturan lama, cuma soal query string) dan ada Cache Rules (sistem baru, bisa dikondisikan berdasarkan cookie, path, method). Kalau kamu sudah pasang Cache Rule untuk bypass halaman login/keranjang belanja, Cache Rule itu yang menang duluan untuk request yang cocok — baru sisanya jatuh ke aturan Cache Level biasa. Dua sistem ini saling melengkapi, bukan saling menggantikan.

Speed → Optimization: Mana yang Beneran Membantu

Auto Minify — Aktifkan HTML Saja

Auto Minify menghapus spasi dan komentar berlebih dari HTML, CSS, dan JavaScript sebelum dikirim ke pengunjung. Kedengarannya sepele, tapi untuk HTML ini murni untung tanpa risiko — tidak ada logic yang bisa rusak dari menghapus spasi kosong di markup.

Untuk CSS dan JavaScript, ceritanya beda kalau situsmu sudah punya plugin optimasi yang melakukan minifikasi di level server sebelum file itu sampai ke Cloudflare. Kalau begitu, minify CSS/JS di Cloudflare cuma kerja dua kali untuk hasil yang sama — tidak merusak, tapi tidak menambah manfaat juga. Kalau kamu tidak punya proses minifikasi apa pun di sisi WordPress, silakan aktifkan ketiganya sekaligus.

Rekomendasi: HTML selalu ON. CSS/JS ikut kondisi — ON kalau belum ada minifikasi di origin, OFF kalau sudah ada.

Rocket Loader — Ini yang Paling Sering Disalahpahami

Rocket Loader menunda eksekusi semua JavaScript di halaman, lalu menyuntikkannya kembali beberapa saat setelah halaman dimuat. Idenya bagus di atas kertas: biar rendering HTML tidak terhambat script yang berat. Tapi implementasinya punya dua masalah serius.

Pertama, Rocket Loader tidak membedakan mana script yang penting dan mana yang tidak. Dia menunda semuanya secara merata, lalu menyuntikkan ulang tanpa mempertimbangkan prioritas — beda dengan pendekatan defer/async manual yang bisa kamu atur sesuai kepentingan tiap script.

Kedua, dan ini yang jarang dibahas: Rocket Loader menggunakan event handler unload untuk mekanismenya. Event ini sudah lama dianggap deprecated oleh browser modern, dan penggunaannya secara otomatis mematikan Back-Forward Cache (bfcache) — fitur yang membuat tombol back/forward browser terasa instan karena halaman diambil dari memori, bukan di-load ulang dari nol. Kalau Rocket Loader aktif, setiap kali pengunjung menekan tombol back, mereka akan mengalami full page reload, bukan restore instan. Ini penalti nyata untuk pengalaman navigasi, dan Google secara eksplisit menghitung bfcache sebagai bagian dari penilaian performa.

Rekomendasi: matikan, kecuali situsmu memang tidak punya cara lain untuk mengatur defer/async script satu per satu.

Polish — Kompresi Gambar di Level Edge

Polish mengompres gambar yang sudah tersimpan di Cloudflare, menghapus metadata, dan bisa mengonversinya ke WebP. Ini fitur berbayar (Pro ke atas) di kebanyakan paket Cloudflare saat ini.

Kalau kamu sudah punya konversi WebP di sisi WordPress — baik lewat plugin bawaan atau fitur built-in di tool optimasi yang kamu pakai — manfaat tambahan dari Polish jadi lebih tipis, karena gambar yang dikirim ke Cloudflare sudah dalam format yang efisien duluan. Polish lebih berguna untuk situs yang gambar originalnya masih mentah (JPEG/PNG besar tanpa optimasi apa pun sebelumnya).

Rekomendasi: kalau berlangganan paket yang mendukung, aktifkan dengan pilihan “Lossy WebP”. Kalau sudah ada konversi WebP di origin, ini jadi opsional, bukan prioritas.

Mirage — Sudah Tidak Ada

Kalau kamu baca panduan lama yang menyebut Mirage sebagai fitur “wajib aktif untuk optimasi gambar berbasis kondisi jaringan”, abaikan saja — fitur ini sudah dihentikan sepenuhnya oleh Cloudflare pada pertengahan September 2025 dan otomatis nonaktif di semua domain. Alasannya masuk akal: implementasinya justru memblokir gambar sampai kecepatan jaringan pengunjung selesai diukur, yang dalam praktiknya sering menyebabkan Cumulative Layout Shift dan memperlambat Largest Contentful Paint — kebalikan dari tujuan awalnya. Browser modern sudah punya loading="lazy" bawaan yang jauh lebih ringan.

Speed Brain — Boleh Dibiarkan Default

Speed Brain memanfaatkan Speculation Rules API untuk mem-prefetch halaman yang kemungkinan besar akan diklik pengunjung berikutnya, tersedia di semua paket termasuk gratis. Levelnya konservatif — cuma prefetch kalau pengunjung sudah terlihat mengarah ke sebuah link (misalnya hover di desktop).

Kalau kamu punya waktu untuk konfigurasi Speculation Rules secara manual, hasilnya bisa lebih presisi karena kamu bisa menentukan sendiri URL mana yang diprioritaskan dan level agresivitasnya. Tapi untuk kebanyakan situs yang tidak punya waktu mengurus itu, membiarkan Speed Brain aktif tetap lebih baik daripada tidak ada speculative loading sama sekali.

Rekomendasi: biarkan default ON kalau tidak berencana setting manual.

Early Hints — Sering Diaktifkan Padahal Tidak Berdampak

Ini bagian yang sering bikin orang salah paham. Early Hints bekerja dengan cara membaca header HTTP Link: yang dikirim origin-mu, lalu meneruskannya ke browser lebih awal (status 103) sebelum body HTML selesai dikirim — supaya browser bisa mulai download resource penting (font, CSS, gambar LCP) lebih cepat.

Masalahnya: kebanyakan plugin optimasi WordPress mengeluarkan resource hint sebagai tag di dalam HTML, bukan sebagai header HTTP. Kalau begitu situasinya, Early Hints tidak punya apa pun untuk dibaca — dia menunggu header Link: yang tidak pernah dikirim origin, sehingga fitur ini jadi tidak berbuat apa-apa, baik untung maupun rugi.

Cara mengecek situsmu sendiri gampang, tinggal jalankan dari terminal:

curl -sI https://situsmu.com/ | grep -i "^link:"

Kalau hasilnya kosong, berarti resource hint di situsmu semuanya lewat HTML, bukan header — dan Early Hints tidak akan memberi manfaat apa pun sampai ada perubahan di sisi origin yang benar-benar mengirim header tersebut. Jangan aktifkan fitur ini cuma karena “kedengarannya berhubungan dengan kecepatan” tanpa mengecek dulu apakah originmu memang mengirim sinyal yang dibutuhkan.

Rekomendasi: cek dulu dengan curl. Aktifkan hanya kalau memang ada header Link: yang keluar dari origin.

Automatic Platform Optimization (APO) untuk WordPress

APO menyimpan seluruh halaman di edge Cloudflare — full-page caching di level CDN. Ini bisa memangkas Time to First Byte secara signifikan untuk pengunjung yang mendapat versi cache-nya.

Tantangannya: APO harus otomatis melewati cache begitu ada tanda personalisasi (cookie login, cookie keranjang belanja) karena kontennya sudah tidak generik lagi untuk visitor itu. Karena APO dirancang untuk bekerja di semua jenis situs WordPress tanpa terkecuali, aturan bypass-nya cenderung dibuat lebih luas dari yang sebenarnya kamu butuhkan — akibatnya cache hit ratio bisa lebih rendah dari yang seharusnya kalau kamu atur sendiri.

Kalau kamu sudah (atau berencana) mengatur Cache Rule sendiri dengan kondisi bypass yang presisi sesuai struktur situsmu — misalnya cuma bypass untuk cookie tertentu, path tertentu, dan method tertentu — itu akan memberi kontrol yang lebih baik dibanding APO yang generik.

Rekomendasi: APO tetap pilihan valid kalau ingin cepat tanpa konfigurasi manual. Tapi kalau sudah punya Cache Rule sendiri yang presisi, itu biasanya lebih baik.

Network: Tiga Toggle Tanpa Risiko

HTTP/2, HTTP/2 to Origin, dan Enhanced HTTP/2 Prioritization sudah selayaknya diaktifkan semua — protokol ini sudah berumur lebih dari sepuluh tahun, didukung luas oleh browser dan server, dan menghilangkan masalah “staircase effect” dari HTTP/1.1 di mana file harus dimuat satu per satu secara berurutan.

HTTP/3 dengan QUIC selangkah lebih maju — menggabungkan proses handshake transport dan enkripsi jadi satu, yang bisa memangkas waktu koneksi awal secara nyata, terutama untuk pengunjung dengan koneksi mobile yang latensinya lebih tinggi. Cukup signifikan sampai ke angka dua digit persen lebih cepat untuk Time to First Byte pada kondisi tertentu.

0-RTT Connection Resumption melengkapi ini — untuk pengunjung yang sudah pernah membuka situsmu sebelumnya, koneksi berikutnya bisa langsung mengirim data tanpa menunggu handshake ulang, karena kunci enkripsi sebelumnya masih tersimpan.

Rekomendasi: aktifkan semuanya. Tidak ada trade-off yang perlu dipikirkan di sini.

Brotli — algoritma kompresi yang menghasilkan file lebih kecil dibanding Gzip — biasanya sudah aktif secara default di paket gratis dan Pro. Tinggal pastikan saja tidak sengaja dimatikan.

Scrape Shield: Kebanyakan Justru Sebaiknya Dimatikan

Email Address Obfuscation terdengar seperti fitur privasi yang bagus — menyembunyikan alamat email dari bot scraper dengan menyamarkannya, lalu menampilkan versi asli lewat JavaScript begitu halaman dimuat. Masalahnya, scraper yang serius sudah lama tidak terganggu oleh trik semacam ini, sementara pengunjung asli mendapat beban script tambahan yang tidak perlu untuk sesuatu yang bisa dicapai dengan cara lain (misalnya form kontak, atau alamat email dalam bentuk gambar kalau memang perlu disembunyikan).

Hotlink Protection berbeda karakternya — ini murni pengaturan server-side yang mencegah situs lain menampilkan gambarmu langsung dari server kamu (mencuri bandwidth). Fitur ini tidak menambah beban JavaScript apa pun ke pengunjung, jadi tidak ada trade-off pagespeed di sini. Aktifkan atau tidak, murni tergantung apakah kamu punya masalah bandwidth gambar dicuri situs lain.

Rekomendasi: matikan Email Address Obfuscation. Hotlink Protection bebas dipilih sesuai kebutuhan, tidak memengaruhi kecepatan.

Security: Trade-off yang Paling Sering Diabaikan

Ini bagian paling penting untuk dipahami, karena efeknya paling besar dan paling jarang disadari.

Bot Fight Mode dan Super Bot Fight Mode bekerja dengan menyuntikkan script bernama invisible.js ke setiap halaman, menjalankan semacam tantangan browser untuk membedakan manusia dari bot. Masalahnya, script ini bisa menambah lebih dari dua detik waktu eksekusi CPU di setiap page load — dua detik penuh main thread ter-blok sebelum halaman benar-benar bisa merespons interaksi pengunjung. Dalam praktik, ini bisa menjatuhkan skor PageSpeed sampai dua puluh poin atau lebih. Ironisnya, fitur yang dirancang untuk menghalangi bot ini justru menghukum setiap pengunjung asli yang datang.

Kalau situsmu sedang menghadapi masalah keamanan nyata — serangan brute force, bot scraping agresif, atau riwayat percobaan eksploitasi — insting pertama biasanya “nyalakan semua proteksi yang ada”. Tapi untuk kasus semacam itu, WAF Managed Rules (tersedia bahkan di paket gratis) memberi proteksi yang setara tanpa menyuntikkan script ke browser pengunjung, karena WAF bekerja di level server sebelum request sampai ke origin — bukan lewat challenge di sisi client.

Rekomendasi: matikan Bot Fight Mode dan Super Bot Fight Mode. Kalau butuh proteksi bot, andalkan WAF Managed Rules atau rate limiting, bukan client-side challenge.

Caching → Configuration: Detail yang Sering Terlewat

Caching Level

Pengaturan ini menentukan bagaimana Cloudflare memperlakukan query string saat menentukan cache. Ada tiga pilihan: “Ignore Query String” (paling cepat tapi berisiko — menyajikan resource yang sama tanpa peduli isi query string-nya), “Standard” (default, menyimpan cache terpisah untuk tiap kombinasi query string berbeda), dan opsi ketiga yang sebaiknya dihindari sama sekali.

“Ignore Query String” cuma aman kalau kamu betul-betul yakin situsmu tidak pernah bergantung pada query string untuk konten yang berbeda. Untuk kebanyakan situs WordPress dengan pencarian, filter produk, atau parameter kampanye (utm_source dan sejenisnya), opsi ini bisa membuat pengunjung melihat cache yang salah.

Justru masalah yang lebih umum ada di “Standard”: kombinasi cache penuh halaman plus parameter tracking seperti utm_campaign bisa membuat satu URL yang sama secara konten disimpan sebagai puluhan versi cache berbeda hanya karena parameter tracking-nya beda-beda — menurunkan cache hit ratio tanpa manfaat nyata. Solusi yang lebih presisi untuk masalah ini adalah menyaring parameter tracking sebelum masuk ke logika cache, tapi itu topik konfigurasi tersendiri yang lebih teknis.

Rekomendasi: “Standard” untuk kebanyakan situs. Hindari “Ignore Query String” kecuali sudah dipastikan situsmu tidak bergantung pada query string sama sekali.

Browser Cache TTL

Setting ini memberitahu browser pengunjung berapa lama boleh menyimpan resource statis di penyimpanan lokal mereka sebelum meminta ulang ke server. Kalau ada pilihan “Respect Existing Headers” di paketmu, itu pilihan terbaik — karena membiarkan header Cache-Control yang sudah diatur per jenis file dari origin (misalnya gambar disimpan setahun, CSS/JS disimpan sebulan) yang menentukan, bukan satu angka pukul rata dari Cloudflare untuk semua jenis file.

Kalau opsi itu tidak tersedia di paketmu, atur ke durasi maksimum yang disediakan — asalkan file statismu memang jarang berubah tanpa berganti nama file.

Rekomendasi: “Respect Existing Headers” kalau tersedia. Kalau tidak, set ke maksimum.

Development Mode

Fitur ini melewati seluruh cache Cloudflare selama aktif — termasuk untuk semua pengunjung lain, bukan cuma kamu. Godaan untuk menyalakannya saat sedang mengubah tampilan atau mengetes sesuatu itu wajar, tapi efeknya adalah semua pengunjung ikut merasakan situs jadi lambat selama fitur ini aktif.

Cara yang lebih benar: siapkan domain terpisah untuk development, atau buat Cache Rule khusus yang mengecualikan IP-mu sendiri dari cache — bukan mematikan cache untuk seluruh dunia.

Rekomendasi: jangan pernah nyalakan di domain production.

Tiered Cache: Fitur yang Sering Terlewat Padahal Gratis

Tiered Cache mengurangi jumlah request yang benar-benar sampai ke servermu, dengan cara membuat Cloudflare mengecek dulu ke server Cloudflare lain sebelum menyerah dan bertanya ke origin. Ini membebaskan beban tambahan dari server asalmu — yang sangat terasa manfaatnya kalau kamu jalan di shared hosting dengan resource terbatas, bukan server dedicated dengan kapasitas berlebih.

Rekomendasi: aktifkan “Smart Tiered Caching Topology”.

Cache Rule untuk Full-Page Caching: Kenapa Ini Beda dari Setting di Atas

Semua setting di atas ada di area “Speed” dan “Caching → Configuration” dashboard Cloudflare. Tapi kalau tujuanmu adalah full-page caching HTML — bukan cuma cache asset statis — itu butuh Cache Rule tersendiri di menu Caching → Cache Rules, dan ini area yang paling mudah salah konfigurasi kalau tergesa-gesa.

Prinsip dasarnya sederhana: buat satu rule paling atas yang mem-bypass cache untuk request yang mengandung tanda personalisasi — cookie login, cookie keranjang belanja, cookie session, method selain GET, atau path menuju area admin. Baru setelah itu, buat rule kedua di bawahnya yang menyatakan sisa request lain boleh di-cache, dengan Edge Cache TTL mengikuti header Cache-Control dari origin.

Urutan ini penting karena Cache Rule dievaluasi dari atas ke bawah, dan begitu satu rule cocok, evaluasi berhenti di situ. Kalau rule bypass diletakkan di bawah rule cache-semua, maka rule bypass itu tidak akan pernah sempat dievaluasi untuk request yang sudah lebih dulu cocok dengan rule di atasnya.

Verifikasi paling gampang untuk mengecek Cache Rule sudah bekerja benar: buka halaman di mode incognito (supaya tidak ada cookie login), lalu jalankan:

curl -sI https://situsmu.com/ | grep -i "cf-cache-status"

Kunjungan pertama biasanya menunjukkan MISS (belum ada di cache edge), kunjungan kedua ke halaman yang sama akan menunjukkan HIT. Kalau kamu login lalu jalankan curl yang sama dengan cookie sesi kamu, hasilnya harus tetap BYPASS atau DYNAMIC — kalau ternyata ikut HIT, berarti rule bypass-mu belum bekerja dan itu masalah serius yang harus segera diperbaiki sebelum data pengunjung lain bocor ke visitor berikutnya.

Kesalahan yang Paling Sering Terjadi

Dari semua yang dibahas di atas, ada beberapa pola kesalahan yang berulang:

Menyalakan semua fitur “performance” tanpa membaca cara kerjanya. Rocket Loader adalah contoh paling jelas — namanya menjanjikan kecepatan, tapi caranya kerja justru mematikan fitur browser yang sudah bagus (bfcache).

Menganggap Bot Fight Mode itu gratis-tanpa-konsekuensi karena “cuma untuk keamanan”. Setiap fitur yang menyuntikkan JavaScript ke browser pengunjung punya biaya performa, tidak peduli tujuannya sebaik apa.

Purge cache berlebihan. Setiap kali cache di-purge, situs jadi lebih lambat sementara sampai cache-nya terisi ulang. Kalau kamu terbiasa purge seluruh cache tiap kali ada perubahan kecil, itu justru membuat pengunjung lebih sering mendapat versi belum ter-cache. Purge yang presisi — cuma file yang benar-benar berubah — jauh lebih baik dibanding purge semua secara rutin.

Mengaktifkan Early Hints tanpa mengecek dulu apakah origin memang mengirim header yang dibutuhkan. Seperti dijelaskan di awal, fitur ini bisa aktif tanpa error apa pun sambil tidak melakukan apa-apa — bukan karena rusak, tapi karena tidak ada bahan untuk diproses.

Mengatur Browser Cache TTL ke satu angka pukul-rata padahal origin sudah mengatur TTL berbeda per jenis file. Kalau originmu sudah cukup pintar membedakan cache gambar dan cache CSS/JS, biarkan Cloudflare menghormati itu daripada menimpanya dengan satu angka generik.

Ringkasan Checklist

Kalau mau versi singkat untuk langsung dicentang satu-satu di dashboard:

Auto Minify: HTML on, CSS/JS sesuai kondisi origin
Rocket Loader: off
Polish: on (kalau paket mendukung) dengan Lossy WebP
Early Hints: cek dulu dengan curl, baru putuskan
Speed Brain: biarkan default
HTTP/2, HTTP/2 to Origin, HTTP/3, 0-RTT: semua on
Brotli: pastikan tetap on
Email Address Obfuscation: off
Bot Fight Mode / Super Bot Fight Mode: off, pakai WAF Managed Rules sebagai gantinya
Caching Level: Standard
Browser Cache TTL: Respect Existing Headers (kalau ada), atau maksimum
Development Mode: jangan pernah di production
Smart Tiered Caching Topology: on
Cache Rule bypass login/cart: pastikan urutannya paling atas, dan tervalidasi lewat curl secara berkala

Tidak ada satu pun dari daftar ini yang butuh upgrade paket mahal untuk sebagian besar poinnya — mayoritas justru tersedia di paket gratis. Yang dibutuhkan cuma waktu untuk memahami kenapa sebuah fitur direkomendasikan atau tidak, bukan sekadar menyalakan semua toggle yang kelihatan menjanjikan.

0 0 ulasan

Beri rating