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

Barry Pollard

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

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

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

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

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

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

หน้าเว็บสามารถแสดงผลล่วงหน้าได้ 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

สำหรับ 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 มิลลิวินาที หรือเหตุการณ์ตัวชี้เป็นการใช้กฎการคาดเดาพื้นฐานแต่มีประสิทธิภาพ:

<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 จะป้องกันไม่ให้ใช้การคาดการณ์ในบางเงื่อนไข ซึ่งรวมถึง

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

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

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

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

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

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

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

คุณสามารถเพิ่มกฎการคาดเดาใน <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 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ชุดเดียว

<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

รองรับ 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 แบบไดนามิกจากคอนโซลเพื่อแทรกกฎ

เพิ่มกฎการคาดเดาผ่าน Tag Manager

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

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

ในการวัดเมตริกประสิทธิภาพ 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 ที่สำเร็จ" ได้โดยดูที่ผลต่างระหว่างตัวเลข 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