Keuntungan dan Kekurangan Menggunakan Cloudflare

Keuntungan dan Kekurangan Menggunakan Cloudflare

 Pertama, bisa dimulai dari pemahaman tentang perlu atau tidaknya pakai CDN secara umum..

Tergantung kualitas infrastruktur/network CDN-nya atau provider CDN apa yang dipakai. Jangan sampai kualitas server, jaringan, dll. pada CDN yang dipilih malah lebih inferior dibanding origin server-nya atau hosting yang kita pakai. Pada kondisi seperti itu (infrastruktur CDN lebih inferior), malah bisa bikin performa web secara keseluruhan menurun, alih2 makin ngebut.

Satu yang perlu digarisbawahi, ketika ngomongin "pakai CDN" itu lazimnya akan dimaknai yang di-CDN-kan itu hanya asset2anya ya, bukan root domain/url atau HTML utamannya. Maka itu, biasanya enggak ngaruh ke misal time to first byte (TTFB) dari root URL-nya. TTFB asset2nya saja seperti gambar, font, JS, dll. yang punya potensi membaik/memburuk.

2016 saya pakai KeyCDN, 2017 BunnyCDN, 2018 Verizon + Akamai (via Azure) serta nyoba Highwinds/StackPath. 2019-sekarang bolak-balik antara Cloudflare (gratis) dan enggak pakai CDN. Beberapa bulan silam, waktu masih pakai cache2an (proxy cache), saya tidak pakai CDN. Kini setelah server-nya tanpa cache2an, balik lagi "numpang CDN" (asset only) di CF.

Idealnya, ketika saat ini saya pakai server di AWS (Lightsail) yang infrastruktur/network-nya jempolan dan target visitor saya hanya satu daerah/region, tidak perlu pakai CDN. Malah rasanya sayang kalau pakai CDN, gratisan "bandwidth premium" 8 TB (akumulasi gratisan BW/data transfer pool 4 VM) dari AWS Lightsail mubazir kalau enggak dipakai.

Tapi, kalau enggak pakai CDN2an, itu server2 saya di Lightsail yang cuma pakai $5-an dengan spek imut2 (setara t2.micro - baseline CPU credits 10%) bakal ngos2an nge-load asset2 static di web saya, khususnya media image yang pakai on-the-fly manipulation (resize, crop, dll.). Solusinya ya di-cache-kan saja ke CF biar meringankan beban origin server-nya.

Ketika saya cek TTFB-nya via DevTools Chrome dengan koneksi antara Tri dan Telkomsel (seringnya sih Tri) itu asset2 yang saya "titipkan" ke CF lebih inferior, jarang dapet < 70ms pada PoP region yang sama dengan origin-nya (AWS-SG). Sebagai pembanding, static2 asset yang diakses langsung via origin-nya di AWS sering dapet < 70ms, bahkan tak jarang nyentuh 50an ms.

Pada kondisi seperti yang saya alami saat ini, akan muncul pertanyaan, ngapain pakai CDN kalau malah tidak meningkatkan kecepatan akses web secara keseluruhan alias tidak bisa menggenjot performa static2 asset-nya. Bukankah lebih baik ke setup sebelumnya, yang tidak pakai CDN tapi cuma cache (proxy cache) di server-nya namun lebih ngebut?

Setup server, CDN, dll. di blog2 saya itu sebenarnya belum final, bahkan mungkin tak akan pernah “selesai”. Untuk saat ini, ketika lagi pengen web/blog2saya jalan tanpa cache2an, baik di level server-nya atau di level WP-nya, CDN dari CF membantu banget untuk ringankan beban server. Bisa jadi besok, lusa, dst. berubah lagi dengan pakai cache2an di origin tanpa CDN CF.