Cloudflare untuk Website Klien: Kecepatan, Keamanan, dan DNS dalam Satu Tempat

Kebanyakan website klien yang saya kirim melewati Cloudflare sebelum sampai ke origin server. Bukan karena stack-nya belum selesai—tapi karena DNS, TLS, caching, dan proteksi dasar seharusnya tidak dibangun ulang dari nol setiap proyek.

Ini baseline yang saya pakai saat situs bisnis go-live di VPS, shared hosting, atau static build.

Apa yang sebenarnya diberikan Cloudflare

Pikirkan dalam lapisan:

1. DNS — propagasi cepat, manajemen record mudah, optional proxy (orange cloud).
2. CDN edge cache — asset static dilayani lebih dekat ke pengunjung.
3. TLS — sertifikat gratis dan redirect HTTPS di edge.
4. Security rules — filter bot, rate limit, WAF di plan lebih tinggi.
5. Observability — analitik traffic tanpa harus pasang tool baru di hari pertama.

Untuk situs UMKM, lapisan 1–3 saja sering sudah terasa di kecepatan dan uptime.

Langkah 1: Pindahkan DNS dengan benar

Sebelum ganti nameserver:

• export record lama (A, AAAA, CNAME, MX, TXT);
• turunkan TTL sehari sebelumnya jika domain masih di provider lain;
• tambahkan situs ke Cloudflare dan verifikasi kepemilikan;
• buat ulang MX dan SPF/DKIM persis—email bisa rusak tanpa pesan error yang jelas.

Baru setelah record cocok, arahkan domain ke nameserver Cloudflare.

Langkah 2: Pengaturan SSL/TLS yang saya pakai

Di tab SSL/TLS:

• mode: Full (strict) jika origin punya sertifikat valid;
• aktifkan Always Use HTTPS;
• aktifkan Automatic HTTPS Rewrites;
• nyalakan TLS 1.3.

Jika origin masih IP telanjang atau sertifikat self-signed, perbaiki origin dulu—jangan bertahan lama di mode “Flexible”.

Langkah 3: Caching tanpa merusak halaman dinamis

Caching default membantu CSS, JS, font, dan gambar. Admin PHP/WordPress harus bypass cache.

Aturan praktis:

• cache extension static agresif (css, js, woff2, webp, jpg);
• bypass cache untuk /wp-admin/*, cart/checkout, dan cookie autentikasi;
• pakai Cache Rules (atau Page Rules di setup lama) instead of “cache everything” sembarangan.

Untuk Astro/static site, dokumen HTML sering bisa di-cache di edge dengan TTL pendek—or langsung dari origin jika deploy sering.

Langkah 4: Toggle performa yang worth di-enable

Di Speed / Optimization:

• kompresi Brotli;
• HTTP/2 dan HTTP/3 (QUIC) bila tersedia;
• Early Hints jika origin mendukung;
• Polish atau pipeline gambar otomatis hanya setelah uji—optimasi auto bisa mengejutkan tim desain.

Saya hindari menumpuk optimasi Cloudflare di atas origin yang rusak. Perbaiki gambar berat dan script blocking dulu; CDN memperkuat arsitektur yang sudah baik, bukan menggantikannya.

Langkah 5: Keamanan dasar sebelum launch marketing

Checklist minimum:

• aktifkan Bot Fight Mode atau setara di plan gratis bila cocok;
• tambah rate limit di endpoint login dan form;
• block country/ASN hanya jika bisnis memang tidak punya audiens di sana;
• review Security Events setelah lonjakan traffic pertama.

Untuk WordPress, batasi juga /wp-login.php dan pertimbangkan hostname admin terpisah.

Langkah 6: Page Rules / Cache Rules yang sering saya ulang

Contoh:

Pattern	Action
*.css, *.js, font	Cache Everything, edge TTL panjang
/wp-admin/*	Bypass cache
/api/*	Bypass cache
Home marketing /	TTL pendek atau bypass jika A/B testing

Dokumentasikan ini di handover proyek agar maintainer berikutnya tahu mengapa suatu halaman berperilaku berbeda.

Kesalahan umum yang saya lihat

• Flexible SSL dengan HTTPS di publik tapi HTTP ke origin—perbaiki dengan Full (strict).
• Cache admin atau cart — bikin login “hantu” dan keranjang kosong.
• Lupa MX record setelah migrasi DNS.
• Orange-cloud subdomain mail yang seharusnya DNS-only.
• Rocket Loader di app dengan inline script rapuh—uji dulu.

Hubungannya dengan kerja PageSpeed

Cloudflare mengurangi latency dan byte di jaringan. Tapi tidak memperbaiki:

• hero JPEG super besar;
• rantai font render-blocking;
• bundle JavaScript tidak terpakai;
• layout shift karena dimensi hilang.

Pakai Cloudflare setelah origin sudah wajar. Lalu ukur lagi dengan PageSpeed Insights dan uji perangkat nyata.

Checklist handover untuk klien

• Akses akun Cloudflare terdokumentasi (atau agency-managed dengan visibilitas klien).
• Record DNS di-export sebagai backup.
• Mode SSL tercatat (Full strict).
• Path bypass cache terdaftar.
• Record email diverifikasi setelah ganti NS.
• Perilaku 404/redirect diuji lewat proxy.

Penutup

Cloudflare bukan sihir—ini hygiene infrastruktur. Untuk website klien, hygiene itu berarti load pertama lebih cepat, brute force ke origin berkurang, dan satu dashboard saat sesuatu rusak jam 10 malam.

Mulai dari DNS + Full (strict) + cache rule masuk akal. Tambah tuning keamanan setelah traffic nyata menunjukkan apa yang benar-benar diserang.