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

Barry Pollard

เผยแพร่เมื่อวันที่ 2 ธันวาคม 2022 อัปเดตล่าสุดเมื่อวันที่ 29 ตุลาคม 2026

Browser Support

  • Chrome: 109.
  • Edge: 109.
  • Firefox Technology Preview: supported.
  • Safari: behind a flag.

Source

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ฟีเจอร์ &quot;Typeahead&quot; ในแถบที่อยู่ของ Chrome
ฟีเจอร์ "Typeahead" ของแถบที่อยู่

Chrome จะอัปเดตตัวคาดคะเนอย่างต่อเนื่องตามสิ่งที่คุณพิมพ์และเลือก

  • สำหรับระดับความเชื่อมั่นที่มากกว่า 30% (แสดงเป็นสีเหลืองอำพัน) Chrome จะเชื่อมต่อกับโดเมนล่วงหน้าในเชิงรุก แต่จะไม่แสดงผลหน้าเว็บล่วงหน้า
  • สำหรับระดับความเชื่อมั่นที่มากกว่า 50% (แสดงเป็นสีเขียว) Chrome จะแสดงผล URL ล่วงหน้า

Speculation Rules API

สำหรับตัวเลือกการแสดงผลล่วงหน้าของ Speculation Rules API นักพัฒนาเว็บสามารถแทรกคำสั่ง JSON ลงในหน้าเว็บเพื่อแจ้งเบราว์เซอร์เกี่ยวกับ URL ที่จะแสดงผลล่วงหน้า

รายชื่อ URL

กฎการคาดเดาอาจอิงตามรายการ URL ดังนี้

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

กฎเอกสาร

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

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

Browser Support

  • Chrome: 121.
  • Edge: 121.
  • Firefox Technology Preview: supported.
  • Safari: behind a flag.

Source

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

  • conservative: การดำเนินการนี้จะคาดเดาเมื่อมีการกดตัวชี้หรือการแตะ
  • moderate: บนเดสก์ท็อป ระบบจะทำการคาดเดาหากคุณวางเคอร์เซอร์เหนือลิงก์เป็นเวลา 200 มิลลิวินาที (หรือในเหตุการณ์ pointerdown หากเร็วกว่านั้น และในอุปกรณ์เคลื่อนที่ที่ไม่มีเหตุการณ์ hover) ในอุปกรณ์เคลื่อนที่ เราได้เปลี่ยนไปใช้ฮิวริสติกวิวพอร์ตที่ซับซ้อนตั้งแต่เดือนสิงหาคม 2025 ฮิวริสติกวิวพอร์ตที่ซับซ้อนจะทริกเกอร์ 500 มิลลิวินาทีหลังจากที่ผู้ใช้หยุดเลื่อน สำหรับ Anchor ที่อยู่ภายใน 30% ของระยะทางแนวตั้งจากตัวชี้ก่อนหน้า โดยที่ Anchor มีขนาดอย่างน้อย 0.5 เท่าของ Anchor ที่ใหญ่ที่สุดในวิวพอร์ต ตามที่อธิบายไว้ในเอกสารนี้
  • eager: ความกระตือรือร้นนี้เคยทำงานเหมือนกับ immediate แต่มีการเปลี่ยนแปลงตั้งแต่ Chrome 143 ในเดสก์ท็อป ระบบจะดำเนินการคาดเดาหากคุณวางเคอร์เซอร์เหนือลิงก์เป็นเวลา 10 มิลลิวินาที ในอุปกรณ์เคลื่อนที่ เราได้เปลี่ยนไปใช้ฮิวริสติกวิวพอร์ตแบบง่ายตั้งแต่เดือนมกราคม 2026 ฮิวริสติกวิวพอร์ตแบบง่ายจะทริกเกอร์ 50 มิลลิวินาทีหลังจากที่ Anchor เข้าสู่วิวพอร์ต
  • immediate: ใช้เพื่อคาดเดาโดยเร็วที่สุด กล่าวคือ ทันทีที่มีการสังเกตกฎการคาดเดา

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

eagerness เริ่มต้นสำหรับกฎ document คือ conservative เนื่องจากเอกสารอาจประกอบด้วย URL จำนวนมาก คุณจึงควรใช้ immediate สำหรับกฎ 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>

Prerender until script

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

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

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

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

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

ขีดจำกัดของ Chrome

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

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

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

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

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

นอกจากนี้ Chrome ยังพิจารณาเพิ่มขีดจำกัดเป็น 5 ในอุปกรณ์เคลื่อนที่สำหรับ eager และ moderate อย่างน้อยก็สำหรับการดึงข้อมูลล่วงหน้า เนื่องจากเป็นวิธีการเรียนรู้ที่แม่นยำน้อยกว่า นักพัฒนาแอปที่ใช้ eager อาจพิจารณาใช้กฎ conservative เพิ่มเติมเมื่อมีลิงก์หลายรายการในวิวพอร์ต เพื่อให้ยังคงคาดเดาได้แม้ว่าจะไม่ได้เลือกเป็นลิงก์ 2 รายการแรกก็ตาม

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

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

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

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

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

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

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

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

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

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

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

Browser Support

  • Chrome: 121.
  • Edge: 121.
  • Firefox: not supported.
  • Safari: behind a flag.

