วิธีกำหนดการตั้งค่าแคชทั้งหมดของ W3 สำหรับไซต์ WordPress ของคุณ

ด้วยการติดตั้งที่ใช้งานมากกว่า 1 ล้านครั้ง W3 Total Cache เป็นหนึ่งในปลั๊กอินแคชและการเพิ่มประสิทธิภาพที่ได้รับความนิยมมากที่สุดในที่เก็บ WordPress ไม่เหมือนกับปลั๊กอินเพิ่มประสิทธิภาพ WordPress อื่น ๆ ที่มีอินเทอร์เฟซที่ค่อนข้างเรียบง่ายและคล่องตัว W3 Total Cache ให้การควบคุมอย่างสมบูรณ์สำหรับการกำหนดค่าแคชของไซต์ WordPress ของคุณ

ความละเอียดของการตั้งค่า W3TC ทำให้เป็นปลั๊กอินในอุดมคติสำหรับผู้ใช้ขั้นสูงและนักพัฒนาที่ต้องการควบคุมไซต์ WordPress ของตนได้อย่างเต็มที่ ในบทความนี้ เราจะเจาะลึกการตั้งค่าของ W3 Total Cache และเราจะแนะนำการกำหนดค่าที่แนะนำเพื่อเพิ่มประสิทธิภาพให้กับไซต์ WordPress ของคุณ

หากคุณเป็นผู้ใช้ Kinsta คุณไม่จำเป็นต้องกำหนดการตั้งค่าบางอย่างใน W3 Total Cache เนื่องจากสแต็คโฮสติ้งของเรามีการเพิ่มประสิทธิภาพมากมายในตัว ตัวอย่างเช่น การแคชหน้าระดับเซิร์ฟเวอร์ผ่าน NGINX ถูกเปิดใช้งานตามค่าเริ่มต้นบนไซต์ Kinsta ทั้งหมด ดังนั้นคุณไม่จำเป็นต้องเปิดใช้งานใน W3 Total Cache หากคุณกำลังตั้งค่า W3TC บนไซต์ที่โฮสต์โดย Kinsta เพียงให้ความสนใจเป็นพิเศษกับคำแนะนำในการตั้งค่าด้านล่าง เราจะแจ้งให้คุณทราบหากไม่ต้องการการตั้งค่าเฉพาะหรือเข้ากันได้กับ Kinsta

วิธีการติดตั้ง W3 Total Cache

หากคุณไม่ได้ติดตั้ง W3 Total Cache บนไซต์ของคุณ คุณสามารถติดตั้งได้ทันทีในแดชบอร์ด WordPress ของคุณ เพียงค้นหา "W3 Total Cache" ในหน้า "Add Plugins" และติดตั้ง

นอกจากนี้ยังมี W3 Total Cache เวอร์ชัน Pro ซึ่งสามารถซื้อได้จากเว็บไซต์ของ BoldGrid รุ่น Pro มาพร้อมกับคุณสมบัติเพิ่มเติมบางอย่าง เช่น การแคช REST API, การแคช Google Maps และส่วนขยายเพิ่มเติม ในบทความนี้ เราจะใช้เวอร์ชันฟรีจากที่เก็บปลั๊กอินของ WordPress

W3 Total Cache Settings เก็บไว้ที่ไหน?

หลังจากติดตั้ง W3 Total Cache แล้ว คุณจะเห็นแท็บ "ประสิทธิภาพ" ในแถบด้านข้างของแดชบอร์ดผู้ดูแลระบบ WordPress การคลิกที่แท็บ "ประสิทธิภาพ" จะแสดงเมนูย่อยต่างๆ เช่น "การตั้งค่าทั่วไป", "แคชหน้า", "ย่อขนาด" และอื่นๆ

คุณยังสามารถเข้าถึงการตั้งค่า W3 Total Cache ได้โดยใช้แท็บ "ประสิทธิภาพ" ในแถบเครื่องมือผู้ดูแลระบบ WordPress ของคุณ

วิธีล้าง W3 Total Cache

ก่อนที่เราจะพูดถึงวิธีกำหนดค่า W3 Total Cache มาดูวิธีการล้างหรือล้างแคชของคุณกันก่อน หากคุณวางเมาส์เหนือแท็บ "ประสิทธิภาพ" ในแถบเครื่องมือผู้ดูแลระบบ คุณจะเห็นตัวเลือกการล้างข้อมูลสองตัวเลือก

1. ล้างแคชทั้งหมด – ล้างแคชทั้งหมดพร้อมกัน
2. โมดูลล้างข้อมูล – ล้างแคชแต่ละรายการ (เช่น เนื้อหาที่ถูกย่อ แคชของหน้า แคชของวัตถุ ฯลฯ)

W3 Total Cache การตั้งค่าทั่วไป

ไปที่เมนู "การตั้งค่าทั่วไป" ของ W3 Total Cache เพื่อกำหนดการตั้งค่าพื้นฐานบางอย่าง

แคชหน้า

ตามค่าเริ่มต้น ทุกคำขอไปยังไซต์ WordPress ของคุณจะแสดงผลตามเวลาจริง สำหรับไซต์บางประเภท เช่น ร้านค้าอีคอมเมิร์ซหรือฟอรัมสนทนา การเรนเดอร์แบบไดนามิกนั้นเหมาะสมที่สุด อย่างไรก็ตาม สำหรับบล็อก ไซต์ข่าว และไซต์อื่นๆ ที่ไม่ต้องการเนื้อหาแบบไดนามิก การเพิ่มเลเยอร์การแคชของหน้าสามารถปรับปรุงประสิทธิภาพและลดภาระของเซิร์ฟเวอร์ได้

หากไซต์ของคุณโฮสต์บน Kinsta คุณไม่ต้องกังวลกับการแคชหน้า เรามีการกำหนดค่าระดับเซิร์ฟเวอร์ประสิทธิภาพสูงที่จะแคชหน้าของไซต์ของคุณเป็นไฟล์ HTML แบบคงที่โดยอัตโนมัติ หากโฮสต์ของคุณไม่มีการแคชหน้า คุณสามารถเปิดใช้งานการแคชหน้าในปลั๊กอิน W3 Total Cache

ลดขนาด

การลดขนาดเนื้อหา HTML, CSS และ JavaScript ของคุณสามารถลดขนาดโดยรวมของหน้าไซต์ของคุณได้โดยการลบช่องว่างที่ไม่จำเป็น สำหรับไซต์ WordPress ส่วนใหญ่ การเปิดใช้งานคุณลักษณะ "ลดขนาด" ของ W3 Total Cache และการเลือกตัวเลือก "อัตโนมัติ" สำหรับ "โหมดลดขนาด" จะถือว่าใช้ได้ดี

ในบางกรณี การลดขนาดเนื้อหาอาจทำให้โค้ด CSS หรือ JavaScript เสียหาย ซึ่งมักส่งผลให้เกิดข้อผิดพลาดที่มองเห็นได้ในส่วนหน้า หากคุณสังเกตเห็นปัญหาที่ผิดปกติในไซต์ของคุณหลังจากลดขนาดเนื้อหา เราขอแนะนำให้ทำงานร่วมกับนักพัฒนาซอฟต์แวร์เพื่อระบุเนื้อหาที่ก่อให้เกิดปัญหา หลังจากนั้น คุณสามารถใช้คุณลักษณะ "ลดขนาด" ในโหมดกำหนดเองได้ ซึ่งช่วยให้คุณข้ามการลดขนาดสำหรับไฟล์ CSS และ JavaScript เฉพาะได้

Opcode Cache

WordPress เป็น CMS แบบไดนามิก ซึ่งหมายความว่าพนักงาน PHP รันโค้ดอย่างต่อเนื่องในเบื้องหลัง แคช Opcode ช่วยเร่งความเร็วไซต์ของคุณโดยการจัดเก็บโค้ด PHP ที่คอมไพล์แล้ว ซึ่งจะทำให้คำขอที่ตามมาซึ่งต้องใช้โค้ดเดียวกันเร็วขึ้น

หากเว็บไซต์ของคุณโฮสต์บน Kinsta คุณไม่ต้องกังวลเกี่ยวกับการเปิดใช้งานเลเยอร์การแคช opcode ใน W3 Total Cache เราเปิดใช้งาน OPcache ซึ่งเป็น opcode cache ในสภาพแวดล้อมแบบสดทั้งหมด OPcache ถูกปิดใช้งานในสภาพแวดล้อมการจัดเตรียมเพื่อให้แน่ใจว่าโค้ด PHP ที่คอมไพล์แล้วจะไม่ถูกแคชและไม่รบกวนการพัฒนาไซต์และการดีบัก

