Ada anggapan yang sudah terlalu lama dipercaya orang: makin banyak toggle security yang dinyalakan, situs makin aman, titik. Anggapan itu tidak salah soal keamanannya — tapi salah kalau dikira semua toggle itu “gratis” dari sisi performa. Sebagian item di menu Security Cloudflare benar-benar tidak menyentuh browser pengunjung sama sekali (murni keputusan di server), sementara sebagian lain justru menyuntikkan JavaScript yang berjalan di perangkat setiap orang yang membuka situsmu — dan dua jenis ini kelihatannya sama-sama “cuma toggle” di dashboard, padahal konsekuensinya jauh berbeda.
Tulisan ini membedah menu Security Cloudflare per kategori, persis seperti yang ditampilkan di halaman Settings dashboard-nya — Bot Traffic, Client Side Abuse, DDoS Attacks, Fraud, Precursor, Web Application Exploits, dan API Abuse — dengan satu pertanyaan yang sama untuk tiap item: ini keputusan yang diambil server, atau ini kode yang dikirim ke browser pengunjung?
Prinsip yang Membedah Semuanya
Sebelum masuk ke daftar, satu prinsip ini yang menjelaskan kenapa dua fitur yang kelihatannya mirip bisa punya dampak pagespeed yang jauh berbeda.
Kalau sebuah fitur keamanan bekerja dengan cara menganalisis request sebelum sampai ke origin-mu — mengecek header HTTP, IP asal, reputasi ASN, pola traffic — itu semua terjadi di infrastruktur Cloudflare, sebelum satu byte pun dikirim ke browser pengunjung. Pengunjung normal tidak merasakan apa pun; yang kena efeknya cuma traffic yang memang mencurigakan, dan itu pun cuma berupa halaman blokir atau tantangan, bukan beban tambahan untuk visitor yang lolos.
Sebaliknya, kalau sebuah fitur bekerja dengan cara menyuntikkan script ke HTML yang dikirim ke SEMUA pengunjung — untuk memantau perilaku mereka, menjalankan tantangan tersembunyi, atau mengumpulkan sinyal browser — maka setiap pengunjung, termasuk manusia asli yang cuma mau baca artikel atau checkout belanja, ikut menanggung biaya eksekusi script itu. Biayanya bisa berbentuk waktu CPU yang terpakai sebelum halaman bisa merespons klik, atau memori yang dipakai script yang jalan terus-menerus di background selama sesi kunjungan.
Dengan prinsip ini di kepala, mari bedah tiap kategori.
Bot Traffic
Configure AI Bot Policies
Ini bukan toggle on/off, tapi panel konfigurasi (di dashboardmu tertulis ada 4 pengaturan) untuk menentukan bagaimana bot AI — crawler untuk training model, crawler untuk fitur “answer engine” seperti yang dipakai chatbot AI mencari jawaban di web — boleh mengakses situsmu. Keputusan ini murni soal siapa boleh masuk, dievaluasi di edge Cloudflare berdasarkan identitas bot yang meminta, tidak pernah menyentuh browser pengunjung manusia sama sekali. Aman untuk pagespeed, murni soal kebijakan konten kamu terhadap AI crawler.
AI Labyrinth (Beta)
Fitur ini menambahkan link nofollow berisi konten hasil AI ke halaman-halamanmu, dengan tujuan membingungkan bot yang mengabaikan aturan crawling (robots.txt) — bot semacam itu akan tersesat mengikuti link palsu yang tidak pernah berujung pada apa pun. Link ini disebut Cloudflare “tidak mengubah konten halaman dan hanya terlihat oleh bot”, artinya secara visual tidak tampil ke pengunjung manusia biasa. Dampak ke pagespeed nyaris tidak ada — beberapa markup link tersembunyi tidak sebanding dengan beban eksekusi JavaScript. Aman dinyalakan kalau kamu memang punya masalah bot scraper yang mengabaikan aturan crawl; kalau tidak, boleh dibiarkan mati juga tanpa rugi apa-apa.
Bot Fight Mode
Ini yang sudah pernah kita bahas panjang: fitur ini menyuntikkan script invisible.js ke SETIAP halaman untuk menjalankan tantangan verifikasi di browser setiap pengunjung. Ini murni client-side, dan bisa menambah waktu blocking CPU yang signifikan sebelum halaman benar-benar responsif — dalam kasus yang parah, penalti skor PageSpeed bisa mencapai dua puluh poin lebih. Matikan, andalkan Cloudflare Managed Ruleset dan Browser Integrity Check sebagai gantinya — dua-duanya server-side, memberi proteksi setara tanpa menghukum pengunjung asli.
Challenge Passage
Ini bukan fitur berdiri sendiri — ini pengaturan durasi, menentukan berapa lama seorang pengunjung yang sudah lolos satu tantangan (dari Bot Fight Mode, WAF rule, atau mekanisme challenge lain) tidak perlu ditantang ulang. Kalau semua sumber tantangan di situsmu sudah dimatikan, pengaturan durasi ini praktis tidak pernah terpakai. Tidak ada dampak pagespeed independen dari pengaturan ini sendiri.
Cloudflare Managed Ruleset
Ini yang direkomendasikan sebagai pengganti Bot Fight Mode — seperangkat aturan WAF (Web Application Firewall) yang dikelola langsung oleh tim Cloudflare, dievaluasi di edge sebelum request sampai ke server asalmu. Ruleset ini mendeteksi pola serangan umum: SQL injection, path traversal, eksploitasi plugin/CMS yang dikenal, dan pola traffic bot yang mencurigakan — semuanya lewat analisis request, bukan lewat kode yang dijalankan di browser. Selalu aktif (“Always active”) memang bukan pilihan yang bisa dimatikan sepenuhnya, dan itu justru bagus — nol biaya pagespeed, proteksi nyata.
Client Side Abuse
Nama kategorinya sendiri agak menjebak — “client side abuse” ini soal melindungi situsmu dari penyalahgunaan yang menyasar sisi client (pencurian konten, harvesting email, hotlinking gambar), bukan berarti fitur di dalamnya semuanya berjalan di client.
Continuous Script Monitoring
Fitur ini memantau file JavaScript di situsmu untuk mendeteksi perubahan yang tidak wajar — script yang tiba-tiba dimodifikasi, disuntik kode asing, atau berubah tanpa sepengetahuanmu (pola klasik serangan supply-chain atau skimmer pencuri data kartu kredit). Monitoring ini berjalan di sisi Cloudflare, membandingkan hash/isi script dari waktu ke waktu — bukan menambahkan kode apa pun ke halaman yang dikirim ke pengunjung. Nol dampak pagespeed, dan untuk situs yang punya riwayat kena malware berulang, ini termasuk fitur yang seharusnya dinyalakan dari awal, bukan ditunda.
Email Address Obfuscation
Menyembunyikan alamat email di halamanmu dari bot scraper dengan menyamarkannya lewat JavaScript, lalu menampilkan versi asli setelah halaman dimuat di browser pengunjung. Scraper yang serius sudah lama tidak terhalang trik semacam ini, sementara setiap pengunjung asli tetap menanggung beban script tambahan untuk sesuatu yang manfaatnya sudah menipis. Matikan — kalau memang perlu menyembunyikan email dari bot, cara yang lebih baik adalah form kontak atau menampilkannya sebagai gambar.
Hotlink Protection
Mencegah situs lain menampilkan gambarmu langsung dari server kamu (mencuri bandwidth tanpa izin) — keputusan ini dibuat di level server berdasarkan header Referer request, tidak menambahkan JavaScript apa pun ke halaman. Nol dampak pagespeed. Aktifkan kalau memang pernah mengalami masalah gambar “dicuri” situs lain; kalau belum pernah jadi masalah, boleh dibiarkan mati.
DDoS Attacks
Beberapa item di kategori ini adalah kategori toggle yang sama seperti di Bot Traffic (Bot Fight Mode, Challenge Passage, Cloudflare Managed Ruleset) — Cloudflare menampilkannya di dua tempat karena relevan untuk dua jenis serangan sekaligus. Yang murni baru di sini:
Browser Integrity Check
Ini sering disalahpahami sebagai “versi ringan Bot Fight Mode”, padahal cara kerjanya beda kelas. Fitur ini mengevaluasi header HTTP yang dikirim browser pengunjung — kombinasi User-Agent, Accept, Accept-Language, dan header lain yang biasanya konsisten pada browser sungguhan, tapi sering hilang atau janggal pada script otomatis sederhana. Evaluasi ini terjadi murni dari data yang SUDAH ADA di request — tidak ada script tambahan yang dikirim ke browser, tidak ada tantangan yang harus diselesaikan pengunjung. Kalau request-nya dari browser normal dengan header wajar, dia lewat tanpa terasa apa pun. Aman diaktifkan, dan justru salah satu fitur yang paling murah secara pagespeed untuk proteksi yang diberikan.
HTTP DDoS Attack Protection
Ruleset otomatis yang memitigasi serangan DDoS berbasis HTTP — analisis pola volume dan bentuk traffic di level jaringan, sepenuhnya di sisi Cloudflare. Untuk traffic normal (bukan sedang diserang), fitur ini transparan total, tidak ada overhead yang terasa. Bagian dari perlindungan dasar yang “selalu aktif”, dan memang seharusnya begitu.
Fraud
Leaked Credentials Detection
Mengecek upaya login terhadap database kredensial yang sudah bocor di internet (kombinasi username/password yang pernah muncul di kebocoran data lain) — kalau kombinasi yang dipakai pengunjung cocok dengan salah satu kebocoran itu, sistem bisa memblokir atau memberi peringatan. Pengecekan ini cuma berjalan pada request yang menuju endpoint otentikasi (halaman login), bukan di setiap halaman yang dibuka pengunjung — jadi dampaknya ke pagespeed keseluruhan situs adalah nol; yang terkena cuma proses login itu sendiri, dan itu pun cuma tambahan validasi server-side, bukan script di browser. Fitur bagus untuk diaktifkan, terutama kalau situsmu punya area login yang sering jadi target brute force.
Precursor — Kategori Baru yang Perlu Perhatian Ekstra
Precursor ini fitur paling baru di antara semua yang dibahas di sini (dirilis general availability pertengahan 2026), dan cara kerjanya berbeda dari semua fitur bot-detection yang lebih lama.
Kalau Bot Fight Mode melakukan satu kali pengecekan di awal kunjungan, Precursor bekerja dengan cara yang jauh lebih menyeluruh: begitu diaktifkan, Cloudflare menyuntikkan JavaScript ringan ke HTML yang dikirim ke pengunjung, dan script ini terus memantau sepanjang sesi kunjungan — bukan cuma sekali di awal. Ia merekam pola gerakan kursor, ritme mengetik, perilaku scroll, perubahan fokus jendela, dan durasi halaman terlihat, lalu mengirim sinyal-sinyal itu untuk dianalisis di edge Cloudflare secara real-time. Tujuannya masuk akal — bot generasi baru sudah bisa menjalankan JavaScript penuh, meniru browser asli, bahkan lolos CAPTCHA satu kali, tapi jauh lebih sulit meniru pola perilaku manusia yang konsisten sepanjang satu sesi penuh.
Dari sisi keamanan, ini pendekatan yang canggih. Dari sisi pagespeed, ini kategori risiko yang berbeda dari Bot Fight Mode — bukan cuma beban satu kali di awal render, tapi potensi beban yang menempel sepanjang kunjungan pengunjung, sekalipun Cloudflare mendeskripsikannya sebagai “ringan”. Precursor juga merupakan bagian dari paket Enterprise Bot Management — di paket Free atau Pro, toggle-nya mungkin kelihatan di dashboard, tapi secara fungsi kemungkinan besar tidak benar-benar aktif tanpa berlangganan tingkat itu.
Rekomendasi: biarkan mati. Situs skala UMKM/bisnis kecil pada umumnya belum menghadapi jenis bot canggih yang jadi target fitur ini, dan kombinasi Cloudflare Managed Ruleset plus Browser Integrity Check sudah menutup sebagian besar ancaman bot yang realistis dihadapi tanpa risiko beban berkelanjutan di sisi client.
Web Application Exploits
Cloudflare Managed Ruleset (lagi)
Sama seperti sebelumnya — WAF server-side, selalu aktif, nol biaya pagespeed.
IP Access Rules & IP Lists
Aturan berdasarkan alamat IP, negara asal, atau nomor ASN — semuanya keputusan yang diambil sebelum request menyentuh origin-mu. Berguna kalau kamu tahu pola serangan datang dari rentang IP atau negara tertentu yang memang tidak relevan dengan target pasarmu. Nol dampak pagespeed, tapi butuh konfigurasi manual sesuai kebutuhan — tidak ada rekomendasi generik “aktifkan semua”, karena aturan yang terlalu agresif bisa memblokir pengunjung asli.
Rate Limit Authentication Requests
Membatasi jumlah percobaan login dalam periode waktu tertentu, memakai template Leaked Credential Check yang sama dibahas di atas. Ini proteksi tambahan terhadap brute force, dievaluasi di edge sebelum sampai ke server, dan cuma berlaku untuk endpoint otentikasi — tidak menyentuh pagespeed halaman lain di situsmu.
Replace Insecure JavaScript Libraries
Fitur ini otomatis mengganti pustaka JavaScript versi lama yang punya kerentanan keamanan dikenal (kasus klasik: versi jQuery lama) dengan versi yang lebih baru dan aman, disajikan lewat CDN Cloudflare sendiri (didukung library seperti cdnjs). Yang menarik, dampaknya ke pagespeed cenderung netral sampai positif — bukan menambah beban, tapi mengganti satu file JS dengan file JS lain yang fungsinya setara namun lebih modern dan sering kali lebih ringan/lebih efisien. Aman diaktifkan, sekaligus menutup celah keamanan yang sering luput dari perhatian developer yang jarang mengaudit versi dependency lawas.
API Abuse
Kategori ini isinya cenderung lebih spesifik untuk situs yang punya API publik atau butuh verifikasi klien tingkat sertifikat — kurang relevan untuk kebanyakan situs WordPress biasa, tapi tetap layak dipahami sekilas.
Client Certificates & mTLS Rules
Mutual TLS (mTLS) adalah mekanisme di mana bukan cuma server yang membuktikan identitasnya ke klien (seperti SSL/TLS biasa), tapi klien juga harus membuktikan identitasnya ke server pakai sertifikat digital. Ini dipakai untuk skenario API-to-API yang butuh kepercayaan tingkat tinggi — bukan sesuatu yang relevan untuk trafik pengunjung web biasa. Tidak ada “on/off” sederhana di sini; ini infrastruktur yang perlu dibangun sesuai kebutuhan spesifik, dan kalau tidak pernah dipakai, tidak menyala sendiri dan tidak memengaruhi apa pun.
Custom Fallthrough Rules & Endpoint Labels
Alat untuk mengelola endpoint API yang tidak terdaftar di dashboard Web Assets (“zombie endpoint” — API lama yang lupa dinonaktifkan) dan pelabelan endpoint untuk kebutuhan organisasi. Murni alat manajemen, tidak berdampak ke pagespeed situs pengunjung biasa.
Cara Memverifikasi Sendiri Klaim di Atas
Tulisan ini penuh klaim “server-side, nol dampak” dan “client-side, ada biaya” — daripada percaya begitu saja, ada cara mudah mengecek sendiri mana yang benar-benar menambah beban di browser.
Buka DevTools browser (F12) → tab Network, lalu muat ulang halaman situsmu dalam kondisi belum login (mode incognito paling bersih). Perhatikan dua hal:
Pertama, jumlah request JavaScript yang ter-load dari domain challenges.cloudflare.com atau nama domain Cloudflare lain yang berhubungan dengan security. Kalau Bot Fight Mode atau Precursor aktif, biasanya akan terlihat request tambahan ke domain ini yang tidak ada saat fitur itu dimatikan — bandingkan sebelum dan sesudah toggle untuk melihat bedanya secara langsung.
Kedua, buka tab Performance, rekam saat halaman dimuat, lalu lihat bagian “Main” thread di flame chart. Kalau ada blok warna kuning (JavaScript execution) yang panjang dan tidak berhubungan dengan script situsmu sendiri, itu kandidat kuat dari fitur security yang menyuntik script tambahan. Cara ini jauh lebih meyakinkan dibanding cuma membaca deskripsi fitur di dashboard Cloudflare, karena kamu melihat langsung biayanya di browser, bukan cuma percaya nama fiturnya.
Untuk fitur yang saya klaim murni server-side (Browser Integrity Check, Managed Ruleset, IP Access Rules), cara membuktikannya justru dengan TIDAK menemukan apa-apa — nyalakan fitur itu, muat ulang, dan pastikan tidak ada request atau script baru yang muncul di Network/Performance tab dibanding sebelum dinyalakan. Kalau memang tidak ada perubahan sama sekali di sisi client, itu konfirmasi bahwa keputusannya betul-betul diambil di server sebelum request itu sampai ke browsermu.
Hubungannya dengan Cache Rule yang Sudah Kamu Pasang
Kalau kamu sudah mengikuti panduan Cache Rule dari artikel sebelumnya (bypass cache untuk cookie login/cart, cache untuk sisanya), ada satu hal yang perlu dipahami soal urutan evaluasi: Security Rules dan Cache Rules itu dua sistem terpisah di Cloudflare, dan Security dievaluasi lebih dulu sebelum request sampai ke logika caching.
Artinya, kalau sebuah request diblokir atau ditantang oleh WAF Managed Ruleset, dia tidak akan pernah sampai ke tahap pengecekan Cache Rule sama sekali — response block/challenge itu sendiri yang dikirim balik, bukan konten halaman yang di-cache. Ini kabar baik: tidak ada skenario di mana konfigurasi Security yang benar (server-side, tidak menyuntik script) mengganggu strategi caching yang sudah kamu bangun. Dua lapisan ini saling melengkapi, bukan saling menimpa.
Satu pengecualian yang perlu diperhatikan: kalau kamu MENGAKTIFKAN Bot Fight Mode atau Precursor, script yang mereka suntikkan ke HTML berarti HTML yang dikirim ke pengunjung berbeda-beda tergantung apakah dia sedang ditantang atau tidak — ini bisa mengacaukan strategi full-page caching, karena versi HTML yang di-cache mungkin mengandung sisipan script tantangan untuk satu pengunjung tapi tidak untuk pengunjung lain yang kebetulan mendapat cache HIT dari versi yang berbeda. Ini satu lagi alasan konkret, di luar soal kecepatan murni, untuk tidak mengaktifkan dua fitur itu di situs yang sudah menjalankan full-page caching lewat Cache Rule.
Kalau distilkan jadi checklist:
Nyalakan (server-side, nol biaya pagespeed, manfaat keamanan nyata):
- Cloudflare Managed Ruleset (biasanya sudah default aktif)
- Browser Integrity Check
- Continuous Script Monitoring
- Leaked Credentials Detection
- HTTP DDoS Attack Protection (default aktif)
- Replace Insecure JavaScript Libraries
Matikan (client-side, biaya pagespeed nyata, manfaat keamanan bisa digantikan opsi lain):
- Bot Fight Mode
- Email Address Obfuscation
Biarkan mati untuk kebanyakan situs (client-side kontinu, biaya berkelanjutan, manfaat baru relevan untuk ancaman bot tingkat lanjut):
- Precursor
Opsional, tergantung kebutuhan (nol biaya pagespeed di kedua kasus, tinggal soal relevan-tidaknya):
- AI Labyrinth
- Hotlink Protection
- IP Access Rules / IP Lists
- Rate Limit Authentication Requests
Pola yang konsisten dari semua ini: fitur yang benar-benar berbahaya untuk pagespeed selalu punya ciri yang sama — dia menyuntikkan sesuatu yang dieksekusi di browser SETIAP pengunjung, bukan cuma memutuskan sesuatu di server. Begitu kamu tahu ciri itu, membaca deskripsi toggle mana pun di dashboard Cloudflare — termasuk fitur baru yang belum pernah dibahas di sini — jadi jauh lebih gampang dinilai sendiri tanpa perlu menunggu artikel baru tiap kali Cloudflare merilis sesuatu.