โฮสติ้งและประสิทธิภาพ
วิธีที่เราทำให้ WordPress ทำงานได้รวดเร็ว: LiteSpeed Enterprise, LSCache และ Redis สำหรับแต่ละเว็บไซต์
คำขอ WordPress ที่เร็วที่สุดคือคำขอที่ไม่เคยรัน — นี่คือวิธีที่สแต็กของเราตอบสนองการเข้าชมส่วนใหญ่จากแคชก่อนที่ PHP หรือ MySQL จะถูกเรียกใช้ และความหมายที่มีต่อ Core Web Vitals
คำขอที่เร็วที่สุดคือคำขอที่ไม่เคยถูกส่ง
คำขอ WordPress แบบมาตรฐานมีต้นทุนสูง เว็บเซิร์ฟเวอร์จะส่งต่อไปยัง PHP, PHP จะบูต WordPress, รันปลั๊กอิน, คิวรี MySQL หลายสิบครั้ง, ประกอบเป็น HTML และหลังจากนั้นจึงส่งไบต์กลับไป บนเว็บไซต์ที่มีผู้เข้าชมหนาแน่น กระบวนการทั้งหมดนั้นเกิดขึ้นกับผู้เข้าชมทุกราย และนั่นคือจุดที่เวลาจนถึงไบต์แรก (time-to-first-byte) ส่วนใหญ่ของคุณหมดไป
คำตอบของเราคือการทำให้มั่นใจว่า สำหรับการเข้าชมส่วนใหญ่ จะไม่มีสิ่งเหล่านี้เกิดขึ้นเลย ในบรรดาเว็บไซต์ที่เราโฮสต์ ซึ่งมีเว็บไซต์ PBN มากกว่า 100,000 เว็บไซต์ รวมถึง managed WordPress ทั่วไป การดูหน้าเว็บส่วนหน้า (front-end) ส่วนใหญ่จะถูกให้บริการในรูปแบบหน้าที่เรนเดอร์ไว้ล่วงหน้าเต็มรูปแบบจากแคชโดยตรง โดยไม่ต้องเรียกใช้ PHP หรือแตะต้องฐานข้อมูล ส่วนที่เหลือของโพสต์นี้จะอธิบายว่าเลเยอร์ต่างๆ ที่ทำให้สิ่งนั้นเกิดขึ้นทำงานร่วมกันอย่างไร และแต่ละเลเยอร์มีความสำคัญอย่างไร
กรอบความคิดที่สำคัญคือสิ่งเหล่านี้ไม่ใช่แคชที่แข่งขันกันจนคุณต้องเลือกอย่างใดอย่างหนึ่ง แคชเต็มหน้า แคชออบเจ็กต์ และ CDN edge ต่างก็จัดการกับคำขอคนละประเภทกัน และคุณค่าที่แท้จริงอยู่ที่วิธีที่แคชเหล่านี้ทำงานสอดประสานกัน
LiteSpeed Enterprise + LSCache: เลเยอร์สำหรับหน้าเว็บเต็มรูปแบบ
ทุกเว็บไซต์ทำงานบน LiteSpeed Enterprise พร้อมด้วย LSCache ในระดับเซิร์ฟเวอร์ เมื่อคำตอบฝั่งฟรอนต์เอนด์สามารถทำแคชได้ เว็บเซิร์ฟเวอร์จะประทับหัวข้อ cache-control และ tag ของ LiteSpeed เอาไว้ และ LiteSpeed จะส่งหน้าเว็บที่สมบูรณ์ให้ทันทีในการเข้าชมครั้งถัดไป โดยไม่มีการเรียกใช้โพรเซส PHP และไม่มีการส่งคำสั่งค้นหา MySQL นี่คือกลไกสำคัญที่สุดที่มีผลต่อ TTFB ของ WordPress เพราะเป็นการตัดขั้นตอนการเริ่มต้นทำงานทั้งหมดของแอปพลิเคชันออกจากเส้นทางการประมวลผลหลัก
เนื่องจาก LSCache ทำงานอยู่ภายในเว็บเซิร์ฟเวอร์แทนที่จะอยู่ในปลั๊กอิน PHP จึงทำให้มันเริ่มทำงานได้เร็วกว่าในวัฏจักรการทำงานของคำขอ และจัดเก็บหน้าเว็บในรูปแบบที่เซิร์ฟเวอร์สามารถส่งออกได้อย่างทันที โปรแกรมท่องแคชจะช่วยให้หน้าเว็บยอดนิยมอัปเดตอยู่เสมอ ดังนั้น ผู้เข้าชมคนแรกหลังจากมีการล้างแคชจึงไม่ต้องเป็นผู้รอโหลดเพื่อสร้างหน้าเว็บใหม่ ผลลัพธ์ที่ได้คือ TTFB ที่ต่ำกว่าและมีความเสถียรมากกว่าอย่างเห็นได้ชัด เมื่อเทียบกับแคชแบบปลั๊กอินทั่วไปที่ติดตั้งเพิ่มเติมบนสแต็กทั่วไป ซึ่งแคชดังกล่าวยังคงทำงานอยู่เบื้องหลัง PHP
ปลั๊กอินแคชระดับคลังของเราติดตั้งมาให้ล่วงหน้าและอัปเดตอัตโนมัติในทุกเว็บไซต์ เชื่อมต่อ WordPress เข้ากับ LSCache ได้อย่างถูกต้องตั้งแต่เริ่มต้นใช้งาน บนเซิร์ฟเวอร์ต้นทางที่ไม่ใช่ LiteSpeed ปลั๊กอินนี้จะไม่ส่งส่วนหัวหน้าเว็บเต็มรูปแบบออกไปและจะหลีกทางให้ ในขณะที่ออบเจ็กต์แคชและกฎการยกเว้นยังคงทำงานต่อไป ดังนั้นเว็บไซต์ที่ย้ายมาจึงไม่เคยถูกทิ้งไว้ในสถานะที่เสียหายและกำหนดค่าไว้เพียงครึ่งๆ กลางๆ
แรงเร็วตลอดเวลาโดยไม่เสิร์ฟข้อมูลเก่า: ESI และการล้างข้อมูลอัตโนมัติอัจฉริยะ
การแคชแบบเต็มหน้าจอเชิงรุกมีจุดบกพร่องคลาสสิกสองประการ ได้แก่ การแสดงหน้าเว็บของผู้อื่นให้ผู้ใช้ที่เข้าสู่ระบบแล้วเห็น และการแสดงหน้าเว็บที่ควรจะเปลี่ยนแปลงไปแล้วให้ใครก็ตามเห็น ปัญหาทั้งสองอย่างนี้ได้รับการแก้ไขที่เลเยอร์การแคช แทนที่จะเป็นการลดการแคชลง
ESI (Edge Side Includes) ช่วยให้เราสามารถแคชหน้าเว็บพร้อมกับเว้นช่องว่างสำหรับส่วนที่ต้องอัปเดตแบบเรียลไทม์ บนร้านค้า WooCommerce หน้าแคตตาล็อก หน้าสินค้า และหน้าหมวดหมู่จะถูกเสิร์ฟเป็นแคชเต็มหน้าเพื่อให้ได้ค่า TTFB ที่เร็วที่สุด ในขณะที่ ESI จะเรนเดอร์ส่วนย่อยของตะกร้าสินค้า ยอดรวมในมินิตะกร้า และสถานะบัญชีตามแต่ละคำขอ หน้าตะกร้าสินค้า หน้าชำระเงิน หน้าบัญชีของฉัน และหน้า nonce หรือ session ใดๆ จะถูกยกเว้นไว้เป็นค่าเริ่มต้น นักช้อปจะเห็นตะกร้าของตนเองและหน้าชำระเงินที่ใช้งานได้เสมอ ในขณะที่ทุกคนยังคงได้รับหน้าหน้าร้านจากระบบแคช
ความสดใหม่ได้รับการจัดการด้วยระบบล้างข้อมูลอัตโนมัติอัจฉริยะ ตะขอการล้างข้อมูลจะทำงานโดยอัตโนมัติเมื่อเนื้อหา สินค้า ราคา หรือคำสั่งซื้อเปลี่ยนแปลง หน้าเว็บที่แคชไว้ที่เกี่ยวข้องจึงรีเฟรชทันทีแทนที่จะใช้ตัวจับเวลา และคุณยังสามารถล้างข้อมูลได้ตามต้องการจากแผงควบคุมหรือจากภายใน WordPress การล้างข้อมูลตามแท็กหมายความว่าการแก้ไขโพสต์หนึ่งรายการจะล้างโพสต์นั้นและคลังข้อมูล – ไม่ใช่แคชทั้งหมด – ดังนั้นการแก้ไขเพียงครั้งเดียวจึงไม่ทำให้เว็บไซต์ทั้งเว็บไซต์ต้องเริ่มทำงานใหม่จากสถานะเย็น
แคชออบเจกต์ Redis ต่อเว็บไซต์: สำหรับสิ่งที่ไม่สามารถเป็นหน้าเต็มได้
ไม่ใช่ทุกคำขอที่จะเป็นหน้าเว็บแบบคงที่เต็มรูปแบบได้ เซสชันของผู้เข้าสู่ระบบ, ระบบผู้ดูแลของ WordPress, ตะกร้าสินค้าของ WooCommerce, การค้นหา, และส่วนย่อยแบบไดนามิกที่ ESI ทิ้งไว้ล้วนต้องรัน PHP ทั้งสิ้น สำหรับสิ่งเหล่านี้ เป้าหมายจึงเปลี่ยนจากการ 'ข้ามตัวแอปพลิเคชัน' ไปเป็นการ 'ข้ามฐานข้อมูล'
แต่ละเว็บไซต์จะได้รับแคชอ็อบเจกต์ Redis ที่แยกเฉพาะของตัวเอง WordPress จะแคชผลลัพธ์ของการอ่านฐานข้อมูลที่ทำซ้ำๆ — เช่น ออฟชัน, ทรานเซียนต์, การค้นหาโพสต์และแท็ก, ข้อมูลสินค้าและเซสชันของ WooCommerce — ไว้ในหน่วยความจำ เพื่อไม่ให้มีการรันคิวรีเดิมซ้ำกับ MySQL ในทุกๆ การเข้าชม ผลลัพธ์ที่ได้จะเด่นชัดที่สุดในจุดที่แคชแบบเต็มหน้าเว็บไม่สามารถช่วยได้: หน้าแดชบอร์ดที่เร็วขึ้น, ตะกร้าสินค้าที่เร็วขึ้น, และภาระของฐานข้อมูลที่ลดลงอย่างมากภายใต้ปริมาณการเข้าชมสูง
แคชออบเจกต์จะแยกเป็นรายเว็บไซต์และไม่ใช้งานร่วมกัน ซึ่งมีความสำคัญต่อทั้งประสิทธิภาพและการแยกส่วน เมื่อใช้งานร่วมกับการจำกัดอัตราการใช้ฐานข้อมูลแบบรายเว็บไซต์ คิวรีที่หนักหน่วงหรือเขียนมาไม่ดีของเว็บไซต์เดียวจึงไม่สามารถแย่งทรัพยากรฐานข้อมูลของเว็บไซต์ข้างเคียงได้ คุณสามารถอ่านเพิ่มเติมเกี่ยวกับการทำงานร่วมกันของการตั้งค่าหลายชั้นนี้ได้ที่หน้าฟีเจอร์แคชของเรา และอ่านเกี่ยวกับขอบเขตระหว่างผู้เช่าระบบภายใต้การแยกส่วนได้ที่หัวข้อการแยกส่วน
ขอบเครือข่ายและระบบขนส่งที่อยู่เบื้องล่าง
แคชที่อยู่บนต้นทางยังคงต้องเดินทางผ่านเครือข่าย ด้านหน้าของเซิร์ฟเวอร์คือ CDN edge ดังนั้นทรัพยากรสถิตและหน้าเว็บที่แคชได้จึงถูกให้บริการจากจุดให้บริการที่อยู่ใกล้กับผู้เยี่ยมชม และต้นทางยังคงเงียบสงบแม้ภายใต้ภาระโหลด สำหรับสายโฮสติ้ง Footprint-Free ของเรา edge แบบเดียวกันนี้คือพูล multi-CDN ที่กระจายอยู่ทั่วหลายผู้ให้บริการ ซึ่งทำหน้าที่ตอบโจทย์ด้าน footprint และประสิทธิภาพไปพร้อมกัน บน WordPress กระแสหลัก นี่เป็นเพียงเลเยอร์ที่รวดเร็วและทำงานได้ดีซึ่งช่วยให้เซิร์ฟเวอร์ต้นทางว่างอยู่เสมอ
เบื้องหลังระบบ พื้นฐานต่างๆ ไม่เคยถูกลดทอน เว็บไซต์ทำงานบนพื้นที่จัดเก็บข้อมูลแบบ NVMe พร้อมด้วย HTTP/3 ดังนั้น ไบต์ที่แคชส่งไปจะเดินทางผ่านทรานสปอร์ตสมัยใหม่แบบมัลติเพล็กซ์ พร้อมพื้นที่จัดเก็บข้อมูลความเร็วสูงเบื้องหลังทุกแคชที่พลาด (cache miss) เลเยอร์เหล่านี้ไม่ใช่สิ่งที่มีไว้ให้ซื้อเพิ่ม: LiteSpeed, LSCache, Redis แบบต่อเว็บไซต์, NVMe และ HTTP/3 คือมาตรฐานพื้นฐานในทุกแพ็กเกจ ไม่ใช่แพ็กเกจระดับอัปเซลล์
สิ่งขับเคลื่อน Core Web Vitals ที่แท้จริง
เรื่องนี้คุ้มค่าที่จะให้ความสำคัญอย่างแม่นยำ เพราะบริการโฮสติ้งมักจะถูกโฆษณาเกินจริงในเรื่องของ Core Web Vitals TTFB คือส่วนของสมการที่เซิร์ฟเวอร์เป็นตัวกำหนด และระบบสแต็กการทำแคชที่อยู่ด้านบนคือสิ่งที่จะช่วยลดค่านั้นลง โดยหน้าที่ถูกทำแคชไว้อย่างสมบูรณ์และให้บริการผ่าน HTTP/3 จาก Edge จะให้ค่า TTFB ที่ต่ำที่สุดเท่าที่จะเป็นไปได้ เนื่องจาก TTFB เป็นปัจจัยเริ่มต้นของ Largest Contentful Paint ต้นทางที่รวดเร็วจะช่วยให้ทุกเมตริกในลำดับถัดไปมีจุดเริ่มต้นที่ได้เปรียบ ซึ่งหาจากวิธีอื่นไม่ได้
แต่ LCP, CLS และ INP ส่วนใหญ่ถูกกำหนดในเบราว์เซอร์ โดยตัวหน้าเว็บเอง: ภาพฮีโร่ที่ไม่ได้ปรับแต่ง, CSS และ JavaScript ที่บล็อกการเรนเดอร์, เลย์เอาต์ที่ขยับเมื่อฟอนต์และโฆษณาโหลด, และงานหนักบนเธรดหลักจากปลั๊กอิน แคชของเซิร์ฟเวอร์ต่อให้มีมากแค่ไหนก็ไม่สามารถแก้ปัญหาภาพฮีโร่ขนาด 2 MB หรือธีมที่โหลด JavaScript ขนาดหลายเมกะไบต์ได้ การโฮสต์ที่จริงใจช่วยให้ส่วนที่เซิร์ฟเวอร์รับผิดชอบทำงานได้อย่างรวดเร็วและสม่ำเสมอ หลังจากนั้นจึงเป็นหน้าที่ของเว็บไซต์ที่จะต้องดูแลส่วนหน้าบ้านให้กะทัดรัด
การแบ่งหน้าที่เช่นนั้นคือรูปแบบความคิดที่เป็นประโยชน์ เรารับประกันว่าคำขอจะเข้าถึงเบราว์เซอร์ได้อย่างรวดเร็วและคงความเร็วไว้ได้แม้มีปริมาณการใช้งานสูง ส่วนคุณทำหน้าที่รักษาขนาดข้อมูลให้มีขนาดเล็กและเสถียร จุดที่ทั้งสองส่วนนี้บรรจบกัน ได้แก่ การอุ่นเครื่องแคช การส่งมอบข้อมูลผ่านเอดจ์ และการรักษาความเร็วของฐานข้อมูลไม่ให้หน้าเว็บแบบไดนามิกเกิดอาการสะดุด คือจุดที่สแต็กของเราได้รับการปรับแต่งมาอย่างแม่นยำ และเป็นสิ่งที่ทำให้ WordPress แบบจัดการบนแพลตฟอร์มนี้มีความรวดเร็วกว่าเว็บไซต์เดียวกันที่โฮสต์บนโฮสต์ทั่วไป
คำถามที่พบบ่อย
ฉันยังจำเป็นต้องใช้ปลั๊กอินแคชอย่าง WP Rocket อยู่ไหม
ไม่จำเป็น การแคชหน้าเว็บแบบเต็มรูปแบบจะจัดการที่เว็บเซิร์ฟเวอร์โดย LSCache ของ LiteSpeed และปลั๊กอินแคชของเราเอง ซึ่งติดตั้งไว้ล่วงหน้าและอัปเดตอัตโนมัติ จะเชื่อมต่อ WordPress เข้ากับแคชดังกล่าวอย่างถูกต้อง พร้อมด้วยออบเจ็กต์แคช Redis ต่อเว็บไซต์ที่อยู่เบื้องหลัง การติดตั้งปลั๊กอินแคชหน้าเว็บแบบเต็มรูปแบบตัวที่สองทับซ้อนกันมักจะขัดแย้งกับแคชระดับเซิร์ฟเวอร์มากกว่าที่จะช่วย ดังนั้นจึงไม่จำเป็นและไม่แนะนำ
การแคชจะทำให้ตะกร้าสินค้า WooCommerce หรือหน้าที่เข้าสู่ระบบของฉันเสียหายหรือไม่
ไม่ ตะกร้าสินค้า, หน้าชำระเงิน, หน้าบัญชีของฉัน และหน้า nonces หรือ session ใดๆ จะถูกยกเว้นจากการแคชตามค่าเริ่มต้น และ ESI จะช่วยให้ส่วนย่อยของตะกร้าสินค้าและยอดรวมยังคงใช้งานได้แบบเรียลไทม์บนหน้าที่ถูกแคชไว้ ลูกค้าจะเห็นตะกร้าสินค้าของตนเองและหน้าชำระเงินที่ใช้งานได้เสมอ ในขณะที่หน้าร้านยังคงโหลดจากแคช
แคชจะอัปเดตใหม่อย่างไรเมื่อฉันเผยแพร่หรือแก้ไขบทความ?
ฟังก์ชันล้างข้อมูลอัตโนมัติอัจฉริยะจะทำงานบน WordPress hooks ที่เกี่ยวข้อง ดังนั้นการเผยแพร่ การแก้ไขเนื้อหา หรือการเปลี่ยนแปลงสินค้า ราคา หรือคำสั่งซื้อ จะล้างเฉพาะหน้าที่ได้รับผลกระทบและหน้าคลังข้อมูลเท่านั้น โดยจะไม่ล้างแคชทั้งหมด และตัวรวบรวมข้อมูลจะทำการอุ่นเครื่องหน้าเหล่านั้นใหม่อีกครั้ง คุณยังสามารถล้างข้อมูลได้ตามต้องการจากแดชบอร์ดหรือจากภายใน WordPress
โฮสติ้งเพียงอย่างเดียวสามารถทำให้ฉันได้ Core Web Vitals ที่สมบูรณ์แบบได้หรือไม่
ระบบนี้มอบ TTFB ที่ดีที่สุดเท่าที่จะเป็นไปได้ ซึ่งคือส่วนแบ่งในฝั่งเซิร์ฟเวอร์และเป็นจุดเริ่มต้นที่ดีสำหรับ Largest Contentful Paint แต่ LCP, CLS และ INP นั้นถูกกำหนดโดยตัวหน้าเว็บเป็นหลัก ได้แก่ ขนาดรูปภาพ, โค้ดที่บล็อกการเรนเดอร์, ความเสถียรของเลย์เอาต์ และ JavaScript บนเธรดหลัก สแต็กของเราช่วยให้การทำงานของเซิร์ฟเวอร์รวดเร็วและสม่ำเสมอ การรักษาขนาดเพย์โหลดของส่วนหน้าให้มีขนาดเล็กคือสิ่งที่จะช่วยปิดช่องว่างที่เหลือ
ที่เกี่ยวข้อง
ทดลองใช้ฟรี 14 วัน
เริ่มต้นใช้งานเว็บไซต์แรกของคุณฟรี 14 วัน โดยไม่ต้องใช้บัตรเครดิต ย้ายเน็ตเวิร์กที่มีอยู่แล้วใช่ไหม การย้ายครั้งแรกเราจัดการให้ฟรี
เริ่มใช้งานฟรี