หากโฮสต์ของคุณไม่มี opcode cache เราแนะนำให้เปิดใช้งานใน W3 Total Cache โปรดทราบว่าคุณลักษณะแคช opcode มีเฉพาะใน W3TC เวอร์ชัน Pro เท่านั้น

แคชฐานข้อมูล

ฐานข้อมูลของ W3TC เก็บผลลัพธ์ของการสืบค้นฐานข้อมูล MySQL แม้ว่าฟีเจอร์นี้จะฟังดูมีประโยชน์ แต่เราแนะนำให้ปิดการใช้งานและใช้อ็อบเจ็กต์แคชแทน

เราพบว่าในบางกรณี คุณลักษณะแคชฐานข้อมูลอาจส่งผลให้มีการใช้งาน CPU สูง ซึ่งหมายความว่าจำนวน CPU ที่บันทึกโดยการจัดเก็บผลลัพธ์การสืบค้นฐานข้อมูลอาจถูกชดเชยด้วยการเพิ่ม CPU ที่จำเป็นสำหรับคุณสมบัตินี้

แคชวัตถุ

ในบริบทของ WordPress ออบเจ็กต์แคชจะเก็บผลลัพธ์ของการสืบค้นฐานข้อมูลที่เสร็จสมบูรณ์ จริง ๆ แล้ว WordPress มีแคชวัตถุในตัว แต่เก็บข้อมูลไว้สำหรับการโหลดหน้าเดียวเท่านั้น ซึ่งช่วยให้การแสดงผลหน้ามีประสิทธิภาพมากขึ้น เนื่องจากช่วยให้มั่นใจได้ว่าการโหลดหน้าเว็บจะไม่ต้องเปลืองทรัพยากร CPU ที่เรียกใช้การสืบค้นฐานข้อมูลที่เหมือนกัน

แม้ว่าแคชออบเจ็กต์เริ่มต้นของ WordPress จะมีประโยชน์ต่อประสิทธิภาพอย่างไม่ต้องสงสัย แต่ออบเจ็กต์แคชที่เก็บข้อมูลในการโหลดหน้าเว็บนั้นดีกว่า! ฟีเจอร์ “Object Cache” ของ W3TC เพิ่มสคริปต์การแคชแบบกำหนดเองในไดเร็กทอรี /wp-content ของคุณและเปลี่ยนพฤติกรรมของออบเจกต์แคชของ WordPress เพื่อเก็บข้อมูลอย่างต่อเนื่อง (ในการโหลดหลายหน้า)

เราแนะนำให้เปิดใช้งานคุณสมบัติแคชวัตถุของ W3TC บนไซต์ WordPress ของคุณเพื่อเพิ่มความเร็วให้กับคำขอที่ใช้การสืบค้นฐานข้อมูล หากไซต์ของคุณไม่ได้โฮสต์บน Kinsta

หากเว็บไซต์ของคุณโฮสต์บน Kinsta เราขอเสนอเลเยอร์การแคชวัตถุประสิทธิภาพสูงที่ขับเคลื่อนโดย Add-on Redis ของเรา Redis เป็นที่เก็บโครงสร้างข้อมูลในหน่วยความจำแบบโอเพนซอร์สที่มักใช้สำหรับแอปพลิเคชันฐานข้อมูลและตัวรับส่งข้อความ

เนื่องจาก Redis แคชข้อมูลใน RAM จึงช่วยให้ WordPress เข้าถึงข้อมูลที่แคชจากแคชอ็อบเจ็กต์ถาวรที่เร็วกว่าการกำหนดค่าแคชออบเจ็กต์แบบเดิมมาก

แคชของเบราว์เซอร์

การแคชเบราว์เซอร์สามารถเพิ่มความเร็วไซต์ WordPress ของคุณได้มากโดยการจัดเก็บทรัพย์สินแบบคงที่ เช่น CSS, JavaScript, รูปภาพ และแบบอักษรไว้ในเครื่อง การแคชของเบราว์เซอร์ใช้ระยะเวลาหมดอายุเพื่อกำหนดระยะเวลาในการแคชเนื้อหา บนเว็บสมัยใหม่ นักพัฒนาส่วนใหญ่ระบุระยะเวลาหมดอายุ 1 ปีสำหรับสินทรัพย์คงที่

สำหรับไซต์ที่โฮสต์บน Kinsta เราบังคับใช้ระยะเวลาแคช 1 ปีสำหรับไฟล์คงที่ ซึ่งสามารถตรวจสอบได้โดยการตรวจสอบส่วนหัวของ cache-control สำหรับไฟล์สแตติกที่โฮสต์บน Kinsta หากโฮสต์เว็บของคุณไม่บังคับใช้ "เวลาหมดอายุในอนาคตอันใกล้" สำหรับการแคชเบราว์เซอร์ คุณสามารถเปิดใช้งานคุณลักษณะ "แคชของเบราว์เซอร์" ใน W3 Total Cache และกำหนดค่าระยะเวลาหมดอายุได้

CDN (เครือข่ายการส่งเนื้อหา)

หากคุณใช้ CDN หรือเครือข่ายการส่งเนื้อหา เพื่อถ่ายโอนไฟล์สแตติกไปยังศูนย์ข้อมูลทั่วโลก คุณสามารถกำหนดค่า W3 Total Cache ให้เขียน URL ใหม่สำหรับ "ไฟล์ธีม ไฟล์แนบในไลบรารีสื่อ CSS, JS" และอื่นๆ ด้วย ชื่อโฮสต์ CDN

หากไซต์ของคุณโฮสต์บน Kinsta เราขอแนะนำให้ใช้ Kinsta CDN ซึ่งเป็นเครือข่ายการจัดส่งเนื้อหาประสิทธิภาพสูงของเราที่ขับเคลื่อนโดย KeyCDN เมื่อเปิดใช้งาน Kinsta CDN URL ของไฟล์แบบคงที่จะถูกเขียนใหม่โดยอัตโนมัติเพื่อให้บริการจาก Kinsta CDN

หากคุณต้องการใช้ผู้ให้บริการ CDN รายอื่น หรือหากไซต์ของคุณไม่ได้โฮสต์บน Kinsta คุณสามารถเปิดใช้งานคุณสมบัติ “CDN” ใน W3 Total Cache และเพิ่ม CDN URL ของคุณ

พร็อกซีย้อนกลับ

พร็อกซีย้อนกลับตั้งอยู่ระหว่างเว็บเซิร์ฟเวอร์ของคุณและ WordPress และสามารถใช้เพื่อดำเนินการจัดการตามตรรกะต่างๆ กับคำขอที่เข้ามา W3TC รองรับ Varnish ซึ่งเป็น "ตัวเร่ง HTTP" ยอดนิยมสำหรับการแคชและให้บริการข้อมูลโดยมีเป้าหมายเพื่อลดภาระแบ็คเอนด์

เพื่อที่จะใช้วานิช โฮสต์ของคุณต้องติดตั้งแพ็คเกจวานิชก่อน หากคุณเป็นลูกค้า Kinsta อย่าเปิดใช้งานตัวเลือก reverse proxy เนื่องจากโครงสร้างพื้นฐานของเราไม่ได้ออกแบบมาให้ทำงานร่วมกับ Varnish

ประสบการณ์ผู้ใช้

การเพิ่มประสิทธิภาพ "ประสบการณ์ผู้ใช้" ของ W3TC ช่วยให้คุณสามารถเปิดใช้งานการโหลดแบบ Lazy Loading, ปิดใช้งานอิโมจิ และปิดใช้งานสคริปต์ wp-embed.js เราแนะนำให้เปิดใช้งานการโหลดแบบ Lazy Loading บนไซต์ WordPress ของคุณเพื่อเพิ่มความเร็วในการโหลดหน้า หากคุณยังไม่ได้ใช้การโหลดแบบ Lazy Loading แบบเนทีฟเบราว์เซอร์หรือแบบปลั๊กอิน เราขอแนะนำให้ใช้ W3 Total Cache สำหรับการโหลดแบบ Lazy Loading

