โหลดหน้าเว็บได้เร็วขึ้นโดยใช้เวลาคิดของเซิร์ฟเวอร์ด้วยคำแนะนำในช่วงแรก

ดูว่าเซิร์ฟเวอร์ของคุณสามารถส่งคำแนะนำให้เบราว์เซอร์เกี่ยวกับทรัพยากรย่อยที่สำคัญได้อย่างไร

Kenji Baheux

Barry Pollard

เคล็ดลับในช่วงแรกคืออะไร

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

Early Hints คือรหัสสถานะ HTTP (103 Early Hints) ที่ใช้เพื่อส่งการตอบกลับ HTTP เบื้องต้นก่อนการตอบกลับขั้นสุดท้าย การดำเนินการนี้จะช่วยให้เซิร์ฟเวอร์ส่งคำแนะนำถึงเบราว์เซอร์เกี่ยวกับทรัพยากรย่อยที่สำคัญ (เช่น สไตล์ชีตสำหรับหน้าเว็บ, JavaScript ที่สำคัญ) หรือต้นทางที่หน้าเว็บน่าจะใช้ ในขณะที่เซิร์ฟเวอร์กำลังยุ่งอยู่กับการสร้างทรัพยากรหลัก เบราว์เซอร์สามารถใช้คําแนะนําเหล่านี้ในการเตรียมการเชื่อมต่อและขอทรัพยากรย่อยในขณะที่รอทรัพยากรหลักได้ กล่าวอีกนัยหนึ่งคือ เคล็ดลับในช่วงเริ่มต้นช่วยให้เบราว์เซอร์ใช้ประโยชน์จาก "เวลาคิดของเซิร์ฟเวอร์" ดังกล่าวโดยการทำงานบางอย่างล่วงหน้า ซึ่งทำให้โหลดหน้าเว็บได้เร็วขึ้น

ในบางกรณี การปรับปรุงประสิทธิภาพใน Largest Contentful Paint อาจอยู่ที่หลายร้อยมิลลิวินาที ตามที่ Shopify และ โดย Cloudflare สังเกต และเพิ่มเร็วขึ้นอีก 1 ตามที่เห็นในก่อนและหลังการเปรียบเทียบนี้

วิธีใช้คำแนะนำในช่วงแรก

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

เมื่อได้รายการหน้า Landing Page ที่จัดลำดับความสำคัญแล้ว ขั้นตอนต่อไปคือการระบุต้นทางหรือทรัพยากรย่อยที่เป็นตัวเลือกที่ดีสำหรับคำแนะนำ preconnect หรือ preload โดยปกติแล้ว แหล่งที่มาและทรัพยากรย่อยเหล่านั้นจะเป็นแหล่งที่มาและทรัพยากรย่อยที่ส่งผลต่อเมตริกผู้ใช้หลักมากที่สุด เช่น Largest Contentful Paint หรือ First Contentful Paint หากเป็นเช่นนี้ คุณควรมองหาทรัพยากรย่อยของการบล็อกการแสดงผล เช่น JavaScript แบบซิงโครนัส, สไตล์ชีต หรือแม้แต่แบบอักษรสำหรับเว็บ ในทำนองเดียวกัน ให้มองหาต้นทางที่โฮสต์ทรัพยากรย่อยที่ส่งผลต่อเมตริกผู้ใช้ที่สำคัญเป็นอย่างมาก

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

เมื่อใช้สิ่งเหล่านี้ใน HTML โดยปกติคุณจะต้องการ preconnect หรือ preload ทรัพยากรที่เครื่องสแกนการโหลดล่วงหน้าไม่พบใน HTML เช่น แบบอักษรหรือภาพพื้นหลังที่จะถูกค้นพบล่าช้า สำหรับคำแนะนำในช่วงแรก คุณจะไม่มี HTML ดังนั้นคุณอาจต้อง preconnect ไปยังโดเมนที่สำคัญหรือทรัพยากรสำคัญ preload รายการที่อาจค้นพบในช่วงต้นของ HTML แทน เช่น การโหลด main.css หรือ app.js ล่วงหน้า นอกจากนี้ เบราว์เซอร์บางประเภทไม่รองรับ preload สำหรับคำแนะนำล่วงหน้า โปรดดูการสนับสนุนเบราว์เซอร์

ขั้นตอนที่ 2 จะลดความเสี่ยงของการใช้คำแนะนำในช่วงแรกกับทรัพยากรหรือต้นทางที่อาจล้าสมัยหรือไม่มีการใช้งานโดยทรัพยากรหลักอีกต่อไป ตัวอย่างเช่น ทรัพยากรที่มีการอัปเดตและกำหนดเวอร์ชันบ่อยๆ (เช่น example.com/css/main.fa231e9c.css) อาจไม่ใช่ตัวเลือกที่ดีที่สุด โปรดทราบว่าข้อกังวลนี้ไม่ได้เจาะจงเฉพาะกับคำแนะนำในช่วงแรก แต่จะมีผลกับ preload หรือ preconnect ทุกที่ที่อาจมีอยู่ นี่เป็นรายละเอียดที่ตรงกับการทำงานอัตโนมัติหรือเทมเพลตมากที่สุด (เช่น กระบวนการที่ดำเนินการด้วยตนเองมักจะทำให้ได้แฮชหรือ URL เวอร์ชันที่ไม่ตรงกันระหว่าง preload และแท็ก HTML จริงเมื่อใช้แหล่งข้อมูล)

