Cara Tetapkan Tempoh Cache Penyemak Imbas (Browser Caching) untuk Prestasi Laju

Tempoh cache penyemak imbas (browser caching) ditentukan melalui peraturan HTTP cache yang mengawal berapa lama fail statik laman web anda disimpan dalam pelayar pelawat. Secara praktikal, untuk fail CSS, JavaScript, imej, fon dan ikon, pengepala Cache-Control dan dalam sesetengah persekitaran Expires ditakrifkan; contohnya, untuk fail CSS dan JS yang telah diversikan, 1 tahun adalah ideal, untuk imej 30 hari-1 tahun, manakala untuk halaman HTML, tempoh singkat atau pengesahan semula (revalidation) lebih digalakkan. Tetapan yang tepat menghalang fail yang sama daripada dimuat turun berulang kali, mempercepatkan masa muat halaman dan menambah baik metrik Teras Web Vital (Core Web Vitals).

Dalam panduan ini, kami akan huraikan langkah demi langkah bagaimana cache penyemak imbas berfungsi, berapa saat perlu diberikan untuk setiap jenis fail, serta cara melaksanakannya di Apache, Nginx, LiteSpeed, WordPress dan CDN. Matlamatnya bukan sekadar untuk mendapatkan skor hijau dalam alat uji kelajuan; tetapi untuk menyampaikan fail terkini kepada pengguna sambil menggunakan sumber pelayan secara cekap, mengurangkan TTFB dan penggunaan lebar jalur, serta memberikan lonjakan kelajuan yang ketara semasa lawatan berulang. Terutamanya dalam hosting kongsi, hosting WordPress dan projek web korporat, strategi cache yang betul adalah antara penambahbaikan prestasi paling berkesan yang boleh dicapai dengan kos rendah. Hostragons pakej hosting web

Apa Itu Cache Penyemak Imbas?

Cache penyemak imbas ialah penyimpanan sementara sumber statik yang dimuat turun semasa membuka halaman web pada peranti pengguna. Apabila pelawat memasuki halaman utama anda, logo, fail CSS, fail JavaScript, fon dan imej akan dimuat turun. Jika fail-fail ini mempunyai pengepala cache yang betul, apabila pelawat beralih ke halaman kedua atau kembali ke laman itu kemudian, penyemak imbas tidak akan meminta semula sebahagian fail tersebut daripada pelayan. Ini menjadikan halaman dimuatkan dengan lebih pantas.

Sebagai contoh, bayangkan anda mempunyai halaman utama bersaiz 2 MB. Jika 1.4 MB daripadanya adalah imej, 300 KB adalah fail CSS dan JS, dan 100 KB adalah fon, sumber ini boleh dimuat turun semasa lawatan pertama. Tetapi semasa lawatan kedua, apabila penyemak imbas menggunakan sumber statik ini secara setempat, data yang dipindahkan melalui rangkaian berkurangan secara mendadak. Perbezaan ini lebih ketara pada sambungan mudah alih dan laman web dengan trafik tinggi.

Cache penyemak imbas tidak boleh dikelirukan dengan cache pihak pelayan. Cache pelayan menyimpan output PHP atau pertanyaan pangkalan data di pelayan. Manakala cache penyemak imbas membolehkan penggunaan semula sumber pada peranti pelawat. Untuk prestasi terbaik, kedua-dua lapisan ini harus dirancang bersama. Bagi laman yang menggunakan WordPress, cache halaman, cache objek, cache CDN dan cache penyemak imbas biasanya merupakan sebahagian daripada strategi pengoptimuman yang sama. Hosting WordPress dan pengoptimuman prestasi

Mengapa Browser Caching Penting untuk SEO?

Google menilai laman yang menawarkan pengalaman pantas dan stabil sebagai lebih bernilai dari segi kepuasan pengguna. Cache penyemak imbas secara langsung tidak menjamin kedudukan tinggi; namun, kerana ia mempengaruhi kelajuan halaman, kelewatan interaksi dan kecekapan pemuatan sumber, ia menyokong prestasi SEO. Ia memberi kesan ketara terutamanya dalam senario seperti lawatan berulang, navigasi kategori, peralihan halaman produk, dan penjelajahan dalam blog.

