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

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

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

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

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

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

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

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

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

ตัวอย่างผลกระทบจากการแสดงผลล่วงหน้า

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

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

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

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

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

สำหรับ Use Case แรก คุณสามารถดูการคาดคะเน URL ของ Chrome ในหน้า chrome://predictors ดังนี้

หน้าเครื่องมือคาดการณ์ของ Chrome กรองให้แสดงการคาดคะเนระดับต่ำ (สีเทา) กลาง (เหลือง) และสูง (เขียว) ตามข้อความที่ป้อน
หน้าตัวคาดการณ์ของ Chrome

เส้นสีเขียวแสดงถึงความมั่นใจเพียงพอที่จะกระตุ้นการแสดงผลล่วงหน้า ในตัวอย่างนี้ การพิมพ์ "s" ให้ความเชื่อมั่นในระดับปานกลาง (สีเหลืองอำพัน) แต่เมื่อคุณพิมพ์ "sh" แล้ว Chrome มีความเชื่อมั่นมากพอว่าคุณมักจะไปยัง https://sheets.google.com

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

ตัวแปรเหล่านี้ยังเป็นตัวขับเคลื่อนตัวเลือกที่แนะนำในแถบที่อยู่ที่คุณอาจสังเกตเห็นด้วย

ฟีเจอร์ &quot;พิมพ์ตามตัวอย่าง&quot; ของแถบที่อยู่ Chrome
ฟีเจอร์ "พิมพ์ตามตัวอย่าง" ของแถบที่อยู่

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 กฎการคาดเดา ซึ่งจะแนะนำคุณเกี่ยวกับการเพิ่มกฎการคาดเดาลงในเว็บไซต์

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

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

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

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

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

eagerness เริ่มต้นสำหรับกฎ list รายการคือ immediate คุณสามารถใช้ตัวเลือก moderate และ conservative เพื่อจํากัดกฎ list ไว้เฉพาะ URL ที่ผู้ใช้โต้ตอบด้วยในรายการที่เฉพาะเจาะจง แต่ในกรณีส่วนใหญ่ กฎ document ที่มีเงื่อนไข where ที่เหมาะสมอาจเหมาะสมกว่า

eagerness เริ่มต้นสำหรับกฎ document รายการคือ conservative เนื่องจากเอกสารหนึ่งๆ อาจประกอบด้วย URL หลายรายการ คุณจึงควรใช้ immediate หรือ eager สำหรับกฎ document อย่างระมัดระวัง (ดูส่วนขีดจํากัดของ Chrome ถัดไป)

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

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

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

ดึงข้อมูลล่วงหน้า

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

<script type="speculationrules">
{
  "prefetch": [
    {
      "urls": ["next.html", "next2.html"]
    }
  ]
}
</script>

ขีดจํากัดของ Chrome

Chrome มีขีดจํากัดเพื่อป้องกันการใช้ Speculation Rules API มากเกินไป ดังนี้

ความกระตือรือร้น ดึงข้อมูลล่วงหน้า การแสดงผลล่วงหน้า
immediate / eager 50 10
moderate / conservative 2 (FIFO) 2 (FIFO)
ขีดจำกัดการคาดเดาใน Chrome

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

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

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

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

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

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

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

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

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

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

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

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

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

  • Chrome: 121
  • Edge: 121
  • Firefox: ไม่สนับสนุน
  • Safari: ไม่รองรับ

แหล่งที่มา

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

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

Speculation-Rules: "/speculationrules.json"

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

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

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

กฎการคาดเดาและ SPA

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

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

แก้ไขข้อบกพร่องของกฎการคาดเดา

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

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

คุณสามารถเพิ่มกฎการคาดเดาหลายกฎลงในหน้าเดียวกัน แล้วผนวกกฎที่มีอยู่ ดังนั้น วิธีการต่างๆ ต่อไปนี้จึงส่งผลให้ทั้ง one.html และ two.html แสดงผลก่อนโหลด

รายการ URL:

<script type="speculationrules">
{
  "prerender": [
    {
      "urls": ["one.html", "two.html"]
    }
  ]
}
</script>

สคริปต์ speculationrules หลายรายการ:

<script type="speculationrules">
{
  "prerender": [
    {
      "urls": ["one.html"]
    }
  ]
}
</script>
<script type="speculationrules">
{
  "prerender": [
    {
      "urls": ["two.html"]
    }
  ]
}
</script>

หลายรายการภายใน speculationrules 1 ชุด

