หน้าที่แสดงผลล่วงหน้าใน Chrome สำหรับการนำทางหน้าเว็บแบบทันใจ

Barry Pollard

เผยแพร่: 2 ธ.ค. 2022, อัปเดตล่าสุด: 17 ส.ค. 2025

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

ประวัติโดยย่อของการแสดงผลล่วงหน้า

ในอดีต Chrome รองรับ<link rel="prerender" href="/next-page">คำแนะนำทรัพยากร แต่ไม่ได้รับการรองรับอย่างกว้างขวางนอกเหนือจาก Chrome และไม่ใช่ API ที่สื่อความหมายได้ดีนัก

การแสดงผลล่วงหน้าแบบเดิมนี้โดยใช้คำแนะนำลิงก์ rel=prerender ถูกเลิกใช้งานแล้วเพื่อรองรับ NoState Prefetch ซึ่งจะดึงข้อมูลทรัพยากรที่หน้าเว็บในอนาคตต้องการแทน แต่ไม่ได้แสดงผลหน้าเว็บล่วงหน้าอย่างเต็มรูปแบบหรือเรียกใช้ JavaScript การดึงข้อมูลล่วงหน้าแบบไม่มีสถานะช่วยปรับปรุงประสิทธิภาพของหน้าเว็บได้ด้วยการปรับปรุงการโหลดทรัพยากร แต่จะไม่ทำให้หน้าเว็บโหลดทันทีเหมือนกับการแสดงผลล่วงหน้าแบบเต็ม

ตอนนี้ทีม Chrome ได้นำการแสดงผลล่วงหน้าแบบเต็มกลับมาใช้ใน Chrome อีกครั้งแล้ว กลไกการแสดงผลล่วงหน้าแบบใหม่นี้จะไม่ใช้ไวยากรณ์ <link rel="prerender"...> เพื่อหลีกเลี่ยงความซับซ้อนในการใช้งานที่มีอยู่ และเพื่อให้สามารถขยายการแสดงผลล่วงหน้าได้ในอนาคต โดยไวยากรณ์นี้จะยังคงใช้สำหรับการดึงข้อมูลล่วงหน้าแบบไม่มีสถานะต่อไป และเรามีแผนที่จะเลิกใช้ไวยากรณ์นี้ในอนาคต

ระบบแสดงผลหน้าเว็บล่วงหน้าอย่างไร

คุณสามารถแสดงหน้าเว็บล่วงหน้าได้ 4 วิธี ซึ่งทั้งหมดนี้มีจุดมุ่งหมายเพื่อทำให้การไปยังส่วนต่างๆ เร็วขึ้น

1. เมื่อคุณพิมพ์ URL ลงในแถบที่อยู่ของ Chrome (หรือที่เรียกว่า "แถบอเนกประสงค์") Chrome อาจแสดงหน้าเว็บล่วงหน้าโดยอัตโนมัติ หากมั่นใจว่าคุณจะเข้าชมหน้านั้นโดยอิงตามประวัติการท่องเว็บก่อนหน้านี้
2. เมื่อคุณใช้แถบบุ๊กมาร์ก Chrome อาจแสดงหน้าเว็บล่วงหน้าโดยอัตโนมัติเมื่อคุณวางเคอร์เซอร์เหนือปุ่มบุ๊กมาร์กปุ่มใดปุ่มหนึ่ง
3. เมื่อคุณพิมพ์คำค้นหาลงในแถบที่อยู่ของ Chrome ทาง Chrome อาจแสดงผลหน้าผลการค้นหาล่วงหน้าโดยอัตโนมัติเมื่อเครื่องมือค้นหาสั่งให้ทำเช่นนั้น
4. เว็บไซต์สามารถใช้ Speculation Rules API เพื่อบอก Chrome แบบเป็นโปรแกรมว่าควรแสดงหน้าใดล่วงหน้า ซึ่งจะแทนที่สิ่งที่ <link rel="prerender"...> เคยทำ และช่วยให้เว็บไซต์แสดงผลหน้าเว็บล่วงหน้าได้โดยอิงตามกฎการคาดเดาในหน้าเว็บ โดยอาจมีอยู่ในหน้าเว็บแบบคงที่ หรือ JavaScript อาจแทรกแบบไดนามิกตามที่เจ้าของหน้าเว็บเห็นสมควร

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