ในโลกปัจจุบัน ระบบปฏิบัติการส่วนใหญ่รองรับอีโมจิในตัว ดังนั้น คุณอาจต้องการปิดการใช้งานสคริปต์อีโมจิของ WordPress หากคุณไม่ใช่ผู้ใช้อีโมจิจำนวนมาก การใช้ W3TC เพื่อลบ wp-emoji-release.min.js จะช่วยให้คุณโกนคำขอ HTTP และลบ ~10KB ออกจากการโหลดหน้าเว็บของคุณ

ในทำนองเดียวกัน หากคุณไม่ฝังบทความ WordPress คุณสามารถปิดการใช้งาน wp-embed.js ด้วย W3 Total Cache การปิดใช้งานสคริปต์นี้จะไม่ส่งผลต่อฟังก์ชัน oEmbed สำหรับการฝังวิดีโอ YouTube, สตรีม SoundCloud ฯลฯ

เบ็ดเตล็ด

W3 Total Cache มีการตั้งค่าเบ็ดเตล็ดบางอย่างที่คุณสามารถกำหนดค่าได้เช่นกัน หากคุณต้องการแสดงวิดเจ็ตแดชบอร์ด Google Page Speed ​​ใน WordPress คุณสามารถป้อนคีย์ Page Speed ​​API ได้ นอกจากนี้ยังมีตัวเลือกในการแสดงคะแนน Page Speed ​​ในแถบเมนูสำหรับแต่ละหน้าในไซต์ WordPress ของคุณ

สำหรับการตั้งค่าอื่นๆ เช่น “เส้นทางไฟล์การกำหนดค่าเซิร์ฟเวอร์ NGINX”, “เปิดใช้งานการล็อกไฟล์”, “เพิ่มประสิทธิภาพหน้าดิสก์ที่ปรับปรุงแล้วและลดการแคชดิสก์สำหรับ NFS” ขอแนะนำให้ปล่อยไว้เป็นการตั้งค่าเริ่มต้น เว้นแต่คุณจะมีเหตุผลเฉพาะในการเปลี่ยนแปลง

ดีบัก

หากคุณกำลังแก้ไขปัญหาบนไซต์ของคุณ W3 Total Cache มีเมนู "ดีบัก" ที่มีประโยชน์ซึ่งช่วยให้คุณสามารถปิดใช้งานเลเยอร์แคชและการตั้งค่าการเพิ่มประสิทธิภาพได้ ตัวอย่างเช่น หากคุณสังเกตเห็นภาพบกพร่องในไซต์ของคุณ คุณสามารถเปิดใช้งานโหมดแก้ไขข้อบกพร่องสำหรับตัวเลือก "ลดขนาด" ซึ่งจะแทรกความคิดเห็น HTML ลงในซอร์สโค้ดของหน้าเว็บเพื่อช่วยคุณในการแก้ปัญหา

เนื่องจากคุณลักษณะโหมดแก้ไขข้อบกพร่องทำให้ทรัพยากรเซิร์ฟเวอร์ของคุณมีภาระมากขึ้น เราจึงแนะนำให้ใช้เฉพาะในสภาพแวดล้อมการจัดเตรียมหรือในช่วงเวลาที่มีการเข้าชมต่ำเท่านั้น นอกจากนี้ อย่าลืมปิดการใช้งานโหมดแก้ไขข้อบกพร่องหลังจากคุณแก้ไขปัญหาเสร็จแล้ว!

นำเข้า/ส่งออกการตั้งค่า

หลังจากที่คุณกำหนดการตั้งค่าเสร็จแล้ว คุณสามารถใช้ฟังก์ชัน "นำเข้า/ส่งออก" ของ W3TC เพื่อสร้างข้อมูลสำรองของการกำหนดค่าของคุณได้ W3 Total Cache มีการตั้งค่ามากมาย ดังนั้นความสามารถในการส่งออกข้อมูลสำรองทั้งหมดจึงเป็นเรื่องที่ดีเพื่อความสบายใจ นอกจากนี้ ยังช่วยให้คุณสามารถจำลองการกำหนดค่า W3TC แบบกำหนดเองของคุณได้อย่างง่ายดายในหลาย ๆ ไซต์โดยไม่ต้องกำหนดค่าใดๆ ด้วยตนเอง

การตั้งค่าแคชทั้งหมดของ W3 — แคชหน้า

มาดูการตั้งค่า “Page Cache” ของ W3 Total Cache กัน อย่าลืมว่าไซต์ของคุณโฮสต์บน Kinsta หรือไม่ คุณไม่จำเป็นต้องกังวลเกี่ยวกับการแคชหน้า – ดังนั้นคุณสามารถข้ามส่วนนี้ไปได้

• Cache Front Page – สำหรับไซต์ส่วนใหญ่ โดยทั่วไปแล้วหน้าแรกจะเป็นหน้าที่รับการเข้าชมมากที่สุด ดังนั้น เราขอแนะนำให้เปิดใช้งานการตั้งค่านี้
• ฟีดแคช – WordPress สร้างฟีด RSS ที่หลากหลาย ซึ่งอนุญาตให้แอปและบริการภายนอก เช่น Feedburner แสดงเนื้อหาในเว็บไซต์ของคุณ แม้ว่า RSS จะไม่ได้รับความนิยมในปัจจุบันเหมือนแต่ก่อน แต่เรายังคงแนะนำให้เปิดใช้งานการตั้งค่านี้
• Cache SSL (คำขอ HTTPS) – หากเว็บเซิร์ฟเวอร์ของคุณไม่บังคับ HTTPS สำหรับคำขอที่เข้ามาทั้งหมด การเปิดใช้งานการตั้งค่านี้อาจส่งผลในเชิงบวกต่อประสิทธิภาพ หากคุณบังคับ HTTPS ที่ระดับเว็บเซิร์ฟเวอร์อยู่แล้ว ไม่จำเป็นต้องเปิดใช้งานสิ่งนี้
• URI ของแคชพร้อมตัวแปรสตริงการสืบค้น – สตริงการสืบค้นคือพารามิเตอร์ที่เพิ่มไว้ที่ส่วนท้ายของ URL (เช่น /?version=123) สตริงการสืบค้นมักใช้เพื่อขอและแสดงข้อมูลเฉพาะจากฐานข้อมูล WordPress ของคุณ โดยทั่วไป จุดประสงค์ของสตริงข้อความค้นหาคือเพื่อขอเวอร์ชันเฉพาะของหน้า ดังนั้นเราแนะนำให้ปิดการใช้งานนี้ เว้นแต่ว่าคุณมีสตริงการสืบค้นเฉพาะที่คุณต้องการแคช
• หน้าแคช 404 (ไม่พบ) – โดยค่าเริ่มต้น W3TC จะปิดใช้งานตัวเลือกนี้ สาเหตุน่าจะมาจากพฤติกรรมการแคช หากคุณใช้วิธีการแคชหน้า "ปรับปรุงดิสก์" เมื่อเลือกตัวเลือกนั้น หน้า 404 จะแสดงรหัสตอบกลับ 200 รหัส ตามหลักการแล้ว 404 หน้าควรส่งคืนรหัสตอบกลับ 404 ดังนั้นเราแนะนำให้ทดสอบการตั้งค่านี้กับการกำหนดค่าแคชของคุณเพื่อดูว่าเข้ากันได้หรือไม่
• อย่าแคชหน้าสำหรับผู้ใช้ ที่เข้าสู่ระบบ – เราขอแนะนำให้เปิดใช้งานตัวเลือกนี้ ผู้ใช้ที่เข้าสู่ระบบมักจะทำงานในการอัปเดตเพจ เมื่อเปิดใช้งานการแคช ผู้ใช้จะต้องล้างแคชอย่างต่อเนื่องเพื่อดูการอัปเดตหน้า
• อย่าแคชหน้าสำหรับบทบาทผู้ใช้บางอย่าง – ตัวเลือกนี้ช่วยให้คุณข้ามแคชสำหรับบทบาทผู้ใช้ WordPress บางอย่างได้ หากเปิดใช้งานตัวเลือก “ไม่แคชหน้าสำหรับผู้ใช้ที่เข้าสู่ระบบ” แล้ว ตัวเลือกนี้จะไม่มีผลต่อการทำงานของแคช

นามแฝง

