การรองรับเบราว์เซอร์
- 109
- 109
- x
- x
ทีม Chrome ได้นำการแสดงผลล่วงหน้าที่สมบูรณ์ของหน้าในอนาคตที่ผู้ใช้มีแนวโน้มที่จะเข้าชมกลับมาอีกครั้ง
ประวัติโดยสังเขปของการแสดงผลล่วงหน้า
ที่ผ่านมา Chrome รองรับคำแนะนำทรัพยากร <link rel="prerender" href="/next-page">
แต่ก็ไม่ได้รองรับอย่างกว้างขวางนอกเหนือจาก Chrome และไม่ใช่ API ที่มีความชัดเจนอย่างมาก
การแสดงผลล่วงหน้าแบบเดิมโดยใช้ลิงก์ rel=prerender
เลิกใช้งานแล้วเพื่อใช้ NoState Prefetch ซึ่งจะดึงทรัพยากรที่จำเป็นสำหรับหน้าเว็บในอนาคตแทน แต่ไม่ได้แสดงผลหน้าเว็บล่วงหน้าหรือเรียกใช้ JavaScript อย่างสมบูรณ์ NoState Prefetch ช่วยปรับปรุงประสิทธิภาพของหน้าเว็บด้วยการปรับปรุงการโหลดทรัพยากร แต่จะไม่แสดงการโหลดหน้าเว็บทันทีเหมือนกับการแสดงผลล่วงหน้าแบบเต็ม
ตอนนี้ทีม 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
สำหรับกรณีการใช้งานแรก คุณสามารถดูการคาดคะเนของ Chrome สำหรับ URL ในหน้า chrome://predictors
ดังนี้
![หน้าเครื่องมือคาดการณ์ของ Chrome กรองให้แสดงการคาดคะเนระดับต่ำ (สีเทา) กลาง (เหลือง) และสูง (เขียว) ตามข้อความที่ป้อน](https://developer.chrome.google.cn/static/docs/web-platform/prerender-pages/image/screenshot-the-chrome-pr-ec7e1506f8378.png?authuser=6&hl=th)
เส้นสีเขียวแสดงถึงความมั่นใจเพียงพอที่จะกระตุ้นการแสดงผลล่วงหน้า ในตัวอย่างนี้ การพิมพ์ "s" จะให้ความเชื่อมั่นที่สมเหตุสมผล (สีเหลือง) แต่เมื่อคุณพิมพ์ "sh" แล้ว Chrome จะมีความมั่นใจมากพอว่าคุณจะไปที่ https://sheets.google.com
ทุกครั้ง
ภาพหน้าจอนี้บันทึกมาจากการติดตั้ง Chrome ที่ค่อนข้างใหม่ และกรองการคาดคะเนค่าความเชื่อมั่นเป็นศูนย์ออก แต่ถ้าคุณดูตัวคาดการณ์ของคุณเอง คุณอาจเห็นรายการมากขึ้นมาก และเป็นไปได้ว่าจำเป็นต้องมีอักขระมากขึ้นเพื่อให้ได้ระดับความเชื่อมั่นที่สูงพอ
นอกจากนี้ ตัวคาดการณ์เหล่านี้ยังเป็นปัจจัยขับเคลื่อนตัวเลือกที่แนะนำในแถบที่อยู่ที่คุณอาจสังเกตเห็นด้วย:
![คุณลักษณะ "Typeahead" ของแถบที่อยู่ Chrome](https://developer.chrome.google.cn/static/docs/web-platform/prerender-pages/image/screenshot-the-address-b-7938093dbbc3c.png?authuser=6&hl=th)
Chrome จะอัปเดตตัวคาดการณ์อย่างต่อเนื่องตามการพิมพ์และสิ่งที่คุณเลือก
- สำหรับระดับความเชื่อมั่นมากกว่า 50% (แสดงเป็นสีเหลือง) Chrome จะเชื่อมต่อกับโดเมนล่วงหน้าโดยไม่แสดงผลหน้าเว็บล่วงหน้า
- สำหรับระดับความเชื่อมั่นมากกว่า 80% (แสดงเป็นสีเขียว) Chrome จะแสดงผล URL ล่วงหน้า
API ของกฎการคาดเดา
สำหรับตัวเลือกการแสดงผลล่วงหน้าสำหรับ Speculation Rules API นักพัฒนาเว็บจะแทรกคำสั่ง JSON ลงในหน้าเว็บเพื่อแจ้งให้เบราว์เซอร์ทราบเกี่ยวกับ URL ที่จะแสดงผลล่วงหน้าได้
<script type="speculationrules">
{
"prerender": [
{
"urls": ["next.html", "next2.html"]
}
]
}
</script>
หรือตามกฎเอกสาร (ใช้ได้ใน Chrome 121) ซึ่งแสดงผลลิงก์ที่พบในเอกสารล่วงหน้าตามตัวเลือก href
(อิงตาม API รูปแบบ URL) หรือตัวเลือก 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 กฎการคาดเดา ซึ่งจะแนะนำคุณเกี่ยวกับการเพิ่มกฎการคาดเดาลงในเว็บไซต์
ความกระตือรือร้น
การรองรับเบราว์เซอร์
- 121
- 121
- x
- x
การตั้งค่า 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 มิลลิวินาที หรือเหตุการณ์ตัวชี้เป็นการใช้กฎการคาดเดาพื้นฐานแต่มีประสิทธิภาพ:
<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
(ขึ้นอยู่กับการโต้ตอบของผู้ใช้) ทำงานในลักษณะแบบ First In First Out (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
นอกจากนี้ คุณยังส่งกฎการคาดเดาได้โดยใช้ส่วนหัว HTTP Speculation-Rules
แทนที่จะใส่กฎเหล่านั้นใน 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 DevTools เพื่อช่วยในการดูและแก้ไขข้อบกพร่องของ 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 นั้นล่วงหน้าอย่างตั้งใจ และควรแสดงผลส่วนหัว 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 เรากำลังเพิ่มการสนับสนุนนี้ ติดตามปัญหาเกี่ยวกับ Support Service Worker นี้เพื่อรับข้อมูลอัปเดต ระบบรองรับการแสดงผลล่วงหน้าสําหรับหน้าที่ควบคุมของ Service Worker
ตรวจหาการรองรับ 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 จากคอนโซลเพื่อแทรกกฎแทน
เพิ่มกฎการคาดเดาผ่าน Tag Manager
หากต้องการเพิ่มกฎการคาดเดาโดยใช้ Tag Manager เช่น Google Tag Manager (GTM) ให้แทรกกฎเหล่านี้ผ่าน JavaScript แทนการเพิ่มองค์ประกอบ <script type = "speculationrules">
ผ่าน GTM โดยตรงด้วยเหตุผลเดียวกับที่กล่าวไปก่อนหน้านี้
![การกำหนดค่าแท็ก HTML ที่กำหนดเองใน Google Tag Manager](https://developer.chrome.google.cn/static/docs/web-platform/prerender-pages/image/adding-speculation-rules-via-gtm.png?authuser=6&hl=th)
โปรดทราบว่าตัวอย่างนี้ใช้ var
เนื่องจาก GTM ไม่รองรับ const
ยกเลิกกฎการคาดเดา
การนำกฎการคาดเดาออกจะส่งผลให้ระบบยกเลิกการแสดงผลล่วงหน้า แต่เมื่อถึงตอนนั้น ทรัพยากรก็น่าจะถูกใช้ไปเพื่อเริ่มการแสดงผลล่วงหน้าไปแล้ว จึงขอแนะนำว่าอย่าแสดงผลล่วงหน้าหากมีแนวโน้มที่จะต้องยกเลิกการแสดงผลล่วงหน้า
กฎการคาดเดาและนโยบายรักษาความปลอดภัยเนื้อหา
เนื่องจากกฎการคาดเดาใช้เอลิเมนต์ <script>
แม้ว่าจะมีเฉพาะ JSON เท่านั้น กฎดังกล่าวจึงต้องรวมอยู่ในนโยบายรักษาความปลอดภัยเนื้อหาของ script-src
หากเว็บไซต์ใช้พารามิเตอร์นี้ ไม่ว่าจะโดยใช้แฮชหรือค่า Nonce
คุณสามารถเพิ่ม inline-speculation-rules
ใหม่ใน script-src
เพื่อให้ระบบรองรับองค์ประกอบ <script type="speculationrules">
ที่แทรกจากแฮชหรือสคริปต์ที่ไม่ใช่สคริปต์ วิธีนี้ไม่รองรับกฎที่รวมอยู่ใน 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 หรือ 304) หน้าเว็บจะไม่แสดงล่วงหน้าและระบบจะทิ้งหน้าเว็บที่ดึงข้อมูลล่วงหน้าไป
หากคุณไม่ต้องการให้หน้าเว็บหนึ่งๆ แสดงผลล่วงหน้า วิธีนี้เป็นวิธีที่ดีที่สุดเพื่อให้แน่ใจว่าหน้าจะไม่แสดงผล อย่างไรก็ตาม เพื่อมอบประสบการณ์ที่ดีที่สุด ขอแนะนำให้อนุญาตการแสดงผลล่วงหน้าแทน แต่ควรเลื่อนการทำงานใดๆ ที่ควรจะเกิดขึ้นก็ต่อเมื่อมีการดูหน้าเว็บจริงๆ โดยใช้ 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 คุณจะทราบว่าหน้าเว็บมีการแสดงผลล่วงหน้าแล้ว
![คอนโซลในเครื่องมือสำหรับนักพัฒนาเว็บใน Chrome ที่แสดงการเปิดใช้งานเป็นบวก ซึ่งระบุว่าหน้าเว็บถูกแสดงผลล่วงหน้า](https://developer.chrome.google.cn/static/docs/web-platform/prerender-pages/image/console-chrome-devtools-7d567e77e3ca6.png?authuser=6&hl=th)
เมื่อผู้ใช้ที่ดูหน้าเว็บเปิดใช้งานอยู่ ระบบจะส่งเหตุการณ์ prerenderingchange
ไปใน document
ซึ่งเหตุการณ์ดังกล่าวสามารถใช้เพื่อเปิดใช้กิจกรรมที่ก่อนหน้านี้เริ่มโดยค่าเริ่มต้นเมื่อโหลดหน้าเว็บ แต่คุณต้องการหน่วงเวลาไว้จนกว่าผู้ใช้จะดูหน้าเว็บจริงๆ ได้
การใช้ API เหล่านี้จะทำให้ JavaScript ของฟรอนท์เอนด์สามารถตรวจจับและดำเนินการกับหน้าที่แสดงผลล่วงหน้าอย่างเหมาะสม
ผลกระทบต่อข้อมูลวิเคราะห์
Analytics ใช้ในการวัดการใช้งานเว็บไซต์ เช่น การใช้ Google Analytics เพื่อวัดการดูหน้าเว็บและเหตุการณ์ หรือโดยการวัดเมตริกประสิทธิภาพของหน้าเว็บโดยใช้การตรวจสอบผู้ใช้จริง (RUM)
หน้าควรแสดงผลล่วงหน้าเฉพาะเมื่อมีความเป็นไปได้สูงที่ผู้ใช้จะโหลดหน้าเว็บ และนี่คือสาเหตุที่ตัวเลือกการแสดงผลล่วงหน้าของแถบที่อยู่ Chrome จะเกิดขึ้นเฉพาะเมื่อมีความเป็นไปได้สูงจริงๆ (มากกว่า 80% ของทั้งหมด)
อย่างไรก็ตาม - โดยเฉพาะอย่างยิ่งเมื่อใช้ Speculation Rules API หน้าที่แสดงผลล่วงหน้าอาจมีผลต่อ Analytics และเจ้าของเว็บไซต์อาจต้องเพิ่มโค้ดเพิ่มเติมเพื่อเปิดใช้การวิเคราะห์สำหรับหน้าที่แสดงผลล่วงหน้าเมื่อเปิดใช้งานเท่านั้น เนื่องจากผู้ให้บริการวิเคราะห์บางรายอาจไม่รองรับเช่นนี้โดยค่าเริ่มต้น
ซึ่งทําได้โดยใช้ 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 ของบุคคลที่สามจะไม่แสดงผล จึงเป็นเพียงเนื้อหานอกเหนือจากนี้ซึ่งจำเป็นที่จะต้องระงับด้วยตนเอง
วัดประสิทธิภาพ
ในการวัดเมตริกประสิทธิภาพ Analytics ควรพิจารณาว่าควรวัดผลเหล่านี้ตามเวลาการเปิดใช้งานมากกว่าเวลาในการโหลดหน้าเว็บที่ API ของเบราว์เซอร์จะรายงานหรือไม่
สำหรับ Core Web Vitals ซึ่งวัดโดย Chrome ผ่านรายงานประสบการณ์ของผู้ใช้ Chrome ค่าเหล่านี้มีไว้เพื่อวัดประสบการณ์ของผู้ใช้ โดยระบบจะวัดค่าเหล่านี้ตามเวลาการเปิดใช้งาน ตัวอย่างเช่น ผลลัพธ์นี้มักจะทําให้ LCP เป็น 0 วินาที แสดงให้เห็นว่าวิธีนี้เป็นวิธีที่ยอดเยี่ยมในการปรับปรุง Core Web Vitals
จากเวอร์ชัน 3.1.0 เราได้อัปเดตไลบรารี web-vitals
ให้จัดการกับการนำทางที่แสดงผลล่วงหน้าเช่นเดียวกับที่ Chrome วัด Core Web Vitals เวอร์ชันนี้แจ้งการไปยังส่วนต่างๆ ที่แสดงผลล่วงหน้าสำหรับเมตริกเหล่านั้นในแอตทริบิวต์ Metric.navigationType
ด้วย หากหน้าเว็บแสดงผลล่วงหน้าบางส่วนหรือทั้งหมด
วัดการแสดงผลล่วงหน้า
สามารถดูหน้าเว็บที่แสดงผลล่วงหน้าได้ด้วยรายการ activationStart
ที่ไม่ใช่ 0 ของ PerformanceNavigationTiming
หรือไม่ จากนั้นระบบจะบันทึกโดยใช้มิติข้อมูลที่กำหนดเองหรือที่คล้ายกันเมื่อบันทึกการดูหน้าเว็บ เช่น โดยใช้ฟังก์ชัน 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 ที่ประสบความสำเร็จ" สามารถประมาณได้ โดยดูผลต่างระหว่างตัวเลขทั้งสองนี้ สำหรับหน้าที่ใช้ Speculation Rules API ในการแสดงผลหน้าล่วงหน้า คุณสามารถปรับกฎอย่างเหมาะสมเพื่อรักษาอัตรา Hit ที่สูงเพื่อรักษาสมดุลระหว่างการใช้ทรัพยากรของผู้ใช้เพื่อช่วยพวกเขา เทียบกับการใช้โดยไม่จำเป็น
โปรดทราบว่าการแสดงผลล่วงหน้าบางส่วนอาจเกิดขึ้นเนื่องจากการแสดงผลล่วงหน้าของแถบที่อยู่ ไม่ใช่เพียงกฎการคาดเดาของคุณ คุณสามารถดู document.referrer
(ซึ่งจะเว้นว่างไว้สำหรับการนำทางในแถบที่อยู่รวมถึงการไปยังส่วนต่างๆ ในแถบที่อยู่เว็บที่แสดงผลล่วงหน้า) หากต้องการแยกความแตกต่าง
อย่าลืมดูหน้าที่ไม่มีการแสดงผลล่วงหน้าด้วย เนื่องจากอาจระบุได้ว่าหน้าเหล่านี้ไม่มีสิทธิ์แสดงผลล่วงหน้า แม้จะมาจากแถบที่อยู่ก็ตาม ซึ่งอาจหมายความว่าคุณไม่ได้รับประโยชน์จากการเพิ่มประสิทธิภาพการทำงานนี้ ทีม Chrome ต้องการเพิ่มเครื่องมือเพิ่มเติมเพื่อทดสอบการมีสิทธิ์ของการแสดงผลล่วงหน้า ซึ่งอาจคล้ายกับเครื่องมือทดสอบ bfcache และอาจเพิ่ม API เพื่อระบุสาเหตุที่การแสดงผลล่วงหน้าล้มเหลว
ผลกระทบต่อส่วนขยาย
ดูโพสต์เฉพาะเรื่องส่วนขยาย Chrome: การขยาย API เพื่อรองรับการนำทางแบบทันที ซึ่งจะให้รายละเอียดเพิ่มเติมเกี่ยวกับข้อพิจารณาที่ผู้เขียนส่วนขยายอาจต้องคำนึงถึงเกี่ยวกับหน้าที่แสดงผลล่วงหน้า
ความคิดเห็น
การแสดงผลล่วงหน้าอยู่ระหว่างการพัฒนาโดยทีม Chrome และมีแผนที่จะขยายขอบเขตของสิ่งที่มีให้ใช้งานใน Chrome 108 ด้วย เรายินดีรับฟังความคิดเห็นเกี่ยวกับที่เก็บ GitHub หรือใช้เครื่องมือติดตามปัญหาของเรา และหวังเป็นอย่างยิ่งว่าจะได้รับฟังและแชร์กรณีศึกษาของ API ใหม่ที่น่าตื่นเต้นนี้
ลิงก์ที่เกี่ยวข้อง
- Codelab กฎการคาดเดา
- การแก้ไขข้อบกพร่องของกฎการคาดเดา
- ขอแนะนำการดึงข้อมูลล่วงหน้าของ NoState
- ข้อกำหนดของ Speculation Rules API
- ที่เก็บ GitHub สำหรับการคาดเดาการนำทาง
- ส่วนขยาย Chrome: การขยาย API เพื่อรองรับการนำทางทันที
กิตติกรรมประกาศ
ภาพขนาดย่อโดย Marc-Olivier Jodoin ใน Unsplash