Pengoptimalan yang Dipercepat Situs Web CDN

Jika Anda membagi pengoptimalan performa WordPress menjadi tiga lapisan:

• lapisan stasiun sumberHosting / PHP / Database / Plugin Caching - Memutuskan TTFB dan Tekanan Backend
• lapisan sumber dayaPengoptimalan Gambar - menentukan ukuran dan kecepatan pengunduhan gambar besar pertama
• lapisan pengiriman:: CDN - Tentukan sumber daya yang lebih dekat dengan pengunjung, pukul lebih keras, sumber lebih mudah

makalah ini Akselerasi CDN：

• Mengetahui apa yang dilakukan dan tidak dilakukan oleh CDN
• Pilih formulir CDN dan penyedia layanan yang tepat untuk Anda (dan pahami batas versi gratis/versi pemula)
• Tayangkan dengan urutan berisiko rendah, tanpa membuat situs crash atau mengalami insiden dengan cache e-commerce/keanggotaan
• Verifikasi bahwa “ini berfungsi” dan selesaikan masalah “mengapa tidak memperbarui/mengapa melambat/mengapa merangkai konten” saat ditayangkan.”

1. Mari kita luruskan konsepnya: apa yang dilakukan dan tidak dilakukan oleh CDN.

1.1 CDN membahas 3 hal utama

1.1.1 Pengiriman sumber daya statis yang lebih cepat
Sumber daya statis seperti gambar / CSS / JS / font / ikon lebih dekat dengan pengunjung, mengunduh lebih cepat, dan merender halaman dengan lebih konsisten.
Untuk WordPress, terutama tema dan sumber daya plugin (wp-content/themes/、wp-content/plugins/) serta gambar galeri media (wp-content/uploads/) biasanya “lebih besar”.

1.1.2 Mengurangi tekanan pada stasiun sumber
Setelah mencapai edge cache, permintaan tidak lagi dikembalikan ke sumber sesering sebelumnya, dan bandwidth, koneksi bersamaan, IO disk, dan fluktuasi CPU pada sumber menjadi lebih ringan.
Hal ini terutama berlaku untuk skenario gelombang seperti “halaman acara, ledakan artikel, dan halaman produk yang mendapatkan banyak kunjungan”.

1.1.3 Stabilitas yang lebih baik (lebih tahan terhadap fluktuasi)
Ketika trafik melonjak, edge node menyerap sejumlah besar permintaan duplikat, dan stasiun sumber jauh lebih kecil kemungkinannya untuk rusak.
Anda akan melihat “akses yang lebih lancar”: cache tepi terus menghasilkan output bahkan ketika situs sumber mengalami tekanan sesaat.

---

1.2 3 Jenis masalah yang tidak dapat diselesaikan oleh CDN secara otomatis

1.2.1 Stasiun sumber lambat itu sendiri
Basis data yang lambat, logika plugin yang lambat, perhitungan PHP yang lambat - ini adalah masalah pada tingkat situs sumber.
CDN dapat membuat sumber daya statis menjadi lebih cepat, tetapi jika Anda bahkan halaman beranda HTML yang dihasilkan sangat lambat, pengguna akan tetap merasa bahwa “buka dengan lambat”. Kali ini prioritasnya kembali ke: pengaya hosting / caching / pengoptimalan basis data.

1.2.2 Gambar itu sendiri terlalu besar
CDN tidak dapat “secara ajaib membuat” gambar besar 3MB menjadi lebih kecil.
Anda sebaiknya melakukan pengoptimalan gambar terlebih dahulu: strategi ukuran (jangan mengunduh gambar yang terlalu besar), kompresi, WebP/AVIF, strategi pemuatan yang malas, dll.

1.2..3 Skrip pihak ketiga yang lambat
Iklan, statistik, layanan pelanggan, komponen media sosial, dll. berasal dari domain pihak ketiga.
CDN biasanya tidak dapat membantu mereka menjadi “lebih cepat”, Anda hanya dapat menanganinya dengan mengurangi/menunda pemuatan, mengganti vendor, atau melakukan pengoptimalan kebijakan skrip.

2. Pilihan 30 detik: Formulir CDN mana yang Anda perlukan?

Untuk WordPress, ada dua kategori utama. Jika Anda memilih “Format” dan kemudian “Penyedia Layanan”, idenya akan sangat jelas.

2.1 “Tipe proxy terbalik” all-in-one (lebih sedikit usaha, cocok untuk sebagian besar situs)

**特点：**它不仅是 CDN，还把 DNS / SSL / Perlindungan keamanan dasar (mis. DDoS / WAF) Dikemas bersama. Anda mengaksesnya dan berdiri di depan situs Anda sebagai proxy.