เนื่องจากหน้าเว็บที่แสดงผลล่วงหน้าจะเปิดในสถานะซ่อน API จำนวนหนึ่งที่ทำให้เกิดลักษณะการทำงานที่ล่วงล้ำ (เช่น พรอมต์) จึงไม่ได้รับการเปิดใช้งานในสถานะนี้ แต่จะเลื่อนออกไปจนกว่าหน้าเว็บจะได้รับการเปิดใช้งาน ในกรณีที่เกิดขึ้นไม่บ่อยซึ่งยังทำไม่ได้ ระบบจะยกเลิกการแสดงผลล่วงหน้า ทีม Chrome กำลังดำเนินการเปิดเผยเหตุผลในการยกเลิกการแสดงผลล่วงหน้าเป็น API และยังปรับปรุงความสามารถของ DevTools เพื่อให้ระบุกรณีที่พบได้ยากดังกล่าวได้ง่ายขึ้นด้วย

ผลกระทบของการแสดงผลล่วงหน้า

การแสดงผลล่วงหน้าช่วยให้หน้าเว็บโหลดได้แทบจะทันที ดังที่แสดงในวิดีโอต่อไปนี้

เว็บไซต์ตัวอย่างเป็นเว็บไซต์ที่รวดเร็วอยู่แล้ว แต่คุณก็ยังเห็นได้ว่าการแสดงผลล่วงหน้าช่วยปรับปรุงประสบการณ์ของผู้ใช้ได้อย่างไร ดังนั้นจึงอาจส่งผลโดยตรงต่อ Core Web Vitals ของเว็บไซต์ด้วย โดยมี LCP ใกล้ 0, CLS ลดลง (เนื่องจาก CLS ในการโหลดเกิดขึ้นก่อนมุมมองเริ่มต้น) และ INP ที่ดีขึ้น (เนื่องจากการโหลดควรเสร็จสมบูรณ์ก่อนที่ผู้ใช้จะโต้ตอบ)

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

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

ดูข้อมูลเพิ่มเติมเกี่ยวกับวิธีวัดผลกระทบด้านประสิทธิภาพที่แท้จริงในข้อมูลวิเคราะห์ได้ที่ส่วนการวัดประสิทธิภาพ

ดูการคาดคะเนของแถบที่อยู่ของ Chrome

สำหรับกรณีการใช้งานแรก คุณสามารถดูการคาดการณ์ของ Chrome สำหรับ URL ได้ใน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 ได้จัดทำ Speculation Rules Codelab ซึ่งจะแนะนำวิธีเพิ่ม Speculation Rules ลงในเว็บไซต์

ความกระตือรือร้น

eagerness การตั้งค่าใช้เพื่อระบุเวลาที่ควรเริ่มการคาดคะเน ซึ่งมีประโยชน์อย่างยิ่งสำหรับกฎของเอกสาร

• immediate: ใช้เพื่อคาดเดาโดยเร็วที่สุด ซึ่งก็คือทันทีที่พบกฎการคาดเดา
• eager: เดิมทำงานเหมือนกับ immediate แต่จะเปลี่ยนเป็น 5 มม. เมื่อวางเมาส์เหนือใน Chrome 141 และมีแผนที่จะเปลี่ยนเป็นฮิวริสติกวิวพอร์ตอย่างง่ายในอุปกรณ์เคลื่อนที่
• moderate: ในเดสก์ท็อป ฟีเจอร์นี้จะทำการคาดการณ์หากคุณวางเมาส์เหนือลิงก์เป็นเวลา 200 มิลลิวินาที (หรือในเหตุการณ์ pointerdown หากเกิดขึ้นก่อน และในอุปกรณ์เคลื่อนที่ที่ไม่มีเหตุการณ์ hover) ในอุปกรณ์เคลื่อนที่ เรากำลังจะเปิดตัวการเปลี่ยนแปลงเพื่อใช้ Heuristics วิวพอร์ตที่ซับซ้อนเป็นพื้นฐาน
• 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 มากเกินไป ดังนี้

