การรองรับเบราว์เซอร์
ทีม Chrome ได้นำการแสดงผลทั้งหมดของหน้าในอนาคตที่ผู้ใช้มีแนวโน้มที่จะเข้าชมกลับมาแสดงผลอีกครั้ง
ประวัติโดยย่อของการแสดงผลล่วงหน้า
ที่ผ่านมา Chrome รองรับคำแนะนำทรัพยากร <link rel="prerender" href="/next-page">
แต่ก็ไม่ได้รองรับอย่างกว้างขวางนอกเหนือจาก Chrome และไม่ใช่ API ที่มีความชัดเจนอย่างมาก
เราเลิกใช้งานการแสดงผลล่วงหน้าเดิมนี้ที่ใช้คำแนะนำ rel=prerender
ของลิงก์แล้ว หันมาใช้การดึงข้อมูลล่วงหน้าแบบไม่มีสถานะแทน ซึ่งจะดึงข้อมูลทรัพยากรที่จําเป็นสําหรับหน้าเว็บในอนาคต แต่ไม่ได้แสดงผลหน้าเว็บล่วงหน้าอย่างเต็มรูปแบบหรือเรียกใช้ JavaScript การดึงข้อมูลล่วงหน้าแบบ NoState ช่วยปรับปรุงประสิทธิภาพหน้าเว็บโดยการปรับปรุงการโหลดทรัพยากร แต่จะไม่ได้ทำให้หน้าเว็บโหลดทันทีเหมือนการแสดงผลล่วงหน้าแบบเต็ม
ตอนนี้ทีม Chrome ได้คืนการแสดงผลล่วงหน้าอย่างเต็มรูปแบบใน Chrome อีกครั้งแล้ว กลไกการแสดงผลล่วงหน้าใหม่นี้จะไม่ใช้ไวยากรณ์ <link rel="prerender"...>
ซึ่งยังคงอยู่สำหรับ NoState Prefetch โดยคาดว่าจะเลิกใช้ขั้นตอนนี้ในอนาคตเพื่อหลีกเลี่ยงความยุ่งยากในการใช้งานที่มีอยู่และเพื่อให้สามารถขยายการแสดงผลล่วงหน้าในอนาคต
หน้าเว็บแสดงผลล่วงหน้าได้อย่างไร
หน้าเว็บสามารถแสดงผลล่วงหน้าได้ 4 วิธี ซึ่งทั้งหมดมีจุดประสงค์เพื่อทําให้ไปยังส่วนต่างๆ ได้เร็วขึ้น
- เมื่อคุณพิมพ์ URL ในแถบที่อยู่ของ Chrome (หรือที่เรียกว่า "แถบอเนกประสงค์") Chrome อาจแสดงผลหน้าเว็บล่วงหน้าให้คุณโดยอัตโนมัติ หากมีความมั่นใจสูงว่าคุณจะไปที่หน้านั้น โดยอิงตามประวัติการท่องเว็บก่อนหน้านี้
- เมื่อคุณใช้แถบบุ๊กมาร์ก Chrome อาจแสดงผลหน้าเว็บล่วงหน้าให้คุณโดยอัตโนมัติเมื่อคุณวางเคอร์เซอร์เหนือปุ่มบุ๊กมาร์กใดปุ่มหนึ่ง
- เมื่อคุณพิมพ์ข้อความค้นหาลงในแถบที่อยู่ของ Chrome แล้ว Chrome อาจแสดงผลหน้าผลการค้นหาล่วงหน้าโดยอัตโนมัติ หากเครื่องมือค้นหาสั่งให้ดำเนินการดังกล่าว
- เว็บไซต์สามารถใช้ Speculation Rules API เพื่อบอก Chrome โดยใช้โปรแกรมว่าให้แสดงผลหน้าเว็บใดก่อน ซึ่งจะแทนที่สิ่งที่
<link rel="prerender"...>
เคยทํา และช่วยให้เว็บไซต์แสดงผลหน้าเว็บล่วงหน้าได้แบบเชิงรุกตามกฎการคาดเดาในหน้า รายการเหล่านี้อาจอยู่ในหน้าเว็บแบบคงที่ หรือ JavaScript อาจแทรกรายการเหล่านี้แบบไดนามิกตามที่เจ้าของหน้าเว็บเห็นสมควร
ในแต่ละกรณีเหล่านี้ การแสดงผลล่วงหน้าจะทํางานราวกับว่าหน้าเว็บเปิดอยู่ในแท็บเบื้องหลังที่มองไม่เห็น จากนั้นจะ "เปิดใช้งาน" โดยแทนที่แท็บเบื้องหน้าด้วยหน้าเว็บที่แสดงผลล่วงหน้านั้น หากหน้าเว็บเปิดใช้งานก่อนที่จะแสดงผลล่วงหน้าจนเสร็จสมบูรณ์ สถานะปัจจุบันของหน้าเว็บจะเป็น "อยู่เบื้องหน้า" และโหลดต่อไป ซึ่งหมายความว่าคุณยังคงได้เปรียบในการเริ่มต้น
เนื่องจากหน้าเว็บที่แสดงผลล่วงหน้าเปิดอยู่ในสถานะซ่อนอยู่ API จํานวนหนึ่งที่ทําให้เกิดลักษณะการทํางานที่ไม่พึงประสงค์ (เช่น พรอมต์) จึงจะไม่เปิดใช้งานในสถานะนี้ และระบบจะเลื่อนเวลาให้จนกว่าหน้าเว็บจะเปิดใช้งาน ในกรณีที่ยังดำเนินการไม่ได้ ระบบจะยกเลิกการแสดงผลล่วงหน้า ทีม Chrome กำลังพยายามแสดงเหตุผลการยกเลิกการแสดงผลล่วงหน้าในรูปแบบ API รวมทั้งปรับปรุงความสามารถของเครื่องมือสำหรับนักพัฒนาเว็บเพื่อช่วยให้ระบุกรณี Edge ดังกล่าวได้ง่ายขึ้น
ผลกระทบของการแสดงผลล่วงหน้า
การแสดงผลล่วงหน้าช่วยให้หน้าเว็บโหลดเกือบจะทันทีตามที่แสดงในวิดีโอต่อไปนี้
ไซต์ตัวอย่างเป็นไซต์ที่รวดเร็วอยู่แล้ว แต่ถึงอย่างไรคุณก็สามารถเห็นได้ว่าการแสดงผลล่วงหน้าช่วยปรับปรุงประสบการณ์ของผู้ใช้ได้อย่างไร ด้วยเหตุนี้ การดำเนินการนี้จึงส่งผลโดยตรงต่อ Core Web Vitals ของเว็บไซต์ด้วย โดยจะมี LCP เกือบเป็น 0, CLS ลดลง (เนื่องจาก CLS ที่โหลดเกิดขึ้นก่อนการแสดงผลครั้งแรก) และ INP ดีขึ้น (เนื่องจากควรโหลดให้เสร็จสมบูรณ์ก่อนที่ผู้ใช้จะโต้ตอบ)
แม้ว่าหน้าเว็บจะเปิดใช้งานก่อนที่หน้าเว็บจะโหลดเสร็จสมบูรณ์ แต่การเริ่มต้นโหลดหน้าเว็บก่อนควรจะปรับปรุงประสบการณ์การโหลด เมื่อเปิดใช้งานลิงก์ขณะที่การแสดงผลล่วงหน้ายังคงเกิดขึ้น หน้าการแสดงผลล่วงหน้าจะย้ายไปยังเฟรมหลักและโหลดต่อ
อย่างไรก็ตาม การแสดงผลล่วงหน้าจะใช้หน่วยความจําและแบนด์วิดท์ของเครือข่ายเพิ่มเติม ระวังอย่าใช้การพรีเรนเดอร์มากเกินไปจนทำให้ทรัพยากรของผู้ใช้เสีย แสดงผลล่วงหน้าเฉพาะเมื่อมีความเป็นไปได้สูงที่ผู้ใช้จะไปยังหน้านั้น
ดูข้อมูลเพิ่มเติมเกี่ยวกับวิธีวัดผลกระทบต่อประสิทธิภาพจริงในข้อมูลวิเคราะห์ได้ที่ส่วนการวัดประสิทธิภาพ
ดูการคาดคะเนของแถบที่อยู่ของ Chrome
สำหรับ Use Case แรก คุณสามารถดูการคาดคะเน URL ของ Chrome ในหน้า chrome://predictors
ดังนี้
เส้นสีเขียวแสดงถึงความมั่นใจเพียงพอที่จะกระตุ้นการแสดงผลล่วงหน้า ในตัวอย่างนี้ การพิมพ์ "s" ให้ความเชื่อมั่นในระดับปานกลาง (สีเหลืองอำพัน) แต่เมื่อคุณพิมพ์ "sh" แล้ว Chrome มีความเชื่อมั่นมากพอว่าคุณมักจะไปยัง https://sheets.google.com
ภาพหน้าจอนี้ถ่ายจากการติดตั้ง Chrome ที่ค่อนข้างใหม่ และกรองการคาดคะเนที่มีความเชื่อมั่นเป็น 0 ออก แต่หากคุณดูตัวคาดคะเนของคุณเอง คุณอาจเห็นรายการมากขึ้น และอาจต้องใช้อักขระมากขึ้นเพื่อให้มีความเชื่อมั่นในระดับที่สูงพอ
ตัวแปรเหล่านี้ยังเป็นตัวขับเคลื่อนตัวเลือกที่แนะนำในแถบที่อยู่ที่คุณอาจสังเกตเห็นด้วย
Chrome จะอัปเดตตัวคาดการณ์อย่างต่อเนื่องตามการพิมพ์และการเลือกของคุณ
- สำหรับระดับความเชื่อมั่นมากกว่า 50% (แสดงเป็นสีเหลือง) Chrome จะเชื่อมต่อกับโดเมนล่วงหน้าอย่างสม่ำเสมอ แต่ไม่แสดงผลหน้าเว็บล่วงหน้า
- สำหรับระดับความเชื่อมั่นมากกว่า 80% (แสดงเป็นสีเขียว) Chrome จะแสดงผล URL ล่วงหน้า
Speculation Rules API
สําหรับตัวเลือกการเรียกใช้ข้อมูลพรอมต์ของ Speculation Rules API นักพัฒนาเว็บสามารถแทรกวิธีการ JSON ลงในหน้าเว็บเพื่อแจ้งให้เบราว์เซอร์ทราบเกี่ยวกับ URL ที่จะแสดงผลล่วงหน้าได้ ดังนี้
<script type="speculationrules">
{
"prerender": [
{
"urls": ["next.html", "next2.html"]
}
]
}
</script>
หรือตามกฎของเอกสาร (ใช้ได้ใน Chrome 121 ขึ้นไป) ซึ่งจะแสดงผลลิงก์ที่พบในเอกสารล่วงหน้าตามตัวเลือก href
(ตาม URL Pattern API) หรือตัวเลือก CSS ดังนี้
<script type="speculationrules">
{
"prerender": [{
"where": {
"and": [
{ "href_matches": "/*" },
{ "not": {"href_matches": "/wp-admin"}},
{ "not": {"href_matches": "/*\\?*(^|&)add-to-cart=*"}},
{ "not": {"selector_matches": ".do-not-prerender"}},
{ "not": {"selector_matches": "[rel~=nofollow]"}}
]
}
}]
}
</script>
ทีม Chrome ได้เตรียม Codelab กฎการคาดเดา ซึ่งจะแนะนำคุณเกี่ยวกับการเพิ่มกฎการคาดเดาลงในเว็บไซต์
ความกระตือรือร้น
การรองรับเบราว์เซอร์
การตั้งค่า eagerness
ใช้เพื่อระบุว่าควรเริ่มการคาดเดาเมื่อใด ซึ่งมีประโยชน์อย่างยิ่งสำหรับกฎเอกสาร
immediate
: ใช้เพื่อคาดเดาโดยเร็วที่สุด นั่นคือทันทีที่พบกฎการคาดเดาeager
: การตั้งค่านี้ทำงานเหมือนกับการตั้งค่าimmediate
แต่ในอนาคตเราอาจจัดให้อยู่ในระดับระหว่างimmediate
กับmoderate
moderate
: การดําเนินการนี้จะคาดเดาหากคุณวางเมาส์เหนือลิงก์เป็นเวลา 200 มิลลิวินาที (หรือในเหตุการณ์pointerdown
หากเร็วกว่า และในอุปกรณ์เคลื่อนที่ที่ไม่มีเหตุการณ์hover
)conservative
: ข้อมูลนี้คาดเดาจากเคอร์เซอร์หรือการแตะลง
eagerness
เริ่มต้นสำหรับกฎ list
รายการคือ immediate
คุณสามารถใช้ตัวเลือก moderate
และ conservative
เพื่อจํากัดกฎ list
ไว้เฉพาะ URL ที่ผู้ใช้โต้ตอบด้วยในรายการที่เฉพาะเจาะจง แต่ในกรณีส่วนใหญ่ กฎ document
ที่มีเงื่อนไข where
ที่เหมาะสมอาจเหมาะสมกว่า
eagerness
เริ่มต้นสำหรับกฎ document
รายการคือ conservative
เนื่องจากเอกสารหนึ่งๆ อาจประกอบด้วย URL หลายรายการ คุณจึงควรใช้ immediate
หรือ eager
สำหรับกฎ document
อย่างระมัดระวัง (ดูส่วนขีดจํากัดของ Chrome ถัดไป)
การตั้งค่า eagerness
ที่จะใช้จะขึ้นอยู่กับเว็บไซต์ของคุณ สําหรับเว็บไซต์แบบคงที่ที่มีน้ำหนักเบา การคาดการณ์อย่างกระตือรือร้นมากขึ้นอาจทําให้เสียค่าใช้จ่ายน้อยและเป็นประโยชน์ต่อผู้ใช้ เว็บไซต์ที่มีสถาปัตยกรรมที่ซับซ้อนมากขึ้นและเพย์โหลดของหน้าเว็บที่หนักกว่าอาจต้องการลดการสูญเสียโดยการคาดคะเนให้น้อยลงจนกว่าคุณจะได้รับสัญญาณเชิงบวกมากขึ้นเกี่ยวกับความตั้งใจจากผู้ใช้เพื่อจำกัดการสูญเสีย
ตัวเลือก moderate
เป็นตัวเลือกกลางๆ และเว็บไซต์จํานวนมากอาจได้รับประโยชน์จากกฎการคาดคะเนต่อไปนี้ที่จะแสดงผลลิงก์ล่วงหน้าเมื่อคุณวางเคอร์เซอร์เหนือลิงก์เป็นเวลา 200 มิลลิวินาทีหรือในเหตุการณ์ pointerdown เป็นการนํากฎการคาดคะเนไปใช้อย่างพื้นฐานแต่มีประสิทธิภาพ
<script type="speculationrules">
{
"prerender": [{
"where": {
"href_matches": "/*"
},
"eagerness": "moderate"
}]
}
</script>
ดึงข้อมูลล่วงหน้า
นอกจากนี้ คุณยังใช้กฎการคาดเดาเพื่อดึงข้อมูลหน้าเว็บล่วงหน้าได้โดยไม่ต้องแสดงผลล่วงหน้าอย่างเต็มรูปแบบ ซึ่งมักเป็นขั้นตอนแรกที่ดีบนเส้นทางสู่การแสดงผลล่วงหน้า
<script type="speculationrules">
{
"prefetch": [
{
"urls": ["next.html", "next2.html"]
}
]
}
</script>
ขีดจํากัดของ Chrome
Chrome มีขีดจํากัดเพื่อป้องกันการใช้ Speculation Rules API มากเกินไป ดังนี้
ความกระตือรือร้น | ดึงข้อมูลล่วงหน้า | การแสดงผลล่วงหน้า |
---|---|---|
immediate / eager |
50 | 10 |
moderate / conservative |
2 (FIFO) | 2 (FIFO) |
การตั้งค่า moderate
และ conservative
ซึ่งขึ้นอยู่กับการโต้ตอบของผู้ใช้จะทํางานในลักษณะ "เข้าก่อนออกก่อน" (FIFO) กล่าวคือ เมื่อถึงขีดจํากัด การคาดคะเนใหม่จะทําให้ระบบยกเลิกการคาดคะเนที่เก่าที่สุดและแทนที่ด้วยการคาดคะเนใหม่เพื่อประหยัดหน่วยความจํา การคาดเดาที่ยกเลิกไปแล้วสามารถเรียกให้แสดงอีกครั้งได้ เช่น โดยการวางเมาส์เหนือลิงก์นั้นอีกครั้ง ซึ่งจะทำให้ระบบคาดเดา URL นั้นอีกครั้งและลบการคาดเดาที่เก่าที่สุดออก ในกรณีนี้ การคาดคะเนก่อนหน้านี้จะแคชทรัพยากรที่แคชได้ไว้ในแคช HTTP สําหรับ URL นั้น การคาดคะเนอีกรอบจึงควรมีต้นทุนลดลง นี่คือเหตุผลที่เราตั้งขีดจำกัดไว้เป็นเกณฑ์ขั้นต่ำที่ 2 กฎรายการแบบคงที่จะไม่ทริกเกอร์จากการดําเนินการของผู้ใช้ จึงมีข้อจํากัดสูงกว่าเนื่องจากเบราว์เซอร์ไม่สามารถทราบว่าต้องการใช้กฎใดและเมื่อใด
ขีดจำกัดของ immediate
และ eager
เป็นแบบไดนามิกเช่นกัน ดังนั้นการนำองค์ประกอบสคริปต์ URL ของ list
ออกจะสร้างขีดจำกัดโดยการยกเลิกการคาดเดาที่นำออกไปแล้ว
นอกจากนี้ Chrome จะป้องกันไม่ให้ใช้การคาดการณ์ในบางเงื่อนไข ซึ่งรวมถึง
- ประหยัดอินเทอร์เน็ต
- โหมดประหยัดพลังงานเมื่อเปิดใช้และแบตเตอรี่เหลือน้อย
- ข้อจำกัดด้านหน่วยความจำ
- เมื่อปิดการตั้งค่า "โหลดหน้าเว็บล่วงหน้า" (ซึ่งเป็นการปิดอย่างชัดเจนโดยส่วนขยาย Chrome เช่น uBlock Origin)
- หน้าเว็บที่เปิดในแท็บพื้นหลัง
นอกจากนี้ Chrome จะไม่แสดง iframe แบบข้ามต้นทางในหน้าที่แสดงผลล่วงหน้าจนกว่าจะเปิดใช้งาน
เงื่อนไขทั้งหมดนี้มีจุดประสงค์เพื่อลดผลกระทบจากการคาดเดามากเกินไปเมื่อเป็นอันตรายต่อผู้ใช้
วิธีใส่กฎการคาดเดาในหน้าเว็บ
กฎการคาดการณ์สามารถรวมไว้ใน HTML ของหน้าเว็บแบบคงที่ หรือ JavaScript จะแทรกลงในหน้าแบบไดนามิกก็ได้
- กฎการคาดคะเนที่รวมไว้แบบคงที่: เช่น เว็บไซต์สื่อข่าวหรือบล็อกอาจแสดงผลบทความใหม่ล่าสุดล่วงหน้า หากเป็นการนำทางถัดไปที่ผู้ใช้ส่วนใหญ่มักใช้ หรือจะใช้กฎเอกสารที่มี
moderate
หรือconservative
เพื่อคาดคะเนเมื่อผู้ใช้โต้ตอบกับลิงก์ก็ได้ - กฎการคาดการณ์ที่แทรกแบบไดนามิก: กฎนี้อาจอิงตามตรรกะของแอปพลิเคชัน ปรับเปลี่ยนในแบบของผู้ใช้ หรืออิงตามการอนุมานอื่นๆ
ผู้ที่ชอบการแทรกแบบไดนามิกซึ่งอิงจากการดำเนินการ เช่น การวางเมาส์เหนือ หรือการคลิกลิงก์ ดังที่ไลบรารีเคยทำกับ <link rel=prefetch>
ในอดีต ขอแนะนำให้ดูกฎของเอกสาร เนื่องจากกฎเหล่านี้จะช่วยให้เบราว์เซอร์จัดการกรณีการใช้งานจำนวนมากได้
คุณสามารถเพิ่มกฎการคาดเดาใน <head>
หรือ <body>
ของเฟรมหลัก ระบบจะไม่ดําเนินการกับกฎการคาดเดาในเฟรมย่อย และระบบจะดําเนินการกับกฎการคาดเดาในหน้าที่แสดงผลล่วงหน้าก็ต่อเมื่อหน้านั้นเปิดใช้งานเท่านั้น
ส่วนหัว HTTP ของ Speculation-Rules
นอกจากนี้ คุณยังส่งกฎการคาดเดาได้โดยใช้ส่วนหัว Speculation-Rules
HTTP แทนการใส่ไว้ใน HTML ของเอกสารโดยตรง ซึ่งช่วยให้ CDN ติดตั้งใช้งานได้ง่ายขึ้นโดยไม่ต้องแก้ไขเนื้อหาเอกสารด้วยตนเอง
ระบบจะแสดงส่วนหัว HTTP Speculation-Rules
พร้อมเอกสารและชี้ไปยังตำแหน่งของไฟล์ JSON ที่มีกฎการคาดการณ์ ดังนี้
Speculation-Rules: "/speculationrules.json"
ทรัพยากรนี้ต้องใช้ประเภท MIME ที่ถูกต้อง และหากเป็นทรัพยากรข้ามแหล่งที่มา จะต้องผ่านการตรวจสอบ CORS
Content-Type: application/speculationrules+json
Access-Control-Allow-Origin: *
หากต้องการใช้ URL แบบสัมพัทธ์ คุณอาจต้องใส่คีย์ "relative_to": "document"
ไว้ในกฎการคาดคะเน มิฉะนั้น URL สัมพัทธ์จะสัมพันธ์กับ URL ของไฟล์ JSON ของกฎการคาดเดา ซึ่งอาจมีประโยชน์อย่างยิ่งในกรณีที่คุณต้องเลือกลิงก์จากแหล่งที่มาเดียวกันบางรายการหรือทั้งหมด
กฎการคาดเดาและ SPA
ระบบรองรับกฎการคาดเดาสําหรับการนําทางหน้าเว็บแบบเต็มซึ่งจัดการโดยเบราว์เซอร์เท่านั้น และไม่รองรับสําหรับแอปหน้าเว็บเดียว (SPA) หรือหน้า app shell สถาปัตยกรรมเหล่านี้ไม่ใช้การดึงข้อมูลเอกสาร แต่สร้าง API หรือการดึงข้อมูลหรือหน้าเว็บบางส่วนแทน ซึ่งจะนำไปประมวลผลและนำเสนอในหน้าปัจจุบัน แอปสามารถเรียกข้อมูลที่จำเป็นสำหรับ "การนําทางแบบเบา" เหล่านี้ล่วงหน้านอกกฎการคาดเดาได้ แต่จะไม่สามารถแสดงผลล่วงหน้า
กฎการคาดคะเนสามารถใช้เพื่อแสดงผลแอปพลิเคชันจากหน้าก่อนหน้าล่วงหน้า ซึ่งจะช่วยชดเชยค่าใช้จ่ายในการโหลดครั้งแรกเพิ่มเติมที่ SPA บางรายการมี อย่างไรก็ตาม การเปลี่ยนแปลงเส้นทางภายในแอปจะไม่สามารถแสดงผลล่วงหน้าได้
แก้ไขข้อบกพร่องของกฎการคาดเดา
ดูฟีเจอร์ใหม่ของเครื่องมือสำหรับนักพัฒนาเว็บใน Chrome ได้ที่โพสต์เฉพาะเรื่องการแก้ไขข้อบกพร่องของกฎการคาดคะเน ซึ่งจะช่วยในการดูและแก้ไขข้อบกพร่องของ API ใหม่นี้
กฎการคาดเดาหลายรายการ
คุณสามารถเพิ่มกฎการคาดเดาหลายกฎลงในหน้าเดียวกัน แล้วผนวกกฎที่มีอยู่ ดังนั้น วิธีการต่างๆ ต่อไปนี้จึงส่งผลให้ทั้ง one.html
และ two.html
แสดงผลก่อนโหลด
รายการ URL:
<script type="speculationrules">
{
"prerender": [
{
"urls": ["one.html", "two.html"]
}
]
}
</script>
สคริปต์ speculationrules
หลายรายการ:
<script type="speculationrules">
{
"prerender": [
{
"urls": ["one.html"]
}
]
}
</script>
<script type="speculationrules">
{
"prerender": [
{
"urls": ["two.html"]
}
]
}
</script>
หลายรายการภายใน speculationrules
1 ชุด
<script type="speculationrules">
{
"prerender": [
{
"urls": ["one.html"]
},
{
"urls": ["two.html"]
}
]
}
</script>
ทีมสนับสนุนของ No-Vary-Search
เมื่อทำการเตรียมข้อมูลล่วงหน้าหรือแสดงผลหน้าเว็บล่วงหน้า พารามิเตอร์ของ URL บางรายการ (ในทางเทคนิคเรียกว่าพารามิเตอร์การค้นหา) อาจไม่สำคัญต่อหน้าที่เซิร์ฟเวอร์แสดงจริง และ JavaScript ฝั่งไคลเอ็นต์เท่านั้นที่ใช้
เช่น Google Analytics ใช้พารามิเตอร์ UTM เพื่อวัดแคมเปญ แต่โดยปกติแล้วจะไม่ทําให้เซิร์ฟเวอร์แสดงหน้าเว็บอื่น ซึ่งหมายความว่า page1.html?utm_content=123
และ page1.html?utm_content=456
จะแสดงหน้าเดียวกันจากเซิร์ฟเวอร์ จึงนําหน้าเดียวกันมาใช้ซ้ำจากแคชได้
ในทํานองเดียวกัน แอปพลิเคชันอาจใช้พารามิเตอร์ URL อื่นๆ ที่จัดการเฉพาะฝั่งไคลเอ็นต์
ข้อเสนอ No-Vary-Search ทำให้เซิร์ฟเวอร์สามารถระบุพารามิเตอร์ที่ไม่สร้างความแตกต่างกับทรัพยากรที่นำส่ง ดังนั้นอนุญาตให้เบราว์เซอร์นำเอกสารเวอร์ชันที่แคชไว้ก่อนหน้านี้มาใช้ซ้ำซึ่งเพียงแค่พารามิเตอร์เหล่านี้ต่างกันเท่านั้น การดำเนินการนี้ใช้ได้ใน Chrome (และเบราว์เซอร์ที่ใช้ Chromium) สำหรับการคาดคะเนการนําทางในการโหลดล่วงหน้า (แม้ว่าเราจะพยายามรองรับการดำเนินการนี้สําหรับการแสดงผลล่วงหน้าด้วย)
กฎการคาดเดารองรับการใช้ expects_no_vary_search
เพื่อระบุตำแหน่งที่คาดว่าระบบจะแสดงผลส่วนหัว HTTP ของ No-Vary-Search
ซึ่งจะช่วยหลีกเลี่ยงการดาวน์โหลดที่ไม่จำเป็นได้มากขึ้น
<script type="speculationrules">
{
"prefetch": [{
"urls": ["/products*"],
"expects_no_vary_search": "params=(\"id\")"
}]
}
</script>
<a href="/products?id=123">Product 123</a>
<a href="/products?id=124">Product 124</a>
ในตัวอย่างนี้ HTML ของหน้าเริ่มต้น /products
เหมือนกันสำหรับทั้งรหัสผลิตภัณฑ์ 123
และ 124
อย่างไรก็ตาม เนื้อหาของหน้าเว็บจะแตกต่างกันไปตามการแสดงผลฝั่งไคลเอ็นต์ที่ใช้ JavaScript เพื่อดึงข้อมูลผลิตภัณฑ์โดยใช้พารามิเตอร์การค้นหา id
เราจึงทำการเตรียม URL นั้นไว้ล่วงหน้าและ URL ควรแสดงผลส่วนหัว HTTP No-Vary-Search
ที่ระบุว่าหน้าเว็บสามารถใช้กับพารามิเตอร์การค้นหา id
ใดก็ได้
อย่างไรก็ตาม หากผู้ใช้คลิกลิงก์ใดลิงก์หนึ่งก่อนที่การโหลดล่วงหน้าจะเสร็จสมบูรณ์ เบราว์เซอร์อาจไม่ได้รับหน้า /products
ในกรณีนี้ เบราว์เซอร์จะไม่ทราบว่าจะมีส่วนหัว HTTP No-Vary-Search
หรือไม่ จากนั้นเบราว์เซอร์จะมีตัวเลือกว่าจะดึงข้อมูลลิงก์อีกครั้งหรือรอให้ระบบทำการเตรียมข้อมูลล่วงหน้าจนเสร็จสมบูรณ์เพื่อดูว่าลิงก์มีส่วนหัว HTTP ของ No-Vary-Search
หรือไม่ การตั้งค่า expects_no_vary_search
ช่วยให้เบราว์เซอร์ทราบว่าการตอบสนองของหน้าเว็บควรมีส่วนหัว HTTP No-Vary-Search
และรอให้การดึงข้อมูลล่วงหน้านั้นเสร็จสมบูรณ์
ข้อจำกัดของกฎการคาดเดาและการปรับปรุงในอนาคต
กฎการคาดเดาจะจำกัดไว้เฉพาะหน้าเว็บที่เปิดในแท็บเดียวกัน แต่เรากำลังพยายามลดข้อจำกัดดังกล่าว
โดยค่าเริ่มต้น การคาดคะเนจะจํากัดไว้ที่หน้าเว็บที่มีแหล่งที่มาเดียวกัน การคาดเดาหน้าแบบข้ามต้นทางในเว็บไซต์เดียวกัน (เช่น https://a.example.com
อาจแสดงผลหน้าเว็บล่วงหน้าใน https://b.example.com
) หากต้องการใช้หน้าที่คาดเดานี้ (ในตัวอย่างนี้ https://b.example.com
) จำเป็นต้องเลือกใช้โดยรวมส่วนหัว HTTP ของ Supports-Loading-Mode: credentialed-prerender
มิเช่นนั้น Chrome จะยกเลิกการคาดคะเน
เวอร์ชันในอนาคตอาจอนุญาตการแสดงผลล่วงหน้าสำหรับหน้าเว็บแบบข้ามต้นทางที่ไม่ใช่เว็บไซต์เดียวกัน ตราบใดที่ไม่มีคุกกี้สําหรับหน้าที่แสดงผลล่วงหน้า และหน้าที่แสดงผลล่วงหน้าเลือกใช้ส่วนหัว HTTP ของ Supports-Loading-Mode: uncredentialed-prerender
ที่คล้ายกัน
กฎการคาดคะเนรองรับการเรียกข้อมูลล่วงหน้าข้ามแหล่งที่มาอยู่แล้ว แต่อีกครั้งเฉพาะในกรณีที่ไม่มีคุกกี้สําหรับโดเมนข้ามแหล่งที่มา หากมีคุกกี้จากผู้ใช้ที่เคยเข้าชมเว็บไซต์นั้นมาก่อน ระบบจะไม่ทริกเกอร์การคาดคะเนและจะแสดงข้อผิดพลาดในเครื่องมือสำหรับนักพัฒนาซอฟต์แวร์
จากข้อจำกัดในปัจจุบัน รูปแบบหนึ่งที่สามารถปรับปรุงประสบการณ์ของผู้ใช้สำหรับทั้งลิงก์ภายในและลิงก์ภายนอกเมื่อเป็นไปได้คือ การแสดงผล URL ต้นทางเดียวกันล่วงหน้าและพยายามดึงข้อมูล URL แบบข้ามต้นทางล่วงหน้า
<script type="speculationrules">
{
"prerender": [
{
"where": { "href_matches": "/*" },
"eagerness": "moderate"
}
],
"prefetch": [
{
"where": { "not": { "href_matches": "/*" } },
"eagerness": "moderate"
}
]
}
</script>
โดยค่าเริ่มต้น ข้อจำกัดเพื่อป้องกันการคาดเดาข้ามต้นทางสำหรับลิงก์ข้ามต้นทางนั้นจำเป็นต่อความปลอดภัย การดำเนินการนี้เป็นการปรับปรุงจาก <link rel="prefetch">
สำหรับปลายทางข้ามแหล่งที่มา ซึ่งจะไม่ส่งคุกกี้เช่นกัน แต่ยังคงพยายามทำการเตรียมข้อมูลล่วงหน้า ซึ่งจะส่งผลให้เกิดการเตรียมข้อมูลล่วงหน้าที่สูญเปล่าซึ่งต้องส่งอีกครั้ง หรือที่แย่กว่านั้นคือการโหลดหน้าเว็บที่ไม่ถูกต้อง
ระบบไม่รองรับกฎการคาดคะเนสําหรับการเรียกข้อมูลล่วงหน้าสําหรับหน้าที่ Service Worker ควบคุม เรากำลังดำเนินการเพิ่มการรองรับนี้ ติดตามข้อมูลอัปเดตเกี่ยวกับปัญหาเกี่ยวกับ Service Worker ได้ที่ส่วนนี้ ระบบรองรับการแสดงผลล่วงหน้าสําหรับหน้าที่ควบคุมโดย Service Worker
รองรับ Detect Speculation Rules API
คุณสามารถตรวจหาการรองรับ Speculation Rules API ด้วยการตรวจสอบ HTML มาตรฐาน ดังนี้
if (HTMLScriptElement.supports && HTMLScriptElement.supports('speculationrules')) {
console.log('Your browser supports the Speculation Rules API.');
}
เพิ่มกฎการคาดเดาแบบไดนามิกผ่าน JavaScript
ต่อไปนี้คือตัวอย่างของการเพิ่มกฎการคาดเดา prerender
ด้วย JavaScript
if (HTMLScriptElement.supports &&
HTMLScriptElement.supports('speculationrules')) {
const specScript = document.createElement('script');
specScript.type = 'speculationrules';
specRules = {
prerender: [
{
urls: ['/next.html'],
},
],
};
specScript.textContent = JSON.stringify(specRules);
console.log('added speculation rules to: next.html');
document.body.append(specScript);
}
คุณดูการสาธิตการแสดงผลล่วงหน้าของ Speculation Rules API โดยใช้การแทรก JavaScript ได้ในหน้าสาธิตการแสดงผลล่วงหน้านี้
การวางองค์ประกอบ <script type = "speculationrules">
ลงใน DOM โดยตรงโดยใช้ innerHTML
จะไม่ลงทะเบียนกฎการคาดการณ์ เพื่อเหตุผลด้านความปลอดภัย และต้องเพิ่มกฎนี้ตามที่แสดงไว้ก่อนหน้านี้ อย่างไรก็ตาม เนื้อหาที่แทรกแบบไดนามิกโดยใช้ innerHTML
ซึ่งมีลิงก์ใหม่จะได้รับการคัดสรรโดยกฎที่มีอยู่ในหน้า
ในทํานองเดียวกัน การแก้ไขแผงองค์ประกอบในเครื่องมือสําหรับนักพัฒนาเว็บใน Chrome โดยตรงเพื่อเพิ่มองค์ประกอบ <script type = "speculationrules">
จะไม่ลงทะเบียนกฎการคาดคะเน แต่จะต้องมีการเรียกใช้สคริปต์เพื่อเพิ่มองค์ประกอบนี้ลงใน DOM แบบไดนามิกจากคอนโซลเพื่อแทรกกฎ
เพิ่มกฎการคาดเดาผ่านเครื่องมือจัดการแท็ก
หากต้องการเพิ่มกฎการคาดการณ์โดยใช้เครื่องมือจัดการแท็ก เช่น Google Tag Manager (GTM) จะต้องแทรกกฎเหล่านี้ผ่าน JavaScript แทนการเพิ่มองค์ประกอบ <script type = "speculationrules">
ผ่าน GTM โดยตรงด้วยเหตุผลเดียวกันกับที่กล่าวไว้ก่อนหน้านี้
โปรดทราบว่าตัวอย่างนี้ใช้ var
เนื่องจาก GTM ไม่รองรับ const
ยกเลิกกฎการคาดเดา
การนำกฎการคาดเดาออกจะทำให้ระบบยกเลิกการแสดงผลล่วงหน้า แต่เมื่อถึงเวลาดังกล่าว ระบบก็อาจใช้ทรัพยากรเพื่อเริ่มการแสดงผลล่วงหน้าไปแล้ว เราจึงขอแนะนำให้ไม่แสดงผลล่วงหน้าหากมีแนวโน้มว่าจะต้องยกเลิกการแสดงผลล่วงหน้า
กฎเกี่ยวกับการคาดเดาและนโยบายความปลอดภัยของเนื้อหา
เนื่องจากกฎการคาดเดาใช้เอลิเมนต์ <script>
แม้ว่าจะมีเฉพาะ JSON เท่านั้น กฎดังกล่าวจึงต้องรวมอยู่ในContent-Security-Policyของ script-src
หากเว็บไซต์ใช้พารามิเตอร์นี้ ไม่ว่าจะโดยใช้แฮชหรือค่า Nonce
คุณสามารถเพิ่ม inline-speculation-rules
ใหม่ลงใน script-src
เพื่อรองรับองค์ประกอบ <script type="speculationrules">
ที่แทรกจากแฮชหรือสคริปต์ที่มี Nonce ซึ่งไม่รองรับกฎที่รวมอยู่ใน HTML เริ่มต้น ดังนั้น JavaScript จึงต้องแทรกกฎสําหรับเว็บไซต์ที่ใช้ CSP แบบเข้มงวด
ตรวจหาและปิดใช้การแสดงผลล่วงหน้า
การแสดงผลล่วงหน้ามักเป็นประสบการณ์ที่ดีสำหรับผู้ใช้ เนื่องจากช่วยให้แสดงผลหน้าเว็บได้อย่างรวดเร็วซึ่งมักจะเป็นแบบทันที ซึ่งจะเป็นประโยชน์ทั้งต่อผู้ใช้และเจ้าของเว็บไซต์ เนื่องจากหน้าเว็บที่แสดงผลล่วงหน้าช่วยให้ผู้ใช้ได้รับประสบการณ์การใช้งานที่ดีขึ้น ซึ่งอาจทำได้ยากหากไม่ใช้วิธีนี้
อย่างไรก็ตาม อาจมีบางกรณีที่คุณไม่ต้องการให้หน้าเว็บแสดงผลล่วงหน้า เช่น เมื่อหน้าเว็บเปลี่ยนสถานะโดยอิงตามคำขอเริ่มต้นหรืออิงตาม JavaScript ที่ทำงานในหน้า
เปิดและปิดใช้การแสดงผลล่วงหน้าใน Chrome
ระบบจะเปิดใช้การแสดงผลล่วงหน้าสำหรับผู้ใช้ Chrome ที่มีการตั้งค่า "โหลดหน้าเว็บล่วงหน้า" ใน chrome://settings/performance/
เท่านั้น นอกจากนี้ จะมีการปิดใช้การแสดงผลล่วงหน้าในอุปกรณ์ที่มีหน่วยความจำต่ำ หรือหากระบบปฏิบัติการอยู่ในโหมดประหยัดอินเทอร์เน็ตหรือโหมดประหยัดพลังงาน โปรดดูส่วนขีดจํากัดของ Chrome
ตรวจหาและปิดใช้การแสดงผลล่วงหน้าฝั่งเซิร์ฟเวอร์
ระบบจะส่งหน้าที่แสดงผลล่วงหน้าพร้อมส่วนหัว HTTP Sec-Purpose
:
Sec-Purpose: prefetch;prerender
หน้าเว็บที่ดึงข้อมูลล่วงหน้าโดยใช้ Speculation Rules API จะมีการตั้งค่าส่วนหัวนี้เป็น prefetch
เท่านั้น
Sec-Purpose: prefetch
เซิร์ฟเวอร์สามารถตอบกลับตามส่วนหัวนี้เพื่อบันทึกคำขอคาดการณ์ แสดงเนื้อหาอื่น หรือป้องกันไม่ให้เกิดการแสดงผลล่วงหน้า หากมีการส่งคืนโค้ดตอบกลับสุดท้ายที่ไม่สำเร็จ ซึ่งก็คือไม่ได้อยู่ในช่วง 200-299 หลังการเปลี่ยนเส้นทาง ระบบจะไม่แสดงผลหน้าเว็บล่วงหน้าและระบบจะทิ้งหน้าที่ดึงข้อมูลล่วงหน้าไป นอกจากนี้ โปรดทราบว่าการตอบกลับ 204 และ 205 จะใช้ไม่ได้กับการแสดงผลล่วงหน้า แต่จะใช้กับการโหลดล่วงหน้าได้
หากไม่ต้องการให้แสดงผลหน้าเว็บใดหน้าหนึ่งล่วงหน้า การคืนค่ารหัสการตอบกลับที่ไม่ใช่ 2XX (เช่น 503) เป็นวิธีที่ดีที่สุดในการป้องกันการแสดงผลล่วงหน้า อย่างไรก็ตาม เราขอแนะนำให้อนุญาตการแสดงผลล่วงหน้าแทน แต่ให้เลื่อนการดำเนินการใดๆ ที่ควรเกิดขึ้นเมื่อมีการดูหน้าเว็บจริงๆ โดยใช้ JavaScript
ตรวจหาการแสดงผลก่อนการโหลดใน JavaScript
document.prerendering
API จะแสดงผล true
ขณะที่หน้าเว็บแสดงผลล่วงหน้า หน้าเว็บสามารถใช้แอตทริบิวต์นี้เพื่อป้องกันหรือเลื่อนเวลากิจกรรมบางอย่างระหว่างการประมวลผลล่วงหน้าจนกว่าหน้าเว็บจะเปิดใช้งานจริง
เมื่อเปิดใช้งานเอกสารที่แสดงผลล่วงหน้าแล้ว ระบบจะตั้งค่า activationStart
ของ PerformanceNavigationTiming
เป็นเวลาที่ไม่ใช่ 0 ซึ่งแสดงถึงเวลาระหว่างที่เริ่มแสดงผลล่วงหน้าและเปิดใช้งานเอกสารจริง
คุณอาจมีฟังก์ชันเพื่อตรวจสอบหน้าแสดงผลล่วงหน้าและแสดงผลล่วงหน้า ดังนี้
function pagePrerendered() {
return (
document.prerendering ||
self.performance?.getEntriesByType?.('navigation')[0]?.activationStart > 0
);
}
วิธีที่ง่ายที่สุดในการดูว่าหน้าเว็บมีการแสดงผลล่วงหน้าหรือไม่ (ไม่ว่าจะแสดงแบบเต็มหรือบางส่วน) คือการเปิดเครื่องมือสำหรับนักพัฒนาเว็บหลังจากที่เปิดใช้งานหน้าแล้วพิมพ์ performance.getEntriesByType('navigation')[0].activationStart
ในคอนโซล หากระบบแสดงค่าที่ไม่ใช่ 0 คุณจะทราบว่าหน้าเว็บมีการแสดงผลล่วงหน้าแล้ว
เมื่อผู้ใช้ดูหน้าเว็บ ระบบจะเปิดใช้งานหน้าเว็บและส่งเหตุการณ์ prerenderingchange
ใน document
ซึ่งสามารถใช้เพื่อเปิดใช้กิจกรรมที่ก่อนหน้านี้จะเริ่มต้นโดยค่าเริ่มต้นเมื่อโหลดหน้าเว็บ แต่คุณต้องการเลื่อนเวลาออกไปจนกว่าผู้ใช้จะดูหน้าเว็บจริงๆ
การใช้ API เหล่านี้จะทำให้ JavaScript ฟรอนท์เอนด์สามารถตรวจจับและดำเนินการกับหน้าที่แสดงผลล่วงหน้าอย่างเหมาะสม
ผลกระทบต่อข้อมูลวิเคราะห์
Analytics ใช้เพื่อวัดการใช้งานเว็บไซต์ เช่น ใช้ Google Analytics เพื่อวัดการดูหน้าเว็บและเหตุการณ์ หรือวัดเมตริกประสิทธิภาพของหน้าเว็บโดยใช้การตรวจสอบผู้ใช้จริง (RUM)
หน้าเว็บควรแสดงผลล่วงหน้าเฉพาะในกรณีที่มีแนวโน้มสูงที่ผู้ใช้จะโหลดหน้าเว็บ ด้วยเหตุนี้ ตัวเลือกการแสดงผลล่วงหน้าของแถบที่อยู่ของ Chrome จึงจะเกิดขึ้นก็ต่อเมื่อมีแนวโน้มสูงมาก (มากกว่า 80% ของเวลา)
อย่างไรก็ตาม โดยเฉพาะเมื่อใช้ Speculation Rules API หน้าเว็บที่แสดงผลล่วงหน้าอาจส่งผลต่อข้อมูลวิเคราะห์ และเจ้าของเว็บไซต์อาจต้องเพิ่มโค้ดเพิ่มเติมเพื่อเปิดใช้ข้อมูลวิเคราะห์สําหรับหน้าเว็บที่แสดงผลล่วงหน้าเท่านั้นเมื่อเปิดใช้งาน เนื่องจากผู้ให้บริการข้อมูลวิเคราะห์บางรายอาจไม่ทําเช่นนี้โดยค่าเริ่มต้น
ซึ่งทำได้โดยใช้ Promise
ที่รอเหตุการณ์ prerenderingchange
หากเอกสารกำลังแสดงผลล่วงหน้า หรือแสดงผลทันทีหากกำลังแสดงผล
// Set up a promise for when the page is activated,
// which is needed for prerendered pages.
const whenActivated = new Promise((resolve) => {
if (document.prerendering) {
document.addEventListener('prerenderingchange', resolve, {once: true});
} else {
resolve();
}
});
async function initAnalytics() {
await whenActivated;
// Initialise your analytics
}
initAnalytics();
อีกวิธีหนึ่งคือเลื่อนเวลากิจกรรมการวิเคราะห์จนกว่าหน้าเว็บจะปรากฏขึ้นเป็นครั้งแรก ซึ่งจะครอบคลุมทั้งกรณีที่แสดงผลก่อนการโหลดและเมื่อเปิดแท็บในเบื้องหลัง (เช่น คลิกขวาแล้วเปิดในแท็บใหม่)
// Set up a promise for when the page is first made visible
const whenFirstVisible = new Promise((resolve) => {
if (document.hidden) {
document.addEventListener('visibilitychange', resolve, {once: true});
} else {
resolve();
}
});
async function initAnalytics() {
await whenFirstVisible;
// Initialise your analytics
}
initAnalytics();
แม้ว่าวิธีนี้อาจเหมาะกับข้อมูลวิเคราะห์และกรณีการใช้งานที่คล้ายกัน แต่ในกรณีอื่นๆ คุณอาจต้องการโหลดเนื้อหาเพิ่มเติมสําหรับกรณีเหล่านั้น จึงอาจต้องใช้ document.prerendering
และ prerenderingchange
เพื่อกําหนดเป้าหมายหน้าเว็บการแสดงผลล่วงหน้าโดยเฉพาะ
ระงับเนื้อหาอื่นๆ ระหว่างการแสดงผลก่อนเผยแพร่
คุณสามารถใช้ API เดียวกันกับที่กล่าวถึงก่อนหน้านี้เพื่อระงับเนื้อหาอื่นๆ ไว้ในระหว่างระยะการแสดงผลก่อนการประมวลผล ซึ่งอาจเป็นบางส่วนของ JavaScript หรือองค์ประกอบสคริปต์ทั้งหมดที่คุณไม่ต้องการให้ทํางานในระยะก่อนแสดงผล
ตัวอย่างเช่น ใช้สคริปต์นี้
<script src="https://example.com/app/script.js" async></script>
คุณสามารถเปลี่ยนการตั้งค่านี้เป็นเอลิเมนต์สคริปต์ที่แทรกแบบไดนามิกซึ่งจะแทรกโดยอิงตามฟังก์ชัน whenActivated
ก่อนหน้านี้เท่านั้นได้ ดังนี้
async function addScript(scriptUrl) {
await whenActivated;
const script = document.createElement('script');
script.src = 'scriptUrl';
document.body.appendChild(script);
}
addScript('https://example.com/app/script.js');
ซึ่งอาจมีประโยชน์ในการระงับสคริปต์ที่แตกต่างกันซึ่งมีข้อมูลวิเคราะห์ หรือแสดงผลเนื้อหาตามสถานะหรือตัวแปรอื่นๆ ที่เปลี่ยนแปลงได้ในระหว่างการเข้าชม ตัวอย่างเช่น ระบบระงับคำแนะนำ สถานะการเข้าสู่ระบบ หรือไอคอนรถเข็นช็อปปิ้งทั้งหมดเพื่อให้แน่ใจว่าจะแสดงข้อมูลที่เป็นปัจจุบันที่สุด
แม้ว่ากรณีนี้อาจมีแนวโน้มที่จะเกิดขึ้นบ่อยกว่าเมื่อใช้การแสดงผลล่วงหน้า แต่เงื่อนไขเหล่านี้ก็เป็นจริงสําหรับหน้าที่โหลดในแท็บที่อยู่เบื้องหลังซึ่งกล่าวถึงก่อนหน้านี้ด้วย (ดังนั้นจึงสามารถใช้ฟังก์ชัน whenFirstVisible
แทน whenActivated
ได้)
ในหลายกรณี ควรตรวจสอบการเปลี่ยนแปลงโดยทั่วไปของ visibilitychange
ด้วย เช่น เมื่อกลับไปยังหน้าที่แสดงเบื้องหลัง ควรอัปเดตจำนวนสินค้าล่าสุดในตะกร้าโดยตัวนับในรถเข็นช็อปปิ้ง ดังนั้นนี่จึงไม่ใช่ปัญหาเฉพาะของการแสดงผลล่วงหน้า แต่การแสดงผลล่วงหน้าทำให้ปัญหาที่มีอยู่ชัดเจนขึ้น
วิธีหนึ่งที่ Chrome ช่วยลดความจำเป็นในการรวมสคริปต์หรือฟังก์ชันบางอย่างด้วยตนเองได้ นั่นก็คือ API บางอย่างถูกระงับไว้ตามที่กล่าวไปแล้วก่อนหน้านี้ และ iframe ของบุคคลที่สามจะไม่แสดงผล จึงเป็นเพียงเนื้อหานอกเหนือจากนี้ซึ่งจำเป็นที่จะต้องระงับด้วยตนเอง
วัดประสิทธิภาพ
สําหรับการวัดเมตริกประสิทธิภาพ ข้อมูลวิเคราะห์ควรพิจารณาว่าควรวัดเมตริกเหล่านี้ตามเวลาการเปิดใช้งานแทนเวลาในการโหลดหน้าเว็บที่ API ของเบราว์เซอร์จะรายงานหรือไม่
สำหรับ Core Web Vitals ที่ Chrome วัดผ่านรายงานประสบการณ์ของผู้ใช้ Chrome ข้อมูลเหล่านี้มีไว้เพื่อวัดประสบการณ์ของผู้ใช้ ดังนั้นเมตริกเหล่านี้จึงวัดตามเวลาการเปิดใช้งาน ซึ่งมักจะส่งผลให้ LCP เป็น 0 วินาที เช่น การแสดงให้เห็นว่านี่เป็นวิธีที่ดีในการปรับปรุง Core Web Vitals
ตั้งแต่เวอร์ชัน 3.1.0 เป็นต้นไป ไลบรารี web-vitals
ได้รับการอัปเดตให้จัดการการนําทางที่แสดงผลล่วงหน้าในลักษณะเดียวกับที่ Chrome วัด Core Web Vitals เวอร์ชันนี้ยังแจ้งการนําทางที่แสดงผลล่วงหน้าสําหรับเมตริกเหล่านั้นในแอตทริบิวต์ Metric.navigationType
ด้วยหากหน้าเว็บแสดงผลล่วงหน้าทั้งหมดหรือบางส่วน
วัดการแสดงผลล่วงหน้า
คุณดูได้ว่าหน้าเว็บได้รับการแสดงผลล่วงหน้าหรือไม่จากรายการ activationStart
ของ PerformanceNavigationTiming
ที่ไม่ใช่ 0 จากนั้นบันทึกข้อมูลนี้โดยใช้มิติข้อมูลที่กําหนดเอง หรือคล้ายกันเมื่อบันทึกการดูหน้าเว็บ เช่น โดยใช้ฟังก์ชัน pagePrerendered
ที่อธิบายไว้ก่อนหน้านี้
// Set Custom Dimension for Prerender status
gtag('set', { 'dimension1': pagePrerendered() });
// Initialise GA - including sending page view by default
gtag('config', 'G-12345678-1');
ซึ่งจะช่วยให้ข้อมูลวิเคราะห์แสดงจํานวนการนําทางที่แสดงผลล่วงหน้าเมื่อเทียบกับการนําทางประเภทอื่นๆ และช่วยให้คุณเชื่อมโยงเมตริกประสิทธิภาพหรือเมตริกธุรกิจกับการนําทางประเภทต่างๆ เหล่านี้ได้ หน้าเว็บที่โหลดเร็วขึ้นทำให้ผู้ใช้พึงพอใจมากขึ้น ซึ่งมักจะส่งผลต่อตัวชี้วัดทางธุรกิจอย่างแท้จริงดังที่กรณีศึกษาของเราแสดงให้เห็น
เมื่อวัดผลลัพธ์ทางธุรกิจของการแสดงผลหน้าเว็บล่วงหน้าเพื่อการนําทางทันที คุณจะตัดสินใจได้ว่าควรลงทุนเพิ่มเติมในการใช้เทคโนโลยีนี้เพื่อให้ระบบแสดงผลหน้าเว็บสำหรับการนําทางล่วงหน้ามากขึ้น หรือจะตรวจสอบสาเหตุที่ระบบไม่แสดงผลหน้าเว็บล่วงหน้า
วัดอัตรา Hit
นอกจากการวัดผลของหน้าเว็บที่มีการเข้าชมหลังจากการแสดงผลล่วงหน้าแล้ว สิ่งสำคัญอีกอย่างหนึ่งคือการวัดหน้าเว็บที่แสดงผลล่วงหน้าและไม่ได้เข้าชมในภายหลัง ซึ่งอาจหมายความว่าคุณแสดงผลล่วงหน้ามากเกินไปและใช้ทรัพยากรที่มีค่าของผู้ใช้เพื่อประโยชน์เพียงเล็กน้อย
ซึ่งสามารถวัดได้โดยเรียกเหตุการณ์ Analytics เมื่อแทรกกฎการคาดคะเน หลังจากตรวจสอบว่าเบราว์เซอร์รองรับการแสดงผลก่อนโหลดโดยใช้ HTMLScriptElement.supports('speculationrules')
เพื่อระบุว่ามีการขอแสดงผลก่อนโหลด (โปรดทราบว่าการที่ระบบขอแสดงผลล่วงหน้าไม่ได้หมายความว่าระบบได้เริ่มหรือแสดงผลล่วงหน้าเสร็จสิ้นแล้ว เนื่องจากการแสดงผลล่วงหน้าเป็นคำแนะนำสำหรับเบราว์เซอร์และเบราว์เซอร์อาจเลือกที่จะไม่แสดงผลหน้าเว็บล่วงหน้าตามการตั้งค่าของผู้ใช้ การใช้งานหน่วยความจำปัจจุบัน หรือวิธีการหาค่าประมาณอื่นๆ ตามที่ระบุไว้ก่อนหน้านี้)
จากนั้นคุณสามารถเปรียบเทียบจํานวนเหตุการณ์เหล่านี้กับการดูหน้าเว็บที่แสดงผลล่วงหน้าจริง หรือจะเรียกเหตุการณ์อื่นให้แสดงเมื่อเปิดใช้งานก็ได้หากช่วยให้เปรียบเทียบได้ง่ายขึ้น
จากนั้นจึงประมาณ "อัตรา Hit ที่สำเร็จ" ได้โดยดูที่ผลต่างระหว่างตัวเลข 2 ตัวนี้ สําหรับหน้าที่คุณใช้ Speculation Rules API เพื่อแสดงผลหน้าเว็บล่วงหน้า คุณสามารถปรับกฎตามความเหมาะสมเพื่อให้อัตราการตีสูงอยู่เสมอเพื่อรักษาสมดุลระหว่างการใช้ทรัพยากรของผู้ใช้เพื่อช่วยพวกเขา กับการใช้ทรัพยากรโดยไม่จําเป็น
โปรดทราบว่าการแสดงผลล่วงหน้าบางส่วนอาจเกิดขึ้นเนื่องจากการแสดงผลล่วงหน้าของแถบที่อยู่ ไม่ใช่แค่กฎการคาดคะเน คุณเลือก document.referrer
(ซึ่งจะเป็นค่าว่างสำหรับการไปยังส่วนต่างๆ ในแถบที่อยู่ รวมถึงการไปยังส่วนต่างๆ ในแถบที่อยู่ซึ่งผ่านการแสดงผลล่วงหน้า) ได้หากต้องการแยกความแตกต่าง
อย่าลืมดูหน้าที่ไม่มีการแสดงผลล่วงหน้าด้วย เนื่องจากอาจระบุได้ว่าหน้าเหล่านี้ไม่มีสิทธิ์แสดงผลล่วงหน้า แม้ว่าจะมาจากแถบที่อยู่ก็ตาม ซึ่งอาจหมายความว่าคุณไม่ได้รับประโยชน์จากการเพิ่มประสิทธิภาพนี้ ทีม Chrome กำลังมองหาเครื่องมือเพิ่มเติมเพื่อทดสอบการมีสิทธิ์ใช้การจําลองหน้าเว็บล่วงหน้า ซึ่งอาจคล้ายกับเครื่องมือทดสอบ bfcache และอาจเพิ่ม API เพื่อแสดงสาเหตุที่การจําลองหน้าเว็บล่วงหน้าไม่สําเร็จ
ผลกระทบต่อส่วนขยาย
ดูโพสต์เฉพาะเรื่องส่วนขยาย Chrome: การขยาย API เพื่อรองรับการนำทางแบบทันที ซึ่งจะอธิบายรายละเอียดเพิ่มเติมที่ควรพิจารณาเกี่ยวกับหน้าที่แสดงผลล่วงหน้าซึ่งผู้เขียนส่วนขยายที่ควรคำนึงถึงเพิ่มเติม
ความคิดเห็น
ทีม Chrome กำลังพัฒนาการแสดงผลล่วงหน้าอยู่อย่างต่อเนื่อง และมีแผนมากมายที่จะขยายขอบเขตของสิ่งที่มีให้ใช้งานในรุ่น Chrome 108 เรายินดีรับฟังความคิดเห็นในที่เก็บ GitHub หรือใช้เครื่องมือติดตามปัญหา และหวังว่าจะได้ฟังและแชร์กรณีศึกษาเกี่ยวกับ API ใหม่ที่น่าตื่นเต้นนี้
ลิงก์ที่เกี่ยวข้อง
- Codelab กฎการคาดเดา
- การแก้ไขข้อบกพร่องของกฎการคาดเดา
- ขอแนะนำการดึงข้อมูลล่วงหน้าของ NoState
- ข้อกำหนดของ Speculation Rules API
- ที่เก็บ GitHub ของการคาดการณ์การนำทาง
- ส่วนขยาย Chrome: การขยาย API เพื่อรองรับการนำทางทันที
กิตติกรรมประกาศ
ภาพปกโดย Marc-Olivier Jodoin ใน Unsplash