Dalam standard SEO 2026, prestasi teknikal bukan hanya tentang skor Lighthouse semata-mata. Pengalaman pengguna yang dinilai oleh Google berkait dengan LCP, INP, CLS, TTFB dan data pengguna sebenar. Muat turun berulang fail CSS dan JS yang tidak perlu boleh memanjangkan masa LCP. Permintaan semula fon pada setiap halaman boleh menjejaskan kestabilan visual. Kegagalan men-cache imej besar boleh menimbulkan persepsi kelambatan pada pengguna mudah alih.

• Lawatan berulang lebih pantas: Pengguna tidak memuat turun semula fail yang sama.
• Lebar jalur lebih rendah: Trafik pelayan berkurangan, sumber hosting digunakan dengan lebih cekap.
• Kecekapan perangkakan lebih baik: Penyampaian sumber statik menjadi lebih teratur untuk bot dan pengguna.
• Risiko kadar lantunan (bounce rate) lebih rendah: Halaman yang dibuka dengan pantas meningkatkan interaksi pengguna.
• Prestasi lebih konsisten: Turun naik beban pada CDN dan hosting dapat diimbangi dengan lebih baik.

Pengepala Asas HTTP Cache

Tempoh cache penyemak imbas diuruskan melalui pengepala respons HTTP. Pengepala yang paling biasa ialah Cache-Control, Expires, ETag dan Last-Modified. Dalam projek moden, titik kawalan utama adalah pengepala Cache-Control; Expires lebih banyak digunakan untuk keserasian ke belakang.

Cache-Control

Cache-Control memberitahu penyemak imbas dan sistem cache perantaraan cara menyimpan sesuatu fail. Arahan yang paling kerap digunakan adalah seperti berikut:

• max-age: Menentukan berapa saat sumber dianggap segar. Contohnya, max-age=31536000 adalah lebih kurang 1 tahun.
• public: Menunjukkan bahawa sumber boleh disimpan dalam sistem cache kongsi seperti penyemak imbas dan CDN.
• private: Menunjukkan bahawa sumber hanya boleh disimpan dalam penyemak imbas pengguna tertentu.
• no-cache: Menunjukkan bahawa sumber perlu disahkan dengan pelayan sebelum digunakan; ini tidak bermakna cache dimatikan sepenuhnya.
• no-store: Menunjukkan bahawa sumber tidak boleh disimpan di mana-mana; sesuai untuk halaman pembayaran, panel, dan data peribadi.
• immutable: Memberitahu bahawa sumber tidak akan berubah sehingga tempohnya tamat; ideal untuk aset yang nama failnya telah diversikan.

Contoh pengepala fail statik boleh jadi seperti ini: Cache-Control: public, max-age=31536000, immutable. Ini memberitahu penyemak imbas bahawa ia boleh menyimpan fail tersebut selama 1 tahun dan tidak perlu menyemak semula selagi nama fail tidak berubah.

Expires

Pengepala Expires menentukan tarikh dan masa sah laku sesuatu sumber. Contohnya, untuk imej, nilai Expires yang menunjukkan 30 hari kemudian boleh ditetapkan. Walau bagaimanapun, Expires menggunakan tarikh mutlak, jadi ia tidak sefleksibel Cache-Control. Dalam konfigurasi moden, Cache-Control diutamakan; Expires boleh ditambah untuk penyemak imbas lama.

ETag dan Last-Modified

ETag dan Last-Modified adalah mekanisme pengesahan. Penyemak imbas boleh bertanya kepada pelayan sama ada versi fail yang dimilikinya adalah terkini. Jika fail tidak berubah, pelayan membalas dengan respons 304 Not Modified dan badan fail tidak dimuat turun semula. Kaedah ini berguna terutamanya untuk kandungan yang kerap berubah seperti HTML, atau fail yang anda tidak mahu berikan tempoh cache yang panjang.