คุณลักษณะ "นามแฝง" ของ W3 Total Cache ช่วยให้คุณสามารถแคชเนื้อหา WordPres ที่เหมือนกันที่มีอยู่ในโดเมนต่างๆ เราไม่แนะนำให้เปิดใช้งานคุณสมบัตินี้ หากไซต์ WordPress ของคุณสามารถเข้าถึงได้จากโดเมนต่างๆ (เช่น domain.com และ www.domain.com) ทางที่ดีควรตั้งค่ากฎการเปลี่ยนเส้นทาง 301 เพื่อส่งต่อคำขอไปยังโดเมนหลักของคุณ เพื่อหลีกเลี่ยงการลงโทษเนื้อหาที่ซ้ำกันจาก Google และเครื่องมือค้นหาอื่นๆ

โหลดแคชล่วงหน้า

คุณลักษณะ "แคชล่วงหน้า" จะรวบรวมข้อมูลผ่านแผนผังไซต์ของคุณและส่งคำขอไปยังหน้าไซต์ของคุณเพื่อโหลดแคชของหน้าล่วงหน้า สำหรับไซต์ส่วนใหญ่ เราแนะนำให้ปิดใช้งานการโหลดแคชล่วงหน้า เนื่องจากอาจทำให้ทรัพยากรเซิร์ฟเวอร์พุ่งสูงขึ้น ซึ่งจะชดเชยผลประโยชน์ด้านประสิทธิภาพที่อาจเกิดขึ้น

หากคุณต้องการเปิดใช้งานการโหลดแคชล่วงหน้า W3TC จะให้คุณระบุ URL ของแผนผังเว็บไซต์ ช่วงเวลาการอัปเดต และหน้าต่อช่วง ตรวจสอบให้แน่ใจว่าคุณไม่ได้ตั้งค่า “ช่วงการอัปเดต” และ “จำนวนหน้าต่อภายใน” สูงเกินไปเพื่อลดโอกาสที่ CPU จะพุ่งสูงขึ้น

นโยบายการล้างข้อมูล

“นโยบายการล้างข้อมูล” ของ W3TC ให้คุณระบุหน้าและฟีดที่คุณต้องการล้างโดยอัตโนมัติหลังจากเผยแพร่หรือแก้ไขโพสต์ สำหรับไซต์ส่วนใหญ่ การตั้งค่าเริ่มต้น (หน้าแรก หน้าโพสต์ และฟีดบล็อก) ควรเพียงพอ หากคุณต้องการเพิ่มหน้าเพิ่มเติมในนโยบายการล้างข้อมูล มีตัวเลือกมากมายที่คุณสามารถกำหนดค่าได้

REST API

REST API ของ WordPress ช่วยให้คุณสืบค้นข้อมูลในรูปแบบ JSON REST API ถูกใช้โดยปลั๊กอินต่างๆ และเป็นสิ่งสำคัญสำหรับการตั้งค่า WordPress แบบไม่มีส่วนหัว ขึ้นอยู่กับกรณีการใช้งานที่แน่นอนของคุณสำหรับ REST API การแคชผลลัพธ์การสืบค้นอาจเป็นความคิดที่ดี การแคช REST API อยู่ภายใต้หมวดหมู่ "ถ้าคุณต้องการ คุณจะรู้" ดังนั้นหากคุณไม่แน่ใจว่าจะเปิดใช้งานการแคช REST API หรือไม่ เราขอแนะนำให้ปล่อยไว้บน "Don't Cache"

ขั้นสูง

ในตัวเลือกแคชหน้า "ขั้นสูง" ของ W3TC คุณสามารถปรับแต่งการตั้งค่าต่างๆ ได้ เช่น "สตริงการสืบค้นที่ยอมรับ", "ตัวแทนผู้ใช้ที่ถูกปฏิเสธ", การตั้งค่าบายพาสแคชแบบละเอียด และอื่นๆ ตัวอย่างเช่น หากคุณต้องการกำหนดค่า W3 Total Cache ของคุณไม่ให้แคชโพสต์ในหมวดหมู่หรือแท็กใดหมวดหมู่หนึ่ง คุณสามารถทำได้ในตัวเลือก "ขั้นสูง"

เนื่องจากการตั้งค่าเหล่านี้มีความเฉพาะเจาะจงกับไซต์มาก เราจึงไม่มี "การตั้งค่าที่แนะนำ" ที่เราสามารถให้ได้ จากที่กล่าวมา หากคุณต้องการปรับแต่งลักษณะเฉพาะเจาะจงของพฤติกรรมการแคชหน้าเว็บของไซต์ของคุณ ให้พิจารณาตัวเลือกขั้นสูงอย่างแน่นอน

การตั้งค่าแคชทั้งหมดของ W3 — ลดขนาด

ต่อไป มาดูการตั้งค่า "ลดขนาด" ของ W3 Total Cache

• เขียนโครงสร้าง URL ใหม่ – การตั้งค่านี้ส่งผลต่อโครงสร้าง URL ของเนื้อหาที่ย่อเล็กสุด เราขอแนะนำให้เปิดใช้งานเพื่อให้ URL ของคุณดู "สวย"
• ปิดใช้งานการลดขนาดสำหรับผู้ใช้ที่เข้าสู่ระบบ – หากคุณกำลังแก้ไขปัญหาหรือแก้ไขจุดบกพร่อง การปิดใช้งานการลดขนาดสำหรับผู้ใช้ที่เข้าสู่ระบบอาจเป็นประโยชน์ มิฉะนั้น เราแนะนำให้ปิดการใช้งานตัวเลือกนี้

HTML & XML

ในส่วน "HTML & XML" คุณสามารถกำหนดการตั้งค่าการลดขนาด HTML ได้

• การ ลดขนาด CSS แบบอินไลน์ – เราขอแนะนำให้เปิดใช้งานตัวเลือกนี้เพื่อลบช่องว่างใน CSS แบบอินไลน์
• การ ลดขนาด JS แบบอินไลน์ – เราแนะนำให้เปิดใช้งานตัวเลือกนี้เพื่อลบช่องว่างใน JavaScript แบบอินไลน์ ในบางกรณี การลดขนาด JS อาจส่งผลให้เกิดข้อผิดพลาดของโค้ด หากการเปิดใช้งานตัวเลือกนี้ทำให้ฟังก์ชันไซต์ของคุณเสียหาย ให้ปิดใช้งาน
• อย่าย่อขนาดฟีด – เราแนะนำให้ปิดการใช้งานตัวเลือกนี้ ฟีดถูกใช้โดยโปรแกรมอ่าน RSS และบริการอื่นๆ ที่คล้ายคลึงกันเท่านั้น ดังนั้นจึงไม่จำเป็นต้องย่อขนาดฟีด
• การลบตัวแบ่งบรรทัด – ตัวเลือกนี้ถูกปิดใช้งานโดยค่าเริ่มต้น และเราไม่แนะนำให้เปิดใช้งานเพื่อให้แน่ใจว่าไซต์ของคุณแสดงผลอย่างถูกต้อง

JS

ในส่วน "JS" คุณสามารถกำหนดการตั้งค่าการลดขนาด JavaScript ได้

• การดำเนินการในพื้นที่ – ตัวเลือกนี้ให้คุณเลือก "ประเภทการฝัง" สำหรับ JavaScript ที่ย่อขนาด สำหรับไฟล์ JS มาก่อน และหลังจากนั้น คุณสามารถเลือกระหว่าง "การบล็อก" "ไม่บล็อก" "ไม่บล็อกโดยใช้ async" และ "ไม่บล็อกโดยใช้การเลื่อนเวลา" แม้ว่าโดยทั่วไปแล้ววิธีการโหลดแบบไม่บล็อกจะส่งผลให้ประสิทธิภาพดีขึ้น แต่ก็ไม่สามารถใช้งานร่วมกับโค้ด JavaScript ทั้งหมดได้ 100% นอกจากนี้ "async" และ "defer" มีกรณีการใช้งานที่แตกต่างกันมาก ดังนั้น เราขอแนะนำให้ใช้วิธีการ "บล็อก" ที่เป็นค่าเริ่มต้น เว้นแต่คุณจะทราบถึงลักษณะนิสัยของ JavaScript ที่ไม่บล็อก
• ลดขนาดหรือรวมเท่านั้น – คุณสามารถเลือกระหว่างโหมดการปรับให้เหมาะสมสองโหมดสำหรับ JavaScript เมื่อเลือก "ย่อ" ไฟล์ JS ของคุณจะถูกรวมและลดขนาด หากคุณเลือก "รวมเท่านั้น" ไฟล์ JS ที่รวมกันจะไม่ถูกย่อ หากคุณประสบปัญหาเกี่ยวกับการลดขนาดและไม่ต้องการแก้ปัญหาเพื่อค้นหาสคริปต์ที่ทำให้เกิดปัญหา การเลือกตัวเลือก "รวมเท่านั้น" อาจแก้ไขข้อผิดพลาดได้
• HTTP/2 Push – หากเซิร์ฟเวอร์ของคุณรองรับ HTTP/2 Server Push การเปิดใช้งานตัวเลือกนี้อาจช่วยลดเวลาในการโหลดหน้าเว็บได้ HTTP/2 Server Push พุชไฟล์ให้ผู้เยี่ยมชมก่อนที่จะได้รับการร้องขอ เราแนะนำให้ทำการทดสอบอย่างเพียงพอก่อนที่จะเปิดใช้งานตัวเลือกนี้ในสภาพแวดล้อมที่ใช้งานจริง เนื่องจากเซิร์ฟเวอร์พุชมักถูกใช้ในทางที่ผิด Server Push ไม่เหมาะสำหรับไฟล์ JavaScript ที่มีขนาดใหญ่กว่า และคุณจะต้องแน่ใจว่าประโยชน์ที่ได้รับมีมากกว่าการโหลดไฟล์ JS โดยตรงจากแคชของเบราว์เซอร์ของผู้เข้าชม

