Akselerasi CDN WordPress.

Jika kita membagi optimasi kinerja WordPress menjadi tiga tingkat:

• lapisan stasiun sumberPlugin Hosting / PHP / Database / Caching - Memutuskan TTFB dan Tekanan Backend
• \nLapisan sumber dayaOptimasi gambar -- Menentukan ukuran unduhan dan kecepatan gambar besar di layar pertama.
• Layanan pengirimanCDN —— Memastikan sumber daya lebih dekat dengan pengunjung, memberikan akses yang lebih stabil, dan mengurangi beban pada server sumber.

Artikel ini membahas tentang Akselerasi CDN.：

• Memahami apa yang dapat dan tidak dapat diselesaikan oleh CDN.
• Dapat memilih format dan penyedia CDN yang cocok untuk diri sendiri (dan memahami batasan versi gratis/versi pemula).
• Luncurkan sesuai urutan risiko rendah, jangan membuat situs macet, dan jangan sampai terjadi kecelakaan pada cache e-commerce/anggota.
• Setelah diluncurkan, Anda dapat memverifikasi apakah itu “benar-benar efektif” dan mengidentifikasi penyebab “mengapa tidak diperbarui/mengapa lambat/mengapa konten tidak sesuai”.”

Pertama, jelaskan konsepnya: Apa yang CDN selesaikan, dan apa yang tidak?

1 CDN terutama menyelesaikan 3 hal.

