ข้อควรพิจารณาทั่วไปเกี่ยวกับประสิทธิภาพ HTML

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

คำขอเริ่มต้นสำหรับ HTML จะต้องผ่านหลายขั้นตอน โดยแต่ละขั้นจะต้อง สักครั้ง การลดเวลาที่ใช้ในแต่ละขั้นตอนจะช่วยให้คุณมีเวลาในการ ไบต์แรก (TTFB) แม้ TTFB ไม่ใช่เมตริกเดียวที่คุณควรมุ่งเน้นเมื่อ ในเรื่องความเร็วในการโหลดหน้าเว็บ TTFB ที่สูงทำให้การเข้าถึง "ดี" ที่กำหนด เกณฑ์สําหรับเมตริก เช่น การแสดงผลเนื้อหาขนาดใหญ่ที่สุด (LCP) และ First Contentful Paint (FCP)

ลดการเปลี่ยนเส้นทางให้เหลือน้อยที่สุด

เมื่อมีการขอทรัพยากร เซิร์ฟเวอร์อาจตอบกลับด้วยการเปลี่ยนเส้นทาง มีการเปลี่ยนเส้นทางถาวร (การตอบกลับ 301 Moved Permanently) หรือชั่วคราว 1 (คำตอบ 302 Found)

การเปลี่ยนเส้นทางทำให้การโหลดหน้าเว็บช้าลงเนื่องจากเบราว์เซอร์ต้องสร้าง คำขอ HTTP เพิ่มเติมที่ตำแหน่งใหม่เพื่อเรียกข้อมูลทรัพยากร มี การเปลี่ยนเส้นทาง 2 ประเภท ได้แก่

1. การเปลี่ยนเส้นทางต้นทางเดียวกันที่เกิดขึ้นภายในต้นทางทั้งหมด ประเภทเหล่านี้ การเปลี่ยนเส้นทางทั้งหมดอยู่ภายในการควบคุมของคุณ ในฐานะที่เป็นตรรกะในการจัดการ ตำแหน่งเหล่านี้จะอยู่บนเว็บเซิร์ฟเวอร์ของคุณทั้งหมด
2. การเปลี่ยนเส้นทางข้ามต้นทางที่เริ่มต้นโดยต้นทางอื่น โดยประเภทของ การเปลี่ยนเส้นทางมักอยู่เหนือการควบคุมของคุณ

โฆษณา บริการย่อ URL และอื่นๆ มักใช้การเปลี่ยนเส้นทางแบบข้ามต้นทาง บริการของบุคคลที่สาม แม้ว่าการเปลี่ยนเส้นทางข้ามต้นทางจะอยู่นอกเหนือการควบคุมของคุณ คุณอาจยังต้องตรวจสอบว่าคุณหลีกเลี่ยงการเปลี่ยนเส้นทางหลายครั้ง เช่น มีโฆษณาที่ลิงก์กับหน้า HTTP ซึ่งเปลี่ยนเส้นทางไปยัง HTTPS ที่เทียบเท่า หรือการเปลี่ยนเส้นทางข้ามต้นทางที่มาถึงต้นทางของคุณ แต่หลังจากนั้น จะเรียกใช้การเปลี่ยนเส้นทางต้นทางเดียวกัน

แคชการตอบสนอง HTML

การแคชการตอบกลับ HTML เป็นเรื่องยาก เนื่องจากการตอบกลับอาจมีลิงก์ไปยัง ทรัพยากรสำคัญอื่นๆ เช่น CSS, JavaScript, รูปภาพ และทรัพยากรอื่นๆ ประเภทต่างๆ ทรัพยากรเหล่านี้อาจมีลายนิ้วมือที่ไม่ซ้ำกันในทรัพยากรดังกล่าว ซึ่งจะเปลี่ยนแปลงตามเนื้อหาของไฟล์ ซึ่งหมายความว่าแคช เอกสาร HTML อาจไม่มีการอัปเดตหลังจากการทำให้ใช้งานได้ เนื่องจากอาจมี การอ้างอิงไปยังทรัพยากรย่อยที่ล้าสมัย

อย่างไรก็ตาม อายุการใช้งานแคชที่สั้นแทนการแคชก็มีประโยชน์เช่นกัน เช่น การอนุญาตให้แคชทรัพยากรที่ CDN การลดจำนวน คำขอที่แสดงผลจากเซิร์ฟเวอร์ต้นทางและในเบราว์เซอร์ ซึ่งทำให้ ทรัพยากรที่ต้องได้รับการตรวจสอบอีกครั้ง แทนที่จะดาวน์โหลดมาใหม่ วิธีนี้ได้ผล เหมาะสำหรับเนื้อหาคงที่ที่ไม่มีการเปลี่ยนแปลงในบริบทใดๆ และ เวลาในการแคชทรัพยากร สามารถกำหนดระยะเวลาเป็นนาทีที่คุณคิดว่า เหมาะสม เวลาห้านาทีสำหรับทรัพยากร 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 ส่งผลให้มีการพัฒนาที่ดีขึ้นประมาณ 15% ถึง 20% เมื่อเทียบกับ gzip