CSS

ในส่วน "CSS" คุณสามารถกำหนดการตั้งค่าการลดขนาด CSS ได้

• รวมเท่านั้น – ซึ่งแตกต่างจากไฟล์ JavaScript โดยทั่วไป CSS จะไม่ประสบปัญหาเกี่ยวกับการลดขนาด ดังนั้น เราไม่แนะนำให้เปิดใช้งาน “รวมเท่านั้น”
• ลบความคิดเห็นที่สงวนไว้ – การตั้งค่านี้จะลบความคิดเห็นออกจากไฟล์ CSS เราขอแนะนำให้เปิดใช้งานตัวเลือกนี้เพื่อลดขนาดไฟล์ให้มากที่สุด
• การลบตัวแบ่งบรรทัด - การตั้งค่านี้จะลบตัวแบ่งบรรทัดออกจากไฟล์ CSS เราขอแนะนำให้เปิดใช้งานตัวเลือกนี้เช่นกัน หากคุณพบปัญหาในการแสดงผลหลังจากเปิดใช้งาน “การลบตัวแบ่งบรรทัด” ให้ปิดการใช้งาน

ขั้นสูง

ส่วน "ขั้นสูง" มีการตั้งค่าเพิ่มเติมเล็กน้อยเพื่อปรับแต่งพฤติกรรมการลดขนาด

• อัปเดตไฟล์ภายนอกทุก ๆ – W3TC ให้คุณระบุระยะเวลาระหว่างการอัปเดตไฟล์ CSS และ JS ด้วยการตั้งค่าเริ่มต้นที่ 86400 วินาที เนื้อหาของคุณจะถูกดาวน์โหลดและลดขนาดทุกๆ 24 ชั่วโมง หากไซต์ของคุณไม่เปลี่ยนแปลงบ่อย อย่าลังเลที่จะกำหนดระยะเวลาให้นานขึ้น
• ช่วงเวลาการเก็บขยะ – การตั้งค่าช่วงเวลานี้ระบุความถี่ในการลบข้อมูลแคชที่หมดอายุ การตั้งค่าเริ่มต้นคือ 24 ชั่วโมง หากไซต์ของคุณมีพื้นที่เก็บข้อมูลเหลือน้อย เราแนะนำให้ลด "ช่วงการเก็บขยะ"

ส่วนที่เหลือของส่วน "ขั้นสูง" มีช่องใส่ข้อมูลที่อนุญาตให้คุณระบุไฟล์เนื้อหาที่ไม่ควรย่อให้เล็กสุด นอกจากนี้ยังมีฟิลด์ "ตัวแทนผู้ใช้ที่ถูกปฏิเสธ" ที่ให้บริการไฟล์ที่ไม่ย่อขนาดให้กับตัวแทนผู้ใช้บางราย สุดท้าย คุณสามารถเพิ่มไฟล์เนื้อหาภายนอกเพื่อรวมไว้ในกระบวนการย่อของ W3 Total Cache

การตั้งค่าแคชทั้งหมดของ W3 — แคชวัตถุ

ถัดไปในรายการคือการตั้งค่า "Object Cache" ของ W3TC สำหรับไซต์ส่วนใหญ่ การตั้งค่าเริ่มต้นจะทำงานได้ดี แต่เราจะมองข้ามมันไป

• อายุการใช้งานเริ่มต้นของวัตถุแคช – เวลาหมดอายุสำหรับรายการแคชที่ไม่เปลี่ยนแปลง ช่วงเวลาที่นานขึ้นส่งผลให้แคชอ็อบเจ็กต์มีขนาดใหญ่ขึ้น หากคุณกังวลเกี่ยวกับความจุของพื้นที่เก็บข้อมูลของเซิร์ฟเวอร์ เราขอแนะนำให้คงค่าเริ่มต้นหรือลดค่านั้นลง
• ช่วงเวลาการเก็บขยะ – การตั้งค่านี้ระบุความถี่ในการทิ้งข้อมูลแคชที่หมดอายุ ค่าเริ่มต้น 3,600 วินาที (1 ชั่วโมง) น่าจะใช้ได้สำหรับไซต์ส่วนใหญ่
• กลุ่มสากล – การตั้งค่านี้ช่วยให้คุณสามารถกำหนดค่ากลุ่มการแคชที่ใช้ร่วมกันระหว่างไซต์ในเครือข่ายหลายไซต์เดียว เราขอแนะนำให้คุณปล่อยให้การตั้งค่านี้อยู่ในสถานะเริ่มต้น เว้นแต่คุณจะมีเหตุผลเฉพาะในการเปลี่ยนแปลง
• Non-Persistent Groups – การตั้งค่านี้ให้คุณเลือกกลุ่มอ็อบเจ็กต์ที่จะไม่แคช อีกครั้ง เราขอแนะนำให้ยึดติดกับการกำหนดค่าเริ่มต้น
• เปิดใช้งานการแคชสำหรับคำขอผู้ดูแลระบบ wp – ตัวเลือกนี้ถูกปิดใช้งานโดยค่าเริ่มต้น และเราไม่แนะนำให้เปิดใช้งานเพราะอาจทำให้เกิดผลข้างเคียงได้ นอกจากนี้ ผู้เยี่ยมชมไซต์ WordPress ส่วนใหญ่ไม่เคยโต้ตอบกับแดชบอร์ด wp-admin

การตั้งค่าแคชทั้งหมดของ W3 — แคชของเบราว์เซอร์

โฮสต์ WordPress ส่วนใหญ่ รวมถึง Kinsta ได้ใช้ส่วนหัวแคชของเบราว์เซอร์ที่เหมาะสมที่ระดับเว็บเซิร์ฟเวอร์อยู่แล้ว หากโฮสต์ของคุณไม่ทำเช่นนั้น หรือหากคุณต้องการปรับแต่งพฤติกรรมการแคชของเบราว์เซอร์เพิ่มเติม คุณสามารถทำได้ด้วย W3 Total Cache

ในการตั้งค่า "แคชของเบราว์เซอร์" การตั้งค่าเริ่มต้นสำหรับส่วน "ทั่วไป", "CSS & JS" และ "HTML & XML" และ "สื่อและไฟล์อื่นๆ" นั้นเพียงพอสำหรับไซต์ WordPress ส่วนใหญ่ เนื่องจากมีการตั้งค่ามากมายในหน้านี้ เราจึงแนะนำให้ปรึกษากับนักพัฒนาซอฟต์แวร์ก่อนทำการเปลี่ยนแปลงใดๆ กับพฤติกรรมการแคชของเบราว์เซอร์ จากที่กล่าวมา ด้านล่างนี้คือการตั้งค่าหลักบางประการที่ควรคำนึงถึงเกี่ยวกับการแคชของเบราว์เซอร์