Jenis Fail Mana Perlukan Tempoh Cache Berapa?

Kesilapan yang paling kerap dilakukan ialah memberikan tempoh yang sama kepada semua jenis fail. Sedangkan HTML, CSS, JS, imej, fon dan respons API mempunyai gelagat pengemaskinian yang berbeza. Peraturan utamanya mudah: Jika nama fail boleh ditukar, cache panjang boleh diberikan; jika kandungan kerap berubah tanpa menukar nama fail, gunakan tempoh singkat atau pengesahan.

Jadual ini adalah titik permulaan umum. Di laman e-dagang, halaman HTML yang mengandungi maklumat stok dan harga tidak seharusnya di-cache secara agresif. Sebaliknya, imej produk boleh di-cache selama 1 tahun selagi nama fail diubah. Di laman korporat, logo, fon dan fail tema boleh disimpan lama; tetapi jika sepanduk kempen kerap berubah, 7-30 hari mungkin lebih selamat.

Bagaimana Merancang Tempoh Cache Penyemak Imbas?

Untuk strategi cache yang berjaya, klasifikasikan dahulu fail-fail di laman anda. Secara teknikal, anda perlu menulis peraturan berdasarkan sambungan fail; secara strategik, anda perlu menentukan tempoh berdasarkan kekerapan pengemaskinian.

1. Asingkan sumber statik dan dinamik

Fail seperti CSS, JS, JPG, PNG, WebP, SVG, WOFF2 adalah sumber statik. HTML, troli, panel pengguna, hasil carian dan respons API dianggap dinamik. Sumber statik di-cache untuk tempoh panjang, manakala kandungan dinamik perlu diurus dengan lebih berhati-hati. Cache awam (public) tidak boleh digunakan untuk kandungan khusus pengguna.

2. Gunakan pemversian fail

Cara selamat untuk tempoh cache panjang adalah pemversian fail. Contohnya, jika anda men-cache fail style.css selama 1 tahun dan kemudian mengubah kandungannya, sesetengah pengguna mungkin terus melihat reka bentuk lama. Sebaliknya, jika anda menggunakan penamaan seperti style.2026.01.css, app.v12.js atau app.8f3a2.js yang mengandungi cincangan fail (file hash), nama fail baharu akan diterbitkan sebaik sahaja kemas kini dibuat dan penyemak imbas akan memuat turun sumber baharu.

Tema WordPress dan alat binaan moden boleh melakukan ini secara automatik. Jika anda membangunkan tema, menggunakan parameter versi dalam fungsi wp_enqueue_style dan wp_enqueue_script memudahkan pengurusan versi melalui rentetan pertanyaan (query string) atau nama fail. Walau bagaimanapun, memandangkan gelagat cache rentetan pertanyaan mungkin berbeza dalam sesetengah konfigurasi CDN, menambah cincangan pada nama fail adalah kaedah yang lebih kukuh.

3. Jangan agresif untuk HTML

Halaman HTML membawa kandungan utama yang dilihat pengguna, jadi ia biasanya diuruskan dengan cache jangka pendek atau pengesahan semula. Untuk catatan blog, cache 5-10 minit mungkin mencukupi; untuk halaman berita, kempen atau harga, tempoh yang lebih singkat diperlukan. Jika anda menggunakan cache halaman di WordPress, anda harus mempertimbangkan pengepala cache penyemak imbas bersama-sama dengan cache pelayan dan mekanisme pembersihan CDN (CDN purge).

4. Matikan cache pada halaman yang memerlukan keselamatan

Untuk halaman log masuk, panel pelanggan, langkah pembayaran, ringkasan pesanan, invois dan halaman yang mengandungi data peribadi, pengepala seperti Cache-Control: no-store, private harus digunakan. Cache penyemak imbas adalah untuk prestasi; tetapi ia tidak sepatutnya menjejaskan keselamatan data peribadi. Penggunaan SSL juga merupakan keperluan asas pada ketika ini. Hostragons sijil SSL

