ขั้นตอนแรกในการสร้างเว็บไซต์ที่โหลดได้อย่างรวดเร็วคือการได้รับการตอบกลับจากเซิร์ฟเวอร์อย่างทันท่วงทีสำหรับ HTML ของหน้าเว็บ เมื่อคุณป้อน URL ในแถบที่อยู่ของเบราว์เซอร์ เบราว์เซอร์จะส่งคำขอ GET ไปยังเซิร์ฟเวอร์เพื่อดึงข้อมูล คำขอแรกสำหรับหน้าเว็บคือทรัพยากร HTML และการตรวจสอบว่า HTML มาถึงอย่างรวดเร็วโดยมีความล่าช้าน้อยที่สุดคือเป้าหมายด้านประสิทธิภาพที่สำคัญ
คำขอ HTML เริ่มแรกนั้นผ่านหลายขั้นตอน แต่ละขั้นตอนต้องใช้เวลาพอสมควร การลดเวลาที่ใช้ในแต่ละขั้นตอนช่วยให้คุณได้ Time to First Byte (TTFB) ที่เร็วขึ้น แม้ว่า TTFB ไม่ใช่เมตริกเดียวที่คุณควรเน้นในแง่ของความเร็วในการโหลดหน้าเว็บ แต่ TTFB ที่สูงทำให้การบรรลุเป้าหมาย "ดี" ที่กำหนดไว้สำหรับเมตริกต่างๆ เช่น Largest Contentful Paint (LCP) และ First Contentful Paint (FCP) ทำได้ยาก
ลดการเปลี่ยนเส้นทางให้เหลือน้อยที่สุด
เมื่อมีการขอทรัพยากร เซิร์ฟเวอร์อาจตอบกลับด้วยการเปลี่ยนเส้นทาง ไม่ว่าจะด้วยการเปลี่ยนเส้นทางถาวร (การตอบกลับ 301 Moved Permanently) หรือแบบชั่วคราว (การตอบกลับ 302 Found)
การเปลี่ยนเส้นทางทำให้เวลาในการโหลดหน้าเว็บช้าลงเนื่องจากเบราว์เซอร์ต้องส่งคำขอ HTTP เพิ่มเติมในตำแหน่งที่ใหม่เพื่อเรียกทรัพยากร การเปลี่ยนเส้นทางมี 2 ประเภท ได้แก่
- การเปลี่ยนเส้นทางจากต้นทางเดียวกันซึ่งเกิดขึ้นภายในต้นทางทั้งหมด การเปลี่ยนเส้นทางประเภทนี้จะอยู่ภายใต้การควบคุมของคุณโดยสมบูรณ์ เนื่องจากตรรกะสำหรับการจัดการการเปลี่ยนเส้นทางเหล่านั้นจะอยู่ในเว็บเซิร์ฟเวอร์ของคุณทั้งหมด
- การเปลี่ยนเส้นทางข้ามต้นทางที่เริ่มต้นโดยต้นทางอื่น โดยทั่วไปแล้วการเปลี่ยนเส้นทางประเภทนี้ เป็นสิ่งที่ควบคุมไม่ได้
โฆษณา บริการย่อ URL และบริการอื่นๆ ของบุคคลที่สามมักใช้การเปลี่ยนเส้นทางแบบข้ามต้นทาง แม้ว่าการเปลี่ยนเส้นทางแบบข้ามต้นทางจะอยู่นอกเหนือการควบคุม แต่คุณอาจต้องตรวจสอบว่าหลีกเลี่ยงการเปลี่ยนเส้นทางหลายครั้ง เช่น มีโฆษณาที่ลิงก์ไปยังหน้า HTTP ซึ่งจะเปลี่ยนเส้นทางไปยังหน้าอื่นเทียบเท่ากับ HTTPS หรือการเปลี่ยนเส้นทางแบบข้ามต้นทางที่มาถึงต้นทางของคุณ จากนั้นจะทริกเกอร์การเปลี่ยนเส้นทางจากต้นทางเดียวกัน
แคชการตอบกลับ HTML
การแคชการตอบกลับ HTML นั้นเป็นเรื่องยาก เนื่องจากการตอบกลับอาจมีลิงก์ไปยังทรัพยากรสำคัญอื่นๆ เช่น CSS, JavaScript, รูปภาพ และทรัพยากรประเภทอื่นๆ ทรัพยากรเหล่านี้อาจรวมถึงลายนิ้วมือที่ไม่ซ้ำกันในชื่อไฟล์ที่เกี่ยวข้อง ซึ่งจะเปลี่ยนไปตามเนื้อหาของไฟล์ ซึ่งหมายความว่าเอกสาร HTML ที่แคชไว้อาจไม่อัปเดตหลังจากการทำให้ใช้งานได้ เนื่องจากจะมีการอ้างอิงไปยังทรัพยากรย่อยที่ล้าสมัย
อย่างไรก็ตาม อายุการใช้งานแคชที่สั้น (แทนการไม่มีการแคช) อาจเป็นประโยชน์ เช่น การอนุญาตให้แคชทรัพยากรใน CDN เพื่อลดจำนวนคำขอที่ให้บริการจากเซิร์ฟเวอร์ต้นทางและในเบราว์เซอร์ ทำให้สามารถตรวจสอบทรัพยากรอีกครั้งแทนที่จะดาวน์โหลดอีกครั้ง วิธีนี้ทำงานได้ดีที่สุดสำหรับเนื้อหาแบบคงที่ที่ไม่มีการเปลี่ยนแปลงในบริบทใดๆ และคุณสามารถกำหนดเวลาที่เหมาะสมในการแคชแหล่งข้อมูลเป็นจำนวนนาทีที่คุณคิดว่าเหมาะสม การใช้เวลา 5 นาทีสำหรับทรัพยากร HTML แบบคงที่นั้นปลอดภัยดี และมั่นใจได้ว่าการอัปเดตเป็นระยะๆ จะไม่ได้รับผลกระทบ
หากเนื้อหา HTML ของหน้าเว็บมีการปรับเปลี่ยนในแบบของคุณในทางใดทางหนึ่ง เช่น สำหรับผู้ใช้ที่ตรวจสอบสิทธิ์แล้ว คุณอาจไม่ต้องการแคชเนื้อหาเลยเนื่องจากข้อกังวลต่างๆ รวมถึงความปลอดภัยและความใหม่ หากเบราว์เซอร์ของผู้ใช้แคชการตอบกลับ HTML ไว้ คุณจะไม่สามารถทำให้แคชเป็นโมฆะได้ วิธีที่ดีที่สุดคือการหลีกเลี่ยงการแคช HTML โดยสิ้นเชิงในกรณีดังกล่าว
วิธีที่ใช้ความระมัดระวังในการแคช HTML อาจเป็นการใช้ส่วนหัวการตอบกลับ ETag หรือ Last-Modified ส่วนหัว ETag หรือเรียกอีกอย่างว่าแท็กเอนทิตี คือตัวระบุที่แสดงถึงทรัพยากรที่ขอแบบไม่ซ้ำกัน ซึ่งมักจะใช้แฮชเนื้อหาของทรัพยากร ดังนี้
ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4"
เมื่อใดก็ตามที่มีการเปลี่ยนแปลงทรัพยากร คุณต้องสร้างค่า ETag ใหม่ เบราว์เซอร์จะส่งค่า ETag ผ่านส่วนหัวของคำขอ If-None-Match ในคำขอที่ตามมา หาก ETag บนเซิร์ฟเวอร์ตรงกับรายการที่เบราว์เซอร์ส่ง เซิร์ฟเวอร์จะตอบสนองด้วยการตอบกลับ 304 Not Modified และเบราว์เซอร์จะใช้ทรัพยากรจากแคช แม้ว่าการดำเนินการดังกล่าวยังทำให้เกิดเวลาในการตอบสนองของเครือข่าย แต่การตอบสนองของ 304 Not Modified จะน้อยกว่าทรัพยากร HTML ทั้งหมดมาก
อย่างไรก็ตาม เวลาในการตอบสนองของเครือข่ายที่เกี่ยวข้องกับการตรวจสอบความใหม่ของทรัพยากรอีกครั้งก็ยังเป็นข้อเสียของทรัพยากรอยู่เอง เช่นเดียวกับการพัฒนาเว็บในด้านอื่นๆ การแย่งกันและการประนีประนอมเป็นสิ่งที่หลีกเลี่ยงไม่ได้ ขึ้นอยู่กับคุณว่าความพยายามเพิ่มเติมในการแคช HTML ด้วยวิธีนี้จะคุ้มค่าไหม หรือควรจะปลอดภัยและไม่รบกวนการแคชเนื้อหา HTML เลย
วัดเวลาในการตอบกลับของเซิร์ฟเวอร์
หากการตอบสนองไม่ได้แคช เวลาในการตอบกลับของเซิร์ฟเวอร์จะขึ้นอยู่กับผู้ให้บริการโฮสติ้งและสแต็กแอปพลิเคชันแบ็กเอนด์ ตัวอย่างเช่น หน้าเว็บที่แสดงการตอบสนองที่สร้างขึ้นแบบไดนามิก เช่น การดึงข้อมูลจากฐานข้อมูล อาจมี TTFB สูงกว่าหน้าเว็บแบบคงที่ที่แสดงได้ทันที โดยไม่ต้องใช้เวลาประมวลผลบนแบ็กเอนด์ที่มากนัก การแสดงตัวหมุนกำลังโหลดและการดึงข้อมูลทั้งหมดในฝั่งไคลเอ็นต์เป็นการกระตุ้นให้ดำเนินการจากสภาพแวดล้อมฝั่งเซิร์ฟเวอร์ที่คาดการณ์ได้ง่ายกว่า ไปเป็นสภาพแวดล้อมฝั่งไคลเอ็นต์ที่คาดการณ์ไม่ได้ การลดความพยายามของฝั่งไคลเอ็นต์มักจะทำให้เมตริกที่มุ่งเน้นผู้ใช้เป็นหลักได้รับการปรับปรุง
หากผู้ใช้ประสบปัญหา TTFB ช้าในภาคสนาม คุณสามารถเปิดเผยข้อมูลเกี่ยวกับเวลาที่ใช้งานบนเซิร์ฟเวอร์ผ่านการใช้ส่วนหัวการตอบกลับ Server-Timing ดังนี้
Server-Timing: auth;dur=55.5, db;dur=220
ค่าของส่วนหัว Server-Timing อาจมีได้หลายเมตริก รวมถึงระยะเวลาสำหรับแต่ละเมตริก จากนั้นระบบจะรวบรวมข้อมูลนี้จากผู้ใช้ในช่องโดยใช้ Navigation Timing API และวิเคราะห์เพื่อดูว่าผู้ใช้ประสบกับความล่าช้าหรือไม่ ในข้อมูลโค้ดก่อนหน้า ส่วนหัวการตอบกลับจะมีเวลา 2 ช่วง ได้แก่
- เวลาในการตรวจสอบสิทธิ์ผู้ใช้ (
auth) ซึ่งใช้เวลา 55.5 มิลลิวินาที - เวลาเข้าถึงฐานข้อมูล (
db) ซึ่งใช้เวลา 220 มิลลิวินาที
คุณยังอาจต้องการตรวจสอบโครงสร้างพื้นฐานของโฮสติ้งและยืนยันว่าคุณมีทรัพยากรเพียงพอที่จะจัดการการเข้าชมที่เว็บไซต์ของคุณได้รับ ผู้ให้บริการโฮสติ้งที่แชร์มักมีแนวโน้มที่จะมี TTFB สูง และโซลูชันเฉพาะที่ทำให้เวลาตอบสนองเร็วขึ้นอาจมีค่าใช้จ่ายสูงกว่า
การบีบอัด
คุณควรบีบอัดการตอบกลับแบบข้อความ เช่น รูปภาพ HTML, JavaScript, CSS และ SVG เพื่อลดขนาดการโอนผ่านเครือข่ายเพื่อให้ดาวน์โหลดได้เร็วขึ้น อัลกอริทึมในการบีบอัดที่ใช้กันอย่างแพร่หลายคือ gzip และ Brotli Brotli ทำให้ gzip ดีขึ้นประมาณ 15-20%
ผู้ให้บริการเว็บโฮสติ้งส่วนใหญ่ตั้งค่าการบีบอัดมักจะตั้งค่าโดยอัตโนมัติ แต่มีสิ่งสําคัญบางอย่างที่ควรพิจารณาหากคุณอยู่ในตําแหน่งที่จะกําหนดค่าหรือปรับการตั้งค่าการบีบอัดด้วยตนเอง ดังนี้
- ใช้ Brotli หากเป็นไปได้ ตามที่ระบุไว้ก่อนหน้านี้ Brotli ให้การปรับปรุงที่ค่อนข้างชัดเจนเมื่อเทียบกับ gzip และเบราว์เซอร์หลักทั้งหมดรองรับ Brotli ใช้ Brotli ทุกครั้งที่ทำได้ แต่หากมีผู้ใช้จำนวนมากบนเบราว์เซอร์รุ่นเก่า ก็ให้ใช้ gzip เป็นรายการสำรอง เนื่องจากการบีบอัดจะดีกว่าที่ไม่มีการบีบอัดเลย
- ขนาดไฟล์เป็นสิ่งสำคัญ ทรัพยากรขนาดเล็กมาก (น้อยกว่า 1 KiB) ไม่บีบอัดมากนัก หรือบางครั้งก็ไม่ได้บีบอัดเลย ประสิทธิภาพของการบีบอัดข้อมูลทุกประเภทขึ้นอยู่กับการมีข้อมูลจำนวนมากที่อัลกอริทึมการบีบอัดสามารถทำได้เพื่อค้นหาข้อมูลขนาดเล็กที่สามารถบีบอัดได้ ยิ่งไฟล์มีขนาดใหญ่เท่าไร การบีบอัดไฟล์ก็จะยิ่งดีขึ้นเท่านั้น อย่างไรก็ตาม อย่าส่งทรัพยากรขนาดใหญ่มากเพียงเพราะว่าไฟล์เหล่านั้นสามารถบีบอัดได้อย่างมีประสิทธิภาพมากกว่า ทรัพยากรขนาดใหญ่ เช่น JavaScript และ CSS จะใช้เวลานานขึ้นในการแยกวิเคราะห์และประเมินหลังจากที่เบราว์เซอร์ดีบีบอัดไฟล์เหล่านั้นแล้ว และอาจมีการเปลี่ยนแปลงบ่อยขึ้นแม้ว่าจะมีการเปลี่ยนแปลงเพียงเล็กน้อย เนื่องจากการเปลี่ยนแปลงใดๆ จะส่งผลให้เกิดแฮชไฟล์ที่ต่างออกไป
- ทำความเข้าใจการบีบอัดแบบไดนามิกและแบบคงที่ การบีบอัดแบบไดนามิกและแบบคงที่เป็นวิธีที่แตกต่างกันในเวลาที่ควรบีบอัดทรัพยากร การบีบอัดแบบไดนามิกจะบีบอัดทรัพยากรในเวลาที่ขอ และบางครั้งจะบีบอัดทุกครั้ง ในทางตรงกันข้าม การบีบอัดแบบคงที่จะบีบอัดไฟล์ล่วงหน้า ทำให้ไม่ต้องทำการบีบอัด ณ เวลาที่ส่งคำขอ การบีบอัดแบบคงที่จะนำเวลาในการตอบสนองที่เกี่ยวข้องกับการบีบอัดออก ซึ่งสามารถเพิ่มเวลาในการตอบสนองของเซิร์ฟเวอร์ในกรณีที่เกิดการบีบอัดแบบไดนามิก ทรัพยากรแบบคงที่ เช่น รูปภาพ JavaScript, CSS และ SVG ควรได้รับการบีบอัดแบบคงที่ ส่วนทรัพยากร HTML โดยเฉพาะหากสร้างขึ้นแบบไดนามิกสำหรับผู้ใช้ที่ตรวจสอบสิทธิ์แล้ว ควรบีบอัดแบบไดนามิก
การบีบอัดด้วยตัวเองนั้นเป็นเรื่องยาก และวิธีที่ดีที่สุดคือให้เครือข่ายนำส่งข้อมูล (CDN) ซึ่งจะมีการกล่าวถึงในส่วนถัดไปจัดการเรื่องนี้ให้คุณ อย่างไรก็ตาม การทราบแนวคิดเหล่านี้จะช่วยให้คุณแยกแยะได้ว่าผู้ให้บริการโฮสติ้งใช้การบีบอัดอย่างถูกต้องหรือไม่ ความรู้ดังกล่าวช่วยให้คุณหาโอกาสในการปรับปรุงการตั้งค่าการบีบอัด เพื่อให้เว็บไซต์ได้รับประโยชน์สูงสุด
เครือข่ายนำส่งข้อมูล (CDN)
เครือข่ายนำส่งข้อมูล (Content Delivery Network หรือ CDN) คือเครือข่ายเซิร์ฟเวอร์แบบกระจายที่แคชทรัพยากรจากเซิร์ฟเวอร์ต้นทางของคุณ และในทางกลับกัน เครือข่ายนำส่งข้อมูลจากเซิร์ฟเวอร์ต้นทางที่ใกล้กับผู้ใช้ของคุณมากที่สุด ความใกล้ชิดกับผู้ใช้ช่วยลดระยะเวลารับส่งข้อมูล (RTT) ได้ ขณะที่การเพิ่มประสิทธิภาพอย่าง HTTP/2 หรือ HTTP/3, การแคช และการบีบอัดจะช่วยให้ CDN แสดงเนื้อหาได้เร็วกว่าที่ดึงข้อมูลจากเซิร์ฟเวอร์ต้นทางของคุณ การใช้ CDN ช่วยปรับปรุง TTFB ของเว็บไซต์ได้อย่างมากในบางกรณี
ทดสอบความรู้ของคุณ
การเปลี่ยนเส้นทางประเภทใดที่คุณสามารถควบคุมได้อย่างสมบูรณ์
ส่วนหัว Server-Timing มีเมตริกได้หลายรายการ
เซิร์ฟเวอร์ประเภทใดที่น่าจะอยู่ใกล้กับผู้ใช้ปลายทางของคุณมากที่สุด
ถัดไป: ทำความเข้าใจเส้นทางวิกฤติ
ตอนนี้เมื่อคุณคุ้นเคยกับข้อควรพิจารณาเกี่ยวกับประสิทธิภาพบางส่วนที่เกี่ยวข้องกับ HTML ของเว็บไซต์แล้ว คุณก็อยู่ในฐานะที่ดีขึ้นที่จะทำให้แน่ใจว่าเว็บไซต์จะโหลดได้เร็วที่สุด แต่นั่นเป็นเพียงจุดเริ่มต้นของการเรียนรู้ประสิทธิภาพของเว็บ ต่อไป เราจะพูดถึงทฤษฎีเบื้องหลังเส้นทางการแสดงผลวิกฤติ โมดูลนี้จะอธิบายถึงแนวคิดสำคัญต่างๆ เช่น ทรัพยากรการบล็อกการแสดงผลและการบล็อกการแยกวิเคราะห์ และบทบาทที่ทรัพยากรเหล่านี้มีบทบาทต่อการแสดงผลเริ่มต้นของหน้าเว็บในเบราว์เซอร์โดยเร็วที่สุด