• Expires Headers Lifetime – การกำหนดค่า "expires lifetime" ที่ยาวนานเป็นสิ่งสำคัญสำหรับการแคชเบราว์เซอร์ที่มีประสิทธิภาพ ที่ Kinsta เราบังคับใช้อายุการใช้งาน 1 ปีสำหรับเนื้อหาคงที่ เช่น CSS, JS, รูปภาพ และแบบอักษร หากคุณใช้ W3TC เพื่อกำหนดค่าการแคชของเบราว์เซอร์ อย่าลืมตั้งค่านี้เป็น 31536000 (1 ปี)
• นโยบายการควบคุมแคช – เพื่อให้แน่ใจว่าสินทรัพย์แบบคงที่ของคุณสามารถแคชได้โดยเบราว์เซอร์ ตรวจสอบให้แน่ใจว่า “นโยบายการควบคุมแคช” ถูกตั้งค่าเป็น “สาธารณะ max_age=EXPIRES SECONDS”
• เปิดใช้งานการบีบอัด HTTP (gzip) – การบีบอัด GZIP ช่วยลดขนาดไฟล์ของหน้า HTML และเนื้อหาได้อย่างมากก่อนที่จะส่งไปยังผู้เยี่ยมชม ดังนั้นโปรดเปิดใช้งานตัวเลือกนี้หากการกำหนดค่าเซิร์ฟเวอร์ของโฮสต์ของคุณรองรับ GZIP หากไซต์ของคุณโฮสต์บน Kinsta คุณไม่จำเป็นต้องเปิดใช้งานการบีบอัด GZIP ใน W3TC เนื่องจากมีการเปิดใช้งานแล้วโดยเป็นส่วนหนึ่งของการกำหนดค่าเริ่มต้นของเรา
• ลบสตริงการสืบค้นออกจากทรัพยากรแบบคงที่ – สตริงการสืบค้นคือสตริงเพิ่มเติมที่เพิ่มไว้ที่ส่วนท้ายของเส้นทาง URL เพื่อระบุพารามิเตอร์คำขอหรือบังคับให้เว็บเซิร์ฟเวอร์ส่งเนื้อหาใหม่ สตริงการสืบค้นเริ่มต้นด้วย ? และเว็บเซิร์ฟเวอร์ส่วนใหญ่ได้รับการกำหนดค่าให้ข้ามแคชสำหรับคำขอที่มีสตริงการสืบค้น การลบสตริงการสืบค้นออกจากคำขอของหน้ามีประโยชน์ในการลดภาระของเซิร์ฟเวอร์ เนื่องจากคำขอเหล่านี้ใช้ PHP เพื่อแสดงหน้า เราไม่แนะนำให้ลบสตริงการสืบค้นออกจากทรัพยากรแบบคงที่ใน W3 Total Cache เนื่องจากช่วยให้แน่ใจว่าไฟล์ CSS และ JS เวอร์ชันล่าสุดถูกส่งไปยังผู้เยี่ยมชมของคุณ

หน้าการตั้งค่า "แคชของเบราว์เซอร์" ยังมีการตั้งค่าต่างๆ ที่เกี่ยวข้องกับส่วนหัวความปลอดภัย เช่น นโยบายความปลอดภัยเนื้อหา (CSP) และ X-XSS Protection เราแนะนำให้ทำงานร่วมกับนักพัฒนาที่ผ่านการรับรองเสมอเพื่อดำเนินการตั้งค่าเหล่านี้ เนื่องจากการกำหนดค่าที่ไม่ถูกต้องอาจส่งผลกระทบโดยตรงต่อประสบการณ์ของผู้ใช้ไซต์ของคุณ ตัวอย่างเช่น การเปิดใช้งานส่วนหัว HSTS โดยไม่มีใบรับรอง SSL ที่เหมาะสมและการกำหนดค่า HTTPS อาจทำให้ไซต์ของคุณไม่สามารถเข้าถึงได้

การตั้งค่าแคชทั้งหมด W3 — กลุ่มตัวแทนผู้ใช้

คุณลักษณะ "กลุ่มตัวแทนผู้ใช้" ของ W3 Total Cache มีประสิทธิภาพมากหากคุณต้องการเปลี่ยนเส้นทางการรับส่งข้อมูลตามประเภทอุปกรณ์ของผู้ใช้ ตัวอย่างเช่น คุณสามารถกำหนดค่าไซต์ของคุณให้แสดงผลด้วยธีมอื่น หากผู้ใช้เข้าชมไซต์ของคุณจากโทรศัพท์มือถือ ในทำนองเดียวกัน คุณสามารถเปลี่ยนเส้นทางผู้ใช้ไปยังไซต์อื่นได้หากไซต์บนมือถือของคุณอยู่ในโดเมนย่อยที่ไม่ซ้ำกัน

ในยุคของการออกแบบเว็บที่ตอบสนอง เราไม่เห็นกรณีการใช้งานสำหรับคุณลักษณะนี้มากเกินไป ในปัจจุบัน แนวทางปฏิบัติที่ดีที่สุดคือการทำให้ไซต์ของคุณตอบสนองได้ตั้งแต่เริ่มต้น แทนที่จะใช้หลายธีมหรือโดเมนย่อยสำหรับมือถือเท่านั้น

การตั้งค่าแคชทั้งหมด W3 — กลุ่มผู้อ้างอิง

ผู้อ้างอิง HTTP เป็นส่วนหัว HTTP ทางเลือกที่ให้ข้อมูลเกี่ยวกับที่มาของคำขอ ตัวอย่างเช่น หากผู้เข้าชมคลิกที่ไซต์ของคุณจากรายการ Google Search ผู้อ้างอิง HTTP จะเป็น google.com

ใน W3 Total Cache คุณสามารถกำหนดพฤติกรรมการแคชแบบกำหนดเองตามผู้อ้างอิง HTTP ของคำขอด้วย “กลุ่มผู้อ้างอิง” ตัวอย่างเช่น คุณสามารถสร้างกลุ่มผู้อ้างอิงที่ประกอบด้วยเครื่องมือค้นหา และปรับแต่งพฤติกรรมการแคชสำหรับคำขอจากโดเมนเหล่านั้นเท่านั้น

เช่นเดียวกับ “กลุ่มตัวแทนผู้ใช้” ที่กล่าวถึงข้างต้น คุณยังสามารถเปลี่ยนเส้นทางคำขอไปยังโดเมนอื่นด้วยคุณสมบัติ “กลุ่มผู้อ้างอิง” ไซต์ WordPress ส่วนใหญ่ไม่จำเป็นต้องตั้งค่ากลุ่มผู้อ้างอิง ดังนั้นเราจึงไม่แนะนำให้กำหนดค่าใดๆ

การตั้งค่าแคชทั้งหมด W3 — กลุ่มคุกกี้

กลุ่มแคชล่าสุดที่ W3 Total Cache รองรับคือ “กลุ่มคุกกี้” คุณลักษณะนี้ช่วยให้คุณสร้างบัคเก็ตแคชและการทำงานที่ไม่ซ้ำกันตามคุกกี้ของคำขอ เช่นเดียวกับ “User Agent Groups” และ “Referer Groups” ไซต์ส่วนใหญ่จะไม่ต้องตั้งค่าการกำหนดค่าแคชตามคุกกี้แบบกำหนดเอง หากไซต์ของคุณต้องใช้การแคชตามคุกกี้ เราแนะนำให้ทำงานร่วมกับนักพัฒนาเพื่อกำหนดค่าอย่างถูกต้อง

การตั้งค่าแคชทั้งหมดของ W3 — CDN

ตอนนี้ ไปที่การตั้งค่า CDN ของ W3 Total Cache

• โฮสต์สิ่งที่แนบมา – เปิดใช้งานสิ่งนี้เพื่อให้บริการเนื้อหาในไลบรารีสื่อ WordPress จาก CDN ของคุณ
• โฮสต์ wp-includes/ ไฟล์ – เปิดใช้งานเพื่อให้บริการไฟล์ในโฟลเดอร์ wp-includes จาก CDN ของคุณ
• ไฟล์ธีมของโฮสต์ – เปิดใช้งานเพื่อให้บริการไฟล์ธีมจาก CDN ของคุณ
• โฮสต์ไฟล์ CSS และ JS ที่ย่อขนาด – เปิดใช้งานสิ่งนี้เพื่อให้บริการไฟล์ CSS และ JS ย่อขนาดของ W3TC จาก CDN ของคุณ
• โฮสต์ไฟล์แบบกำหนดเอง – หากคุณมีไฟล์ที่ไม่ได้อยู่ในไลบรารีสื่อหรือโฟลเดอร์ธีมของคุณ คุณสามารถเพิ่มพาธไฟล์ใน W3TC เพื่อให้บริการจาก CDN ของคุณได้
• เพิ่ม Canonical Header – แท็ก rel=”canonical” ช่วยให้เครื่องมือค้นหาระบุแหล่งที่มาหรือ URL ดั้งเดิมได้ เนื่องจากโดยทั่วไปแล้ว CDN จะใช้โดเมนอื่น การเพิ่มแท็กตามรูปแบบบัญญัติจะแจ้งเครื่องมือค้นหาตำแหน่งของเนื้อหาดั้งเดิม จากที่กล่าวมา คุณสามารถปิดการตั้งค่านี้ไว้ได้ เนื่องจากเครื่องมือค้นหาสมัยใหม่นั้นฉลาดพอที่จะระบุ CDN ได้โดยไม่ส่งผลต่อการจัดอันดับ SEO ของไซต์ของคุณ

