ตั้ง Cloudflare Cache Rules เร่งเว็บ ลด Bandwidth

Cloudflare Cache Rules เป็นฟีเจอร์ที่ช่วยควบคุมการ cache เนื้อหาเว็บไซต์บน Cloudflare edge servers ซึ่งกระจายอยู่ทั่วโลกกว่า 300 จุด เมื่อตั้งค่า Cache Rules อย่างถูกต้อง ผู้เยี่ยมชมเว็บจะได้รับเนื้อหาจาก server ที่ใกล้ที่สุด แทนที่จะต้องวิ่งมาที่ origin server ทุกครั้ง ผลลัพธ์คือเว็บเร็วขึ้น Bandwidth ของ hosting ลดลงอย่างเห็นได้ชัด และ origin server แบกภาระน้อยลง บทความนี้จะพาตั้งค่า Cache Rules ตั้งแต่พื้นฐานจนถึงเทคนิคขั้นสูง พร้อม Expression ที่นำไปใช้ได้ทันที

Cache Rules คืออะไร และทำงานอย่างไร

Cache Rules คือกฎที่กำหนดให้ Cloudflare รู้ว่า request ไหนควร cache, cache นานแค่ไหน, และ request ไหนต้องให้ผ่านไปยัง origin server โดยไม่ cache Cloudflare ใช้ระบบที่เรียกว่า Ruleset Engine ซึ่งประมวลผลกฎแบบ top-down ตามลำดับที่กำหนด

เมื่อ user เข้าเว็บ request จะวิ่งผ่าน Cloudflare edge ก่อน edge จะตรวจสอบว่ามี cache ที่ยังใช้งานได้ (HIT) หรือไม่ ถ้ามี edge ส่งเนื้อหาทันทีโดยไม่ถาม origin ถ้าไม่มี (MISS) edge จึงดึงจาก origin แล้วเก็บ cache ไว้สำหรับ request ถัดๆ ไป Cache Rules ทำให้คุณควบคุมพฤติกรรมนี้ได้อย่างละเอียด

สิ่งสำคัญที่ต้องเข้าใจก่อนตั้งค่า:

• Cache Hit Ratio — สัดส่วน request ที่ตอบจาก cache โดยไม่ต้องถาม origin ยิ่งสูงยิ่งดี เป้าหมายควรอยู่ที่ 80% ขึ้นไปสำหรับเว็บ static
• Edge TTL — นานแค่ไหนที่ Cloudflare เก็บ cache ก่อนที่จะขอใหม่จาก origin
• Browser TTL — นานแค่ไหนที่ browser ของ user เก็บ cache ก่อนที่จะขอ Cloudflare ใหม่
• Cache Status — HIT/MISS/BYPASS/REVALIDATED แสดงอยู่ใน response header CF-Cache-Status

เข้าถึง Cache Rules ใน Cloudflare Dashboard

การสร้าง Cache Rules ทำได้ผ่าน Cloudflare Dashboard ตามขั้นตอนต่อไปนี้:

1. เข้า dash.cloudflare.com แล้วเลือก Zone (โดเมน) ที่ต้องการ
2. ไปที่เมนู Caching ทางด้านซ้าย
3. เลือก Cache Rules
4. กด Create rule
5. ตั้งชื่อ rule ที่สื่อความหมาย เช่น "Cache Static Assets" หรือ "Bypass WP Admin"
6. กำหนด Expression และ Cache Behavior
7. กด Deploy

Cache Rules ใน Free Plan รองรับ 10 rules ซึ่งเพียงพอสำหรับเว็บทั่วไป แต่ละ rule มี Expression ที่ใช้ Cloudflare Ruleset Engine ซึ่ง powerful กว่า wildcard ของ Page Rules เดิมมาก

Rule 1 — Cache ไฟล์ Static ให้นานที่สุด

เริ่มจาก rule พื้นฐานที่สำคัญที่สุด: กำหนดให้ไฟล์ static ทุกชนิด (รูปภาพ, CSS, JS, font) ถูก cache นานที่ edge และที่ browser เพื่อลด Bandwidth และเพิ่มความเร็วสูงสุด

Expression:

(http.request.uri.path.extension in {"jpg" "jpeg" "png" "gif" "webp" "svg" "ico" "css" "js" "woff" "woff2" "ttf" "eot" "mp4" "mp3" "pdf" "zip"})

