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

Barry Pollard

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

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

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

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

ตอนนี้ทีม 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

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

วันที่

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

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

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

วันที่

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

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

API ของกฎการคาดเดา

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

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

หรือตามกฎเอกสาร (ใช้ได้ใน Chrome 121) ซึ่งแสดงผลลิงก์ที่พบในเอกสารล่วงหน้าตามตัวเลือก href (อิงตาม API รูปแบบ URL) หรือตัวเลือก CSS

<script type="speculationrules">
{
  "prerender": [{
    "where": {
      "and": [
        { "href_matches": "/*" },
        { "not": {"href_matches": "/wp-admin"}},
        { "not": {"href_matches": "/*\\?*(^|&)add-to-cart=*"}},
        { "not": {"selector_matches": ".do-not-prerender"}},
        { "not": {"selector_matches": "[rel~=nofollow]"}}
      ]
    }
  }]
}
</script>

ทีม Chrome ได้เตรียม Codelab กฎการคาดเดา ซึ่งจะแนะนำคุณเกี่ยวกับการเพิ่มกฎการคาดเดาลงในเว็บไซต์

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

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

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

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

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

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

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

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

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

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

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

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

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

การตั้งค่า moderate และ conservative ซึ่งขึ้นอยู่กับการโต้ตอบของผู้ใช้ ทำงานในลักษณะแบบ First In First Out (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

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

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

Speculation-Rules: "/speculationrules.json"

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

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

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

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

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

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

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

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

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

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

รายการ URL:

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

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

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

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

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

ทีมสนับสนุนของ No-Vary-Search

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ตรวจหาการรองรับ 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 ซึ่งมีลิงก์ใหม่จะได้รับการเลือกโดยกฎที่มีอยู่ในหน้าเว็บ

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

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

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

วันที่

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

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

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

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

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

คุณสามารถเพิ่ม inline-speculation-rules ใหม่ใน script-src เพื่อให้ระบบรองรับองค์ประกอบ <script type="speculationrules"> ที่แทรกจากแฮชหรือสคริปต์ที่ไม่ใช่สคริปต์ วิธีนี้ไม่รองรับกฎที่รวมอยู่ใน 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 หรือ 304) หน้าเว็บจะไม่แสดงล่วงหน้าและระบบจะทิ้งหน้าเว็บที่ดึงข้อมูลล่วงหน้าไป

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

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

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

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

initAnalytics();

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

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

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

initAnalytics();

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

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

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

ตัวอย่างเช่น สำหรับสคริปต์นี้:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

วัดอัตรา Hit

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

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

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

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

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

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

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

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

ความคิดเห็น

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

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

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

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

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