Apa yang akan Anda dapatkan:

• HTTPS Manajemen Sertifikat dan TLS yang Lebih Mudah
• Portal keamanan terpadu (DDoS dasar, kontrol akses, WAF, dll.)
• Edge caching dengan mesin aturan (dapat melakukan lebih banyak kebijakan caching granular, kebijakan bypass)
• “Lebih banyak ruang untuk ekspansi”: jika Anda ingin menambahkan keamanan, batas kecepatan, dan proteksi bot di kemudian hari, biasanya semuanya ada di dalam sistem yang sama.

Penyedia: Cloudflare / EdgeOne Tencent Cloud / ESA Alibaba Cloud

Jika Anda mau:

• Anda ingin. HTTPS + CDN + Keamanan Dasar lakukan semuanya dalam sekali jalan
• Apakah Anda ingin menyatukan lapisan resolusi nama domain/proxy di bawah satu platform?
• Anda lebih tertarik pada “pengalaman keseluruhan dan perluasan selanjutnya” dan tidak ingin membagi DNS, sertifikat, CDN, keamanan ke dalam beberapa set.

---

2.2 “Static Pull CDN” murni (start berisiko rendah, terutama akselerasi gambar/CSS/JS)

**特点：**你只把静态资源放到 CDN 边缘缓存；HTML 页面仍由源站（以及源站缓存插件）负责。

Apa yang akan Anda dapatkan:

• Risiko bisnis yang sangat rendah: tidak ada “crosstalk/keranjang belanja” tanpa menyentuh HTML”
• Pemodelan biaya lebih intuitif: biasanya ditagih berdasarkan lalu lintas/permintaan/wilayah
• Struktur yang lebih murni: lebih seperti “layanan distribusi sumber daya statis”.”

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

Jika Anda mau:

• Anda ingin mengambil “langkah paling pasti” terlebih dahulu - akselerasi sumber daya statis.
• Anda ingin mendapatkan pendapatan dengan cepat sebelum memutuskan apakah akan menggunakan jenis proxy/ cache situs penuh atau tidak
• Anda ingin biayanya lebih dekat dengan “membayar apa yang Anda gunakan.”

3. Bagaimana cara melakukannya

• Tingkat 1: Jenis agen terintegrasi (lebih disukai): Cloudflare / EdgeOne / ESA
• Tingkat 2: Tarikan Statis CDN (awal yang kokoh): bunny.net / Cloudways CDN dll.

4. Penyedia layanan yang direkomendasikan

4.1 CloudflareIntegrasi proksi terbalik (mulai bebas, matang secara ekologis)

Apa itu?
Anda mencolokkan domain dan domain tersebut berdiri di depan situs sebagai proxy, menyediakan kemampuan CDN, sertifikat, perlindungan dasar, dan aturan caching.

untuk siapa

• Ingin menghemat: HTTPS + CDN + Keamanan Dasar dalam satu paket
• Ingin ekosistem yang matang: tindak lanjut untuk menambahkan WAF, batas kecepatan, aturan tepi, dll., jalurnya mulus

titik risiko

• Pembaruan tidak berlakuTautan cache yang lebih panjang (cache browser + cache CDN + cache sumber) setelah CDN ditayangkan, perlu “kebijakan versi” untuk menjaga pembaruan tetap terkendali (pohon pemecahan masalah nanti)
• Berhati-hatilah dengan caching HTMLjika caching HTML, halaman e-commerce/keanggotaan/personalisasi harus dilewati secara ketat atau rentan terhadap insiden serius (daftar skenario berikut)

instruksi：

• Pemosisian: Integrasi Proksi Terbalik (SSL + CDN + Perlindungan Dasar)
• Cocok untuk: menyimpan secara online, ruang yang besar untuk perluasan berikutnya
• Nilai inti: portal sertifikat/keamanan/cache terpadu
• Risiko: Pembaruan bergantung pada kebijakan versi; cache HTML perlu dilewati dengan ketat

---

4.2 Tencent Cloud International EdgeOne: Integrasi proksi terbalik

Apa itu?
Formulir ini juga merupakan platform all-in-one “akselerasi + keamanan + sertifikat”, yang cocok untuk menempatkan situs ke dalam manajemen lapisan agen terpadu.

• memiliki versi gratis seperti Cloudflare, tetapi biasanya ada Kuota/pagu fungsional(jumlah aturan, jumlah tugas pencatatan, dll.), tetapi tidak ada modifikasi pada DNS yang diperlukan, hanya akses cname keVersi gratis tidak direkomendasikan untuk situs web komersial！
• Sementara itu, paket gratis sering kali berarti SLA tidak dijamin
  Ini berfungsi, tetapi tidak sebagai “paket SLA komersial”.