การตั้งค่า moderate และ conservative ซึ่งขึ้นอยู่กับการโต้ตอบของผู้ใช้จะทำงานในลักษณะเข้าก่อนออกก่อน (FIFO) กล่าวคือ หลังจากถึงขีดจำกัดแล้ว การคาดคะเนใหม่จะทำให้ระบบยกเลิกการคาดคะเนที่เก่าที่สุดและแทนที่ด้วยการคาดคะเนใหม่กว่าเพื่อประหยัดหน่วยความจำ การคาดคะเนที่ยกเลิกไปแล้วจะทริกเกอร์ได้อีกครั้ง เช่น โดยการวางเมาส์เหนือลิงก์นั้นอีกครั้ง ซึ่งจะทำให้ระบบคาดคะเน URL นั้นอีกครั้งและนำการคาดคะเนที่เก่าที่สุดออก ในกรณีนี้ การคาดคะเนก่อนหน้าจะแคชทรัพยากรที่แคชได้ในแคช HTTP สำหรับ URL นั้น ดังนั้นการคาดคะเนในครั้งต่อๆ ไปจึงควรมีต้นทุนที่ลดลง ด้วยเหตุนี้เราจึงกำหนดขีดจำกัดไว้ที่เกณฑ์ต่ำสุดที่ 2 กฎรายการแบบคงที่จะไม่ทริกเกอร์โดยการดำเนินการของผู้ใช้ จึงมีขีดจำกัดที่สูงกว่าเนื่องจากเบราว์เซอร์ไม่สามารถทราบว่าต้องใช้รายการใดและเมื่อใด

ขีดจํากัดของ immediate และ eager ยังเป็นแบบไดนามิกด้วย ดังนั้นการนําองค์ประกอบสคริปต์ URL ของ list ออกจะสร้างความจุโดยการยกเลิกการคาดการณ์ที่นําออก

นอกจากนี้ Chrome ยังป้องกันไม่ให้มีการใช้การคาดเดาในบางกรณีด้วย ซึ่งรวมถึง

• Save-Data
• โหมดประหยัดพลังงานเมื่อเปิดใช้และแบตเตอรี่เหลือน้อย
• ข้อจำกัดด้านหน่วยความจำ
• เมื่อปิดการตั้งค่า "โหลดหน้าเว็บล่วงหน้า" (ซึ่งส่วนขยาย Chrome เช่น uBlock Origin จะปิดอย่างชัดเจนด้วย)
• เปิดหน้าเว็บในแท็บพื้นหลัง

นอกจากนี้ Chrome จะไม่แสดงผล iframe แบบข้ามต้นทางในหน้าเว็บที่แสดงผลล่วงหน้าจนกว่าจะมีการเปิดใช้งาน

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

วิธีรวมกฎการคาดเดาในหน้าเว็บ

คุณสามารถใส่กฎการคาดคะเนแบบคงที่ใน HTML ของหน้าเว็บ หรือแทรกแบบไดนามิกลงในหน้าเว็บโดยใช้ JavaScript ได้

• กฎการคาดคะเนที่รวมแบบคงที่: ตัวอย่างเช่น เว็บไซต์สื่อข่าวหรือบล็อกอาจแสดงผลล่วงหน้าสำหรับบทความล่าสุด หากผู้ใช้จำนวนมากมักจะไปยังบทความดังกล่าวเป็นลำดับถัดไป หรืออาจใช้กฎของเอกสารที่มี moderate หรือ conservative เพื่อคาดคะเนเมื่อผู้ใช้โต้ตอบกับลิงก์
• กฎการคาดคะเนที่แทรกแบบไดนามิก: กฎนี้อาจอิงตามตรรกะของแอปพลิเคชัน ปรับเปลี่ยนในแบบของผู้ใช้ หรืออิงตามฮิวริสติกอื่นๆ

ขอแนะนำให้ผู้ที่ต้องการใช้การแทรกแบบไดนามิกตามการดำเนินการต่างๆ เช่น การวางเมาส์เหนือหรือการคลิกลิงก์ (เช่นเดียวกับที่ไลบรารีหลายแห่งเคยทำในอดีตด้วย <link rel=prefetch>) ให้ดูที่กฎของเอกสาร เนื่องจากกฎเหล่านี้จะช่วยให้เบราว์เซอร์จัดการกรณีการใช้งานของคุณได้หลายกรณี

คุณเพิ่มกฎการคาดคะเนได้ทั้งใน <head> หรือ <body> ของเฟรมหลัก ระบบจะไม่ดำเนินการตามกฎการคาดเดาในเฟรมย่อย และจะดำเนินการตามกฎการคาดเดาในหน้าที่แสดงผลล่วงหน้าเมื่อเปิดใช้งานหน้าดังกล่าวแล้วเท่านั้น