Konfigurasi Cache Penyemak Imbas dengan Apache .htaccess

Pada pelayan Apache, cache penyemak imbas biasanya dikonfigurasikan melalui fail .htaccess. Ini adalah kaedah paling praktikal bagi kebanyakan pemilik laman yang menggunakan hosting kongsi. Pertama, modul mod_expires dan mod_headers mesti aktif. Dalam kebanyakan persekitaran hosting berkualiti, modul ini tersedia secara lalai.

Anda boleh menggunakan logik berikut: tempoh panjang untuk imej dan fon, tempoh panjang untuk CSS dan JS, pengesahan pendek untuk HTML. Dalam peraturan yang akan anda tambahkan pada fail .htaccess, takrifan ExpiresByType dan Header set Cache-Control dibuat mengikut jenis fail. Contohnya, 1 tahun untuk fail image/webp, image/jpeg, image/png, image/svg+xml; 1 tahun untuk text/css dan application/javascript; no-cache untuk text/html boleh dilaksanakan.

Buat sandaran fail .htaccess anda sebelum pelaksanaan. Peraturan yang salah taip boleh menyebabkan ralat 500 Internal Server Error. Selepas membuat perubahan, buka laman dalam tetingkap inkognito, kemudian semak bahagian pengepala respons (response headers) fail yang berkaitan dalam tab Rangkaian (Network) DevTools. Jika Cache-Control tidak kelihatan, modul pelayan mungkin dimatikan, CDN mungkin mengubah pengepala, atau pemalam lain mungkin menimpa (override) pengepala tersebut.

Contoh tempoh untuk Apache: max-age=31536000 untuk CSS dan JS, max-age=31536000 untuk imej, max-age=2592000 untuk PDF, max-age=0 dan no-cache untuk HTML. Nilai-nilai ini baik untuk permulaan; ia harus disemak semula mengikut aliran penerbitan laman anda. Semasa menggunakan tetapan prestasi yang boleh dibuat melalui .htaccess dalam infrastruktur hosting Hostragons, adalah disyorkan untuk memeriksa sama ada terdapat percanggahan dengan tetapan cache tema dan pemalam anda. tetapan prestasi Apache .htaccess

Konfigurasi Browser Caching dengan Nginx

Pada pelayan yang menggunakan Nginx, pengepala cache ditakrifkan dalam blok server atau location. Nginx digemari dalam projek dengan trafik tinggi terutamanya kerana penyampaian fail statiknya yang berprestasi tinggi. Logik asas di sini adalah untuk menentukan nilai expires dan add_header Cache-Control dengan peraturan location berdasarkan sambungan.

Pendekatan contoh adalah seperti berikut: expires 1y dan Cache-Control public, immutable diberikan kepada sumber statik seperti CSS, JS, WebP, JPG, PNG, SVG, WOFF2. Untuk output HTML, expires off atau no-cache lebih diutamakan. Jika anda menggunakan CDN, anda juga harus menguji bagaimana pengepala Cache-Control dari pelayan asal (origin server) ditafsirkan oleh CDN.

Satu isu yang perlu diberi perhatian dalam tetapan Nginx ialah arahan add_header dalam sesetengah keadaan hanya digunakan pada kod respons tertentu. Dalam konfigurasi Nginx moden, parameter always boleh digunakan. Selain itu, jika aplikasi, Nginx dan CDN semuanya menambah pengepala yang sama, nilai Cache-Control yang bercanggah atau bertindih mungkin terhasil. Dalam kes ini, rantai keutamaan mesti dijelaskan, dan satu sumber mesti ditetapkan sebagai autoriti tunggal.

Caching di LiteSpeed dan Laman WordPress