การบีบอัดมักได้รับการตั้งค่าโดยอัตโนมัติโดยผู้ให้บริการเว็บโฮสติ้งส่วนใหญ่ แต่ มีเรื่องสําคัญบางอย่างที่ควรพิจารณาหากคุณสามารถกําหนดค่าได้ หรือปรับการตั้งค่าการบีบอัดด้วยตนเอง

1. ใช้ Brotli ทุกครั้งที่เป็นไปได้ ดังที่กล่าวไว้ก่อนหน้านี้ Brotli ได้ระบุ การปรับปรุงที่เห็นได้ชัดเมื่อเทียบกับ gzip และBrotli ได้รับการรองรับใน เบราว์เซอร์ ใช้ Brotli เมื่อเป็นไปได้ แต่ถ้าเว็บไซต์ของคุณมีการใช้งานโดย จำนวนผู้ใช้ในเบราว์เซอร์รุ่นเก่า ดูให้แน่ใจว่าใช้ gzip เป็นตัวสำรอง เพราะการบีบอัดใดๆ ก็ดีกว่าไม่บีบอัดเลย
2. ขนาดไฟล์มีความสำคัญ ทรัพยากรที่มีขนาดเล็กมาก น้อยกว่า 1 KiB อย่าบีบอัด ดีมาก หรือบางครั้งอาจไม่บีบอัดเลย ประสิทธิภาพทุกประเภท การบีบอัดข้อมูลขึ้นอยู่กับการมีข้อมูลปริมาณมากที่ สามารถทำงานกับอัลกอริทึมการบีบอัด เพื่อหาบิตที่บีบอัดเพิ่มเติมได้ อีกด้วย ยิ่งไฟล์มีขนาดใหญ่เท่าใด การบีบอัดก็ยิ่งมีประสิทธิภาพมากขึ้นเท่านั้น แต่ ส่งทรัพยากรขนาดใหญ่มาก เพียงแค่บีบอัดข้อมูลได้มากขึ้นเท่านั้น อย่างมีประสิทธิภาพ ทรัพยากรขนาดใหญ่ เช่น JavaScript และ CSS ตัวอย่างเช่น มีเวลามากขึ้นในการแยกวิเคราะห์และประเมินหลังจากที่เบราว์เซอร์ ลดขนาด และอาจเปลี่ยนแปลงบ่อยขึ้นแม้จะมี ลดลงเล็กน้อย เนื่องจากการเปลี่ยนแปลงจะทำให้แฮชไฟล์แตกต่างกัน
3. ทำความเข้าใจการบีบอัดแบบไดนามิกและแบบคงที่ ไดนามิกและคงที่ การบีบอัดจะมีแนวทางแตกต่างกันว่าเมื่อใดที่ควรใช้ทรัพยากร บีบอัดแล้ว การบีบอัดแบบไดนามิกจะบีบอัดทรัพยากรในเวลาที่กำหนด ส่งคำขอและบางครั้งก็ทุกครั้งที่มีการขอ ในทางกลับกัน การบีบอัดแบบคงที่จะบีบอัดไฟล์ล่วงหน้าโดยไม่จำเป็นต้องบีบอัด เมื่อได้รับคำขอ การบีบอัดแบบคงที่จะนำ เวลาในการตอบสนองที่เกี่ยวข้องกับการบีบอัด ซึ่งอาจเพิ่มให้กับการตอบสนองของเซิร์ฟเวอร์ได้ ในกรณีของการบีบอัดแบบไดนามิก ทรัพยากรแบบคงที่ เช่น รูปภาพ JavaScript, CSS และ SVG ควรบีบอัดแบบคงที่ ขณะที่ HTML ทรัพยากร โดยเฉพาะอย่างยิ่งหากทรัพยากรเหล่านั้นสร้างขึ้นแบบไดนามิกสำหรับการตรวจสอบสิทธิ์ ควรบีบอัดแบบไดนามิก

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

เครือข่ายนำส่งข้อมูล (CDN)

เครือข่ายนำส่งข้อมูล (CDN) คือเครือข่ายเซิร์ฟเวอร์แบบกระจายที่ ทรัพยากรแคชจากเซิร์ฟเวอร์ต้นทางของคุณ และในทางกลับกันก็ให้บริการจาก Edge เซิร์ฟเวอร์ที่อยู่ใกล้ผู้ใช้ของคุณมากขึ้น ความใกล้กับ ผู้ใช้ช่วยลดระยะเวลารับส่งข้อมูล (RTT) ไปพร้อมกับการเพิ่มประสิทธิภาพอย่างเช่น HTTP/2 หรือ HTTP/3, การแคช และการบีบอัดช่วยให้ CDN แสดงเนื้อหาได้รวดเร็วยิ่งขึ้น สูงกว่าที่ระบบจะดึงข้อมูล จากเซิร์ฟเวอร์ต้นทางของคุณ การใช้ CDN ปรับปรุง TTFB ของเว็บไซต์อย่างมากในบางกรณี

ทดสอบความรู้ของคุณ

ถัดไป: ทำความเข้าใจเส้นทางสำคัญ

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