ส่วนหัว HTTP ของ Speculation-Rules

นอกจากนี้ คุณยังส่งกฎการคาดคะเนได้โดยใช้ส่วนหัว Speculation-Rules HTTP แทนที่จะรวมไว้ใน HTML ของเอกสารโดยตรง ซึ่งช่วยให้ CDN ทำให้ใช้งานได้ง่ายขึ้นโดยไม่ต้องแก้ไขเนื้อหาของเอกสาร

Speculation-Rules ส่วนหัว HTTP จะแสดงพร้อมกับเอกสารและชี้ไปยังตำแหน่งของไฟล์ JSON ที่มีกฎการคาดคะเน

Speculation-Rules: "/speculationrules.json" 

ทรัพยากรนี้ต้องใช้ประเภท MIME ที่ถูกต้อง และหากเป็นทรัพยากรข้ามต้นทาง จะต้องผ่านการตรวจสอบ CORS

Content-Type: application/speculationrules+json Access-Control-Allow-Origin: * 

หากต้องการใช้ URL แบบสัมพัทธ์ คุณอาจต้องรวมคีย์ "relative_to": "document" ไว้ในกฎการคาดการณ์ ไม่เช่นนั้น URL ที่เกี่ยวข้องจะเกี่ยวข้องกับ URL ของไฟล์ JSON ของกฎการคาดคะเน ซึ่งอาจมีประโยชน์อย่างยิ่งหากคุณต้องการเลือกลิงก์ที่มาจากต้นทางเดียวกันบางลิงก์หรือทั้งหมด

ฟิลด์แท็กกฎการคาดเดา

นอกจากนี้ คุณยังเพิ่ม "แท็ก" ในไวยากรณ์ JSON ของกฎการคาดการณ์ได้ที่ระดับกฎแต่ละรายการ

{   "prefetch": [     "urls": ["next.html"],     "tag": "my-prefetch-rules"   ],   "prerender": [     "urls": ["next2.html"],     "tag": "my-prerender-rules"   ], } 

หรือที่ระดับโดยรวมสำหรับกฎการคาดเดาทั้งหมดในชุดกฎ

{   "tag": "my-rules",   "prefetch": [     "urls": ["next.html"]   ],   "prerender": [     "urls": ["next2.html"]   ], } 

จากนั้นแท็กนี้จะแสดงในส่วนหัว Sec-Speculation-Tags HTTP ซึ่งใช้เพื่อกรองกฎการคาดคะเนที่เซิร์ฟเวอร์ได้ ส่วนหัว HTTP Sec-Speculation-Tags อาจมีแท็กหลายรายการหากการคาดการณ์ครอบคลุมกฎหลายข้อ ดังตัวอย่างต่อไปนี้

Sec-Speculation-Tags: null Sec-Speculation-Tags: null, "cdn-prefetch" Sec-Speculation-Tags: "my-prefetch-rules" Sec-Speculation-Tags: "my-prefetch-rules", "my-rules", "cdn-prefetch" 

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

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

ฟิลด์กฎการคาดเดา target_hint

กฎการคาดคะเนยังอาจมีฟิลด์ target_hint ซึ่งมีชื่อหรือคีย์เวิร์ดบริบทการท่องเว็บที่ถูกต้องซึ่งระบุตำแหน่งที่หน้าเว็บคาดหวังให้เปิดใช้งานเนื้อหาที่แสดงผลล่วงหน้าด้วย

<script type=speculationrules> {   "prerender": [{     "target_hint": "_blank",     "urls": ["next.html"]   }] } </script> 

คำใบ้นี้ช่วยให้จัดการการคาดการณ์การแสดงผลล่วงหน้าสำหรับลิงก์ target="_blank" ได้

<a target="_blank" href="next.html">Open this link in a new tab</a> 

ตอนนี้ Chrome รองรับเฉพาะ "target_hint": "_blank" และ "target_hint": "_self" (ค่าเริ่มต้นหากไม่ได้ระบุ) และรองรับเฉพาะการแสดงผลล่วงหน้า ส่วนการดึงข้อมูลล่วงหน้าไม่รองรับ

target_hint จำเป็นสำหรับurlsกฎการคาดคะเนเท่านั้น เนื่องจากสำหรับกฎเอกสาร target จะทราบจากลิงก์เอง

กฎการคาดเดาและ 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เดียว

<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> 