<script type="speculationrules">
{
  "prerender": [
    {
      "urls": ["one.html"]
    },
    {
      "urls": ["two.html"]
    }
  ]
}
</script>

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

  • Chrome: 121.
  • Edge: 121
  • Firefox: ไม่รองรับ
  • Safari: ไม่รองรับ

แหล่งที่มา

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

เช่น Google Analytics ใช้พารามิเตอร์ UTM เพื่อวัดแคมเปญ แต่โดยปกติแล้วจะไม่ทําให้เซิร์ฟเวอร์แสดงหน้าเว็บอื่น ซึ่งหมายความว่า page1.html?utm_content=123 และ page1.html?utm_content=456 จะแสดงหน้าเดียวกันจากเซิร์ฟเวอร์ จึงนําหน้าเดียวกันมาใช้ซ้ำจากแคชได้

ในทํานองเดียวกัน แอปพลิเคชันอาจใช้พารามิเตอร์ URL อื่นๆ ที่จัดการเฉพาะฝั่งไคลเอ็นต์

ข้อเสนอ No-Vary-Search ทำให้เซิร์ฟเวอร์สามารถระบุพารามิเตอร์ที่ไม่สร้างความแตกต่างกับทรัพยากรที่นำส่ง ดังนั้นอนุญาตให้เบราว์เซอร์นำเอกสารเวอร์ชันที่แคชไว้ก่อนหน้านี้มาใช้ซ้ำซึ่งเพียงแค่พารามิเตอร์เหล่านี้ต่างกันเท่านั้น การดำเนินการนี้ใช้ได้ใน Chrome (และเบราว์เซอร์ที่ใช้ Chromium) สำหรับการคาดคะเนการนําทางในการโหลดล่วงหน้า (แม้ว่าเราจะพยายามรองรับการดำเนินการนี้สําหรับการแสดงผลล่วงหน้าด้วย)

กฎการคาดเดารองรับการใช้ expects_no_vary_search เพื่อระบุตำแหน่งที่คาดว่าระบบจะแสดงผลส่วนหัว HTTP ของ No-Vary-Search ซึ่งจะช่วยหลีกเลี่ยงการดาวน์โหลดที่ไม่จำเป็นได้มากขึ้น

<script type="speculationrules">
{
  "prefetch": [{
    "urls": ["/products*"],
    "expects_no_vary_search": "params=(\"id\")"
  }]
}
</script>

<a href="/products?id=123">Product 123</a>
<a href="/products?id=124">Product 124</a>

ในตัวอย่างนี้ HTML ของหน้าเริ่มต้น /products เหมือนกันสำหรับทั้งรหัสผลิตภัณฑ์ 123 และ 124 อย่างไรก็ตาม เนื้อหาของหน้าเว็บจะแตกต่างกันไปตามการแสดงผลฝั่งไคลเอ็นต์ที่ใช้ JavaScript เพื่อดึงข้อมูลผลิตภัณฑ์โดยใช้พารามิเตอร์การค้นหา id เราจึงทำการเตรียม URL นั้นไว้ล่วงหน้าและ URL ควรแสดงผลส่วนหัว HTTP No-Vary-Search ที่ระบุว่าหน้าเว็บสามารถใช้กับพารามิเตอร์การค้นหา id ใดก็ได้

อย่างไรก็ตาม หากผู้ใช้คลิกลิงก์ใดลิงก์หนึ่งก่อนที่การโหลดล่วงหน้าจะเสร็จสมบูรณ์ เบราว์เซอร์อาจไม่ได้รับหน้า /products ในกรณีนี้ เบราว์เซอร์จะไม่ทราบว่าจะมีส่วนหัว HTTP No-Vary-Search หรือไม่ จากนั้นเบราว์เซอร์จะมีตัวเลือกว่าจะดึงข้อมูลลิงก์อีกครั้งหรือรอให้ระบบทำการเตรียมข้อมูลล่วงหน้าจนเสร็จสมบูรณ์เพื่อดูว่าลิงก์มีส่วนหัว HTTP ของ No-Vary-Search หรือไม่ การตั้งค่า expects_no_vary_search ช่วยให้เบราว์เซอร์ทราบว่าการตอบสนองของหน้าเว็บควรมีส่วนหัว HTTP No-Vary-Search และรอให้การดึงข้อมูลล่วงหน้านั้นเสร็จสมบูรณ์

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

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