• Jika Anda ingin beralih secara otomatis di antara jalur Cina daratan di Cina daratan, Anda biasanya harus menyelesaikanRekor ICP Tiongkokhanya rute internasional yang dapat digunakan jika tidak diajukan.

Deskripsi:

• Pemosisian: Integrasi proksi terbalik (akselerasi + keamanan + sertifikat)
• Ideal untuk: mereka yang menginginkan akses terintegrasi dan mempertimbangkan kapasitas node di daratan Tiongkok
• Gratis: tersedia paket gratis/versi gratis, tetapi kuota terbatas dan SLA biasanya tidak dijamin
• Risiko: aturan/log/kuota subdomain harus direncanakan terlebih dahulu; caching HTML harus sama berhati-hatinya

---

4.3 Aliyun International ESA: Integrasi proksi terbalik

• memiliki versi gratis seperti Cloudflare, tetapi biasanya ada Kuota/pagu fungsional(jumlah aturan, jumlah tugas pencatatan, dll.), tetapi tidak ada modifikasi pada DNS yang diperlukan, hanya akses cname keVersi gratis tidak direkomendasikan untuk situs web komersial！
• Mendaftar untuk mendapatkan akun di situs internasional untuk digunakan
• Buka konsol ESA untuk menambahkan situs dan pilih yang gratis Pintu masuk akses berlangganan
• Jika Anda ingin beralih ke daratan Tiongkok secara otomatis, Anda biasanya harus melengkapi berkas ICP terlebih dahulu; Anda hanya dapat pergi ke rute internasional jika Anda belum mengajukannya.
• Gratis lebih cocok untuk pengembangan/pengujian/evaluasi dan biasanya tidak setara dengan paket SLA komersial.
• Paket gratis sering kali memiliki batas kecepatan/pembatasan metode dukungan (mis. SLA, dll.)

Tentang jalur Cina daratan:

• Untuk mengaktifkan node Cina daratan, Anda biasanya harus memenuhi persyaratan pengarsipan dan regional
• Pintu Masuk Gratis Rute internasional default, jika ingin mengambil rute Tiongkok daratan harus dilengkapi.Persyaratan Rekor ICP China

Deskripsi:

• Pemosisian: integrasi proksi terbalik (akselerasi situs + keamanan)
• Gratis: akun stasiun internasional tersedia Akses masuk gratis; default tidak termasuk akselerasi Cina daratan
• Ideal untuk: evaluasi/pengujian dengan penggunaan ringan; atau paket peningkatan berikutnya
• Risiko: batas-batas bebas yang harus diperhatikan (SLA/batas kecepatan/metode dukungan); zona dan pengajuan yang harus direncanakan sebelumnya

---

4.4 bunny.net: Static Pull CDN (start berisiko rendah, penagihan per volume yang jelas)

Jika Anda ingin “mendapatkan keuntungan yang paling pasti terlebih dahulu”, Pull CDN seperti kelinci sangat cocok:
Ini lebih seperti “layanan pengiriman sumber daya”: Anda memberikan sumber daya statis untuk dikirimkan, biayanya biasanya terkait dengan lalu lintas/permintaan/wilayah, dan modelnya jelas serta dapat dikontrol.

Cocok:

• lakukan sth. pertama Gambar / CSS / JS / Font Akselerasi statis dari
• Anda ingin mendapatkan “pendapatan berisiko rendah dan stabil” terlebih dahulu, dan tidak terburu-buru untuk menyerahkan seluruh situs ke platform tipe proxy (DNS/SSL/WAF all-in-one).
• Anda ingin model biaya lebih dekat dengan “membayar apa yang Anda gunakan” daripada langsung masuk ke paket yang lebih kompleks.

titik risiko

Sumber daya statis “pembaruan tidak berlaku” hampir selalu bukan merupakan bug di CDN.melainkan merupakan perilaku normal dari sistem caching:
Saat Anda memperbarui CSS/JS/gambar di backend, tetapiURL sumber daya tidak berubah.(alamat/nama file/jalur yang sama), CDN dan browser akan terus menggunakan cache lama, dan Anda akan melihat “mengapa tidak diperbarui”.

Prinsip yang jelas dan dapat diterapkan:

Nomor versi didahulukan, Bersihkan kantong.

Mengapa ini adalah yang paling stabil:

• Perubahan nomor versi/nama file → Perubahan URL → CDN di-cache sebagai sumber daya baru → versi baru segera berlaku
• **Purge** mengharuskan Anda untuk memicunya secara aktif, yang cenderung menghasilkan jangkauan yang tidak akurat dan penyebaran node yang tertunda; seringnya melakukan Purge juga dapat menghasilkan hit rate yang lebih rendah, lebih banyak return, dan volatilitas yang lebih tinggi.

Contoh yang mudah dilihat:

• style.css Konten telah berubah, tetapi URL-nya masih style.css → CDN Lanjutkan memberikan cache lama (wajar)
• URL menjadi style.css?ver=20260103 或 style.abc123.css → CDN Dianggap sebagai sumber daya baru → versi baru segera berlaku

Kelinci sebagai Praktik Terbaik “Langkah Pertama CDN”

1. Cakup hanya sumber daya statis terlebih dahulu(gambar/CSS/JS/font), jangan langsung men-cache HTML!
   • Manfaat: Hampir tidak ada insiden serius seperti “pengguna melihat konten/nomor seri troli orang lain”.
   • Anda juga lebih mungkin memvalidasi keuntungan: sumber daya statis yang lebih cepat, stasiun sumber yang lebih ringan
2. Menetapkan strategi pembaruan dengan benar
   • CSS/JS: coba gunakan perubahan nomor versi/nama file
   • Gambar: cobalah untuk menghindari “cakupan nama yang sama” dalam jangka panjang, perubahan nama / jalur file baru yang lebih direkomendasikan (terutama spanduk halaman beranda, peta acara)
3. Konfirmasikan hit dengan daftar periksa validasi saat ditayangkan
   • Apakah sumber daya statis berasal dari CDN
   • Apakah hit rate secara bertahap meningkat dan bandwidth/permintaan sumber menjadi lebih lancar (daftar verifikasi berikut)

5. Peta jalan menuju garis teratas: maju dalam 3 fase (dari stabil ke kuat)

CDN Cara termudah untuk “mengacaukan” di telepon adalah mencoba mendapatkan semua kemampuan sekaligus.

Tahap 1: Sumber daya statis hanya CDN (sangat disarankan terlebih dahulu)

tujuanGambar/CSS/JS/font menggunakan CDN terlebih dahulu; HTML tidak ada dalam cache CDN (atau tidak bergerak untuk sementara).

Mengapa ini adalah hal yang paling aman untuk dilakukan pertama kali?

• Risiko minimal: cache sumber daya statis salah, hingga “gaya/gambar tidak diperbarui”, dapat dikelola
• Tidak akan menyentuh status login, proses e-commerce, kebenaran informasi akun
• Anda dapat dengan jelas melihat manfaatnya: pengunduhan sumber daya statis yang lebih cepat dan situs sumber yang lebih lancar!

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

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

---

Tahap 2: Strategi penyegaran (nomor versi terlebih dahulu, kantong pembersihan/kegagalan)

Ini adalah titik awal dari “CDN dilakukan secara profesional atau tidak”.

Aturan yang keras:

Jangan mengandalkan Purge untuk pembaruan yang dapat diselesaikan dengan perubahan nomor versi/nama file.

Mengapa tautan cache menjadi metafisik ketika semakin panjang:

• Cache browser: Anda mungkin memiliki CSS/JS lama yang disimpan secara lokal.
• CDN Caching: Node tepi mungkin menyimpan sumber daya lama
• Cache situs sumber: Plugin cache/cache server mungkin masih mengeluarkan konten lama

Jika Anda tidak memiliki strategi versi, maka rilis akan menjadi seperti itu:
“Mengubah sesuatu → Segarkan → Tidak berhasil → Hapus cache lagi → Tidak berhasil lagi → Hapus tingkat cache lain”
Itulah titik masalah terbesar yang dialami banyak orang dengan CDN.

---

Tahap 3 (lanjutan): untuk men-cache atau tidak men-cache HTML (hasil tinggi tetapi risiko tertinggi)

Cache HTML (cache situs penuh/cache tepi) secara signifikan mengurangi TTFB, tetapi juga merupakan area insiden yang tinggi dalam skenario WordPress.

Jangan cache HTML jika Anda tidak yakin. statis pertama CDN + plugin cache sumber.

Jika Anda ingin menyimpan cache HTML, ada dua aturan yang berlaku:

1. Ini hanya dimulai dengan “Status Pengunjung”.Hanya halaman pengunjung yang tidak di-cache yang tidak di-cache
2. Tulis daftar bypass terlebih dahulu: Ketepatan adalah yang utama, lalu memukul

6. Daftar aturan skenario: apa yang harus dilakukan untuk berbagai jenis lokasi tanpa insiden

6.1 Situs konten / blog (berbasis artikel, banyak pengunjung)