Pelayan LiteSpeed menawarkan kelebihan prestasi yang hebat, terutamanya dalam projek WordPress dengan pemalam LiteSpeed Cache. Walau bagaimanapun, cache penyemak imbas dan cache halaman mesti diasingkan. Apabila pilihan Cache Penyemak Imbas (Browser Cache) diaktifkan dalam pemalam LiteSpeed Cache, pengepala cache untuk fail statik boleh digunakan secara automatik. Namun, adalah penting untuk memeriksa tempohnya.

Amalan yang disyorkan dalam WordPress adalah untuk men-cache aset statik untuk tempoh yang lama dan memastikan pemversian fail aktif. Apabila anda membuat kemas kini tema, perubahan CSS atau perubahan JS, anda harus membersihkan cache pemalam, dan jika CDN digunakan, proses pembersihan CDN (CDN purge) mesti dilaksanakan. Jika tidak, sesetengah pengguna mungkin menghadapi reka bentuk lama atau gelagat JavaScript yang rosak.

Pemalam cache popular mempunyai pilihan seperti Cache Penyemak Imbas, Minify, Combine, Critical CSS, integrasi CDN dan Cache Objek. Mengaktifkan kesemuanya secara agresif pada masa yang sama tidak semestinya betul. Susun dahulu pengepala cache penyemak imbas, kemudian uji tetapan minify dan combine. Memandangkan HTTP/2 dan HTTP/3 telah meluas pada 2026, menggabungkan setiap fail tidaklah sekritikal zaman dahulu; malah dalam beberapa kes, ia boleh mengurangkan kecekapan cache.

Jika laman WordPress anda lambat, isunya mungkin bukan sekadar cache penyemak imbas. Pangkalan data yang membengkak, tema yang berat, terlalu banyak pemalam, imej yang tidak dioptimumkan, dan hosting dengan sumber rendah juga mempengaruhi prestasi. Oleh itu, nilaikan tetapan caching bersama-sama dengan hosting berkualiti, versi PHP terkini, dan konfigurasi SSL yang betul. Hostragons hosting WordPress

Bagaimana Menetapkan Tempoh Cache Apabila Menggunakan CDN?

CDN menyampaikan fail statik anda daripada pelayan tepi (edge servers) yang dekat secara geografi dengan pengguna. Cache penyemak imbas pula menyimpan fail dalam pelayar pengguna. Apabila kedua-dua lapisan ini berfungsi bersama, peningkatan prestasi menjadi lebih ketara. Walau bagaimanapun, tempoh cache tepi (edge cache) yang anda tetapkan dalam panel CDN mestilah serasi dengan pengepala Cache-Control di pelayan asal.

Pendekatan umum boleh jadi seperti ini: Berikan Cache-Control 1 tahun kepada fail statik di pelayan asal, dan takrifkan TTL yang sama atau terkawal di CDN. Apabila fail berubah, versikan nama fail atau lakukan pembersihan CDN. Untuk halaman HTML, jika anda menggunakan cache CDN, buat peraturan khas; pastikan kawasan seperti troli, akaun, pembayaran dan panel pentadbiran dikecualikan daripada cache.

Masalah biasa di laman yang menggunakan CDN ialah fail lama kelihatan selepas kemas kini. Punca biasanya adalah kandungan diubah tanpa menukar nama fail, atau pembersihan CDN tidak dilakukan. Kaedah paling kukuh adalah untuk menjana fail dengan cincangan semasa proses binaan (build process) dan memanggil nama fail baharu dalam HTML. Dengan cara ini, walaupun penyemak imbas dan CDN menyimpan fail lama, halaman baharu akan meminta fail baharu.

Senarai Semak Pelaksanaan Langkah Demi Langkah

Senarai semak berikut menyediakan pelan pelaksanaan praktikal untuk tempoh cache penyemak imbas. Ia boleh dilaksanakan dalam masa 30-60 minit untuk laman korporat kecil; tempoh ujian harus lebih panjang untuk projek e-dagang atau perisian tersuai.