1.1 Sumber daya statis disampaikan lebih cepat.
Gambar / CSS / JS / font / ikon, dan sumber daya statis lainnya lebih dekat dengan pengunjung, sehingga dapat diunduh lebih cepat dan halaman dapat ditampilkan lebih stabil.
Untuk WordPress, terutama sumber daya tema dan plugin (wp-content/themes/、wp-content/plugins/Dan gambar-gambar dari perpustakaan media.wp-content/uploads/Mereka biasanya memiliki ukuran yang sangat besar.

1.2 Mengurangi tekanan pada stasiun sumber.
Setelah permintaan mengenai cache tepi, permintaan tersebut tidak lagi sering kembali ke sumbernya. Dengan demikian, bandwidth sumber, koneksi bersamaan, I/O disk, dan fluktuasi CPU akan berkurang.
Ini sangat jelas dalam skenario puncak seperti “halaman acara, artikel populer, dan halaman produk yang banyak dikunjungi”.

1.3 Meningkatkan stabilitas (lebih tahan terhadap fluktuasi)
Pada saat lalu lintas puncak, node tepi akan menyerap sejumlah besar permintaan yang berulang, sehingga stasiun sumber lebih kecil kemungkinannya mengalami kelebihan beban.
Anda akan melihat “akses yang lebih lancar”: bahkan jika stasiun sumber mengalami peningkatan tekanan secara instan, caching tepi akan tetap dapat terus memberikan output.

---

2 CDN tidak akan secara otomatis menyelesaikan 3 jenis masalah.

2.1 Situs sumber itu sendiri lambat.
Database lambat, logika plugin lambat, perhitungan PHP lambat - ini adalah masalah pada layer stasiun sumber.
CDN dapat mempercepat sumber daya statis, tetapi jika Anda bahkan membuat HTML halaman utama dengan sangat lambat, pengguna akan tetap merasa “membuka halaman itu sangat lambat”. Dalam hal ini, prioritaskan kembali: host/plugin cache/optimisasi database.

2.2 Gambar itu sendiri terlalu besar.
CDN tidak dapat “secara ajaib” mengubah gambar besar berukuran 3 MB menjadi lebih kecil.
Kamu harus melakukan optimasi gambar terlebih dahulu: strategi ukuran (jangan unduh gambar yang terlalu besar), kompresi, WebP/AVIF, strategi lazy loading, dll.

2..3 Skrip pihak ketiga lambat.
Iklan, statistik, layanan pelanggan, komponen media sosial, dan lain-lain berasal dari domain pihak ketiga.
CDN biasanya tidak dapat membantu mereka “lebih cepat”. Anda hanya dapat menanganinya dengan mengurangi/menunda pemuatan, mengganti penyedia, atau melakukan optimasi strategi skrip.

Pilihan dalam 30 detik: Jenis CDN apa yang kamu butuhkan?

Untuk WordPress, ada dua kategori utama. Pertama, Anda memilih “format”, lalu memilih “penyedia layanan”, dan pendekatannya akan sangat jelas.

2.1 Tipe “proksi balik” terintegrasi (lebih praktis, cocok untuk sebagian besar situs)

*Fitur:** Ini bukan hanya CDN, tetapi juga... DNS / SSL / Perlindungan keamanan dasar (seperti DDoS/WAF) Mari kita berkemas bersama. Setelah Anda terhubung, itu akan berdiri di depan situs web Anda dan berfungsi sebagai proxy.

Apa yang akan kamu dapatkan:

• Sertifikat HTTPS dan manajemen TLS lebih sederhana.
• Portal perlindungan keamanan terpadu (DDoS dasar, kontrol akses, WAF, dll.)
• Cache tepi dan mesin aturan (yang dapat membuat strategi caching yang lebih detail dan strategi bypass).
• “Ruang yang dapat diperluas lebih besar”: Jika nantinya ingin menambahkan fitur keamanan, batasan kecepatan, atau perlindungan Bot, biasanya semua itu berada dalam sistem yang sama.

*Perwakilan:** Cloudflare / Tencent Cloud International EdgeOne / Alibaba Cloud International ESA

Jika kamu ingin:

• Kamu ingin HTTPS + CDN + keamanan dasar. Selesaikan itu sekali saja.
• Apakah Anda bersedia menyerahkan manajemen domain name resolution/proxy layer kepada satu platform?
• Kamu lebih menghargai “pengalaman keseluruhan dan ekspansi selanjutnya”, dan tidak ingin membagi DNS, sertifikat, CDN, dan keamanan menjadi beberapa paket.

---

2 “Pull CDN statis” murni (awal dengan risiko rendah, terutama untuk mempercepat gambar/CSS/JS)

*Fitur:** Kamu hanya menempatkan sumber daya statis ke dalam cache tepi CDN; halaman HTML masih ditangani oleh sumber (dan plugin cache sumber).

Apa yang akan kamu dapatkan:

• Risiko bisnis yang sangat rendah: Jika tidak menggunakan HTML, hampir tidak akan terjadi “konten yang tidak teratur/keranjang belanja yang tidak teratur”.”
• Model biaya lebih intuitif: biasanya dikenakan biaya berdasarkan lalu lintas/permintaan/wilayah.
• Strukturnya lebih murni: lebih seperti “layanan distribusi sumber daya statis”.”

*Perwakilan:** bunny.net (model penagihan berdasarkan penggunaan yang jelas)

Jika kamu ingin:

• Kamu ingin melakukan “langkah paling aman” terlebih dahulu - mempercepat sumber daya statis.
• Kamu ingin mendapatkan keuntungan dengan cepat, lalu memutuskan apakah akan menggunakan caching agen/seluruh situs.
• Kamu ingin biayanya lebih dekat dengan “bayar sesuai penggunaan”.”

Bagaimana cara melakukannya?

• Tingkat pertama: Agen terintegrasi (yang terbaik): Cloudflare / EdgeOne / ESA
• Tingkat kedua: Pull CDN statis (awal yang aman): bunny.net / Cloudways CDN, dll.

Penyedia layanan yang direkomendasikan.

4.1 Cloudflare: Integrasi proxy terbalik (gratis untuk memulai, ekosistem yang matang)

Apa itu?
Setelah Anda menghubungkan domain, itu akan berfungsi sebagai proxy di depan situs web, menyediakan CDN, sertifikat, perlindungan dasar, dan kemampuan aturan caching.

Untuk siapa ini cocok?

• Inginkan ketenangan pikiran: HTTPS + CDN + keamanan dasar secara terintegrasi.
• Menginginkan ekosistem yang matang: selanjutnya perlu menambahkan WAF, pembatasan kecepatan, aturan tepi, dll. Prosesnya sangat lancar.

\nTitik risiko

• Pembaruan tidak berlaku.Setelah CDN online, rantai caching menjadi lebih panjang (cache browser + cache CDN + cache sumber), sehingga perlu menerapkan “kebijakan versi” agar pembaruan dapat dikontrol (ada pohon debugging di bagian selanjutnya).
• Harus berhati-hati saat menyimpan HTML dalam cache.Jika HTML di-cache, halaman e-commerce/anggota/personalisasi harus dilewati dengan ketat, jika tidak, mudah terjadi kecelakaan serius (ada daftar skenario di bawah ini)

instruksi：

• Posisi: Integrasi proxy terbalik (SSL + CDN + perlindungan dasar)
• Cocok untuk: Peluncuran yang mudah, dengan ruang yang cukup untuk ekspansi di masa mendatang.
• Nilai inti: sertifikat terpadu/keamanan/entri cache.
• Risiko: Pembaruan tergantung pada strategi versi; cache HTML harus diabaikan sepenuhnya.

---

4.2 Tencent Cloud International EdgeOne: Integrasi proxy terbalik.

Apa itu?
Morph juga merupakan platform terintegrasi yang menggabungkan “akselerasi + keamanan + sertifikat”, cocok untuk menempatkan situs di bawah manajemen lapisan proxy terpadu.

• Seperti Cloudflare, mereka juga memiliki versi gratis, tetapi biasanya ada batasannya. Quota/batasan fitur.(Jumlah aturan, jumlah tugas log, dll.), tetapi tidak perlu mengubah DNS, hanya perlu akses CNAME saja.Situs web bisnis tidak disarankan untuk menggunakan versi gratisnya.！
• Di sisi lain, paket gratis sering kali berarti SLA tidak menjamin.
  Ini bisa digunakan, tetapi jangan menganggapnya sebagai “Paket SLA komersial”.

• Jika Anda ingin secara otomatis beralih ke jaringan China daratan saat berada di China daratan, biasanya Anda harus melakukan hal berikut terlebih dahulu.Pendaftaran ICP di Tiongkok.;Jika belum terdaftar, Anda hanya dapat menggunakan rute internasional.

Catatan:

• Posisi: Integrasi proxy terbalik (akselerasi + keamanan + sertifikat)
• Cocok untuk: Mereka yang menginginkan akses terintegrasi dan mempertimbangkan kapasitas node di Tiongkok Daratan.
• Gratis: Ada paket gratis/versi gratis, tetapi kuotanya terbatas dan SLA biasanya tidak dijamin.
• Risiko: Kuota aturan/log/subdomain harus direncanakan terlebih dahulu; caching HTML juga harus dilakukan dengan hati-hati.

---

4.3 Alibaba Cloud International ESA: Integrasi proxy terbalik.

• Seperti Cloudflare, mereka juga memiliki versi gratis, tetapi biasanya ada batasannya. Quota/batasan fitur.(Jumlah aturan, jumlah tugas log, dll.), tetapi tidak perlu mengubah DNS, hanya perlu akses CNAME saja.Situs web bisnis tidak disarankan untuk menggunakan versi gratisnya.！
• Cukup daftar akun di situs web internasional, maka Anda sudah bisa menggunakannya.
• Masuk ke konsol ESA, tambahkan situs, dan pilih yang gratis. Entrance Akses paket.
• Jika Anda ingin secara otomatis mengalihkan koneksi ke jaringan daratan Tiongkok, biasanya Anda harus terlebih dahulu menyelesaikan pendaftaran ICP; jika belum terdaftar, Anda hanya dapat menggunakan koneksi internasional.
• Gratis lebih cocok untuk pengembangan/penguji/evaluasi, dan biasanya tidak setara dengan paket SLA komersial.
• Paket gratis biasanya memiliki batasan kecepatan/batasan dukungan (seperti SLA, dll.)

Mengenai rute di Tiongkok Daratan:

• Untuk mengaktifkan node di Tiongkok Daratan, biasanya diperlukan untuk memenuhi syarat-syarat pendaftaran dan regional.
• Masuk gratis. Secara default, Anda akan mengikuti rute internasional. Jika Anda ingin mengikuti rute Tiongkok Daratan, Anda harus menyelesaikan prosesnya terlebih dahulu.Persyaratan Pendaftan ICP di Tiongkok.

Catatan:

• Posisi: Integrasi proksi terbalik (akselerasi situs + keamanan)
• Gratis: Akun stasiun internasional dapat menggunakan akses Entrance secara gratis; secara default tidak termasuk akselerasi Tiongkok Daratan.
• Cocok untuk: Evaluasi/Pengujian dan penggunaan ringan; atau paket upgrade selanjutnya.
• Risiko: Pastikan memahami batasan gratis (SLA/batasan kecepatan/metode dukungan); perencanaan area dan pendaftaran harus dilakukan terlebih dahulu.

---

4.4 \nbunny.net: CDN Pull statis (awal dengan risiko rendah, dengan penagihan berdasarkan volume yang jelas)

Jika kamu ingin “mendapatkan keuntungan paling stabil terlebih dahulu”, Pull CDN seperti Bunny sangat cocok untuk itu:
Ini lebih seperti “layanan distribusi sumber daya”: Anda menyerahkan sumber daya statis kepadanya untuk didistribusikan, biayanya biasanya terkait dengan lalu lintas/permintaan/wilayah, dengan model yang jelas dan dapat dikendalikan.

Cocok untuk:

• Lakukan dulu. Gambar / CSS / JS / Font Akselerasi statis
• Kamu ingin mendapatkan “pendapatan yang rendah risiko dan stabil” terlebih dahulu, dan tidak terburu-buru menyerahkan seluruh situs ke platform berbasis agen (DNS/SSL/WAF terintegrasi).
• Anda ingin model biaya lebih dekat dengan “bayar sesuai penggunaan”, daripada langsung masuk ke sistem paket yang lebih kompleks.

\nTitik risiko

Sumber daya statis yang “tidak diperbarui” hampir selalu bukan merupakan bug dari CDN.Namun, ini adalah perilaku normal dari sistem caching:
Saat Anda memperbarui CSS/JS/gambar di latar belakang, tetapiURL sumber daya tidak berubah.(Dengan alamat/nama file/jalur yang sama), CDN dan browser akan terus mengakses cache lama secara wajar, sehingga Anda melihat “mengapa belum diperbarui”.

Sebuah prinsip yang jelas dan dapat diterapkan:

Nomor versi diutamakan, Purge sebagai cadangan.

Mengapa ini yang paling aman:

• \nPerubahan nomor versi/nama file. ← Perubahan URL → CDN menyimpan sumber daya baru → Versi baru berlaku hampir seketika.
• *Purge (Membersihkan Cache)** membutuhkan Anda untuk memicunya secara aktif, dan seringkali tidak akurat dalam jangkauan, serta ada penundaan dalam penyebaran node; Purge yang terlalu sering juga dapat mengakibatkan penurunan tingkat keberhasilan, peningkatan permintaan sumber, dan volatilitas yang lebih besar.

Contoh yang mudah dipahami:

• style.css Kontennya telah diubah, tetapi URL-nya masih sama. style.css → CDN terus menggunakan cache lama (masuk akal)
• URL-nya berubah menjadi style.css?ver=20260103 或 style.abc123.css → CDN menganggapnya sebagai sumber daya baru → Versi baru segera berlaku.

\nBunny sebagai praktik terbaik untuk “CDN Tahap Pertama”.

1. Untuk saat ini, hanya sumber daya statis yang akan dicakup.(Gambar/CSS/JS/Font), jangan langsung menyimpan HTML-nya terlebih dahulu.
   • Keuntungannya: Hampir tidak akan terjadi kecelakaan serius seperti “pengguna melihat konten/nomor seri keranjang belanja orang lain”.
   • Kamu juga lebih mudah memverifikasi keuntungannya: sumber daya statis lebih cepat, dan server sumber lebih ringan.
2. Desain strategi pembaruan dengan baik.
   • CSS/JS: Cobalah untuk menggunakan nomor versi/perubahan nama file.
   • Gambar: Cobalah untuk menghindari “penutupan nama yang sama” dalam jangka panjang, dan lebih merekomendasikan perubahan nama file/jalur baru (terutama untuk spanduk halaman utama dan gambar acara).
3. Setelah online, gunakan daftar verifikasi untuk mengonfirmasi keberhasilannya.
   • Apakah sumber daya statis berasal dari CDN?
   • Apakah tingkat hit meningkat secara bertahap, dan apakah bandwidth/permintaan dari server sumber lebih stabil? (Ada daftar verifikasi di bagian selanjutnya.)

Peta rute peluncuran: Maju dalam 3 tahap (dari stabil hingga kuat).

Alasan paling umum CDN mengalami masalah saat diluncurkan adalah karena orang-orang ingin mengaktifkan semua fiturnya sekaligus.

Tahap 1: Hanya lakukan CDN sumber daya statis (sangat disarankan untuk melakukannya terlebih dahulu)

\nTujuan: Gambar/CSS/JS/font terlebih dahulu menggunakan CDN; HTML tidak dalam cache CDN (atau tidak bergerak untuk sementara waktu).

Mengapa melakukan ini terlebih dahulu adalah yang paling aman?

• Risiko terendah: Jika caching sumber daya statis salah, maksimumnya adalah “gaya/gambar tidak diperbarui”, yang dapat dikendalikan.
• Tidak akan memengaruhi status login, proses e-commerce, atau keakuratan informasi akun.
• Kamu dapat melihat manfaatnya dengan jelas: sumber daya statis diunduh lebih cepat, dan server sumber lebih stabil.

Masalah umum pada tahap ini (pohon pemecahan masalah akan diberikan nanti)

• Konten campuran (halaman HTTPS yang memuat sumber daya HTTP)
• Pembaruan sumber daya statis tidak berlaku (URL tidak berubah)

---

Tahap 2: Strategi pembaruan (prioritas nomor versi, Purge/kesalahan sebagai cadangan)

Ini adalah titik penting dalam menilai “seberapa profesional CDN tersebut”.

Aturan keras:

Untuk pembaruan yang dapat diselesaikan dengan perubahan nomor versi/nama file, jangan mengandalkan Purge.

Mengapa caching link menjadi lebih tidak dapat diprediksi saat panjangnya bertambah?

• Cache browser: Anda mungkin telah menyimpan CSS/JS lama di lokal Anda.
• Cache CDN: Node tepi mungkin telah menyimpan sumber daya lama di cache.
• Cache stasiun sumber: Plugin cache/cache server mungkin masih mengeluarkan konten lama.

Jika Anda tidak memiliki strategi versi, proses rilis akan menjadi:
“Mengubah sesuatu → Refresh → Tidak berhasil → Hapus cache lagi → Masih tidak berhasil → Hapus cache tingkat lainnya”
Inilah hal paling menjengkelkan bagi banyak orang tentang CDN.

---

Tahap 3 (Lanjutan): Apakah akan menyimpan HTML dalam cache (manfaatnya tinggi, tetapi risikonya juga tinggi)

Cache HTML (cache seluruh situs/cache tepi) dapat secara signifikan mengurangi TTFB, tetapi juga merupakan area yang rawan terjadi kesalahan di WordPress.

Jika Anda tidak yakin, jangan menyimpan HTML. Gunakan CDN statis + plugin caching sisi server terlebih dahulu.

Jika ingin menyimpan HTML dalam cache, ada dua prinsipnya:

1. Hanya mulai dari “mode pengunjung”.Hanya menyimpan halaman tamu yang belum login.
2. \nPertama, tulis daftar hal-hal yang perlu dihindari.: Prioritaskan akurasi, baru kemudian bicara tentang tingkat keberhasilan.

Daftar aturan adegan: Bagaimana cara menghindari kecelakaan di berbagai tipe lokasi?

1 Situs Konten / Blog (terutama artikel, dengan banyak pengunjung)

Rekomendasi

• Sumber daya statis: sepenuhnya di-cache.
• HTML: Pertimbangkan untuk menyimpan halaman “Pengunjung yang belum login” dalam cache.”

Biasanya perlu untuk menghindari

• Di belakang layar dan login:/wp-admin/*、/wp-login.php
• Pratinjau/Draf (preview)
• Halaman hasil pencarian (perubahan parameter sangat besar, jadi lebih baik tidak menyimpannya terlebih dahulu untuk menghemat waktu).
• Permintaan POST untuk pengiriman formulir/komentar.

Kunci cache harus setidaknya bisa membedakan.

• Apakah sudah login (dimensi cookie)?
• Bahasa (situs multibahasa)

---

2 Situs Perusahaan / Halaman Pendaratan Pemasaran (banyak formulir dan aktivitas)

Rekomendasi

• Sumber daya statis: sepenuhnya di-cache.
• HTML: Halaman arahan publik dapat di-cache (saat pengunjung mengaksesnya), tetapi harus berhati-hati dalam menangani halaman hasil formulir.

Perangkap yang paling mudah dihindari: Pelacakan parameter yang mengakibatkan fragmentasi cache.
Halaman arahan biasanya utm_* Parameter:

• Semua kunci cache terlibat → Cache terfragmentasi, tingkat hit buruk.
• Semua abaikan → Beberapa halaman yang mengandalkan parameter rendering mungkin tidak sesuai dengan harapan.

---

3 Situs Anggota / Situs Kursus / Komunitas (dengan persentase pengguna yang login cukup tinggi)

Kesimpulan.: Halaman web yang di-cache oleh browser harus ditangani dengan sangat hati-hati.
Praktik yang aman biasanya adalah: CDN statis + caching sumber/objek; HTML hanya di-cache saat pengunjung aktif.

Harus menyiasati

• Login/Daftar/Pulihkan Kata Sandi
• Pusat Akun, Pesanan/Berlangganan, Profil Pribadi.
• Semua halaman dan antarmuka yang “sangat terkait dengan mode pengguna”.

---

4 Situs E-commerce (WooCommerce)

Daftar cara paling penting untuk menyiasati sensor.

• Keranjang belanja, checkout, halaman akun.
• Halaman terkait konfirmasi pesanan dan pemberitahuan pembayaran.
• Masuk/Daftar, Kupon/Poin, dan entri terkait pengguna lainnya.

Mengapa e-commerce lebih rentan mengalami kecelakaan?

• Setelah pengguna memiliki keranjang belanja, sesi, dan status login, halaman tersebut akan sangat personal.
• Jika caching HTML tidak melewati/membedakan status, konsekuensi paling umumnya adalah: kerusakan keranjang belanja, nomor akun yang salah, dan harga yang ditampilkan secara tidak normal.
  Prioritaskan keakuratan, jangan mengorbankan keakuratan demi tingkat keberhasilan.

---

5 Situs multibahasa / multimata uang.

Rekomendasi

• Sumber daya statis: sepenuhnya di-cache.
• HTML: Dapat menyimpan status pengunjung, tetapi kunci caching harus membedakan secara jelas antara varian bahasa/mata uang.

Kunci Cache harus dipertimbangkan.

• Bahasa (jalur) /en/ /zh/ Atau subdomain. en.）
• Apakah sudah login (cookie)?
• Mata uang/tarif pajak (jika memengaruhi tampilan)

---

7. Peringatan Risiko

Risiko 1: Konten cache yang salah (yang paling serius)

• Kesalahan caching sumber daya statis: Sebagian besar adalah gaya/gambar yang usang.
• Kesalahan caching HTML: mungkin konten string, keranjang belanja string, akun string —— ini adalah kecelakaan serius.

Risiko 2: Pembaruan tidak berlaku (yang paling umum).

Setelah tautan cache menjadi lebih panjang, “diubah tapi tidak berlaku” akan lebih sering terjadi:

• \nPrioritas perubahan nomor versi/nama file.
• Mengosongkan/Menanggung kerugian
• Proses rilis harus dapat direproduksi (mengetahui URL mana yang diubah setiap kali rilis dilakukan).

Risiko 3: Batasan janji versi gratis/versi pemula.

• Karakteristik umum dari solusi gratis: kuota terbatas, beberapa fitur tidak disertakan, SLA/dukungan tidak sama dengan yang komersial resmi.

Risiko 4: Kemampuan terkait Tiongkok daratan dapat dengan mudah disalahpahami.

• ESA: Jika ingin menggunakan rute daratan Tiongkok, Anda harus melakukan pendaftaran ICP di Tiongkok.
• EdgeOne: Jika ingin menggunakan rute China Daratan, Anda harus melakukan pendaftaran ICP di China.

8 Daftar Verifikasi: Bagaimana cara memastikan bahwa itu “benar-benar efektif” setelah diluncurkan?”

1 Apakah sumber daya statis benar-benar dialihkan ke CDN?

• Apakah gambar/CSS/JS berasal dari nama domain CDN/simpul tepi?
• Apakah Anda dapat melihat tanda-tanda cache hit yang jelas (dengan identifikasi yang berbeda di platform yang berbeda)?

2 Apakah tekanan di stasiun sumber menurun?

• Apakah bandwidth stasiun sumber lebih stabil?
• Apakah jumlah permintaan/koneksi dari stasiun sumber menurun? (terutama permintaan sumber daya yang berulang)

Apakah pembaruan 8.3 dapat dikendalikan?

• Mengubah CSS/JS sekali atau mengganti sebuah gambar.
• Apakah versi baru dapat berlaku dengan cepat melalui “perubahan nomor versi/perubahan nama file”?
• Jika Anda hanya bisa melakukan pembaruan menggunakan Purge, itu berarti strategi versinya belum optimal (prioritaskan strategi, jangan gunakan Purge sebagai hal rutin).

4 Apakah halaman kunci dinamis itu benar?

(Wajib dilakukan oleh situs e-commerce/anggota)

• Apakah konten halaman setelah login/logout sudah benar?
• Apakah halaman terkait keranjang belanja/penyelesaian pembelian/akun selalu akurat?
• Apakah ada anomali (berisiko tinggi) di mana “pengguna yang berbeda melihat konten user-mode yang sama”?

5 Apakah tingkat kesalahan meningkat?

• Waktu pemuatan yang lama, kode eror 5xx, dan tidak bisa diakses secara intermiten.
• Ini biasanya berarti: stasiun sumber tidak mampu, aturan yang salah, pemicu batasan kecepatan, atau masalah dengan tautan kembali ke sumber.

9 Memperbarui pohon pencarian untuk memastikan pembaruan berhasil (mengubah “ilmu hitam” menjadi langkah-langkah yang jelas).

Pertama, tentukan jenis masalah yang kamu hadapi:

1 Sumber daya statis tidak diperbarui (CSS/JS/gambar masih yang lama)

Situasi A: Hanya kamu sendiri yang melihat yang lama, sedangkan yang baru adalah invisible/mengganti perangkat.
Kemungkinan penyebab utama: cache browser.

• Solusinya: Rilis sumber daya baru dengan perubahan nomor versi/nama file.

Situasi B: Semua orang melihat yang lama (tersembunyi/perangkat lain juga lama)
Kecurigaan utama: CDN masih mengakses cache lama.

• 99%. Alasan: URL sumber daya tidak berubah.
• Solusi prioritas: Strategi versi
• Menanggung semua tanggung jawab: Purge (solusi sementara)

Situasi C: Gambar dengan nama yang sama terus menampilkan gambar lama setelah diganti.
Ini adalah masalah klasik dari cache browser + cache CDN yang tumpang tindih.

• Saran praktis: Cobalah untuk menghindari “penamaan yang tumpang tindih” dalam jangka panjang, gunakan nama file/jalur atau nomor versi baru.

---

2 HTML belum diperbarui (konten halaman/modulu masih yang lama).

Situasi A: Halaman belakang/setelah login adalah yang baru, sedangkan pengunjung melihat yang lama.
Kemungkinan utama: HTML halaman login tamu telah di-cache.

• Pertama, pastikan: apakah halaman-halaman seperti ini harus menyimpan cache HTML?
• Jika seharusnya di-cache: Diperlukan strategi pembaruan yang terkendali, jika tidak, publikasinya akan tidak terkendali.

Situasi B: Hanya sebagian wilayah/sebagian jaringan yang memberikan umpan balik tentang konten lama.
Kemungkinan utama: Status caching dari node tepi yang berbeda tidak sama.

• Solusinya: Gunakan strategi versi/penyegaran untuk mengurangi perbedaan; jika perlu, lakukan penanganan kegagalan yang lebih jelas.

Kasus C: Pengguna login/keranjang belanja mengalami kelainan.
Tanda peringatan: mungkin konten yang salah tersimpan di cache.

• Segera periksa apakah halaman mode pengguna (keranjang belanja/penyelesaian pembayaran/akun, dll.) telah di-cache.
• Periksa apakah Cache Key mengabaikan varian kunci seperti “cookie pengguna/bahasa/mata uang” dan lain-lain.

Rekomendasi.

Cloudflare

• Integrasi proxy terbalik.
• Cocok untuk: Memulai dengan mudah.
• Pont utama: Strategi versi untuk mengatasi pembaruan; Caching HTML dari sudut pandang pengunjung.
• Risiko: Halaman dinamis harus dilewati.

Tencent Cloud International EdgeOne

• Integrasi proxy terbalik.
• Cocok untuk: Mempertimbangkan kapasitas node Tiongkok Daratan dan akses terintegrasi.
• Gratis: Ada paket gratis/versi gratis, tetapi perlu memperhatikan kuota dan batasan yang diberlakukan.
• Risiko: Kuota aturan/log/subdomain perlu direncanakan; caching HTML harus dilakukan dengan hati-hati.

Alibaba Cloud International ESA

• Integrasi proxy terbalik.
• Gratis: Akun stasiun internasional dapat menggunakan akses Entrance secara gratis.
• Risiko: Pastikan terlebih dahulu batasan gratis (SLA/dukungan/batasan kecepatan) dan persyaratan regional/pendaftan.
• Cocok untuk: Evaluasi/Pengujian dengan akses ringan; atau paket upgrade selanjutnya, atau mempertimbangkan kapasitas node Tiongkok Daratan dan akses terintegrasi.

\nbunny.net

• \nPull CDN statis.
• Cocok: Lakukan akselerasi statis dengan risiko rendah terlebih dahulu.
• Pontnya: Nomor versi diutamakan, Purge sebagai cadangan; hindari tumpang-tindih nama.
• Risiko: Jika strategi pembaruan tidak dilakukan dengan baik, Anda akan sering menemukan “sumber daya lama”.”

Saran tindakan.

1. Pilih terlebih dahulu: proxy terbalik terintegrasi (Cloudflare/EdgeOne/ESA) atau CDN Pull statis (Bunny).
2. Meluncurkan secara bertahap:Pertama, statis → kemudian strategi versi → terakhir, pertimbangkan caching HTML.
3. Setelah online, periksa sesuai dengan daftar verifikasi: hit/backsource/update/dynamic bypass/error rate.
4. Diperlukan lebih cepat: kembali ke “Plugins Cache” dan “Optimasi Gambar”, dan kompres ulang layer sumber dan layer sumber daya.

Pertanyaan Umum tentang WordPress CDN.

Mengapa masih lambat meski menggunakan CDN?

Alasan paling umum bukanlah CDN tidak berfungsi, tetapi kemacetan tidak terjadi di “lapisan pengiriman”.

Kamu bisa menilai dalam urutan ini:

• Waktu respons server (TTFB) masih sangat tinggi.: Menunjukkan bahwa situs sumber membutuhkan waktu lama untuk menghasilkan HTML (database/plugin/konfigurasi plugin caching/kinerja host) → Kembali ke optimasi tingkat situs sumber.
• Gambar utama di layar pertama sangat lambat.: Menunjukkan bahwa ukuran, dimensi, atau format gambar tidak benar → Lakukan optimasi gambar terlebih dahulu (kompresi, WebP/AVIF, strategi dimensi)
• Skrip pihak ketiga memperlambat.: Skrip iklan/statistik/layanan pelanggan yang umum → CDN biasanya tidak bisa membantu, perlu mengurangi atau menunda pemuatan.
• Hanya di beberapa daerah saja yang lambat.Mungkin karena cakupan node, rute kembali ke sumber, atau cache tidak tersedia (tingkat hit rendah) → Lihat tingkat hit dan situasi kembali ke sumber.

CDN bertanggung jawab untuk mengirimkan “sumber daya yang sudah dioptimalkan” dengan lebih cepat; sementara itu, jika sumbernya lambat, gambar terlalu besar, atau skripnya lambat, masing-masing masalah tersebut harus ditangani secara terpisah.

---

Mengapa saya memperbarui CSS/JS/gambar, tetapi pengguna masih melihat versi lama?

Ini adalah masalah paling umum dalam skenario CDN, dan penyebab utamanya biasanya adalah:URL sumber daya tidak berubah.Sistem cache akan terus mengakses cache lama secara wajar.

Prinsip penanganan paling stabil:

• Nomor versi diutamakan.: Membuat URL sumber daya berubah (misalnya style.css?ver=xxxx Atau, hash nama file.
• \nPurge mengambil tanggung jawab.: Gunakan menghapus cache sebagai solusi sementara jika Anda belum menetapkan strategi versi

Jika Anda sering mengganti banner / gambar aktivitas di halaman utama, disarankan untuk menghindari “penimpaan nama yang sama”, dan sebaiknya gunakan nama file / jalur baru (yang lebih mudah dikendalikan).

---

Apakah saya perlu menyimpan HTML dalam cache? Apakah tidak menyimpannya dalam cache tidak akan ada gunanya?

Itu tidak selalu diperlukan.

Untuk banyak situs, nilai terbesar CDN berasal dari:

• Sumber daya statis (gambar/CSS/JS/font) lebih cepat.
• Penurunan tekanan di stasiun sumber dan peningkatan stabilitas.

Menyimpan HTML dalam cache. Memang, manfaatnya mungkin lebih besar (TTFB akan lebih rendah), tetapi risikonya juga paling besar: e-commerce, keanggotaan, konten yang dipersonalisasi, dan multi-bahasa/multi-mata uang semuanya rentan terhadap kesalahan caching konten.

Rute yang aman:

1. Pertama, lakukan CDN statis (risiko rendah, imbal hasil tinggi).
2. Melaksanakan strategi versi dan daftar verifikasi.
3. Evaluasi lagi apakah HTML harus di-cache (mulai dari “mode pengunjung”).

---

Bisakah situs e-commerce menggunakan CDN? Apakah itu akan membuat keranjang belanja menjadi kacau?

Bisa, dan seharusnya (setidaknya untuk sumber daya statis), tetapi hindari menyimpan halaman dalam mode pengguna.

• Sumber daya statis dapat di-cache.: Gambar, CSS, JS
• Halaman dalam mode pengguna harus dilewati.: Halaman terkait keranjang belanja, penyelesaian pembayaran, dan akun tidak boleh disimpan dalam bentuk HTML.
• Selama Anda tidak melakukan caching HTML pada halaman-halaman ini, risiko terjadinya “cross-cart/cross-account” akan sangat berkurang.

---

Bagaimana cara membuat CDN untuk situs multibahasa/multimata uang agar tidak mengganggu bahasa/harga?

Intinya adalah Kunci Cache Apakah itu benar?

• Bahasa (jalur atau subdomain)
• Mata uang (jika memengaruhi penampilan harga)
• Apakah sudah login (cookie)?
• Area/tarif pajak (jika halaman tersebut dapat berubah tergantung area)

Jika dimensi-dimensi ini tidak masuk ke logika caching, maka akan sangat mudah terjadi hal-hal seperti pengguna bahasa A yang melihat konten dalam bahasa B, atau ketidaksesuaian harga.

---

Haruskah saya memilih Integrasi Proxy Terbalik (Cloudflare/EdgeOne/ESA) atau CDN Pull Statis (Bunny)?

Kamu bisa memilih berdasarkan “tujuan” dan “toleransi risiko”:

• Ingin menyelesaikan HTTPS + CDN + keamanan dasar sekaligus, dan kemudian dapat memperluas aturan/WAF di masa mendatang:Integrasi proxy terbalik.
• Saya ingin melakukan langkah pertama yang paling aman terlebih dahulu (sumber daya statis lebih cepat), dan tidak ingin mengubah seluruh proksi situs web:\nPull CDN statis.(Misalnya kelinci)

Jika Anda ragu, saran defaultnya adalah:Pertama, CDN statis. → Uji coba strategi versi dan daftar verifikasi → Kemudian putuskan apakah akan menggunakan caching berbasis proxy/HTML.

---

7 Apakah versi gratisnya bisa langsung digunakan di situs web resmi?

Itu bisa digunakan, tetapi pertimbangkan “gratis” sebagai “awal/penilaian/penggunaan ringan”, jangan anggap itu sebagai “solusi resmi dengan SLA komersial”.

• Apakah Anda dapat menerima solusi gratis?Batas kuota, kurangnya fungsi, perbedaan dalam dukungan, dan kemungkinan tidak ada komitmen SLA.？
• Jika tidak bisa, maka seharusnya menganggapnya sebagai uji coba gratis, dan kemudian meningkatkan ke paket yang lebih cocok.

---

8 Bagaimana saya bisa memastikan CDN benar-benar berfungsi, bukan hanya sekadar ketenangan pikiran?

Gunakan tiga langkah ini untuk mengonfirmasi (tanpa memerlukan alat yang rumit):

1. Lihat apakah sumber daya statis dikembalikan dari CDN.(Apakah sumber gambar/CSS/JS berubah?)
2. Lihat apakah tingkat keberhasilan dan rasio konversi telah meningkat.(Hanya dianggap sebagai keuntungan nyata jika jumlah klik meningkat dan jumlah pengunjung yang kembali ke sumbernya berkurang.)
3. Mengubah strategi pembaruan validasi CSS/gambar sekali.(Nomor versi berlaku, yang menunjukkan bahwa tautan tersebut dapat dikontrol)

Jika Anda tidak dapat melakukan hal yang ke-3, maka semakin Anda mengoptimalkan, semakin besar kemungkinan Anda akan mengalami masalah “pembaruan tidak berlaku”. Disarankan untuk melengkapi strategi versi terlebih dahulu.

---

9 Mengapa akselerasi Tiongkok Daratan sering kali tertinggal?

Alasan paling umumnya adalah:\nPilihan wilayah tidak sesuai dengan kondisi pendaftaran.。

• Jika Anda ingin memilih wilayah akselerasi yang mencakup Tiongkok Daratan, biasanya Anda harus menyelesaikan terlebih dahulu. Pendaftaran ICP；Jika belum terdaftar, Anda hanya dapat memilih wilayah yang tidak termasuk Tiongkok Daratan.

---

Haruskah saya menginstal plugin cache terlebih dahulu atau menggunakan CDN terlebih dahulu?

Urutan yang umumnya disarankan adalah:

1. Tingkat stasiun sumber: Plugin caching/hosting harus stabil terlebih dahulu (TTFB berkurang, tekanan latar belakang berkurang).
2. Tingkat sumber daya: Optimisasi gambar untuk mengurangi ukurannya.
3. Tingkat pengiriman: CDN mengirimkan sumber daya dengan lebih cepat dan lebih stabil.

Jika saat ini kamu hanya ingin melakukan satu hal, tetapi takut gagal:Pertama, unggah CDN statis (tahap 1).Keuntungannya stabil, dengan risiko paling rendah.