testimonial

• Sumber daya statis: sepenuhnya di-cache
• HTML: pertimbangkan untuk menyimpan cache “halaman pengunjung yang tidak masuk”

Sering kali perlu untuk melewati

• Backend & Login:/wp-admin/*、/wp-login.php
• Pratinjau/draft (pratinjau)
• Halaman hasil pencarian (parameter banyak berubah, akan lebih ekonomis jika tidak disimpan dalam cache terlebih dahulu)
• Permintaan POST untuk pengiriman formulir/kiriman komentar

Kunci Cache setidaknya harus membedakan antara

• Masuk atau tidak (dimensi cookie)
• Bahasa (stasiun multibahasa)

---

6.2 Situs perusahaan / halaman arahan pemasaran (formulir, banyak aktivitas)

testimonial

• Sumber daya statis: sepenuhnya di-cache
• HTML: halaman arahan publik dapat di-cache (status tamu), tetapi hati-hati dengan halaman hasil formulir

Jebakan termudah untuk dilewati: melacak parameter yang mengarah ke fragmentasi cache
Halaman arahan adalah hal yang umum utm_* Parameter:

• Semua Tombol Cache yang Terlibat → Cache Rusak, Rasio Hit yang Buruk
• Abaikan Semua → Beberapa halaman yang bergantung pada rendering parameter mungkin tidak seperti yang diharapkan

---

6.3 Situs keanggotaan / situs kursus / komunitas (pangsa status login yang tinggi)

mencapai putusanCaching HTML harus dilakukan dengan sangat hati-hati.
Praktik yang aman biasanya adalah: CDN statis + cache sumber/objek; HTML hanya menyimpan status tamu.

Harus memotong

• Masuk/Daftar/Mengambil Kata Sandi
• Pusat Akun, Pesanan/Langganan, Detail Pribadi
• Setiap halaman dan antarmuka “status pengguna yang sangat relevan”

---

6.4 Stasiun perdagangan elektronik (WooCommerce)

Daftar jalan pintas yang paling penting

• Keranjang Belanja, Checkout, Halaman Akun
• Konfirmasi pesanan, halaman terkait panggilan balik pembayaran
• Login/pendaftaran, kupon/poin, dan pintu masuk terkait status pengguna lainnya

Mengapa e-commerce lebih rentan terhadap kecelakaan

• Setelah pengguna memiliki keranjang belanja, sesi, dan status login, halaman ini sangat dipersonalisasi
• Konsekuensi umum dari cache HTML yang tidak dilewati/dibedakan adalah: ketidaksesuaian keranjang belanja, string akun, dan anomali tampilan harga.
  Ketepatan lebih diutamakan, jangan mengorbankan ketepatan untuk mendapatkan hasil yang bagus.

---

6.5 Situs Multi-Bahasa/Multi Mata Uang

testimonial

• Sumber daya statis: sepenuhnya di-cache
• HTML: status tamu dapat di-cache, tetapi kunci cache harus dengan jelas membedakan antara varian bahasa/mata uang

Kunci Cache harus dipertimbangkan

• Bahasa (Path) /en/ /zh/ atau subdomain en.）
• Apakah akan masuk (cookie)
• Mata uang/tarif pajak (jika mempengaruhi penyajian)

---

7. Peringatan risiko

Risiko 1: Menyimpan konten yang salah (paling serius)

• Kesalahan penyimpanan sumber daya statis: sebagian besar gaya/gambar lama
• Kesalahan caching HTML: mungkin konten string, keranjang belanja string, akun string - ini adalah insiden serius!

Risiko 2: Pembaruan tidak berlaku (paling umum)

Seiring dengan semakin panjangnya tautan cache, “perubahan tidak berlaku” akan semakin sering terjadi:

• Perubahan nomor versi/nama file lebih diutamakan
• Pembersihan / kegagalan menjajakan
• Proses penerbitan harus dapat direproduksi (mengetahui URL apa yang diubah untuk setiap penerbitan)

Risiko 3: Batas komitmen untuk versi gratis/versi pemula

• Fitur umum dari program gratis: kuota terbatas, beberapa kapasitas dikecualikan, pendekatan SLA/dukungan tidak setara dengan penggunaan komersial penuh

Risiko 4: Kompetensi yang berhubungan dengan Tiongkok Daratan mudah disalahartikan

• ESA: Rekor ICP Tiongkok Diperlukan untuk Rute Tiongkok Daratan
• EdgeOne: Pengajuan ICP Tiongkok diperlukan untuk rute-rute di daratan Tiongkok

8 Daftar periksa validasi: cara mengonfirmasi bahwa itu “benar-benar berfungsi” setelah ditayangkan”

8.1 Apakah sumber daya statis benar-benar hilang CDN?

• Gambar/CSS/JS baik dari domain/simpul tepi CDN
• Apakah Anda dapat melihat tanda-tanda yang jelas dari cache hit atau tidak (tanda bervariasi menurut platform)

8.2 Apakah tekanan stasiun sumber turun?

• Apakah bandwidth stasiun sumber lebih lancar
• Apakah jumlah permintaan/koneksi dari situs sumber telah menurun (terutama permintaan untuk sumber daya duplikat)

8.3 Apakah pembaruan dapat dikelola?

• Ubah CSS/JS sekali atau ganti gambar.
• Apakah versi baru dapat dilacak dengan cepat melalui “perubahan nomor versi/perubahan nama file”.
• Jika Anda hanya dapat memperbarui dengan Purge, Anda belum memiliki strategi versioning yang baik (prioritaskan strategi patching, jangan jadikan Purge sebagai rutinitas harian)

8.4 Apakah halaman kunci dinamis sudah benar?

(Situs e-commerce/situs keanggotaan adalah suatu keharusan)

• Konten halaman setelah login/logout sudah benar
• Halaman terkait keranjang belanja/checkout/akun selalu benar
• Tidak ada pengecualian “pengguna yang berbeda melihat konten status pengguna yang sama” (risiko tinggi).

8.5 Apakah tingkat kesalahan meningkat?

• Batas waktu kembali ke sumber, 5xx, kegagalan intermiten untuk membuka
• Hal ini biasanya berarti: pembawa yang tidak mencukupi di sumber, aturan yang salah, pemicu batas kecepatan, atau masalah dengan tautan kembali ke sumber

9. Memperbarui pohon non-fungsionalitas (mengubah “metafisika” menjadi langkah-langkah)

Mulailah dengan menentukan jenis masalah yang Anda alami:

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

Skenario A: Hanya Anda yang melihat perangkat lama, perangkat siluman/tukar guling yang baru
Kecurigaan prioritas: cache browser

• Arah resolusi: rilis sumber daya baru dengan perubahan nomor versi/nama file

Skenario B: Semua orang melihat yang lama (siluman/perangkat yang berbeda juga lama)
Kecurigaan prioritas: CDN masih menggunakan cache lama

• 99% Penyebab: URL sumber daya tidak diubah
• Solusi prioritas: strategi pembuatan versi
• Saku: Pembersihan (sarana sementara)

Skenario C: Gambar lama tetap muncul setelah gambar ditimpa dengan nama yang sama.
Ini adalah masalah klasik dengan cache browser + hamparan cache CDN

• Saran praktis: cobalah untuk menghindari “penimpaan nama yang sama” dalam jangka panjang, gunakan nama file/path atau nomor versi yang baru

---

9.2 HTML tidak diperbarui (konten halaman/modul masih lama)

Skenario A: backend/login baru, pengunjung melihat yang lama
Kecurigaan prioritas: HTML tamu di-cache

• Hal pertama yang pertama: haruskah halaman-halaman ini menyimpan cache HTML?
• Jika harus di-cache: perlu strategi penyegaran yang terkendali, jika tidak, rilis tidak dapat dikontrol

Skenario B: Hanya beberapa wilayah/beberapa jaringan yang memberikan konten lama
Keraguan prioritas: node tepi yang berbeda memiliki status cache yang berbeda

• Arahan untuk resolusi: konvergensi perbedaan dengan strategi pembuatan versi/penyegaran; lakukan pembatalan yang lebih eksplisit jika perlu

Skenario C: Ketidaknormalan pada pengguna yang login/keranjang belanja
Tanda risiko tinggi: mungkin menyimpan konten yang salah

• Segera periksa apakah halaman status pengguna (keranjang/checkout/akun, dll.) di-cache
• Periksa apakah Kunci Cache mengabaikan varian kunci seperti “userland cookie/bahasa/mata uang”.

10. Rekomendasi

Cloudflare

• Integrasi proxy terbalik
• Cocok untuk: awal yang hemat
• Fokus: kebijakan versi untuk mengatasi pembaruan; cache HTML dilakukan dari status tamu
• Risiko: Halaman dinamis harus dilewati

Tencent Cloud International EdgeOne

• Integrasi proxy terbalik
• Cocok: Pertimbangkan kapasitas simpul Cina daratan dan akses terintegrasi
• Gratis: ada paket gratis/versi gratis, tetapi batasan kuota dan komitmen harus dilihat dengan jelas
• Risiko: aturan/log/kuota subdomain yang harus direncanakan; cache HTML dengan hati-hati

Aliyun International ESA

• Integrasi proxy terbalik
• Gratis: Tersedia akun internasional Akses Masuk Gratis
• Risiko: Batas bebas (SLA/dukungan/batas kecepatan) dan zona/kondisi pengarsipan harus dikonfirmasi terlebih dahulu
• Cocok untuk: evaluasi/pengujian dan akses ringan; atau peningkatan paket berikutnya, atau mempertimbangkan kapasitas node di daratan Cina dan akses terintegrasi

bunny.net

• Tarik Statis CDN
• Cocok: akselerasi statis berisiko rendah terlebih dahulu
• Fokus: nomor versi terlebih dahulu, Bersihkan penyamaran; hindari penggantian nama yang sama
• Risiko: Sering bertemu dengan “sumber daya lama” jika strategi pembaruan tidak dilakukan dengan benar.”

11. Rekomendasi untuk ditindaklanjuti

1. Pilihan bentuk pertama: integrasi proxy terbalik (Cloudflare/EdgeOne/ESA) atau Pull statis CDN (kelinci)
2. Tayangkan secara langsung di atas panggung:Statis terlebih dahulu → kemudian kebijakan versi → terakhir pertimbangkan cache HTML
3. Periksa dengan daftar periksa validasi setelah go-live: hit/kembali ke sumber/pembaruan/pintas dinamis/tingkat kesalahan
4. Perlu lebih cepat: kembali ke “Cache Plugin”, “Image Optimization”, dan kompres lagi lapisan sumber dan sumber daya!

Pertanyaan yang Sering Diajukan WordPress CDN

1. Mengapa masih lambat setelah menggunakan CDN?

Alasan yang paling umum bukan karena CDN tidak berfungsi, tetapi hambatannya bukan pada “lapisan pengiriman”.

Anda dapat menilai mereka dalam urutan itu:

• TTFB masih tinggi.Penjelasan tentang pembuatan HTML yang lambat dari sumbernya (konfigurasi database/plugin/cache plugin/performa hosting) → kembali ke pengoptimalan tingkat sumber
• Gambar besar pertama sangat lambatmenunjukkan volume, ukuran, atau format gambar yang salah → lakukan pengoptimalan gambar terlebih dahulu (kompresi, WebP/AVIF, strategi ukuran)
• Skrip pihak ketiga melambat: skrip iklan/statistik/layanan pelanggan adalah umum → CDN Biasanya tidak membantu, perlu dikurangi atau ditunda pemuatannya
• Hanya area tertentu yang lambatbisa berupa penimpaan simpul, baris pengembalian, atau cache miss (hit rate rendah) → lihat hit rate dan pengembalian

CDN bertanggung jawab untuk memberikan “sumber daya yang dioptimalkan” lebih cepat; situs sumber yang lambat, gambar besar, dan skrip yang lambat harus ditangani secara terpisah.

---

2. Mengapa pengguna masih melihat versi lama meskipun saya telah memperbarui CSS/JS/gambar?

Ini adalah masalah yang paling umum dalam skenario CDN dan biasanya merupakan alasan utamanya:URL sumber daya tidak berubah.sistem cache akan terus menggunakan cache yang lama.

Prinsip perawatan yang paling stabil:

• prioritas nomor versiMembiarkan URL sumber daya berubah (mis. style.css?ver=xxxx atau hash nama file)
• Penjaminan PembersihanMenghapus cache sebagai solusi sementara ketika Anda tidak memiliki kebijakan versi.

Jika Anda sering mengganti banner homepage / gambar kampanye, disarankan untuk menghindari “penimpaan nama yang sama”, dan lebih memilih untuk menggunakan nama file baru / jalur baru (lebih dapat dikontrol).

---

3. Apakah saya perlu menyimpan cache HTML? Apakah tidak ada gunanya jika tidak menyimpannya dalam cache?

Belum tentu dibutuhkan.

Untuk banyak situs, nilai terbesar dari CDN berasal dari:

• Lebih cepat untuk sumber daya statis (gambar/CSS/JS/font)
• Pengurangan Tekanan Stasiun Sumber dan Peningkatan Stabilitas

Caching HTML Manfaatnya mungkin memang lebih besar (TTFB akan lebih rendah), tetapi risikonya juga paling besar: e-commerce, keanggotaan, konten yang dipersonalisasi, multi-bahasa/multi-mata uang, semuanya rentan terhadap penyimpanan konten yang salah.

Rute yang stabil:

1. CDN pertama yang statis (risiko rendah, imbalan tinggi)
2. Jalankan kebijakan pembuatan versi dan daftar periksa validasi
3. Evaluasi kembali apakah akan menyimpan cache HTML (dimulai dengan “status tamu”)

---

4. Dapatkah situs e-commerce menggunakan CDN dan apakah akan mengacaukan keranjang belanja?

Ini bisa diaktifkan, dan seharusnya diaktifkan (setidaknya untuk sumber daya statis), tetapi hindari caching halaman userland.

• Sumber daya statis dapat di-cache: gambar, CSS, JS
• Halaman userland harus melewati halamanJangan menyimpan cache keranjang belanja, checkout, dan halaman terkait akun HTML
• Selama Anda tidak menyimpan cache HTML pada halaman-halaman ini, risiko “crosstalk” akan sangat berkurang!

---

5. Bagaimana situs multi-bahasa/multi-mata uang dapat melakukan CDN tanpa merangkai bahasa/harga?

pusat Kunci Cache Apakah sudah benar.

• Bahasa (jalur atau subdomain)
• Mata uang (jika mempengaruhi tampilan harga)
• Apakah akan masuk (cookie)
• Wilayah/tarif pajak (jika halaman dapat berubah berdasarkan wilayah)

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

---

6. Haruskah saya memilih integrasi proxy terbalik (Cloudflare/EdgeOne/ESA) atau Pull CDN statis (kelinci)?

Anda dapat memilih berdasarkan “Target” dan “Preferensi Risiko”:

• Ingin mendapatkan HTTPS + CDN + keamanan dasar, dengan perluasan aturan/WAF berikutnya dalam sekali jalan:Integrasi proxy terbalik
• Ingin melakukan langkah pertama dari langkah pertama yang paling stabil (sumber daya statis lebih cepat) dan tidak ingin memindahkan seluruh agen:Tarik Statis CDN(misalnya kelinci)

Jika Anda ragu-ragu, gunakan saran default:CDN pra-statis → Jalankan kebijakan versi dan daftar periksa validasi → lalu putuskan apakah akan membuka cache proxy/HTML.

---

7. Apakah versi gratis dapat digunakan secara langsung di situs web resmi?

Layanan ini dapat digunakan, tetapi pikirkan kata “gratis” sebagai “starter/evaluasi/penggunaan ringan”, bukan sebagai “program formal dengan SLA komersial”.

• Apakah Anda merasa nyaman dengan program gratis dariBatas kuota, fitur yang hilang, perbedaan dukungan, dan kemungkinan kurangnya komitmen SLA？
• Jika tidak bisa, Anda harus memperlakukan yang gratis sebagai uji coba dan kemudian meningkatkan ke paket yang lebih sesuai

---

8. Bagaimana saya bisa yakin bahwa CDN benar-benar berlaku dan bukan hanya catatan mental?

Konfirmasikan dengan tiga langkah ini (tanpa alat bantu yang rumit):

1. Lihat apakah sumber daya statis dikembalikan dari CDN(apakah sumber gambar/CSS/JS sudah berubah)
2. Lihat apakah rasio klik dan sumber pengembalian meningkat(Memukul, sumber kembali untuk mendapatkan keuntungan nyata)
3. Ubah strategi pembaruan validasi CSS/gambar sekali saja(nomor versi yang berlaku, menunjukkan kemampuan kontrol tautan)

Jika Anda tidak dapat melakukan #3, semakin Anda mengoptimalkan, semakin besar kemungkinan Anda tersiksa oleh “pembaruan tidak berlaku”, jadi disarankan agar Anda memprioritaskan kebijakan versi.

---

9. Mengapa saya sering macet saat mengaktifkan akselerasi untuk daratan Cina?

Penyebab paling umum adalah:Ketidaksesuaian antara pilihan regional dan kondisi pengajuan。

• Jika Anda ingin memilih wilayah akselerasi yang mencakup daratan Tiongkok, Anda biasanya perlu menyelesaikan bagian ICP 备案Tidak berdokumen hanya dapat memilih wilayah yang tidak termasuk daratan Tiongkok.

---

10. Haruskah saya menginstal plugin caching atau CDN terlebih dahulu?

Urutan umum yang direkomendasikan adalah:

1. Lapisan situs sumber: plugin cache/dasar hosting distabilkan terlebih dahulu (TTFB turun, tekanan backend turun)
2. Lapisan sumber daya: optimalisasi gambar untuk menjaga ukurannya tetap kecil
3. Lapisan Pengiriman: CDN Mengantarkan Sumber Daya Lebih Cepat dan Lebih Konsisten

Jika Anda hanya ingin melakukan satu hal saat ini dan takut membalik:CDN pertama yang statis (Fase 1)dengan imbal hasil yang stabil dan risiko minimal.