ขั้นตอนแรกในการสร้างเว็บไซต์ที่โหลดได้อย่างรวดเร็วคือการได้รับการตอบสนองจากเซิร์ฟเวอร์สำหรับ HTML ของหน้าเว็บอย่างทันท่วงที
เมื่อคุณป้อน URL ในแถบที่อยู่ของเบราว์เซอร์ เบราว์เซอร์จะส่งคำขอ GET ไปยังเซิร์ฟเวอร์เพื่อ
ดึงข้อมูล คำขอแรกสำหรับหน้าเว็บคือคำขอสำหรับทรัพยากร HTML และการตรวจสอบว่า HTML มาถึงอย่างรวดเร็วโดยมีความล่าช้าน้อยที่สุดเป็นเป้าหมายด้านประสิทธิภาพที่สำคัญ
คำขอ HTML เริ่มต้นนั้นผ่านหลายขั้นตอน ซึ่งแต่ละขั้นตอนต้องใช้เวลา สักระยะ การลดเวลาที่ใช้ในแต่ละขั้นตอนจะช่วยให้คุณมีเวลาในการตอบสนองครั้งแรก (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 ในเซิร์ฟเวอร์ตรงกับ 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 ช่วยปรับปรุงประสิทธิภาพได้ประมาณ 15% ถึง 20% เมื่อเทียบกับ gzip
ผู้ให้บริการเว็บโฮสติ้งส่วนใหญ่มักจะตั้งค่าการบีบอัดโดยอัตโนมัติ แต่มีสิ่งสำคัญบางอย่างที่ควรพิจารณาหากคุณอยู่ในตำแหน่งที่สามารถกำหนดค่าหรือปรับแต่งการตั้งค่าการบีบอัดด้วยตนเอง
- ใช้ Brotli หากเป็นไปได้ ดังที่ได้กล่าวไว้ก่อนหน้านี้ Brotli ช่วยปรับปรุงประสิทธิภาพได้ดีกว่า gzip อย่างเห็นได้ชัด และเบราว์เซอร์หลักทั้งหมดรองรับ Brotli ใช้ Brotli เมื่อเป็นไปได้ แต่หากมีผู้ใช้จำนวนมากใช้เว็บไซต์ของคุณในเบราว์เซอร์รุ่นเดิม โปรดตรวจสอบว่าได้ใช้ gzip เป็นการสำรองข้อมูล เนื่องจากมีการบีบอัดดีกว่าไม่มีการบีบอัดเลย
- ขนาดไฟล์มีความสำคัญ ทรัพยากรขนาดเล็กมาก (น้อยกว่า 1 KiB) จะบีบอัดได้ไม่ดีนัก หรือบางครั้งก็บีบอัดไม่ได้เลย ประสิทธิภาพของการบีบอัดข้อมูลประเภทใดก็ตามขึ้นอยู่กับการมีข้อมูลจำนวนมากที่อัลกอริทึมการบีบอัดสามารถใช้เพื่อค้นหาบิตข้อมูลที่บีบอัดได้มากขึ้น ยิ่งไฟล์มีขนาดใหญ่ การบีบอัดก็จะยิ่งได้ผลดี แต่ก็ไม่ควร ส่งทรัพยากรที่มีขนาดใหญ่มากเพียงเพราะบีบอัดได้อย่างมีประสิทธิภาพมากขึ้น ทรัพยากรขนาดใหญ่ เช่น JavaScript และ CSS จะใช้เวลาในการแยกวิเคราะห์และประเมินนานขึ้นอย่างมากหลังจากที่เบราว์เซอร์คลายการบีบอัดแล้ว และอาจมีการเปลี่ยนแปลงบ่อยขึ้นแม้ว่าจะมีการเปลี่ยนแปลงเพียงเล็กน้อย เนื่องจากทุกการเปลี่ยนแปลงจะส่งผลให้แฮชของไฟล์แตกต่างกัน
- ทําความเข้าใจการบีบอัดแบบไดนามิกเทียบกับการบีบอัดแบบคงที่ การบีบอัดแบบไดนามิกและแบบคงที่ เป็นแนวทางที่แตกต่างกันในการระบุเวลาที่ควรบีบอัดทรัพยากร การบีบอัดแบบไดนามิกจะบีบอัดทรัพยากรในเวลาที่มีการส่งคำขอ และบางครั้งจะบีบอัดทุกครั้งที่มีการส่งคำขอ ในทางกลับกัน การบีบอัดแบบคงที่จะบีบอัดไฟล์ล่วงหน้า จึงไม่จำเป็นต้องบีบอัด เมื่อมีการส่งคำขอ การบีบอัดแบบคงที่จะลดเวลาในการตอบสนองของเซิร์ฟเวอร์ เนื่องจากไม่มีเวลาในการบีบอัดเอง ซึ่งอาจเพิ่มเวลาในการตอบสนองของเซิร์ฟเวอร์ ในกรณีของการบีบอัดแบบไดนามิก ทรัพยากรแบบคงที่ เช่น รูปภาพ JavaScript, CSS และ SVG ควรได้รับการบีบอัดแบบคงที่ ในขณะที่ทรัพยากร HTML โดยเฉพาะหากสร้างแบบไดนามิกสำหรับผู้ใช้ที่ได้รับการตรวจสอบสิทธิ์ ควรได้รับการบีบอัดแบบไดนามิก
การบีบอัดด้วยตัวเองเป็นเรื่องที่ท้าทาย และมักจะดีที่สุดหากปล่อยให้เครือข่ายนำส่งข้อมูล (CDN) ซึ่งจะกล่าวถึงในส่วนถัดไปจัดการเรื่องนี้ให้คุณ อย่างไรก็ตาม การทำความเข้าใจแนวคิดเหล่านี้จะช่วยให้คุณพิจารณาได้ว่าผู้ให้บริการโฮสติ้งใช้การบีบอัดอย่างถูกต้องหรือไม่ ความรู้ดังกล่าวจะช่วยให้คุณค้นพบโอกาสในการปรับปรุงการตั้งค่าการบีบอัดเพื่อให้การตั้งค่าเหล่านั้น สร้างประโยชน์สูงสุดแก่เว็บไซต์
เครือข่ายนำส่งข้อมูล (CDN)
เครือข่ายนำส่งข้อมูล (CDN) คือเครือข่ายเซิร์ฟเวอร์แบบกระจายที่แคชทรัพยากรจากเซิร์ฟเวอร์ต้นทาง และให้บริการทรัพยากรเหล่านั้นจาก Edge Server ที่อยู่ใกล้กับผู้ใช้มากกว่า การอยู่ใกล้กับผู้ใช้จะช่วยลดเวลาในการรับส่ง (RTT) ในขณะที่การเพิ่มประสิทธิภาพ เช่น HTTP/2 หรือ HTTP/3, การแคช และการบีบอัด จะช่วยให้ CDN แสดงเนื้อหาได้เร็วกว่าการดึงข้อมูลจากเซิร์ฟเวอร์ต้นทาง การใช้ CDN อาจช่วยปรับปรุง TTFB ของเว็บไซต์ได้อย่างมากในบางกรณี
ทดสอบความรู้ของคุณ
คุณควบคุมการเปลี่ยนเส้นทางประเภทใดได้อย่างสมบูรณ์
ส่วนหัว Server-Timing มีเมตริกได้หลายรายการ
เซิร์ฟเวอร์ประเภทใดที่น่าจะอยู่ใกล้กับผู้ใช้ปลายทางมากที่สุด
ถัดไป: ทำความเข้าใจเส้นทางที่สำคัญ
ตอนนี้คุณคุ้นเคยกับข้อควรพิจารณาด้านประสิทธิภาพบางอย่างที่เกี่ยวข้องกับ HTML ของเว็บไซต์แล้ว คุณจึงอยู่ในสถานะที่ดีขึ้นเพื่อให้มั่นใจว่าเว็บไซต์จะโหลดได้เร็วที่สุด แต่การเพิ่มประสิทธิภาพเว็บเป็นเพียงจุดเริ่มต้นของการเรียนรู้ ถัดไป เราจะพูดถึงทฤษฎีเบื้องหลังเส้นทางการแสดงผลที่สำคัญ โมดูลนี้อธิบายแนวคิดหลักๆ เช่น ทรัพยากรที่บล็อกการแสดงผลและบล็อกการแยกวิเคราะห์ รวมถึงบทบาทของทรัพยากรเหล่านี้ในการทำให้เบราว์เซอร์แสดงผลหน้าเว็บครั้งแรกได้เร็วที่สุด