ขั้นสูง

• ล้าง CDN ด้วยตนเองเท่านั้น – เราแนะนำให้ปิดการใช้งานตัวเลือกนี้เพื่อให้ W3TC จัดการการล้างแคชโดยอัตโนมัติ
• ปิดใช้งาน CDN บนหน้า SSL – ปิดใช้งานการตั้งค่านี้ไว้ หากคุณกำลังใช้ CDN วิธีที่ดีที่สุดคือให้เปิดใช้งานทั้งบนหน้า HTTP และ HTTPS
• ใช้ลิงก์ CDN สำหรับไลบรารีสื่อในหน้าผู้ดูแลระบบ – เราไม่แนะนำให้เปิดใช้งานตัวเลือกนี้ เนื่องจากจะเขียน URL ใหม่ในไลบรารีสื่อของคุณ
• เพิ่มส่วนหัว CORS – เปิดใช้งานการตั้งค่านี้ไว้เพื่อให้เนื้อหา CDN ของคุณแสดงบนโดเมนอื่น
• ปิดใช้งาน CDN สำหรับบทบาทต่อไปนี้ - ตัวเลือกนี้ช่วยให้คุณสามารถปิดใช้งาน CDN สำหรับบทบาทผู้ใช้ WordPress บางอย่างได้ ในกรณีส่วนใหญ่ วิธีที่ดีที่สุดคือปิดการใช้งานตัวเลือกนี้
• wp-includes File Types to Upload – ฟิลด์นี้ระบุรูปแบบไฟล์ใน wp-includes ที่จะให้บริการจาก CDN ของคุณ รายการรูปแบบไฟล์เริ่มต้นน่าจะใช้ได้สำหรับไซต์ส่วนใหญ่ หากคุณมีไฟล์แบบกำหนดเองในโฟลเดอร์ wp-includes คุณสามารถเพิ่มรูปแบบเพิ่มเติมได้ตามต้องการ
• ประเภทไฟล์ธีมที่จะอัปโหลด – ฟิลด์นี้ระบุรูปแบบไฟล์ในโฟลเดอร์ธีม WordPress ที่จะให้บริการจาก CDN ของคุณ รายการเริ่มต้นประกอบด้วยรูปแบบเนื้อหา รูปภาพ และแบบอักษรยอดนิยมทั้งหมด คุณสามารถเพิ่มรูปแบบเพิ่มเติมได้ตามต้องการ หากจำเป็น
• รายการไฟล์ที่กำหนดเอง – หากคุณเปิดใช้งาน "โฮสต์ไฟล์ที่กำหนดเอง" คุณสามารถเพิ่มรายการไฟล์ในฟิลด์นี้เพื่อให้บริการจาก CDN ของคุณ
• ตัวแทนผู้ใช้ที่ถูกปฏิเสธ – ฟิลด์นี้ช่วยให้คุณสามารถระบุตัวแทนผู้ใช้ที่จะไม่ได้รับสินทรัพย์จาก CDN ของคุณ เราแนะนำให้เว้นฟิลด์นี้ว่างไว้เพื่อให้แน่ใจว่า CDN ของคุณถูกใช้อย่างเหมาะสม
• ไฟล์ที่ถูกปฏิเสธ – ฟิลด์นี้อนุญาตให้คุณระบุไฟล์ที่ไม่ควรให้บริการจาก CDN ของคุณ หากบริการที่คุณใช้ต้องการบริการเนื้อหาจากโดเมนรากของคุณ คุณสามารถเพิ่มเส้นทางของไฟล์ลงในช่อง "ไฟล์ที่ถูกปฏิเสธ"

การตั้งค่าแคชทั้งหมดของ W3 — ประสบการณ์ผู้ใช้

ต่อไป มาปรับแต่งการตั้งค่า "ประสบการณ์ผู้ใช้" หรือการโหลดแบบ Lazy Loading ใน W3 Total Cache

• ประมวลผลแท็กรูปภาพ HTML – เปิดใช้งานสิ่งนี้เพื่อให้แน่ใจว่ารูปภาพจะโหลดแบบ Lazy Loading
• ประมวลผลรูปภาพพื้นหลัง – หากคุณใช้ "พื้นหลัง" เพื่อแสดงรูปภาพใน CSS การเปิดใช้ตัวเลือกนี้จะทำให้โหลดรูปภาพเหล่านั้นได้แบบ Lazy Loading
• ไม่รวมคำ – ในฟิลด์นี้ คุณสามารถระบุข้อความที่จะข้ามการโหลดแบบ Lazy Loading ได้ ตัวอย่างเช่น หากคุณเพิ่ม no-lazy-load ลงในฟิลด์นี้ รูปภาพที่แสดงด้วย <img src="image.jpg"> จะไม่โหลดแบบ Lazy Loading
• วิธีการฝังสคริปต์ – การตั้งค่านี้ให้คุณปรับแต่งวิธีการโหลดสำหรับสคริปต์การโหลดแบบสันหลังยาว วิธีการ async เริ่มต้นเป็นตัวเลือกที่ดีที่สุดสำหรับไซต์ส่วนใหญ่ หากเว็บไซต์ของคุณประกอบด้วยหน้า Landing Page เพียงหน้าเดียว คุณสามารถใช้วิธีการ inline เพื่อลดจำนวนคำขอ HTTP เพื่อโหลดหน้าได้

ส่วนขยายที่พร้อมใช้งานสำหรับ W3 Total Cache

W3 Total Cache นำเสนอส่วนขยายที่หลากหลายเพื่อรวมเข้ากับบริการของบุคคลที่สาม ปัจจุบัน W3TC มีส่วนขยายสำหรับบริการต่อไปนี้

• แอมป์
• คลาวด์แฟลร์
• Google Feedburner
• Fragment Cache
• กรอบปฐมกาล
• พระบรมธาตุใหม่
• Swarmify
• Yoast SEO
• WPML

หากคุณกำลังใช้บริการใดๆ เหล่านี้บนไซต์ของคุณ เราแนะนำให้ตั้งค่าส่วนขยายที่เกี่ยวข้องเพื่อให้แน่ใจว่าสามารถใช้งานร่วมกับ W3 Total Cache ได้อย่างเหมาะสม ในส่วนนี้ เราจะดูที่ส่วนขยาย Cloudflare สำหรับ W3 Total Cache

วิธีตั้งค่า W3 Total Cache ด้วยส่วนขยาย Cloudflare

ในการผสานรวม Cloudflare กับ W3 Total Cache คุณจะต้องมีข้อมูลสองส่วนจากแดชบอร์ด Cloudflare ของคุณ – อีเมลบัญชีและคีย์ API อีเมลของบัญชีคือที่อยู่อีเมลที่คุณใช้เข้าสู่ระบบ Cloudflare มาดูวิธีตั้งค่าคีย์ Cloudflare API

ในแดชบอร์ด Cloudflare ให้คลิกที่แท็บ "ภาพรวม" ถัดไป ให้เลื่อนลงมาแล้วคลิก Get Your API Token ในแถบด้านข้างขวา

เลื่อนลงแล้วคลิก ดู ถัดจาก "Global API Key" เพื่อรับคีย์ Cloudflare API ของคุณ Be careful not to share this API key anywhere outside W3 Total Cache because it can be used to control your Cloudflare account.

Next, activate the Cloudflare extension in W3 Total Cache's “Extensions” page and click “Settings”. In the “Credentials” section, click on the Authorize button.

In the subsequent popup, input your Cloudflare account email and API key. If you receive an error message, double-check to make sure your email address and API key are correct. After the credentials are authorized, you should see additional Cloudflare settings on the page.

Let's go over the Cloudflare settings in W3 Total Cache.

