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

ดูวิธีที่เซิร์ฟเวอร์สามารถส่งคำแนะนำไปยังเบราว์เซอร์เกี่ยวกับทรัพยากรย่อยที่สำคัญ

คำแนะนำเบื้องต้นคืออะไร

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

รูปภาพแสดงช่วงเวลาที่เซิร์ฟเวอร์ประมวลผล 200 มิลลิวินาทีระหว่างการโหลดหน้าเว็บกับการโหลดทรัพยากรอื่นๆ
หากไม่มีคำแนะนำเบื้องต้น: ระบบจะบล็อกทุกอย่างในเซิร์ฟเวอร์เพื่อกำหนดวิธีตอบสนองสำหรับทรัพยากรหลัก

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

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

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

การเปรียบเทียบ 2 เว็บไซต์
การเปรียบเทียบก่อน/หลังการใช้คำแนะนำเบื้องต้นในเว็บไซต์ทดสอบที่ทําด้วย WebPageTest (Moto G4 - DSL)

วิธีใช้คำแนะนำเบื้องต้น

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

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

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

เมื่อใช้สิ่งเหล่านี้ใน HTML คุณมักจะต้อง preconnect หรือ preload ทรัพยากรที่ Preload Scanner จะไม่ค้นพบใน 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 นี้มีการอัปเดตบ่อยครั้ง และทรัพยากรหลักอยู่เวอร์ชันที่ 5 ข้างหน้า (abcd105) ของทรัพยากร CSS ที่คาดการณ์ (abcd100)

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

หลังจากผ่านไป 2-3 นาที

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
  • ขอบ: 103
  • Firefox: 120
  • Safari: 17.

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

การรองรับเบราว์เซอร์

  • Chrome: 103
  • Edge: 103
  • Firefox: 123
  • Safari: ไม่รองรับ

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

แผงเครือข่ายที่แสดงส่วนหัวของคำแนะนำเบื้องต้น ส่วนหัว
Early Hints Link จะแสดงในเครื่องมือสําหรับนักพัฒนาเว็บใน Chrome

หมายเหตุ หากต้องการใช้ทรัพยากรของคำแนะนำขั้นต้น คุณต้องไม่เลือก Disable cache ในเครื่องมือสำหรับนักพัฒนาซอฟต์แวร์ เนื่องจากคำแนะนำขั้นต้นใช้แคชของเบราว์เซอร์ สําหรับทรัพยากรที่โหลดไว้ล่วงหน้า initiator จะแสดงเป็น early-hints และsize จะแสดงเป็น (Disk cache)

แผงเครือข่ายที่แสดงคำแนะนำเบื้องต้น
ทรัพยากรที่มีการบอกใบ้ตั้งแต่เนิ่นๆ จะมีเงื่อนไขเริ่มต้น early-hints และโหลดจากแคชดิสก์

ซึ่งต้องใช้ใบรับรองที่เชื่อถือได้สำหรับการทดสอบ HTTPS ด้วย

Firefox (เวอร์ชัน 126) ไม่รองรับคำแนะนำเบื้องต้น 103 อย่างชัดเจนในเครื่องมือสำหรับนักพัฒนาซอฟต์แวร์ แต่ทรัพยากรที่โหลดโดยใช้คำแนะนำเบื้องต้นจะไม่แสดงข้อมูลส่วนหัว HTTP ซึ่งเป็นตัวบ่งชี้อย่างหนึ่งว่าทรัพยากรดังกล่าวโหลดผ่านคำแนะนำเบื้องต้น

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

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

เปิดใช้คำแนะนำก่อนแสดงโฆษณาอย่างง่ายดาย

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

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

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

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

นอกจากนี้ เราขอแนะนำให้ส่งคำแนะนำล่วงหน้าผ่านการเชื่อมต่อ HTTP/2 หรือ HTTP/3 เท่านั้น และเบราว์เซอร์ส่วนใหญ่จะยอมรับคำแนะนำเหล่านั้นผ่านโปรโตคอลเหล่านั้นเท่านั้น

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

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

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

ข้อจํากัดปัจจุบัน

ข้อจํากัดของคำแนะนำก่อนแสดงผลที่ติดตั้งใช้งานใน Chrome มีดังนี้

  • ใช้ได้กับคำขอการนําทางเท่านั้น (นั่นคือ ทรัพยากรหลักสําหรับเอกสารระดับบนสุด)
  • รองรับ preconnect และ preload เท่านั้น (ไม่รองรับ prefetch)
  • คำแนะนำเบื้องต้นตามด้วยการเปลี่ยนเส้นทางข้ามต้นทางในการตอบกลับสุดท้ายจะส่งผลให้ Chrome ลดทรัพยากรและการเชื่อมต่อที่ได้รับโดยใช้คำแนะนำเบื้องต้น
  • ทรัพยากรที่โหลดล่วงหน้าโดยใช้ Early Hints จะจัดเก็บไว้ในแคช HTTP และหน้าเว็บจะดึงข้อมูลจากแคชดังกล่าวในภายหลัง ดังนั้น เฉพาะทรัพยากรที่แคชได้เท่านั้นที่จะโหลดล่วงหน้าได้โดยใช้ Early Hints ไม่เช่นนั้นระบบจะดึงข้อมูลทรัพยากร 2 ครั้ง (1 ครั้งโดย Early Hints และอีก 1 ครั้งโดยเอกสาร) ใน Chrome ระบบจะปิดใช้แคช HTTP สำหรับใบรับรอง HTTPS ที่ไม่เชื่อถือ (แม้ว่าคุณจะโหลดหน้าเว็บต่อไป)
  • ระบบไม่รองรับการโหลดรูปภาพที่ปรับเปลี่ยนตามอุปกรณ์ล่วงหน้า (โดยใช้ imagesrcset, imagesizes หรือ media) โดยใช้ส่วนหัว HTTP <link> เนื่องจากระบบจะไม่กำหนดวิวพอร์ตจนกว่าจะมีการสร้างเอกสาร ซึ่งหมายความว่าจะใช้คำแนะนำขั้นต้น 103 เพื่อโหลดรูปภาพที่ปรับเปลี่ยนตามพื้นที่โฆษณาล่วงหน้าไม่ได้ และอาจโหลดรูปภาพที่ไม่ถูกต้องเมื่อใช้เพื่อวัตถุประสงค์นี้ โปรดดูการพูดคุยเกี่ยวกับข้อเสนอเกี่ยวกับวิธีจัดการเรื่องนี้ให้ดียิ่งขึ้น

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

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

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

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

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

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

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

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

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