ดูว่าเซิร์ฟเวอร์จะส่งคำแนะนำเกี่ยวกับทรัพยากรย่อยที่สำคัญไปยังเบราว์เซอร์ได้อย่างไร
คำแนะนำเบื้องต้นคืออะไร
เว็บไซต์มีความซับซ้อนมากขึ้นเรื่อยๆ ดังนั้น จึงไม่แปลกที่เซิร์ฟเวอร์จะต้องทำงานที่ไม่ได้สำคัญ (ตัวอย่างเช่น การเข้าถึงฐานข้อมูล หรือ CDN ที่เข้าถึงเซิร์ฟเวอร์ต้นทาง) เพื่อสร้าง HTML สำหรับหน้าที่ขอ น่าเสียดายที่ "เวลาคิดของเซิร์ฟเวอร์" นี้ ส่งผลให้ใช้เวลาในการตอบสนองเพิ่มขึ้นก่อนที่เบราว์เซอร์จะเริ่มแสดงผลหน้าเว็บได้ ที่จริงแล้ว การเชื่อมต่อจะไม่มีการใช้งานอย่างมีประสิทธิภาพตราบใดที่เซิร์ฟเวอร์ใช้ในการเตรียมการตอบสนอง
![รูปภาพแสดงช่องว่างเวลาคิดของเซิร์ฟเวอร์ที่ 200 มิลลิวินาทีระหว่างการโหลดหน้าเว็บกับการโหลดทรัพยากรอื่นๆ](https://developer.chrome.google.cn/static/docs/web-platform/early-hints/image/image-showing-server-tim-c6a1c47529e9f.png?authuser=0000&hl=th)
Early Hints คือรหัสสถานะ HTTP (103 Early Hints
) ที่ใช้ส่งการตอบกลับ HTTP เบื้องต้นก่อนการตอบกลับสุดท้าย วิธีนี้จะช่วยให้เซิร์ฟเวอร์ส่งคำแนะนำไปยังเบราว์เซอร์เกี่ยวกับทรัพยากรย่อยที่สำคัญ (เช่น สไตล์ชีตสำหรับหน้าเว็บ, JavaScript ที่สำคัญ) หรือต้นทางที่หน้าเว็บมีแนวโน้มที่จะใช้ ขณะที่เซิร์ฟเวอร์กำลังยุ่งอยู่กับการสร้างทรัพยากรหลัก เบราว์เซอร์จะใช้คำแนะนำดังกล่าวเพื่อทำให้การเชื่อมต่อดีขึ้น และขอทรัพยากรย่อยในขณะที่รอทรัพยากรหลักได้ กล่าวอีกนัยหนึ่งคือ Early Hints ช่วยให้เบราว์เซอร์ใช้ประโยชน์จาก "เวลาคิดของเซิร์ฟเวอร์" ด้วยการทำงานล่วงหน้า ซึ่งจะช่วยเพิ่มความเร็วในการโหลดหน้าเว็บ
![รูปภาพแสดงวิธีที่คำแนะนำเบื้องต้นช่วยให้หน้าเว็บส่งคำตอบบางส่วนได้](https://developer.chrome.google.cn/static/docs/web-platform/early-hints/image/image-showing-early-hint-8adb7fe696e4f.png?authuser=0000&hl=th)
ในบางกรณี การปรับปรุงประสิทธิภาพของ Largest Contentful Paint อาจมาจากเวลาหลายร้อยมิลลิวินาที ตามที่สังเกตโดย Shopify และ โดย Cloudflare และเพิ่มความเร็วสูงสุด 1 วินาที ดังที่เห็นได้จากก่อนและหลังการเปรียบเทียบ
![การเปรียบเทียบเว็บไซต์ 2 แห่ง](https://developer.chrome.google.cn/static/docs/web-platform/early-hints/image/comparison-two-sites-157e25c61058d.jpg?authuser=0000&hl=th)
วิธีใช้คำแนะนำเบื้องต้น
ขั้นตอนแรกในการใช้ประโยชน์จากคำแนะนำเบื้องต้นประกอบด้วยการระบุหน้า 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">
สุดท้าย ในฝั่งเซิร์ฟเวอร์ ให้มองหาคำขอทรัพยากรหลักที่ส่งมาจากเบราว์เซอร์ที่รู้จักว่ารองรับคำแนะนำเบื้องต้น และตอบกลับทันทีด้วยคำแนะนำเบื้องต้น 103 ข้อ ในคำตอบ 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 คำแนะนำเบื้องต้น แต่คำสั่งที่สามารถส่งสำหรับคำแนะนำเบื้องต้นจะแตกต่างกันไปตามแต่ละเบราว์เซอร์ ดังนี้
การสนับสนุนเกี่ยวกับการเชื่อมต่อล่วงหน้า
การรองรับเบราว์เซอร์
โหลดการสนับสนุนล่วงหน้า:
การรองรับเบราว์เซอร์
เครื่องมือสำหรับนักพัฒนาเว็บใน Chrome ยังมีการรองรับคำแนะนำเบื้องต้น 103 รายการ และส่วนหัว Link
โปรดดูในทรัพยากรของเอกสารต่อไปนี้
![แผงเครือข่ายที่แสดงส่วนหัวของคำแนะนำเบื้องต้น](https://developer.chrome.google.cn/static/docs/web-platform/early-hints/image/early-hint-headers.png?authuser=0000&hl=th)
Link
จะแสดงในเครื่องมือสำหรับนักพัฒนาเว็บใน Chromeหมายเหตุในการใช้ทรัพยากร Early Hints ต้องไม่เลือก Disable cache
ใน DevTools เนื่องจาก Early Hints ใช้แคชของเบราว์เซอร์ สำหรับทรัพยากรที่โหลดไว้ล่วงหน้า ผู้เริ่มจะแสดงเป็น early-hints
และขนาดเป็น (Disk cache)
![แผงเครือข่ายที่แสดงผู้เริ่มคำแนะนำเบื้องต้น](https://developer.chrome.google.cn/static/docs/web-platform/early-hints/image/early-hint-initiators.png?authuser=0000&hl=th)
early-hints
และโหลดจากดิสก์แคชซึ่งต้องใช้ใบรับรองที่เชื่อถือได้สำหรับการทดสอบ HTTPS ด้วย
Firefox (ตั้งแต่เวอร์ชัน 126 เป็นต้นไป) ไม่รองรับ 103 Early Hints อย่างชัดแจ้งใน DevTools แต่ทรัพยากรที่โหลดโดยใช้ Early Hints ไม่แสดงข้อมูลส่วนหัว HTTP ซึ่งเป็นตัวบ่งชี้หนึ่งว่าโหลดผ่าน Early Hints
การสนับสนุนเซิร์ฟเวอร์
ต่อไปนี้เป็นข้อมูลสรุปคร่าวๆ เกี่ยวกับระดับการสนับสนุนสำหรับ Early Hints ในหมู่ซอฟต์แวร์เซิร์ฟเวอร์ HTTP ที่เป็นซอฟต์แวร์โอเพนซอร์สยอดนิยม
- Apache: รองรับโดยใช้ mod_http2
- H2O: รองรับ
- NGINX: โมดูลทดสอบ
- โหนด: รองรับตั้งแต่ 18.11.0 สำหรับ http และ http2
เปิดใช้คำแนะนำเบื้องต้นวิธีที่ง่ายขึ้น
หากคุณใช้ CDN หรือแพลตฟอร์มรายการใดรายการหนึ่งต่อไปนี้ คุณอาจไม่จำเป็นต้องใช้คำแนะนำเบื้องต้นด้วยตนเอง โปรดดูเอกสารออนไลน์ของผู้ให้บริการโซลูชันเพื่อดูว่ารองรับคำแนะนำเบื้องต้นหรือไม่ หรือดูรายการโดยสังเขปที่นี่
วิธีหลีกเลี่ยงปัญหาสำหรับลูกค้าที่ไม่รองรับ Early Hints
การตอบสนองของ HTTP ที่ให้ข้อมูลในช่วง 100 เป็นส่วนหนึ่งของมาตรฐาน HTTP แต่ไคลเอ็นต์หรือบ็อตรุ่นเก่าบางรุ่นอาจประสบปัญหาเหล่านี้เนื่องจากก่อนที่มีคำแนะนำ 103 อย่างในช่วงแรก พวกเขาไม่ค่อยได้ใช้ในการเรียกดูเว็บทั่วไป
การปล่อยคำแนะนำเบื้องต้นเพียง 103 รายการเพื่อตอบกลับไคลเอ็นต์ที่ส่งส่วนหัวของคำขอ HTTP sec-fetch-mode: navigate
ควรตรวจสอบว่ามีการส่งคำแนะนำดังกล่าวสำหรับไคลเอ็นต์ที่ใหม่กว่าที่เข้าใจว่าต้องรอการตอบกลับถัดไปเท่านั้น นอกจากนี้ เนื่องจากคำแนะนำเบื้องต้นรองรับเฉพาะคำขอการนำทางเท่านั้น (ดูข้อจำกัดปัจจุบัน) คำแนะนำนี้จึงมีประโยชน์เพิ่มเติมคือหลีกเลี่ยงการส่งคำขอเหล่านี้โดยไม่จำเป็นในคำขออื่นๆ
นอกจากนี้ เราขอแนะนำให้ส่งคำแนะนำเบื้องต้นผ่านการเชื่อมต่อ HTTP/2 หรือ HTTP/3 เท่านั้น และเบราว์เซอร์ส่วนใหญ่จะยอมรับผ่านโปรโตคอลดังกล่าวเท่านั้น
รูปแบบขั้นสูง
หากคุณได้ใช้คำแนะนำเบื้องต้นกับหน้า Landing Page ที่สำคัญโดยสมบูรณ์แล้ว และเห็นว่าคุณกำลังมองหาโอกาสเพิ่มเติม คุณอาจสนใจรูปแบบขั้นสูงต่อไปนี้
สำหรับผู้เข้าชมที่อยู่ในคำขอหน้าเว็บที่ n ซึ่งเป็นส่วนหนึ่งของเส้นทางของผู้ใช้ทั่วไป คุณอาจต้องปรับการตอบสนองต่อคำแนะนำเบื้องต้นให้เข้ากับเนื้อหาที่อยู่ลึกและต่ำในหน้านั้น กล่าวคือ การใช้คำแนะนำเบื้องต้นกับทรัพยากรที่มีลำดับความสำคัญต่ำกว่า นี่อาจฟังดูขัดกันเพราะเราขอแนะนำให้โฟกัสที่ทรัพยากรย่อยหรือต้นทางที่บล็อกการแสดงผลและมีลำดับความสำคัญสูง แต่เมื่อผู้เข้าชมสำรวจไปสักระยะหนึ่ง ก็มีแนวโน้มสูงที่เบราว์เซอร์ของผู้เข้าชมจะมีทรัพยากรที่สำคัญทั้งหมดอยู่แล้ว จากจุดนี้ คุณควรสลับความสนใจไปที่ทรัพยากรที่มีลำดับความสำคัญต่ำกว่า เช่น อาจหมายถึงการใช้คำแนะนำเบื้องต้นเพื่อโหลดรูปภาพผลิตภัณฑ์ หรือ JS/CSS เพิ่มเติมที่จำเป็นสำหรับการโต้ตอบของผู้ใช้ที่เกิดขึ้นไม่บ่อยนักเท่านั้น
ข้อจำกัดปัจจุบัน
ข้อจำกัดของคำแนะนำเบื้องต้นที่ใช้ใน Chrome มีดังนี้
- ใช้ได้กับคำขอการนำทาง (ซึ่งเป็นทรัพยากรหลักสำหรับเอกสารระดับบนสุด) เท่านั้น
- รองรับ
preconnect
และpreload
เท่านั้น (ไม่รองรับprefetch
) - คำแนะนำเบื้องต้นตามด้วยการเปลี่ยนเส้นทางข้ามต้นทางในการตอบกลับสุดท้ายจะส่งผลให้ Chrome ลดทรัพยากรและการเชื่อมต่อที่ได้รับโดยใช้คำแนะนำเบื้องต้น
- ทรัพยากรที่โหลดไว้ล่วงหน้าโดยใช้คำแนะนำเบื้องต้นจะจัดเก็บอยู่ในแคช HTTP และดึงมาจากหน้าเว็บในภายหลัง ดังนั้นระบบจึงโหลดเฉพาะทรัพยากรแบบแคชล่วงหน้าได้โดยใช้คำแนะนำเบื้องต้น ไม่เช่นนั้นระบบจะดึงข้อมูลทรัพยากรซ้ำ (1 ครั้งโดยคำแนะนำเบื้องต้นและอีกครั้งในเอกสาร) ใน Chrome ระบบจะปิดใช้แคช HTTP สำหรับใบรับรอง HTTPS ที่ไม่น่าเชื่อถือ (แม้ว่าคุณจะดำเนินการเพื่อโหลดหน้าเว็บก็ตาม)
- การโหลดรูปภาพที่ตอบสนองตามอุปกรณ์ล่วงหน้า (โดยใช้
imagesrcset
,imagesizes
หรือmedia
) จะไม่รองรับโดยใช้ส่วนหัว HTTP<link>
เนื่องจากจะไม่มีการกำหนดวิวพอร์ตจนกว่าจะมีการสร้างเอกสาร ซึ่งหมายความว่า 103 คำแนะนำเบื้องต้นไม่สามารถใช้เพื่อโหลดรูปภาพที่ปรับเปลี่ยนตามอุปกรณ์ล่วงหน้าได้ และอาจโหลดรูปภาพที่ไม่ถูกต้องเมื่อใช้กับกรณีนี้ ทำตามการพูดคุยเกี่ยวกับข้อเสนอในการรับมือกับปัญหานี้ให้ดียิ่งขึ้น
เบราว์เซอร์อื่นๆ ก็มีข้อจำกัดที่คล้ายกันและดังที่ได้ระบุไว้ก่อนหน้านี้ บางเบราว์เซอร์จะจำกัดคำแนะนำเบื้องต้นไว้เพียง 103 รายการสำหรับ preconnect
เท่านั้น
ขั้นตอนถัดไปคือ
เราอาจนำ Early Hints มาใช้ด้วยความสามารถต่อไปนี้ ขึ้นอยู่กับความสนใจจากชุมชน
- คำแนะนำเบื้องต้นสำหรับทรัพยากรที่แคชไม่ได้โดยใช้แคชหน่วยความจำแทนแคช HTTP
- ส่งคำแนะนำเบื้องต้นสำหรับคำขอทรัพยากรย่อย
- ส่งคำแนะนำเบื้องต้นในคำขอทรัพยากรหลักของ iframe
- รองรับการดึงข้อมูลล่วงหน้าในคำแนะนำเบื้องต้น
เรายินดีรับฟังความคิดเห็นของคุณเกี่ยวกับสิ่งที่ควรให้ความสำคัญและวิธีปรับปรุงคำแนะนำเบื้องต้นต่อไป
ความสัมพันธ์กับ H2/Push
หากคุณคุ้นเคยกับฟีเจอร์ HTTP2/Push ที่เลิกใช้งานแล้ว คุณอาจสงสัยว่าคำแนะนำเบื้องต้นแตกต่างกันอย่างไร แม้ว่าคำแนะนำเบื้องต้นต้องใช้การรับส่งของเบราว์เซอร์เพื่อเริ่มดึงข้อมูลทรัพยากรย่อยที่สำคัญ แต่ HTTP2/Push จะทำให้เซิร์ฟเวอร์เริ่มพุชทรัพยากรย่อยไปพร้อมๆ กับการตอบสนองได้ แม้ว่านี่จะฟังดูน่ามหัศจรรย์ แต่ก็ทำให้เกิดข้อด้อยทางโครงสร้างที่สำคัญ นั่นก็คือการใช้ HTTP2/Push นั้นทำได้ยากมากในการหลีกเลี่ยงการพุชทรัพยากรย่อยที่เบราว์เซอร์มีอยู่แล้ว "การผลักดันมากเกินไป" นี้ ส่งผลให้มีการใช้งานแบนด์วิดท์ของเครือข่ายอย่างมีประสิทธิภาพน้อยลง ซึ่งช่วยขัดขวางประโยชน์ด้านประสิทธิภาพอย่างเห็นได้ชัด ในภาพรวม ข้อมูล Chrome แสดงให้เห็นว่าอันที่จริงแล้ว HTTP2/Push ส่งผลลบสุทธิต่อประสิทธิภาพทั่วทั้งอินเทอร์เน็ต
ในทางตรงกันข้าม Early Hints มีประสิทธิภาพดีกว่าเพราะรวมความสามารถในการส่งคำตอบเบื้องต้นเข้ากับคำแนะนำที่ปล่อยให้เบราว์เซอร์ทำหน้าที่ดึงข้อมูลหรือเชื่อมต่อสิ่งที่ต้องใช้จริงๆ แม้ว่า Early Hints ไม่ได้ครอบคลุม Use Case ทั้งหมดที่ HTTP2/Push สามารถจัดการตามทฤษฎี แต่เราเชื่อว่า Early Hints เป็นโซลูชันที่ใช้งานได้ดีกว่าสำหรับการเร่งการนำทาง
ภาพขนาดย่อโดย Pierre Bamin