• Widget Statistics Interval – This specifies the time period covered for W3TC's Cloudflare widget. The default setting is 30 minutes. If you'd like to see a longer time period, feel free to increase it.
• Cache Time – This specifies the amount of time that widget data from Cloudflare is cached. If you don't plan on using the widget much, we recommend increasing this number to reduce the number of requests to Cloudflare from your site.
• Page Caching – If you've configured Cloudflare to cache HTML pages for your WordPress site, enable this option to automatically clear the Cloudflare cache after post modifications and updates.

Cloudflare Caching

This section lets you customize Cloudflare's caching settings.

• Development Mode – Keep this option disabled unless you need to put Cloudflare in Development Mode. When Cloudflare is in Development Mode, edge caching, minification, and image optimization is disabled for three hours. This allows you to see updates to CSS and JS files immediately and is useful for troubleshooting.
• Cache Level – For most sites, we recommend using the “Standard” cache level, which serves a different resource each time the query string changes. If you're 100% sure that your WordPress site does not make use of query strings to serve dynamic content, you can also use the “Ignore Query String” setting as well.
• Browser Cache TTL – We recommend setting Cloudflare's browser cache TTL to 31536000 seconds, which is equal to 1 year.
• Challenge TTL – Cloudflare offers a variety of security-related services, and visitor challenges is one of them. If Cloudflare detects a malicious user or strange behavior, it will serve a challenge message in the form of a Captcha. The “Challenge TTL” setting specifies how long a user will have access to your site after completing a challenge. With the default setting of 3600 seconds, a visitor who was subject to a challenge will be able to use your site for 1 hour before another challenge.
• Edge Cache TTL – This setting controls how long assets will be cached at Cloudflare's edge servers. We recommend setting this to the maximum value of 31536000 seconds, or 1 year.

Cloudflare Content Processing

Let's dive into the Cloudflare content processing settings in W3 Total Cache.

• Rocket Loader – Cloudflare's Rocket Loader speeds up JavaScript loading for your WordPress site. We recommend enabling Rocket Loader if your site has a lot of JS.
• Minify JS/CSS/HTML – If you've already enabled minification for HTML, CSS, and JavaScript in W3 Total Cache, feel free to keep these options in the Cloudflare extension settings disabled, as there is no need to minify assets that have already been minified.
• Server Side Exclude (SSE) – This option allows you to hide sensitive information from suspicious visitors (deemed by Cloudflare). Server-side excludes are useful for hiding information like email address, phone numbers, and other personal information on your site. To use SSE, enable it and wrap sensitive information in <!--sse--><!--/sse--> tags in your HTML code or PHP theme template.
• Email Obfuscation – When this option is enabled, Cloudflare will automatically obfuscate email addresses on your WordPress site with JavaScript. While obfuscation is not going to get rid of email spam completely, we recommend enabling this option because it does deter basic bots from scraping email addresses from your site.

Cloudflare Image Processing

Let's go over Cloudflare's image processing settings.

• Hotlink Protection – Enabling hotlink protection will prevent other sites from embedding your images. If you're running into bandwidth limits due to unauthorized external embeds, enabling “Hotlink Protection” can help you reduce bandwidth usage.
• Mirage (Pro Only) – Mirage optimizes image delivery to low-bandwidth devices and networks. This feature is only available on Cloudflare Pro plan and above.
• Polish (Pro Only) – Polish optimizes your site's images, and can be configured to serve WEBP images to supported browsers. This feature is only available on Cloudflare Pro plan and above.

Cloudflare Protection

Cloudflare's primary feature is a sophisticated firewall that can help protect you against DDoS attacks and malicious actors. Let's go over Cloudflare's security settings.

• Security Level – This setting controls the sensitivity of Cloudflare's firewall and security rules. We recommend setting the “Security Level” to “Medium” for most sites.
• Browser Integrity Check – This feature looks out for bad behavior and suspicious user agents. If it detects a potentially malicious user or spammer, Cloudflare will automatically serve a challenge. We recommend enabling this feature.
• Always Online – This option will serve static HTML pages of your site if your origin goes down. We recommend enabling it if you've configured Cloudflare to cache HTML.
• Web Application Firewall – Cloudflare's WAF, or web application firewall, will scan incoming traffic and filter out “illegitimate traffic” from reaching your site. We recommend enabling this feature.
• Advanced DDoS Protection – This feature is enabled by default, and cannot be disabled as long as Cloudflare's proxy is active. DDoS protection helps shield your site from “distributed denial of service” attacks.
• Max Upload – This sets the maximum allowed file size for uploads to your site. You'll want to make sure that this setting is either equal to or greater than your upload file size setting in WordPress.

Cloudflare SSL

Lastly, you'll want to make sure your Cloudflare SSL settings are configured correctly. Let's go over the right configuration in this section.

• SSL – If your site is hosted on Kinsta, we recommend using either the “Full” or “Full (Strict)” SSL option. The “Flexible” option is not compatible with our infrastructure. “Full Strict” requires an SSL from a valid certificate authority, while the “Full” option also supports self-signed SSLs. The “Flexible” option does not require an SSL certificate on the origin server – we don't recommend this option because it is the most insecure.
• TLS 1.2 Only – TLS, or Transport Layer Security, is a secure protocol for transferring data over a network. Some PCI compliance standards require dropping support for TLS 1.1 and below. If that is a requirement for your site, you can enable the “TLS 1.2 Only” setting in Cloudflare to set the minimum TLS version to 1.2.

การอ่านที่แนะนำ: วิธีตั้งค่า Cloudflare APO สำหรับ WordPress

การตั้งค่า W3 Total Cache WooCommerce

WooCommerce เป็นแพลตฟอร์มอีคอมเมิร์ซที่ได้รับความนิยมมากที่สุดสำหรับไซต์ WordPress หากคุณกำลังใช้ W3 Total Cache กับร้านค้าที่ขับเคลื่อนด้วย WooCommerce คุณจะต้องแน่ใจว่าการกำหนดค่าของคุณถูกต้องเพื่อหลีกเลี่ยงการแคชรายละเอียดของลูกค้า

บายพาสคุกกี้ WooCommerce

หากต้องการเลี่ยงการแคชหน้าสำหรับหน้าที่มีคุกกี้เฉพาะของ WooCommerce ให้ไปที่การตั้งค่า "แคชหน้า" ของ W3TC เลื่อนลงไปที่ "คุกกี้ที่ถูกปฏิเสธ" และเพิ่มสี่รายการด้านล่าง

• woocommerce_items_in_cart
• woocommerce_cart_hash
• wp_woocommerce_session_
• wordpress_logged_in

เพื่อความปลอดภัย เราขอแนะนำให้คุณข้าม URL เฉพาะของ WooCommerce เช่น หน้ารถเข็น หน้าชำระเงิน และหน้าบัญชี หากต้องการข้ามหน้าเหล่านี้จากการแคช ให้ไปที่การตั้งค่า "แคชหน้า" ของ W3TC และเพิ่ม URL ในส่วน "ไม่แคชหน้าต่อไปนี้"

วิธีรีเซ็ตการตั้งค่าทั้งหมดใน W3 Total Cache

ในบางกรณี คุณอาจต้องเริ่มต้นใหม่ด้วยการกำหนดค่า W3TC ต่อไปนี้คือวิธีการเปลี่ยน W3 Total Cache เป็นการตั้งค่าเริ่มต้น ไปที่เมนู "การตั้งค่าทั่วไป" ของ W3TC เลื่อนลงไปที่ส่วน "นำเข้า/ส่งออกการตั้งค่า" แล้วคลิก คืนค่าการตั้งค่าเริ่มต้น

สรุป

อย่างที่คุณเห็น ปลั๊กอิน W3 Total Cache นั้นเต็มไปด้วยคุณสมบัติและการตั้งค่า จากการแคชหน้า การลดขนาดเนื้อหา ไปจนถึงการรวม Cloudflare W3TC มีทุกสิ่งที่คุณต้องการเพื่อเพิ่มประสิทธิภาพไซต์ WordPress ของคุณ!

ในบทความนี้ เราได้ดำเนินการตามคำแนะนำของปลั๊กอินการกำหนดค่าสำหรับ W3TC คุณมีปลั๊กอินการเพิ่มประสิทธิภาพ WordPress ที่ชื่นชอบหรือไม่? แจ้งให้เราทราบในความคิดเห็นด้านล่าง!