• 1. Keluarkan inventori fail: Asingkan CSS, JS, imej, fon, PDF, HTML dan respons API.
• 2. Tentukan kekerapan kemas kini: Catatkan fail mana yang berubah setiap hari, dan mana yang berubah sebulan sekali.
• 3. Pilih strategi pemversian: Gunakan cincangan nama fail, parameter versi, atau nombor binaan.
• 4. Tambahkan peraturan pelayan: Takrifkan pengepala Cache-Control dalam panel Apache, Nginx, LiteSpeed atau CDN.
• 5. Kecualikan halaman selamat: Gunakan no-store pada halaman admin, pembayaran, troli, panel pengguna dan data peribadi.
• 6. Uji: Sahkan dengan Chrome DevTools, curl -I, WebPageTest, Lighthouse dan ujian peranti sebenar.
• 7. Pantau selepas penerbitan: Periksa sama ada terdapat fail lama yang rosak, reka bentuk yang pecah, atau ralat JS.

Bagaimana Menguji Cache Penyemak Imbas?

Cara terpantas untuk memahami sama ada tetapan berfungsi adalah dengan menggunakan alat pembangun penyemak imbas. Di Chrome, buka halaman, pergi ke tab Rangkaian (Network) DevTools, klik pada fail CSS atau imej, dan periksa nilai Cache-Control di bahagian Pengepala Respons (Response Headers). Pada muatan kedua, anda mungkin melihat ungkapan 'memory cache' atau 'disk cache' dalam lajur Status.

Jika anda menggunakan baris arahan, perintah curl -I domainanda.com/fail.css menunjukkan pengepala respons. Di sini anda boleh menyemak nilai Cache-Control, Expires, ETag dan Last-Modified. Jika pengepala yang anda jangkakan tiada, salah satu lapisan aplikasi, pelayan web, atau CDN mungkin telah mengubah tetapan tersebut.

Untuk ujian prestasi, Lighthouse, PageSpeed Insights dan WebPageTest boleh digunakan. Walau bagaimanapun, daripada mengikut saranan alat ini secara membuta tuli, buat penilaian dengan senario pengguna sebenar. Contohnya, Lighthouse mencadangkan tempoh cache yang panjang untuk fail statik tetapi tidak menjangkakan keagresifan yang sama untuk halaman HTML anda. Selain itu, alat ujian kadangkala memberi amaran untuk skrip pihak ketiga; anda mungkin tidak dapat mengawal tempoh cache untuk Google Fonts, rangkaian iklan, atau skrip media sosial.

Kesilapan yang Kerap Dilakukan

Cache penyemak imbas kelihatan mudah, tetapi jika dikonfigurasikan secara salah, ia boleh menyebabkan masalah kemas kini, risiko keselamatan dan isu pengalaman pengguna. Kesilapan berikut sering dilihat terutamanya di kalangan mereka yang baru bermula.

• Memberi cache 1 tahun kepada semua sumber: HTML, respons API dan kandungan khusus pengguna tidak seharusnya termasuk dalam skop ini.
• Menggunakan cache panjang tanpa pemversian fail: Pengguna mungkin terus melihat fail CSS atau JS yang lama.
• Lupa proses pembersihan CDN: Walaupun pelayan asal dikemas kini, CDN mungkin masih menyampaikan fail lama.
• Menggunakan pemalam cache secara bertindih: Pelbagai pemalam yang menulis pengepala yang sama boleh menyebabkan percanggahan.
• Salah tafsir amaran pihak ketiga: Pengepala cache skrip sumber luaran mungkin di luar kawalan anda.
• Men-cache halaman selamat: no-store mesti digunakan pada halaman pembayaran dan akaun.

Nilai Permulaan yang Disyorkan

Untuk laman baharu, nilai permulaan yang selamat boleh diringkaskan seperti berikut: Fail CSS dan JS 1 tahun jika diversikan; imej 1 tahun, imej kempen yang kerap berubah 30 hari; fon 1 tahun; fail PDF 7-180 hari bergantung pada kekerapan kemas kini; halaman HTML pula no-cache atau tempoh singkat beberapa minit. Pendekatan ini mengekalkan keseimbangan antara prestasi dan kesegaran.

