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

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

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

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

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

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

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

หน้าเว็บสามารถแสดงผลล่วงหน้าได้ 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 ได้เตรียม Speculation Rules Codelab ซึ่งจะแนะนำวิธีเพิ่มกฎการคาดเดาลงในเว็บไซต์

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

รองรับ Detect Speculation Rules API

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

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

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

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

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

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

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

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

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

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

โปรดทราบว่าตัวอย่างนี้ใช้ var เนื่องจาก GTM ไม่รองรับ const

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

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

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

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

เมื่อเปิดใช้งานเอกสารที่แสดงผลล่วงหน้าแล้ว ระบบจะตั้งค่า activationStart ของ PerformanceNavigationTiming เป็นเวลาที่ไม่ใช่ 0 ซึ่งแสดงถึงเวลาระหว่างที่เริ่มแสดงผลล่วงหน้าและเปิดใช้งานเอกสารจริง

คุณอาจมีฟังก์ชันเพื่อตรวจสอบหน้าแสดงผลล่วงหน้าและแสดงผลล่วงหน้า ดังนี้

function pagePrerendered() {
  return (
    document.prerendering ||
    self.performance?.getEntriesByType?.('navigation')[0]?.activationStart > 0
  );
}

วิธีที่ง่ายที่สุดในการดูว่าหน้าเว็บได้รับการแสดงผลล่วงหน้า (ทั้งหน้าหรือบางส่วน) หรือไม่คือเปิดเครื่องมือสำหรับนักพัฒนาเว็บหลังจากที่เปิดใช้งานหน้าเว็บแล้ว และพิมพ์ performance.getEntriesByType('navigation')[0].activationStart ในคอนโซล หากระบบแสดงผลค่าที่ไม่ใช่ 0 แสดงว่าหน้าเว็บได้รับการแสดงผลล่วงหน้าแล้ว

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

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

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

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

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

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

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

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

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

initAnalytics();

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

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

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

initAnalytics();

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

วัดการประมวลผลล่วงหน้า

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

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

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

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

วัดอัตรา Hit

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

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

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

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

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

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

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

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

ความคิดเห็น

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

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

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

ขอขอบคุณ

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