เพื่อเป็นตัวอย่าง ลองพิจารณาขั้นตอนต่อไปนี้

GET /main.html
Host: example.com
User-Agent: [....] Chrome/103.0.0.0 [...]

เซิร์ฟเวอร์คาดการณ์ว่าจะต้องใช้ main.abcd100.css และแนะนำให้โหลดล่วงหน้าโดยใช้คำแนะนำในช่วงแรก

103 Early Hints
Link: </main.abcd100.css>; rel=preload; as=style
[...]

หลังจากนั้นไม่นาน หน้าเว็บ รวมถึง CSS ที่ลิงก์ไว้ก็จะปรากฏขึ้น ขออภัย แหล่งข้อมูล CSS นี้มีการอัปเดตบ่อยครั้ง และทรัพยากรหลักเป็นทรัพยากร CSS ที่คาดการณ์ไว้ (abcd100) อยู่แล้ว 5 เวอร์ชัน (abcd105)

200 OK
[...]
<HTML>
<head>
   <title>Example</title>
   <link rel="stylesheet" href="/main.abcd105.css">

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

<HTML>
<head>
   <title>Example</title>
   <link rel="stylesheet" href="/main.css">
   <link rel="stylesheet" href="/experimental.3eab3290.css">

สุดท้าย ในฝั่งเซิร์ฟเวอร์ ให้มองหาคำขอทรัพยากรหลักที่ส่งโดยเบราว์เซอร์ที่ทราบว่ารองรับ Early Hints และตอบกลับทันทีด้วย 103 Early Hints ในคำตอบ 103 ให้ใส่คำแนะนำการเชื่อมต่อล่วงหน้าที่เกี่ยวข้องและการโหลดล่วงหน้า เมื่อแหล่งข้อมูลหลักพร้อมแล้ว ให้ติดตามผลด้วยคำตอบปกติ (เช่น 200 OK หากสำเร็จ) สำหรับความเข้ากันได้แบบย้อนหลัง แนวทางปฏิบัติที่ดีคือการรวมส่วนหัว HTTP ของ Link ในคำตอบสุดท้ายด้วย โดยอาจเพิ่มทรัพยากรสำคัญที่เห็นได้ชัดว่าเป็นส่วนหนึ่งของการสร้างทรัพยากรหลัก (เช่น ส่วนแบบไดนามิกของทรัพยากรหลักหากคุณทำตามคำแนะนำ "แบ่งออกเป็น 2 ส่วน") ซึ่งจะมีลักษณะดังนี้

GET /main.html
Host: example.com
User-Agent: [....] Chrome/103.0.0.0 [...]
103 Early Hints
Link: <https://fonts.google.com>; rel=preconnect
Link: </main.css>; rel=preload; as=style
Link: </common.js>; rel=preload; as=script

หลังจากนั้นสักครู่

200 OK
Content-Length: 7531
Content-Type: text/html; charset=UTF-8
Content-encoding: br
Link: <https://fonts.google.com>; rel=preconnect
Link: </main.css>; rel=preload; as=style
Link: </common.js>; rel=preload; as=script
Link: </experimental.3eab3290.css>; rel=preload; as=style
<HTML>
<head>
   <title>Example</title>
   <link rel="stylesheet" href="/main.css">
   <link rel="stylesheet" href="/experimental.3eab3290.css">
   <script src="/common.js"></script>
   <link rel="preconnect" href="https://fonts.googleapis.com">

การสนับสนุนเบราว์เซอร์

แม้ว่า 103 Early Hint จะรองรับในเบราว์เซอร์หลักๆ ทั้งหมด แต่คำสั่งที่สามารถส่งบนคำแนะนำในช่วงแรกจะแตกต่างกันในแต่ละเบราว์เซอร์ ดังนี้

เชื่อมต่อการสนับสนุนล่วงหน้า:

การสนับสนุนการโหลดล่วงหน้า:

นอกจากนี้ เครื่องมือสำหรับนักพัฒนาเว็บใน Chrome ยังมีการรองรับคำแนะนำล่วงหน้า 103 รายการด้วย

การสนับสนุนเซิร์ฟเวอร์

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

• Apache: รองรับโดยใช้ mod_http2
• H2O: รองรับ
• NGINX: โมดูลทดลอง
• โหนด: รองรับตั้งแต่ 18.11.0 สำหรับ http และ http2