Jika laman anda adalah laman korporat, tempoh cache yang panjang biasanya tidak bermasalah. Jika ia laman e-dagang, anda boleh memberikan cache panjang kepada fail statik di halaman produk, tetapi mesti mengecualikan data harga, stok, troli dan pengguna daripada cache. Jika ia laman berita atau blog, anda boleh menyimpan imej dan fail tema untuk tempoh lama, dan men-cache output HTML untuk tempoh singkat mengikut kekerapan penerbitan anda. Nama domain, SSL dan infrastruktur hosting anda juga merupakan sebahagian daripada rantaian prestasi. Hostragons semakan domain Hostragons penyelesaian hosting korporat

Kesimpulan

Tempoh cache penyemak imbas, apabila dirancang dengan betul, meningkatkan prestasi lawatan berulang laman web anda dengan serius. Peraturan asasnya; gunakan tempoh panjang untuk fail statik yang diversikan, dan tempoh singkat atau no-store untuk halaman yang mengandungi HTML dan data peribadi. Logik yang sama terpakai dalam persekitaran Apache, Nginx, LiteSpeed, WordPress dan CDN: kenali jenis sumber, tentukan kekerapan kemas kini, uji pengepala Cache-Control, dan teruskan pemantauan selepas penerbitan.

Ringkasnya, browser caching adalah pengoptimuman kelajuan berkos rendah tetapi berimpak tinggi. Jika anda mengehoskan laman anda di infrastruktur Hostragons, anda boleh memperkukuhkan pengalaman pengguna dan prestasi SEO teknikal dengan memilih tetapan cache yang sesuai dengan jenis hosting anda. Untuk menilai penyelesaian pengehosan yang paling sesuai dengan keperluan anda, anda boleh menyemak pilihan hosting Hostragons atau mengawal konfigurasi cache di laman sedia ada anda langkah demi langkah. Hostragons Pakej Hosting

Soalan Lazim

Berapa lamakah tempoh cache penyemak imbas yang ideal?

Untuk fail statik yang diversikan seperti CSS, JS, imej dan fon, antara 30 hari hingga 1 tahun adalah ideal. Untuk halaman HTML, memandangkan kesegaran kandungan adalah penting, no-cache, max-age=0 atau tempoh singkat beberapa minit adalah lebih digalakkan.

Apakah perbezaan antara Cache-Control dan Expires?

Cache-Control adalah pengepala HTTP yang moden dan lebih fleksibel; ia menggunakan peraturan berasaskan saat seperti max-age. Expires pula memberikan nilai tarikh-masa yang spesifik. Dalam projek semasa, Cache-Control harus diutamakan, dan Expires boleh ditambah untuk keserasian ke belakang.

Bagaimana cara mengaktifkan browser caching di WordPress?

Dalam pemalam seperti LiteSpeed Cache, WP Rocket, W3 Total Cache, pilihan Cache Penyemak Imbas (Browser Cache) boleh diaktifkan. Selain itu, pengepala Cache-Control boleh ditambah mengikut jenis fail melalui .htaccess atau konfigurasi pelayan.

Adakah kemas kini laman tidak akan kelihatan jika saya berikan tempoh cache yang panjang?

Jika anda mengemas kini fail CSS atau JS yang sama tanpa menukar nama fail, sesetengah pengguna mungkin melihat fail yang lama. Untuk mengelakkan ini, pemversian fail, nama fail bercincang, dan proses pembersihan CDN harus digunakan.

Perlukah halaman pembayaran dan panel pengguna di-cache?

Tidak. Untuk halaman yang mengandungi data peribadi seperti pembayaran, troli, akaun, invois dan panel pentadbiran, pengepala selamat seperti Cache-Control: no-store, private mesti digunakan. Keselamatan tidak seharusnya dikompromi demi prestasi.