Source

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

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

Speculation-Rules: "/speculationrules.json"

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

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

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

ช่องแท็กกฎการคาดเดา

Browser Support

  • Chrome: 136.
  • Edge: 136.
  • Firefox: not supported.
  • Safari: behind a flag.

Source

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

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

หรือที่ระดับกฎแต่ละรายการ ดังนี้

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

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

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

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

แท็กกฎยังแสดงในเครื่องมือสำหรับนักพัฒนาเว็บใน Chrome ด้วย

ช่อง target_hint ของกฎการคาดเดา

Browser Support

  • Chrome: 138.
  • Edge: 138.
  • Firefox: not supported.
  • Safari: not supported.

Source

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

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

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

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

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

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

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

ระบบรองรับกฎการคาดเดาสำหรับการนำทางหน้าเว็บแบบเต็มที่จัดการโดยเบราว์เซอร์เท่านั้น และไม่รองรับแอปหน้าเว็บเดียว (SPA) หรือหน้าเชลล์แอป สถาปัตยกรรมเหล่านี้ไม่ได้ใช้การดึงข้อมูลเอกสาร แต่จะใช้ 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>

Browser Support

  • Chrome: 141.
  • Edge: 141.
  • Firefox: 154.
  • Safari: not supported.

Source

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

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

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

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

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

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

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

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

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

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

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

ตรวจหาการรองรับ Speculation Rules API

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

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

เพิ่ม Speculation Rules แบบไดนามิกผ่าน 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 โดยตรงด้วยเหตุผลเดียวกับที่กล่าวไว้ก่อนหน้านี้

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

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

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

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

Browser Support

  • Chrome: 138.
  • Edge: 138.
  • Firefox: not supported.
  • Safari: not supported.

Source

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

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

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

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

เนื่องจากกฎการคาดเดาใช้องค์ประกอบ <script> แม้ว่าจะมีเพียง JSON แต่ก็ต้องรวมไว้ใน script-src Content-Security-Policy หากเว็บไซต์ใช้สิ่งนี้ ไม่ว่าจะใช้แฮชหรือ Nonce ก็ตาม

คุณสามารถเพิ่ม inline-speculation-rules ใหม่ลงใน script-src เพื่อให้รองรับองค์ประกอบ <script type="speculationrules"> ที่แทรกจากสคริปต์แฮชหรือ Nonce ได้ ซึ่งไม่รองรับกฎที่รวมอยู่ใน HTML เริ่มต้น ดังนั้น JavaScript จึงต้องแทรกกฎสำหรับเว็บไซต์ที่ใช้ CSP ที่เข้มงวด

ตรวจจับและปิดใช้การแสดงผลล่วงหน้า

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

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

เปิดใช้และปิดใช้การแสดงผลล่วงหน้าใน Chrome

การแสดงผลล่วงหน้าจะเปิดใช้สำหรับผู้ใช้ Chrome ที่มีการตั้งค่า "โหลดหน้าเว็บล่วงหน้า" ใน chrome://settings/performance/ เท่านั้น นอกจากนี้ การแสดงผลล่วงหน้าจะปิดใช้ในอุปกรณ์ที่มีหน่วยความจำต่ำ หรือหากระบบปฏิบัติการอยู่ในโหมดประหยัดอินเทอร์เน็ตหรือโหมดประหยัดพลังงาน โปรดดูส่วนขีดจำกัดของ Chrome

ตรวจจับและปิดใช้การแสดงผลล่วงหน้าฝั่งเซิร์ฟเวอร์

ระบบจะส่งหน้าที่แสดงผลล่วงหน้าพร้อมส่วนหัว HTTP Sec-Purpose ดังนี้

Sec-Purpose: prefetch;prerender

หน้าเว็บที่ดึงข้อมูลล่วงหน้าโดยใช้ Speculation Rules API จะมีการตั้งค่าส่วนหัวนี้เป็น prefetch เท่านั้น

Sec-Purpose: prefetch

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

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

ตรวจหาการแสดงผลล่วงหน้าใน JavaScript

document.prerendering API จะแสดงผล true ขณะที่หน้าเว็บกำลังแสดงผลล่วงหน้า หน้าเว็บสามารถใช้ฟีเจอร์นี้เพื่อป้องกันหรือเลื่อนกิจกรรมบางอย่างในระหว่างการแสดงผลล่วงหน้าจนกว่าหน้าเว็บจะเปิดใช้งานจริง

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

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

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

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

คอนโซลในเครื่องมือสำหรับนักพัฒนาเว็บใน Chrome ที่แสดง 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 ที่ไม่ใช่ 0 ของ PerformanceNavigationTiming จากนั้นคุณสามารถบันทึกข้อมูลนี้โดยใช้มิติข้อมูลที่กำหนดเองหรือที่คล้ายกันเมื่อบันทึกการดูหน้าเว็บ เช่น ใช้ฟังก์ชัน pagePrerendered ที่อธิบายไว้ก่อนหน้านี้

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

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

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

วัดอัตราการเข้าถึง

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

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

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

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

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

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

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

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

ความคิดเห็น

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

การรับทราบ

ภาพขนาดย่อโดย Marc-Olivier Jodoin บน Unsplash