Cache Behavior Settings:

• Eligibility: Eligible for cache
• Edge TTL: Override origin / 1 month (2592000 seconds)
• Browser TTL: Override origin / 1 month

การตั้ง Edge TTL 1 เดือนหมายความว่า Cloudflare จะ serve ไฟล์เหล่านี้จาก edge โดยไม่ถาม origin เป็นเวลา 30 วัน ลด load บน hosting ได้มากในทันที ถ้าต้องการ invalidate cache ก็ใช้ Purge ใน Dashboard

Rule 2 — Bypass Cache สำหรับ WordPress Admin และ Login

หนึ่งในความผิดพลาดที่พบบ่อยคือ cache หน้า admin หรือหน้า login ของ WordPress ส่งผลให้ login ไม่ได้ หรือ admin เห็นข้อมูลเก่า ต้องสร้าง Bypass rule สำหรับ path เหล่านี้โดยเฉพาะ

Expression:

(http.request.uri.path contains "/wp-admin") or
(http.request.uri.path contains "/wp-login.php") or
(http.request.uri.path contains "/wp-cron.php") or
(http.cookie contains "wordpress_logged_in") or
(http.cookie contains "wp-settings")

Cache Behavior: Bypass cache

เงื่อนไข http.cookie contains "wordpress_logged_in" มีความสำคัญมาก เพราะทำให้ user ที่ login แล้วจะไม่เห็น cached version ของหน้าใดๆ ป้องกันปัญหา user A เห็น session ของ user B

Rule 3 — Cache HTML แต่ตั้ง TTL สั้นกว่า

Cloudflare โดย default ไม่ cache HTML เพราะ Cloudflare ถือว่า HTML เป็น "dynamic" เสมอ ถ้าเว็บเป็น static site หรือบทความที่ไม่ค่อยเปลี่ยน การ cache HTML จะลด Bandwidth ได้มากขึ้นอีก

Expression สำหรับ static blog/news:

(http.request.uri.path contains "/blog/") or
(http.request.uri.path contains "/article/") or
(http.request.uri.path matches "^/[a-z-]+-[0-9]{4}\.html$")

Cache Behavior Settings:

• Eligibility: Eligible for cache
• Edge TTL: Override origin / 4 hours (14400 seconds)
• Browser TTL: Override origin / 30 minutes

การตั้ง Edge TTL 4 ชั่วโมงสำหรับ HTML หมายความว่าเนื้อหาของบทความจะถูก cache สูงสุด 4 ชั่วโมง ซึ่งเหมาะกับเว็บข่าวหรือบล็อกที่อัพเดตวันละ 1-2 ครั้ง แต่ถ้าเป็นเว็บ news ที่อัพเดตทุกชั่วโมงควรลดเป็น 30-60 นาที

Rule 4 — Serve Stale Content While Revalidating

ฟีเจอร์ที่มักถูกมองข้ามคือ "Serve stale content while revalidating" ซึ่งทำให้ Cloudflare ส่ง cache เก่าให้ user ในทันทีขณะที่กำลัง fetch ข้อมูลใหม่จาก origin อยู่เบื้องหลัง ผู้ใช้ไม่ต้องรอ revalidation เลยแม้แต่น้อย ช่วยให้ Time To First Byte (TTFB) ต่ำมากสม่ำเสมอ

ตั้งค่านี้ได้ใน Cache Rule เดียวกับ Rule ของ HTML โดยเปิดตัวเลือก Serve stale content while revalidating ไว้

นอกจากนี้ ยังมีตัวเลือก Serve stale content while updating ที่ทำงานคล้ายกัน แต่จะ serve stale แม้กระทั่งตอนที่ Cloudflare กำลัง fetch ใหม่อยู่ (ไม่ใช่แค่ revalidate) ใช้กับเว็บที่ tolerate ข้อมูลเก่าได้เล็กน้อยเพื่อแลกกับความเร็ว

ตารางเปรียบเทียบ Cache Behavior Options

Rule 5 — ตั้ง Cache Key เพื่อจัดการ URL Parameters