ในตัวอย่างนี้ /products HTML ของหน้าเริ่มต้นจะเหมือนกันสำหรับรหัสผลิตภัณฑ์ทั้ง 2 รายการ 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 และรอให้การดึงข้อมูลล่วงหน้าดังกล่าวเสร็จสมบูรณ์

นอกจากนี้ คุณยังเพิ่มพารามิเตอร์หลายรายการลงใน expects_no_vary_search ได้โดยคั่นด้วยการเว้นวรรค (เนื่องจาก No-Vary-Search เป็นส่วนหัวที่มีโครงสร้าง HTTP) ดังนี้

    "expects_no_vary_search": "params=(\"param1\" \"param2\" \"param3\")" 

การจำกัดกฎการคาดเดาและการปรับปรุงในอนาคต

กฎการคาดคะเนจะจำกัดเฉพาะหน้าเว็บที่เปิดในแท็บเดียวกัน แต่เรากำลังพยายามลดข้อจำกัดดังกล่าว

โดยค่าเริ่มต้น การคาดคะเนจะจำกัดไว้ที่หน้าเว็บที่มีต้นทางเดียวกัน หน้าข้ามต้นทางแบบเดียวกันที่คาดการณ์ (เช่น 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 ที่คล้ายกัน

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

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

<script type="speculationrules">   {     "prerender": [       {         "where": { "href_matches": "/*" },         "eagerness": "moderate"       }     ],     "prefetch": [       {         "where": { "not": { "href_matches": "/*" } },         "eagerness": "moderate"       }     ]   } </script> 

การจำกัดเพื่อป้องกันการคาดเดาแบบข้ามต้นทางสำหรับลิงก์แบบข้ามต้นทางโดยค่าเริ่มต้นเป็นสิ่งจำเป็นเพื่อความปลอดภัย ซึ่งเป็นการปรับปรุง<link rel="prefetch">สำหรับปลายทางแบบข้ามต้นทางซึ่งจะไม่ส่งคุกกี้เช่นกัน แต่จะยังคงพยายามทำการดึงข้อมูลล่วงหน้า ซึ่งอาจส่งผลให้เกิดการดึงข้อมูลล่วงหน้าที่สูญเปล่าซึ่งต้องส่งใหม่ หรือที่แย่กว่านั้นคือหน้าเว็บโหลดไม่ถูกต้อง

การรองรับ 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

ยกเลิกกฎการคาดเดา

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

นอกจากนี้ยังยกเลิกการคาดการณ์ได้โดยใช้ส่วนหัว HTTP ของ Clear-Site-Data ที่มีคำสั่ง prefetchCache และ prerenderCache

ซึ่งจะมีประโยชน์เมื่อมีการเปลี่ยนแปลงสถานะในเซิร์ฟเวอร์ เช่น เมื่อเรียกใช้ API "เพิ่มลงในตะกร้า" หรือ API การเข้าสู่ระบบหรือออกจากระบบ

ในอุดมคติ การอัปเดตสถานะเหล่านี้จะเผยแพร่ไปยังหน้าที่แสดงผลล่วงหน้าโดยใช้ API เช่น Broadcast Channel API แต่ในกรณีที่ทำไม่ได้ หรือจนกว่าจะมีการใช้ตรรกะดังกล่าว การยกเลิกการคาดคะเนจะทำได้ง่ายกว่า

กฎการคาดคะเนและนโยบายความปลอดภัยของเนื้อหา

เนื่องจากกฎการคาดคะเนใช้องค์ประกอบ <script> แม้ว่าจะมีเพียง JSON แต่ก็ต้องรวมไว้ใน script-src Content-Security-Policy หากเว็บไซต์ใช้นโยบายนี้ ไม่ว่าจะใช้แฮชหรือ 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 ขณะที่หน้าเว็บแสดงผลล่วงหน้า หน้าเว็บสามารถใช้ฟีเจอร์นี้เพื่อป้องกันหรือชะลอกิจกรรมบางอย่างในระหว่างการแสดงผลล่วงหน้าจนกว่าหน้าเว็บจะเปิดใช้งานจริง

เมื่อเปิดใช้งานเอกสารที่แสดงผลล่วงหน้าแล้ว ระบบจะตั้งค่า PerformanceNavigationTimingactivationStart เป็นเวลาที่ไม่ใช่ 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 ของบุคคลที่สามจะไม่ได้รับการแสดงผล ดังนั้นจึงมีเพียงเนื้อหาที่อยู่ด้านบนเท่านั้นที่ต้องถูกระงับไว้ด้วยตนเอง

วัดประสิทธิภาพ

สําหรับการวัดเมตริกประสิทธิภาพ 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'); 

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

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

วัดอัตราการเข้าชม

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

คุณวัดผลได้โดยการทริกเกอร์เหตุการณ์ Analytics เมื่อแทรกกฎการคาดคะเน หลังจากตรวจสอบว่าเบราว์เซอร์รองรับการแสดงผลล่วงหน้าโดยใช้ HTMLScriptElement.supports('speculationrules') เพื่อระบุว่ามีการขอการแสดงผลล่วงหน้า (โปรดทราบว่าการขอแสดงผลล่วงหน้าไม่ได้หมายความว่าการแสดงผลล่วงหน้าจะเริ่มต้นหรือเสร็จสมบูรณ์ เนื่องจากดังที่ได้กล่าวไว้ก่อนหน้านี้ การแสดงผลล่วงหน้าเป็นคำแนะนำสำหรับเบราว์เซอร์ และเบราว์เซอร์อาจเลือกที่จะไม่แสดงผลล่วงหน้าในหน้าต่างๆ ตามการตั้งค่าของผู้ใช้ การใช้งานหน่วยความจำปัจจุบัน หรือฮิวริสติกอื่นๆ)

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

จากนั้นคุณจะประมาณ "อัตราการเข้าชมที่สําเร็จ" ได้โดยดูความแตกต่างระหว่างตัวเลขทั้ง 2 นี้ สำหรับหน้าเว็บที่คุณใช้ Speculation Rules API เพื่อแสดงหน้าเว็บล่วงหน้า คุณสามารถปรับกฎให้เหมาะสมเพื่อให้มั่นใจว่าอัตราการเข้าชมจะสูงอยู่เสมอเพื่อรักษาสมดุลระหว่างการใช้ทรัพยากรของผู้ใช้เพื่อช่วยเหลือผู้ใช้กับการใช้ทรัพยากรโดยไม่จำเป็น

โปรดทราบว่าการแสดงผลล่วงหน้าบางอย่างอาจเกิดขึ้นเนื่องจากการแสดงผลล่วงหน้าของแถบที่อยู่ ไม่ใช่แค่กฎการคาดคะเน คุณสามารถตรวจสอบ document.referrer (ซึ่งจะว่างเปล่าสำหรับการไปยังแถบที่อยู่ รวมถึงการไปยังแถบที่อยู่ที่แสดงผลล่วงหน้า) หากต้องการแยกความแตกต่าง

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

ผลกระทบต่อส่วนขยาย

ดูโพสต์เฉพาะเรื่องเกี่ยวกับส่วนขยาย Chrome: การขยาย API เพื่อรองรับการไปยังส่วนต่างๆ ทันที ซึ่งจะอธิบายข้อควรพิจารณาเพิ่มเติมบางอย่างที่ผู้เขียนส่วนขยายอาจต้องคำนึงถึงสำหรับหน้าเว็บที่แสดงผลล่วงหน้า

ความคิดเห็น

ทีม Chrome กำลังพัฒนาการแสดงผลล่วงหน้าอย่างต่อเนื่อง และมีแผนมากมายที่จะขยายขอบเขตของสิ่งที่พร้อมใช้งานใน Chrome เวอร์ชัน 108 เรายินดีรับฟังความคิดเห็นเกี่ยวกับที่เก็บ GitHub หรือการใช้เครื่องมือติดตามปัญหาของเรา และหวังว่าจะได้รับฟังและแชร์กรณีศึกษาเกี่ยวกับ API ใหม่ที่น่าสนใจนี้

ลิงก์ที่เกี่ยวข้อง

• Codelab เกี่ยวกับกฎการคาดเดา
• การแก้ไขข้อบกพร่องของกฎการคาดเดา
• ขอแนะนำ NoState Prefetch
• ข้อกำหนดของ Speculation Rules API
• ที่เก็บ GitHub ของการคาดการณ์การนำทาง
• ส่วนขยาย Chrome: ขยาย API เพื่อรองรับการไปยังส่วนต่างๆ ทันที

คำขอบคุณ

ภาพปกโดย Marc-Olivier Jodoin ใน Unsplash