เปิดใช้คำแนะนำล่วงหน้าด้วยวิธีที่ง่ายขึ้น

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

• คำแนะนำเบื้องต้นจาก Cloudflare
• คำแนะนำแบบรวดเร็วทันใจ
• คำแนะนำเบื้องต้นที่ Akamai

วิธีหลีกเลี่ยงปัญหาสำหรับลูกค้าที่ไม่รองรับคำแนะนำในช่วงแรก

การตอบกลับ HTTP ที่ให้ข้อมูลในช่วง 100 ช่วงเป็นส่วนหนึ่งของมาตรฐาน HTTP แต่ไคลเอ็นต์หรือบ็อตรุ่นเก่าๆ บางรายอาจประสบปัญหาเนื่องจากก่อนที่จะเปิดตัวคำแนะนำในช่วงแรก 103 คำแนะนำที่ไม่ค่อยมีการใช้งานสำหรับการท่องเว็บทั่วไป

การส่งเฉพาะคำแนะนำล่วงหน้า 103 รายการเพื่อตอบสนองต่อไคลเอ็นต์ที่ส่งส่วนหัวของคำขอ HTTP sec-fetch-mode: navigate ควรตรวจสอบว่าระบบส่งคำแนะนำดังกล่าวเฉพาะลูกค้าใหม่ที่ทราบว่าจะรอการตอบกลับในภายหลัง นอกจากนี้ เนื่องจากคำแนะนำในช่วงแรกรองรับเฉพาะคำขอการนำทางเท่านั้น (ดูข้อจำกัดปัจจุบัน) ฟีเจอร์นี้จึงมีประโยชน์เพิ่มเติมในการหลีกเลี่ยงการส่งคำใบ้เหล่านี้โดยไม่จำเป็นในคำขออื่นๆ

นอกจากนี้ ขอแนะนำให้ส่งคำแนะนำในช่วงแรกผ่านการเชื่อมต่อ HTTP/2 หรือ HTTP/3 เท่านั้น

รูปแบบขั้นสูง

หากคุณใช้คำแนะนำในช่วงแรกกับหน้า Landing Page หลักอย่างครบถ้วนและกำลังมองหาโอกาสเพิ่มเติม คุณอาจสนใจรูปแบบขั้นสูงต่อไปนี้

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

ข้อจำกัดปัจจุบัน

ข้อจำกัดของคำแนะนำในช่วงแรกที่ติดตั้งใช้งานใน Chrome มีดังนี้

• ใช้ได้เฉพาะกับคำขอการนำทาง (ซึ่งเป็นทรัพยากรหลักของเอกสารระดับบนสุด)
• รองรับเฉพาะ preconnect และ preload (ไม่รองรับ prefetch)
• คำใบ้ล่วงหน้าตามด้วยการเปลี่ยนเส้นทางแบบข้ามต้นทางในการตอบสนองสุดท้ายจะทำให้ Chrome ลดทรัพยากรและการเชื่อมต่อที่ได้รับโดยใช้ Early Hints

เบราว์เซอร์อื่นก็มีข้อจำกัดที่คล้ายกัน และบางเบราว์เซอร์ก็จำกัดคําแนะนําล่วงหน้า 103 รายการสําหรับ preconnect เท่านั้น

ขั้นตอนถัดไปคือ

เราอาจเพิ่มประสิทธิภาพการใช้งานคำแนะนำเบื้องต้นด้วยความสามารถต่อไปนี้ ทั้งนี้ขึ้นอยู่กับความสนใจจากชุมชน

• ส่งคำแนะนำในช่วงแรกในคำขอทรัพยากรย่อยแล้ว
• มีการส่งคำแนะนำในช่วงแรกในคำขอทรัพยากรหลักของ iframe
• รองรับการดึงข้อมูลล่วงหน้าในคำแนะนำล่วงหน้า

เรายินดีรับฟังข้อมูลจากคุณเกี่ยวกับสิ่งที่ควรให้ความสำคัญและวิธีปรับปรุงคำแนะนำในช่วงแรก

ความสัมพันธ์กับ H2/พุช

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

ในทางตรงกันข้าม เคล็ดลับในช่วงแรกมีประสิทธิภาพดีกว่าในทางปฏิบัติ เนื่องจากวิธีนี้ผสานรวมความสามารถในการส่งคำตอบเบื้องต้นเข้ากับคำแนะนำที่ทำให้เบราว์เซอร์มีหน้าที่ดึงข้อมูลหรือเชื่อมต่อกับสิ่งที่ต้องใช้จริงๆ แม้ว่าคำใบ้ในช่วงแรกจะไม่ครอบคลุม Use Case ทั้งหมดที่ HTTP2/Push ทำได้ในทางทฤษฎี แต่เราเชื่อว่า Early Hints เป็นวิธีแก้ปัญหาที่ช่วยเพิ่มความเร็วในการนำทางได้จริงมากกว่า

ภาพขนาดย่อโดย Pierre Bamin