ปัญหาที่พบบ่อยคือ URL เดียวกันแต่มี query string ต่างกัน เช่น /product?color=red กับ /product?color=blue Cloudflare จะมองว่าเป็นคนละ cache entry ซึ่งถูกต้องสำหรับ E-Commerce แต่บางกรณีอาจทำให้ Cache Hit Ratio ต่ำโดยไม่จำเป็น

ตัวอย่างเช่น ถ้า URL มี parameter แค่ ?utm_source=google หรือ ?fbclid=xxx ซึ่งไม่ได้เปลี่ยนเนื้อหาหน้า สามารถบอก Cloudflare ให้ ignore parameter เหล่านั้นใน Cache Key ได้:

/* ใน Cache Rule — Cache Key section */
Query string: Exclude specific parameters
Parameters to exclude: utm_source, utm_medium, utm_campaign, utm_term,
                       utm_content, fbclid, gclid, _ga

การ exclude UTM parameters จาก Cache Key ทำให้ /page?utm_source=google และ /page ได้รับ cache entry เดียวกัน เพิ่ม Cache Hit Ratio ได้อย่างเห็นได้ชัดบนเว็บที่ใช้ analytics tracking

วิธีตรวจสอบว่า Cache ทำงานแล้วหรือยัง

หลังตั้ง Cache Rules แล้ว ต้องตรวจสอบด้วยการดู response header CF-Cache-Status ซึ่ง Cloudflare ใส่ไว้ทุก response

curl -I https://yoursite.com/images/hero.jpg

ดูค่า CF-Cache-Status ใน output:

• HIT — cache ทำงาน เนื้อหามาจาก edge
• MISS — ยังไม่มี cache มาจาก origin แต่จะ cache รอบนี้แล้ว
• BYPASS — rule Bypass บังคับให้ผ่าน origin โดยไม่ cache
• EXPIRED — เคยมี cache แต่หมดอายุแล้ว กำลัง revalidate
• DYNAMIC — Cloudflare ตัดสินว่าเป็น dynamic content ไม่ cache
• REVALIDATED — cache ถูก revalidate แล้ว ยังใช้ได้

ถ้าเห็น DYNAMIC บนไฟล์ที่ควร cache แปลว่า Rule ยังไม่ match หรือ origin ส่ง header Cache-Control: no-store ให้ตรวจ rule expression และ origin header ประกอบกัน

นอกจาก curl ยังดู Cache Analytics ได้ใน Cloudflare Dashboard ที่ Caching > Overview จะเห็น Cache Hit Ratio รายวัน รวมถึง Saved Bandwidth เทียบกับ total requests ทำให้เห็นผลลัพธ์เป็นตัวเลขชัดเจน

Rule ขั้นสูง — ควบคุม Cache ด้วย Header จาก Origin

สำหรับเว็บที่ต้องการควบคุม cache อย่างละเอียด สามารถกำหนดให้ origin server ส่ง header Cache-Control มาเองได้ แล้วให้ Cloudflare เชื่อฟัง header นั้น วิธีนี้ช่วยให้ developers ควบคุม caching policy โดยตรงจากแอพโดยไม่ต้องเปลี่ยน Cloudflare Rules ทุกครั้ง

ตัวอย่าง response header จาก origin สำหรับไฟล์ static:

Cache-Control: public, max-age=2592000, s-maxage=2592000, immutable

และสำหรับหน้า HTML ที่ควรตรวจสอบทุกชั่วโมง:

Cache-Control: public, max-age=3600, stale-while-revalidate=86400

ตัวเลือก stale-while-revalidate บอก CDN ว่าถ้า cache หมดอายุไม่เกิน 86400 วินาที (1 วัน) ยังส่ง cache เก่าได้ในระหว่างที่ revalidate อยู่เบื้องหลัง ผู้ใช้ไม่รอเลย

ถ้าใช้ PHP สามารถใส่ header จาก PHP ได้ดังนี้:

<?php
// สำหรับบทความที่อัพเดตนานๆ ครั้ง
header('Cache-Control: public, max-age=3600, s-maxage=14400');
header('Vary: Accept-Encoding');
?>

หรือถ้าใช้ Apache ตั้งใน .htaccess:

<FilesMatch "\.(jpg|jpeg|png|gif|webp|ico|css|js|woff|woff2)$">
  Header set Cache-Control "public, max-age=2592000, immutable"
</FilesMatch>