โดยค่าเริ่มต้น การคาดคะเนจะจํากัดไว้ที่หน้าเว็บที่มีแหล่งที่มาเดียวกัน การคาดเดาหน้าแบบข้ามต้นทางในเว็บไซต์เดียวกัน (เช่น https://a.example.com อาจแสดงผลหน้าเว็บล่วงหน้าใน https://b.example.com) หากต้องการใช้หน้าที่คาดเดานี้ (ในตัวอย่างนี้ https://b.example.com) จำเป็นต้องเลือกใช้โดยรวมส่วนหัว HTTP ของ Supports-Loading-Mode: credentialed-prerender มิเช่นนั้น Chrome จะยกเลิกการคาดคะเน

เวอร์ชันในอนาคตอาจอนุญาตการแสดงผลล่วงหน้าสำหรับหน้าเว็บแบบข้ามต้นทางที่ไม่ใช่เว็บไซต์เดียวกัน ตราบใดที่ไม่มีคุกกี้สําหรับหน้าที่แสดงผลล่วงหน้า และหน้าที่แสดงผลล่วงหน้าเลือกใช้ส่วนหัว HTTP ของ Supports-Loading-Mode: uncredentialed-prerender ที่คล้ายกัน

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

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

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

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

ระบบไม่รองรับกฎการคาดคะเนสําหรับการเรียกข้อมูลล่วงหน้าสําหรับหน้าที่ Service Worker ควบคุม เรากำลังดำเนินการเพิ่มการรองรับนี้ ติดตามข้อมูลอัปเดตเกี่ยวกับปัญหาเกี่ยวกับ Service Worker ได้ที่ส่วนนี้ ระบบรองรับการแสดงผลล่วงหน้าสําหรับหน้าที่ควบคุมโดย Service Worker

รองรับ Detect Speculation Rules API

คุณสามารถตรวจหาการรองรับ Speculation Rules API ด้วยการตรวจสอบ HTML มาตรฐาน ดังนี้

if (HTMLScriptElement.supports && HTMLScriptElement.supports('speculationrules')) {
  console.log('Your browser supports the Speculation Rules API.');
}

เพิ่มกฎการคาดเดาแบบไดนามิกผ่าน JavaScript

ต่อไปนี้คือตัวอย่างของการเพิ่มกฎการคาดเดา prerender ด้วย JavaScript

if (HTMLScriptElement.supports &&
    HTMLScriptElement.supports('speculationrules')) {
  const specScript = document.createElement('script');
  specScript.type = 'speculationrules';
  specRules = {
    prerender: [
      {
        urls: ['/next.html'],
      },
    ],
  };
  specScript.textContent = JSON.stringify(specRules);
  console.log('added speculation rules to: next.html');
  document.body.append(specScript);
}

คุณดูการสาธิตการแสดงผลล่วงหน้าของ Speculation Rules API โดยใช้การแทรก JavaScript ได้ในหน้าสาธิตการแสดงผลล่วงหน้านี้

การวางองค์ประกอบ <script type = "speculationrules"> ลงใน DOM โดยตรงโดยใช้ innerHTML จะไม่ลงทะเบียนกฎการคาดการณ์ เพื่อเหตุผลด้านความปลอดภัย และต้องเพิ่มกฎนี้ตามที่แสดงไว้ก่อนหน้านี้ อย่างไรก็ตาม เนื้อหาที่แทรกแบบไดนามิกโดยใช้ innerHTML ซึ่งมีลิงก์ใหม่จะได้รับการคัดสรรโดยกฎที่มีอยู่ในหน้า

ในทํานองเดียวกัน การแก้ไขแผงองค์ประกอบในเครื่องมือสําหรับนักพัฒนาเว็บใน Chrome โดยตรงเพื่อเพิ่มองค์ประกอบ <script type = "speculationrules"> จะไม่ลงทะเบียนกฎการคาดคะเน แต่จะต้องมีการเรียกใช้สคริปต์เพื่อเพิ่มองค์ประกอบนี้ลงใน DOM แบบไดนามิกจากคอนโซลเพื่อแทรกกฎ

เพิ่มกฎการคาดเดาผ่านเครื่องมือจัดการแท็ก

หากต้องการเพิ่มกฎการคาดการณ์โดยใช้เครื่องมือจัดการแท็ก เช่น Google Tag Manager (GTM) จะต้องแทรกกฎเหล่านี้ผ่าน JavaScript แทนการเพิ่มองค์ประกอบ <script type = "speculationrules"> ผ่าน GTM โดยตรงด้วยเหตุผลเดียวกันกับที่กล่าวไว้ก่อนหน้านี้

การกําหนดค่าแท็ก HTML ที่กําหนดเองใน Google Tag Manager
การเพิ่มกฎการคาดคะเนผ่าน Google Tag Manager

โปรดทราบว่าตัวอย่างนี้ใช้ 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 คุณจะทราบว่าหน้าเว็บมีการแสดงผลล่วงหน้าแล้ว

คอนโซลใน Chrome DevTools ที่แสดงค่าบวกของ activationStart ซึ่งบ่งบอกว่าหน้าเว็บได้รับการแสดงผลล่วงหน้า
การทดสอบการแสดงผลล่วงหน้าในคอนโซล

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

การใช้ API เหล่านี้จะทำให้ JavaScript ฟรอนท์เอนด์สามารถตรวจจับและดำเนินการกับหน้าที่แสดงผลล่วงหน้าอย่างเหมาะสม

ผลกระทบต่อข้อมูลวิเคราะห์

Analytics ใช้เพื่อวัดการใช้งานเว็บไซต์ เช่น ใช้ Google Analytics เพื่อวัดการดูหน้าเว็บและเหตุการณ์ หรือวัดเมตริกประสิทธิภาพของหน้าเว็บโดยใช้การตรวจสอบผู้ใช้จริง (RUM)

หน้าเว็บควรแสดงผลล่วงหน้าเฉพาะในกรณีที่มีแนวโน้มสูงที่ผู้ใช้จะโหลดหน้าเว็บ ด้วยเหตุนี้ ตัวเลือกการแสดงผลล่วงหน้าของแถบที่อยู่ของ Chrome จึงจะเกิดขึ้นก็ต่อเมื่อมีแนวโน้มสูงมาก (มากกว่า 80% ของเวลา)

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

ซึ่งทำได้โดยใช้ Promise ที่รอเหตุการณ์ prerenderingchange หากเอกสารกำลังแสดงผลล่วงหน้า หรือแสดงผลทันทีหากกำลังแสดงผล

// Set up a promise for when the page is activated,
// which is needed for prerendered pages.
const whenActivated = new Promise((resolve) => {
  if (document.prerendering) {
    document.addEventListener('prerenderingchange', resolve, {once: true});
  } else {
    resolve();
  }
});

async function initAnalytics() {
  await whenActivated;
  // Initialise your analytics
}

initAnalytics();

อีกวิธีหนึ่งคือเลื่อนเวลากิจกรรมการวิเคราะห์จนกว่าหน้าเว็บจะปรากฏขึ้นเป็นครั้งแรก ซึ่งจะครอบคลุมทั้งกรณีที่แสดงผลก่อนการโหลดและเมื่อเปิดแท็บในเบื้องหลัง (เช่น คลิกขวาแล้วเปิดในแท็บใหม่)

// Set up a promise for when the page is first made visible
const whenFirstVisible = new Promise((resolve) => {
  if (document.hidden) {
    document.addEventListener('visibilitychange', resolve, {once: true});
  } else {
    resolve();
  }
});

async function initAnalytics() {
  await whenFirstVisible;
  // Initialise your analytics
}

initAnalytics();

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

ระงับเนื้อหาอื่นๆ ระหว่างการแสดงผลก่อนเผยแพร่

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

ตัวอย่างเช่น ใช้สคริปต์นี้

<script src="https://example.com/app/script.js" async></script>

คุณสามารถเปลี่ยนการตั้งค่านี้เป็นเอลิเมนต์สคริปต์ที่แทรกแบบไดนามิกซึ่งจะแทรกโดยอิงตามฟังก์ชัน whenActivated ก่อนหน้านี้เท่านั้นได้ ดังนี้

async function addScript(scriptUrl) {
  await whenActivated;
  const script = document.createElement('script');
  script.src = 'scriptUrl';
  document.body.appendChild(script);
}

addScript('https://example.com/app/script.js');

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

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

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

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

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

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

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

ตั้งแต่เวอร์ชัน 3.1.0 เป็นต้นไป ไลบรารี web-vitals ได้รับการอัปเดตให้จัดการการนําทางที่แสดงผลล่วงหน้าในลักษณะเดียวกับที่ Chrome วัด Core Web Vitals เวอร์ชันนี้ยังแจ้งการนําทางที่แสดงผลล่วงหน้าสําหรับเมตริกเหล่านั้นในแอตทริบิวต์ Metric.navigationType ด้วยหากหน้าเว็บแสดงผลล่วงหน้าทั้งหมดหรือบางส่วน

วัดการแสดงผลล่วงหน้า

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

// Set Custom Dimension for Prerender status
gtag('set', { 'dimension1': pagePrerendered() });
// Initialise GA - including sending page view by default
gtag('config', 'G-12345678-1');

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

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

วัดอัตรา Hit

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

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

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

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

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

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

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

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

ความคิดเห็น

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

กิตติกรรมประกาศ

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