การตั้งค่าเวลาค้างแคชของเบราว์เซอร์ (browser caching) คือการกำหนดว่าข้อมูลไฟล์สแตติกต่าง ๆ บนเว็บไซต์ เช่น CSS, JavaScript, รูปภาพ, ฟอนต์ และไอคอน จะถูกเก็บไว้ในเบราว์เซอร์ของผู้ใช้งานนานแค่ไหน โดยใช้ HTTP cache headers อย่าง แคช-คอนโทรล และ Expires สำหรับบางกรณี เช่น CSS/JS ที่มีการเวอร์ชัน สามารถตั้งค่ายาวถึง 1 ปี รูปภาพ 30 วัน-1 ปี ส่วนไฟล์ HTML ควรตั้งค่าสั้นหรือใช้การตรวจสอบซ้ำ การตั้งค่าที่ถูกต้องจะช่วยลดการดาวน์โหลดไฟล์ซ้ำ ๆ เพิ่มความเร็วหน้าเว็บ และปรับปรุงคะแนน Core Web Vitals ได้อย่างเห็นผล
บทความนี้จะอธิบายหลักการเบราว์เซอร์แคช วิธีเลือกเวลาแคชที่เหมาะสมสำหรับแต่ละไฟล์ วิธีตั้งค่าใน Apache, Nginx, LiteSpeed, WordPress และ CDN แบบละเอียดทีละขั้นตอน เป้าหมายคือไม่ใช่แค่ให้เว็บผ่านคะแนน speed test แต่ต้องให้ผู้ใช้ได้รับข้อมูลล่าสุด ใช้ทรัพยากรเซิร์ฟเวอร์อย่างคุ้มค่า ลด TTFB และ bandwidth และมอบประสบการณ์ความเร็วที่แตกต่างในการกลับมาเยี่ยมชม โดยเฉพาะเว็บไซต์องค์กร, WordPress, และ shared hosting การวางกลยุทธ์แคชที่ดีคือวิธีเพิ่มประสิทธิภาพที่ต้นทุนต่ำแต่ให้ผลสูงที่สุด แพ็คเกจเว็บโฮสติง Hostragons
Browser Caching คืออะไร?
Browser caching คือการที่ไฟล์สแตติกของเว็บไซต์ถูกเก็บไว้ชั่วคราวในเครื่องของผู้ใช้งาน เมื่อมีคนเข้าเว็บไซต์ โลโก้, CSS, JS, ฟอนต์, และรูปภาพจะถูกโหลดมา หากมีการตั้ง cache header ที่เหมาะสม เมื่อผู้ใช้เปิดหน้าถัดไปหรือกลับมาอีกครั้ง เบราว์เซอร์จะใช้ไฟล์เดิมจาก cache แทนการขอใหม่จากเซิร์ฟเวอร์ ส่งผลให้หน้าเว็บโหลดเร็วขึ้นมาก
ตัวอย่างเช่น หน้าแรกเว็บไซต์มีขนาด 2 MB โดย 1.4 MB เป็นรูปภาพ, 300 KB เป็น CSS/JS, 100 KB เป็นฟอนต์ ครั้งแรกจะโหลดทั้งหมด แต่ครั้งต่อไปข้อมูลเหล่านี้จะถูกใช้จาก cache ลดการรับส่งข้อมูลผ่านเครือข่ายได้อย่างมาก โดยเฉพาะในมือถือหรือเว็บไซต์ที่มีทราฟฟิกสูง
Browser caching ไม่ใช่ server-side cache ซึ่งเป็นการเก็บผลลัพธ์ PHP หรือ database ในเซิร์ฟเวอร์ ส่วน browser cache คือการ reuse ไฟล์ในเครื่องผู้ใช้ ทั้งสองควรใช้ร่วมกันเพื่อประสิทธิภาพสูงสุด สำหรับ WordPress จะมี page cache, object cache, CDN cache และ browser cache เป็นส่วนประกอบของกลยุทธ์ optimize ที่ดี WordPress hosting และการปรับแต่งประสิทธิภาพ
Browser Caching สำคัญกับ SEO อย่างไร?
Google ให้ความสำคัญกับเว็บไซต์ที่โหลดเร็วและเสถียร Browser caching แม้ไม่ใช่ปัจจัยอันดับแรกในการจัดอันดับ แต่มีผลต่อ page speed, interaction delay, efficiency ในการโหลดไฟล์ ซึ่งสนับสนุน SEO โดยเฉพาะกรณีผู้ใช้กลับมาเยี่ยมชม, เปิดหลายหน้าหมวดหมู่, ดูสินค้า หรืออ่านบล็อก
มาตรฐาน SEO ในปี 2026 จะเน้น user experience มากกว่าคะแนน Lighthouse; เช่น LCP, INP, CLS, TTFB และข้อมูลจริงจากผู้ใช้ หาก CSS/JS ถูกโหลดซ้ำโดยไม่จำเป็น จะทำให้ LCP ช้าลง ฟอนต์ที่ขอใหม่ทุกหน้าจะกระทบ visual stability รูปภาพขนาดใหญ่ที่ไม่ cache จะทำให้ mobile ช้าขึ้น
- กลับมาเยี่ยมชมเร็วขึ้น: ไฟล์ไม่ต้องโหลดซ้ำ
- ใช้แบนด์วิดท์น้อยลง: ทราฟฟิกเซิร์ฟเวอร์ลด ใช้ hosting ได้คุ้มขึ้น
- Bot และคน crawl ง่าย: ไฟล์สแตติกถูกจัดการอย่างมีระบบ
- ลด bounce: หน้าเปิดเร็ว ผู้ใช้ engage มากขึ้น
- ประสิทธิภาพเสถียร: CDN และ hosting รับโหลดได้ดีขึ้น
HTTP Cache Headers ที่สำคัญ
เวลาค้างแคชของเบราว์เซอร์ถูกควบคุมด้วย HTTP response headers ที่สำคัญ ได้แก่ Cache-Control, Expires, ETag และ Last-Modified โดย Cache-Control เป็นตัวหลัก Expires ใช้สำหรับ browser เก่าที่รองรับ
แคช-คอนโทรล
Cache-Control กำหนดวิธีเก็บไฟล์ใน browser และ CDN โดยคำสั่งที่ใช้บ่อยมี:
- max-age: กำหนดเวลาวินาทีที่ไฟล์ถือว่าใหม่ เช่น max-age=31536000 คือ 1 ปี
- public: ไฟล์เก็บได้ทั้ง browser และ CDN
- private: ไฟล์เก็บเฉพาะใน browser ผู้ใช้เท่านั้น
- no-cache: ต้องตรวจสอบกับเซิร์ฟเวอร์ก่อนใช้ cache (ไม่ใช่ปิด cache)
- no-store: ไม่เก็บไฟล์ไว้ที่ไหนเลย เหมาะสำหรับหน้า payment หรือข้อมูลส่วนตัว
- immutable: ไฟล์ไม่เปลี่ยนจนหมดอายุ เหมาะกับไฟล์ที่เวอร์ชันหรือชื่อไม่เปลี่ยน
ตัวอย่าง header ไฟล์สแตติก: Cache-Control: public, max-age=31536000, immutable หมายถึง browser เก็บไฟล์นี้ 1 ปี โดยไม่ต้องเช็คใหม่ถ้าชื่อไฟล์เหมือนเดิม
Expires
Expires กำหนดวัน/เวลาที่ไฟล์หมดอายุ เช่น รูปภาพอาจ Expires หลัง 30 วัน ข้อจำกัดคือกำหนดเป็นวันที่แน่นอน ไม่ยืดหยุ่นเท่า Cache-Control ในโปรเจคใหม่ควรใช้ Cache-Control เป็นหลัก Expires ใช้เสริมสำหรับ browser เก่า
ETag และ Last-Modified
ETag และ Last-Modified เป็นกลไกเช็คว่าไฟล์ที่ browser มีตรงกับเซิร์ฟเวอร์หรือไม่ ถ้าไฟล์ไม่เปลี่ยน เซิร์ฟเวอร์จะตอบ 304 Not Modified และ browser ไม่ต้องโหลดไฟล์ใหม่ เหมาะสำหรับ HTML หรือไฟล์ที่ต้องการ cache สั้น ๆ
แต่ละไฟล์ควรตั้งเวลาแคชอย่างไร?
ข้อผิดพลาดที่พบบ่อยคือการตั้งเวลาแคชเหมือนกันทุกไฟล์ ซึ่งไม่ถูกต้อง เพราะ HTML, CSS, JS, รูป, ฟอนต์ และ API มีพฤติกรรมการเปลี่ยนแปลงต่างกัน หลักการคือ ถ้าไฟล์สามารถเปลี่ยนชื่อได้ (version/hash) ให้แคชยาว ถ้าไฟล์เปลี่ยนบ่อยแต่ชื่อเดิม ให้แคชสั้นหรือใช้ revalidate
| ประเภทไฟล์ | เวลาแนะนำ | Header แนะนำ | หมายเหตุ |
|---|---|---|---|
| HTML | 0-10 นาที หรือ revalidate | no-cache, max-age=0 | เนื้อหาเปลี่ยนบ่อย ต้องเน้นความสดใหม่ |
| CSS/JS | 30 วัน-1 ปี | public, max-age=31536000, immutable | ควร version ชื่อไฟล์ เช่น style.v3.css |
| รูปภาพ | 30 วัน-1 ปี | public, max-age=2592000 หรือ 31536000 | โลโก้/ไอคอนให้แคชยาว รูปโปรโมชั่นสั้นลง |
| ฟอนต์ | 6 เดือน-1 ปี | public, max-age=31536000, immutable | เช่น woff2 เปลี่ยนไม่บ่อย |
| PDF/สื่อ | 7 วัน-6 เดือน | public, max-age=604800 หรือ 15552000 | ไฟล์ที่อัพเดทบ่อยต้องระวังเวลาแคช |
| หน้าผู้ดูแล/ชำระเงิน | ไม่ใช้ cache | no-store, private | เน้นความปลอดภัยและข้อมูลส่วนตัว |
ตารางนี้เป็นแนวทางเริ่มต้น เช่น เว็บไซต์ e-commerce ที่ HTML มีข้อมูลสต็อก/ราคา ไม่ควร cache aggressive แต่รูปสินค้าเปลี่ยนชื่อได้ cache ยาว 1 ปีได้ เว็บองค์กร โลโก้/ฟอนต์/ธีม cache ยาวได้ แต่ banner โปรโมชั่นที่เปลี่ยนบ่อยควร 7-30 วัน
กลยุทธ์วางแผนเวลาค้างแคชเบราว์เซอร์
การวางแผน cache ที่ดีต้องเริ่มจากแบ่งประเภทไฟล์ และตั้งกฎตามนามสกุลไฟล์ (extension) พร้อมพิจารณาความถี่ในการเปลี่ยนแปลงจริง
1. แยกไฟล์สแตติกกับไฟล์ไดนามิก
CSS, JS, JPG, PNG, WebP, SVG, WOFF2 ถือเป็นสแตติก HTML, ตะกร้าสินค้า, user panel, ผลค้นหา, API เป็นไดนามิก สแตติก cache ยาวได้ ไดนามิกต้องระวัง โดยเฉพาะไฟล์ที่มีข้อมูลเฉพาะตัวผู้ใช้ต้องไม่ใช้ public cache
2. ใช้การเวอร์ชันไฟล์
การ cache ยาวที่ปลอดภัยคือการเปลี่ยนชื่อไฟล์เมื่อมีอัพเดท เช่น style.css cache 1 ปี ถ้าเปลี่ยนเนื้อหาแต่ชื่อเดิม ผู้ใช้บางคนอาจเห็นดีไซน์เก่า ควรใช้ชื่อเช่น style.2026.01.css, app.v12.js หรือ app.8f3a2.js (hash) ทุกครั้งที่อัพเดท WordPress theme และ build tools ใหม่ ๆ ทำได้อัตโนมัติ หากพัฒนาเองให้ใช้ version parameter ใน wp_enqueue_style และ wp_enqueue_script หรือใส่ hash ที่ชื่อไฟล์
บาง CDN จะ cache ต่างกันระหว่าง query string กับชื่อไฟล์ hash ดังนั้นการใส่ hash ที่ชื่อไฟล์จะปลอดภัยกว่า
3. HTML ไม่ควร cache aggressive
HTML คือเนื้อหาหลักที่ผู้ใช้เห็น ควร cache สั้นหรือใช้ revalidate บทความบล็อก cache 5-10 นาทีได้ ข่าว, โปรโมชั่น, ข้อมูลราคา ควร cache สั้นกว่า หากใช้ page cache ใน WordPress ต้องคิดถึง browser cache, server cache และ CDN purge ร่วมกัน
4. ปิด cache ในหน้าที่ต้องการความปลอดภัย
หน้าล็อกอิน, user panel, payment, order summary, invoice, หรือหน้าข้อมูลส่วนตัว ควรใช้ Cache-Control: no-store, private เท่านั้น Browser caching เพื่อ performance แต่ต้องไม่เสี่ยงข้อมูลส่วนตัว SSL ก็เป็น must สำหรับหน้านี้ ใบรับรอง SSL Hostragons
การตั้งค่า Browser Caching ด้วย Apache .htaccess
สำหรับ Apache hosting ส่วนใหญ่จะตั้งค่าแคชผ่าน .htaccess ได้ง่าย เจ้าของเว็บไซต์ shared hosting นิยมใช้วิธีนี้ ต้องแน่ใจว่า mod_expires และ mod_headers เปิดอยู่ (hosting คุณภาพสูงมักมีอยู่แล้ว)
หลักการคือ ไฟล์รูป/ฟอนต์ cache ยาว CSS/JS cache ยาว HTML cache สั้นหรือ revalidate ใน .htaccess จะใช้ ExpiresByType และ Header set Cache-Control ตามประเภทไฟล์ เช่น image/webp, image/jpeg, image/png, image/svg+xml 1 ปี, text/css และ application/javascript 1 ปี, text/html ใช้ no-cache
ก่อนแก้ไข .htaccess ต้อง backup ไว้ เพราะผิดพลาดอาจเจอ 500 Internal Server Error หลังตั้งค่าให้เปิดเว็บใน incognito และเช็ค response headers ด้วย DevTools หากไม่เห็น Cache-Control อาจเพราะ module ปิด, CDN เปลี่ยน header หรือ plugin override
ค่าเริ่มต้น: CSS/JS max-age=31536000, รูป max-age=31536000, PDF max-age=2592000, HTML max-age=0/no-cache ปรับตามอัตราการอัพเดทของเว็บไซต์ Hostragons hosting สามารถกำหนด performance ผ่าน .htaccess ได้ แต่ให้เช็คว่าค่า cache theme/plugin ไม่ชนกัน การตั้งค่าประสิทธิภาพ Apache .htaccess
การตั้งค่า Browser Caching ด้วย Nginx
Nginx hosting จะตั้ง cache headers ใน block server/location Nginx เหมาะกับเว็บทราฟฟิกสูงเพราะเสิร์ฟไฟล์สแตติกเร็ว โดยจะกำหนด cache ตาม extension ด้วย expires และ add_header Cache-Control
ตัวอย่าง: CSS, JS, WebP, JPG, PNG, SVG, WOFF2 ใช้ expires 1y และ Cache-Control public, immutable HTML ใช้ expires off หรือ no-cache ถ้าใช้ CDN ต้องเช็คว่าค่า Cache-Control ของ origin server ถูก CDN อ่านถูกต้องหรือไม่
ข้อควรระวัง: add_header บางกรณีใช้ได้กับ response code ที่กำหนดเท่านั้น ใน Nginx ใหม่ ๆ ให้ใช้ always parameter หากมีการตั้ง header ซ้อนจาก application, Nginx, CDN จะเกิด cache headers ซ้ำ ต้องกำหนดลำดับความสำคัญให้ชัด
LiteSpeed และ WordPress กับการตั้งค่า Browser Caching
LiteSpeed hosting โดยเฉพาะ WordPress ใช้ LiteSpeed Cache plugin เพื่อ optimize ได้ดี ต้องแยก page cache กับ browser cache ใน LiteSpeed Cache มี browser cache option ให้เปิดสำหรับไฟล์สแตติก แต่ควรเช็คเวลาที่ตั้งเสมอ
คำแนะนำคือ ไฟล์สแตติก cache ยาว ใช้เวอร์ชันชื่อไฟล์ เมื่ออัพเดท theme, CSS, JS ควร clear cache plugin และ CDN purge มิฉะนั้นผู้ใช้บางคนจะเห็นดีไซน์เก่าหรือ JS error
Plugin cache ที่นิยมมี Browser Cache, Minify, Combine, Critical CSS, CDN integration, Object Cache ไม่ควรเปิดทุกอันพร้อมกันโดยไม่เช็คผล เริ่มที่ browser cache แล้วค่อยปรับ minify/combine ในปี 2026 HTTP/2/3 ใช้งานจริงแล้ว ไม่จำเป็นต้อง combine ไฟล์เหมือนสมัยก่อน อาจลด cache efficiency ได้ด้วย
ถ้า WordPress ช้า อาจไม่ใช่ปัญหาแค่ browser cache แต่เกิดจาก database, theme หนัก, plugin เยอะ, รูปไม่ optimize, หรือ hosting ไม่แรง ให้พิจารณา cache ร่วมกับ hosting คุณภาพ, PHP รุ่นใหม่ และ SSL ที่เหมาะสม โฮสติง WordPress Hostragons
การตั้งค่า Cache เวลาเมื่อใช้ CDN
CDN ส่งไฟล์สแตติกจาก edge server ที่ใกล้ผู้ใช้ ส่วน browser cache เก็บในเครื่องผู้ใช้ ทั้งสองระบบเสริมกันให้ประสิทธิภาพสูงขึ้น ควรตั้ง edge cache ใน CDN ให้สอดคล้องกับ Cache-Control ที่ origin server
แนวทางคือ origin server ตั้ง Cache-Control 1 ปีสำหรับไฟล์สแตติก CDN ตั้ง TTL เท่ากันหรือกำหนดเอง เมื่อมีการอัพเดทไฟล์ให้เปลี่ยนชื่อ (version/hash) หรือ purge CDN สำหรับ HTML ถ้าใช้ CDN cache ต้องตั้งกฎพิเศษ เช่น ตะกร้า, บัญชี, payment, admin ต้องไม่ cache
ปัญหาที่พบในเว็บที่ใช้ CDN คือหลังอัพเดทไฟล์ ผู้ใช้ยังเห็นไฟล์เก่า เพราะไม่ได้เปลี่ยนชื่อหรือไม่ได้ purge CDN ทางแก้คือ build ด้วย hash file และเรียกชื่อไฟล์ใหม่ใน HTML ทั้ง browser และ CDN จะขอไฟล์ใหม่ทันที
เช็คลิสต์การตั้งค่า Browser Caching แบบทีละขั้นตอน
เช็คลิสต์นี้เหมาะกับเว็บขนาดเล็ก ใช้เวลา 30-60 นาที หากเป็นเว็บ e-commerce หรือ custom software ควรเพิ่มเวลาทดสอบ
- 1. แยกประเภทไฟล์: CSS, JS, รูป, ฟอนต์, PDF, HTML, API
- 2. เช็คความถี่อัพเดท: ไฟล์ไหนเปลี่ยนทุกวัน/เดือนจดไว้
- 3. เลือกวิธีเวอร์ชัน: ใช้ hash, version, build number ที่ชื่อไฟล์
- 4. ตั้งกฎ server: กำหนด Cache-Control ใน Apache, Nginx, LiteSpeed หรือ CDN
- 5. ยกเว้นหน้าสำคัญ: admin, payment, cart, user panel, ข้อมูลส่วนตัว ใช้ no-store
- 6. ทดสอบ: DevTools, curl -I, WebPageTest, Lighthouse, device จริง
- 7. ตรวจหลัง live: เช็คไฟล์เก่า, ดีไซน์เสีย, JS error
วิธีทดสอบการตั้งค่า Browser Caching
วิธีเร็วที่สุดคือใช้ browser developer tools เปิดเว็บแล้วไปที่ Network ใน DevTools คลิกไฟล์ CSS หรือรูป แล้วดู Response Headers ว่า Cache-Control ตรงตามที่ตั้งไหม โหลดซ้ำจะเห็น Status เป็น memory cache หรือ disk cache
ใช้ command line ได้ เช่น curl -I domain.com/file.css จะเห็น header: Cache-Control, Expires, ETag, Last-Modified ถ้าไม่เห็น header อาจเพราะ application, server หรือ CDN override
สำหรับ performance test ใช้ Lighthouse, PageSpeed Insights, WebPageTest แต่ควรประเมินตาม user scenario จริง เช่น Lighthouse จะแนะนำให้ cache สแตติกยาว แต่ HTML ไม่ควร aggressive เครื่องมือบางตัวจะแจ้งเตือน script third-party เช่น Google Fonts, ads, social ที่คุณควบคุมไม่ได้
ข้อผิดพลาดที่พบบ่อย
Browser caching อาจดูง่ายแต่ถ้าตั้งผิด จะเกิดปัญหาอัพเดท, ความปลอดภัย หรือ user experience ตามนี้
- ให้ cache 1 ปีกับทุกไฟล์: HTML, API, ข้อมูลเฉพาะ user ไม่ควร cache ยาว
- ใช้ cache ยาวแต่ไม่เปลี่ยนชื่อไฟล์: ผู้ใช้อาจเห็น CSS/JS เก่า
- ลืม purge CDN: แม้ origin update แต่ CDN ยังเสิร์ฟไฟล์เก่า
- ใช้ cache plugin ซ้อนกัน: header ซ้ำกันเกิด conflict
- เข้าใจผิดกับ warning ของ third-party: cache header ของ script จากภายนอกคุณควบคุมไม่ได้
- cache หน้า sensitive: payment, account ต้องใช้ no-store
ค่าเริ่มต้นที่แนะนำสำหรับเว็บไซต์ใหม่
สำหรับเว็บไซต์ใหม่ CSS/JS ที่มีเวอร์ชัน cache 1 ปี รูป 1 ปี รูปโปรโมชั่น 30 วัน ฟอนต์ 1 ปี PDF ตามอัตราอัพเดท 7-180 วัน HTML ใช้ no-cache หรือ cache สั้น วิธีนี้สมดุลทั้งความเร็วและเนื้อหาสดใหม่
ถ้าเป็นเว็บองค์กร cache ยาวมักไม่มีปัญหา ถ้า e-commerce ให้ cache สแตติกยาว แต่ข้อมูลราคา, stock, cart, user data อย่า cache ถ้า blog/news ให้ cache รูป/ธีมยาว HTML สั้นตามความถี่อัพเดท Domain, SSL, hosting ก็เป็นส่วนหนึ่งของ performance chain การตรวจสอบโดเมน Hostragons โซลูชันโฮสติงองค์กร Hostragons
สรุป
การวางแผนเวลาค้างแคชเบราว์เซอร์ที่เหมาะสมจะทำให้เว็บโหลดเร็วขึ้นอย่างมาก หลักการคือ ไฟล์สแตติกที่เวอร์ชันชื่อ ให้ cache ยาว HTML และไฟล์ sensitive ใช้ cache สั้นหรือ no-store ไม่ว่า Apache, Nginx, LiteSpeed, WordPress หรือ CDN ก็ใช้หลักเดียวกัน: แยกไฟล์, เช็คความถี่เปลี่ยน, ตั้ง header, ทดสอบ, ติดตาม
Browser caching คือ speed optimization ที่ลงทุนต่ำแต่ผลลัพธ์สูง หากใช้ Hostragons hosting สามารถเลือก cache ให้เหมาะกับประเภท hosting เพื่อเพิ่มทั้ง user experience และ SEO ได้อย่างเต็มที่ สนใจดู Hosting แพ็คเกจ หรือเช็ค cache configuration ในเว็บคุณก็ได้ แพ็คเกจโฮสติง Hostragons
คำถามที่พบบ่อย
เวลาค้างแคชเบราว์เซอร์ควรตั้งเท่าไหร่?
ไฟล์สแตติกที่เวอร์ชันชื่อ เช่น CSS, JS, รูป, ฟอนต์ แนะนำ 30 วันถึง 1 ปี HTML ให้ cache สั้นหรือ no-cache, max-age=0
Cache-Control กับ Expires ต่างกันอย่างไร?
Cache-Control ใช้หลักวินาที (max-age) ยืดหยุ่นกว่า Expires ซึ่งใช้วัน/เวลาคงที่ โปรเจคใหม่ควรใช้ Cache-Control เป็นหลัก Expires เสริมสำหรับ browser เก่า
WordPress เปิด browser caching ได้อย่างไร?
ใช้ plugin เช่น LiteSpeed Cache, WP Rocket, W3 Total Cache หรือเพิ่ม Cache-Control ใน .htaccess/server ตามประเภทไฟล์
ถ้า cache ยาวจะเกิดปัญหาอัพเดทเว็บไซต์ไหม?
ถ้าไม่เปลี่ยนชื่อไฟล์ CSS/JS แม้อัพเดทเนื้อหา ผู้ใช้บางคนจะเห็นไฟล์เก่า ควรใช้การเวอร์ชันชื่อไฟล์, hash, หรือ purge CDN ทุกครั้งที่อัพเดท
หน้า payment และ user panel ควร cache หรือไม่?
ไม่ควร หน้า payment, cart, account, invoice, admin ที่มีข้อมูลส่วนตัว ต้องใช้ Cache-Control: no-store, private เพื่อความปลอดภัย ไม่ควรลด security เพื่อ performance