<FilesMatch "\.html$">
  Header set Cache-Control "public, max-age=3600, stale-while-revalidate=86400"
</FilesMatch>

Purge Cache เมื่ออัพเดตเนื้อหา

เมื่อมีการอัพเดตเนื้อหา เช่น แก้บทความหรืออัพเดตรูปภาพ จำเป็นต้อง purge cache ที่ Cloudflare เพื่อให้ผู้ใช้เห็นเนื้อหาใหม่ก่อนที่ TTL จะหมดเอง

วิธีที่ 1 — Purge ผ่าน Dashboard:

1. ไปที่ Caching > Configuration
2. กด Purge Cache
3. เลือก Purge Everything หรือ Custom Purge (ระบุ URL)

วิธีที่ 2 — Purge ผ่าน Cloudflare API (สำหรับ automation):

curl -X POST "https://api.cloudflare.com/client/v4/zones/ZONE_ID/purge_cache" \
  -H "Authorization: Bearer YOUR_API_TOKEN" \
  -H "Content-Type: application/json" \
  --data '{"files":["https://yoursite.com/article/updated-post.html"]}'

การ purge ด้วย API เป็นวิธีที่ดีที่สุดสำหรับระบบ CMS เพราะสามารถ trigger อัตโนมัติทุกครั้งที่มีการบันทึกบทความ WordPress มี plugin หลายตัวที่ทำ purge อัตโนมัติผ่าน Cloudflare API เช่น Cloudflare plugin official หรือ W3 Total Cache

คำถามที่พบบ่อย (FAQ)

Cloudflare Cache Rules กับ Page Rules ต่างกันอย่างไร

Page Rules เป็นระบบเก่าที่ Cloudflare กำลังทยอยเลิกใช้ รองรับได้เพียง 3 rules ใน free plan และมี syntax แบบ wildcard (*) ส่วน Cache Rules เป็นระบบใหม่ที่ใช้ Cloudflare Ruleset Engine รองรับเงื่อนไขซับซ้อนได้มากกว่าผ่าน Expression Editor สามารถ match URL, hostname, cookie, header ได้ แนะนำให้ย้ายมาใช้ Cache Rules แทน Page Rules เพราะมีความสามารถมากกว่าและ Cloudflare จะ support ในระยะยาว

Cache Rules แบบ Bypass จะทำให้เว็บช้าลงไหม

Bypass Cache ไม่ได้ทำให้เว็บช้าลงในเชิงโครงสร้าง เพียงแต่ request ที่ match rule จะไม่ถูก cache ที่ Cloudflare edge ทำให้ origin server (hosting) รับ request โดยตรง สำหรับหน้า admin หรือ checkout ที่ต้องการข้อมูล real-time การ Bypass Cache คือสิ่งที่ถูกต้อง เพราะถ้า cache ไว้ผู้ใช้อาจเห็นข้อมูลเก่าหรือข้ามขั้นตอน authentication ได้

ควรตั้ง Cache TTL นานแค่ไหนสำหรับไฟล์ static

ไฟล์ static ที่ไม่ค่อยเปลี่ยน เช่น รูปภาพ (.jpg, .png, .webp), font (.woff2), CSS และ JS ที่มี version hash ในชื่อไฟล์ แนะนำ Cache TTL 1 เดือน (2,592,000 วินาที) ถึง 1 ปี (31,536,000 วินาที) แต่ถ้าไฟล์ CSS/JS ไม่มี version ใน filename ให้ใช้ TTL สั้นกว่า เช่น 1 สัปดาห์ เพื่อให้ผู้ใช้ได้รับไฟล์ใหม่เมื่อมีการอัพเดต

Cache Rules ใน Free Plan ใช้ได้กี่ rule

Cloudflare Free Plan รองรับ Cache Rules ได้ 10 rules ต่อ zone ซึ่งเพียงพอสำหรับเว็บส่วนใหญ่ สำหรับ Pro Plan รองรับ 25 rules และ Business Plan รองรับ 50 rules หากต้องการ rule จำนวนมากสำหรับเว็บที่ซับซ้อน เช่น E-Commerce ขนาดใหญ่ ควรพิจารณา upgrade plan หรือออกแบบ rule ให้ครอบคลุมหลาย URL ด้วย expression เดียว