คู่มือการใช้งานกฎการคาดเดาสําหรับเว็บไซต์ที่ซับซ้อนมากขึ้น

Barry Pollard

เผยแพร่: 7 มีนาคม 2025

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

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

การวางแผน

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

ตัดสินใจว่าจะใช้กฎการคาดเดาอย่างไร

การตัดสินใจอย่างแรกๆ ที่คุณต้องทำคือวิธีใช้กฎการเก็งกำไรในเว็บไซต์ เนื่องจากมีวิธีการต่างๆ ที่คุณใช้ได้ ดังนี้

• ใน HTML ของหน้าเว็บโดยตรง
• การใช้ JavaScript
• การใช้ส่วนหัว HTTP

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

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

รวมกฎการคาดเดาไว้ใน HTML ของหน้าเว็บโดยตรง

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

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

<script type="speculationrules">
  {
    "prerender": [{
      "where": { "selector_matches": ".prerender" }
    }],
    "prefetch": [{
      "where": { "selector_matches": ".prefetch" }
    }]
  }
</script>

สคริปต์ก่อนหน้านี้จะแสดงผลลิงก์ที่มีคลาส prerender ล่วงหน้า และแสดงผลล่วงหน้าในทำนองเดียวกันเมื่อลิงก์มีคลาส prefetch ซึ่งช่วยให้นักพัฒนาแอปรวมคลาสเหล่านี้ไว้ใน HTML เพื่อเรียกให้เกิดการคาดเดาได้

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

หรือหากจำเป็นต้องใช้กฎการคาดการณ์ที่เฉพาะเจาะจงมากขึ้น กฎเฉพาะหน้าหรือเฉพาะเทมเพลตจะอนุญาตให้ใช้กฎที่แตกต่างกันสำหรับบางหน้าหรือบางประเภทหน้า

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

เพิ่มกฎการคาดเดาโดยใช้ JavaScript

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

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

ดังที่ได้กล่าวไปก่อนหน้านี้ อีกวิธีในการแทรกกฎใหม่คือให้มีกฎเอกสารพื้นฐานในหน้าเว็บ และมี JavaScript ที่ทริกเกอร์กฎเอกสารด้วยการเพิ่มคลาสที่เหมาะสมลงในลิงก์ซึ่งทําให้ตรงกับกฎ

เพิ่มกฎการคาดเดาโดยใช้ส่วนหัว HTTP

ตัวเลือกสุดท้ายสำหรับนักพัฒนาแอปคือการรวมกฎโดยใช้ส่วนหัว HTTP ดังนี้

Speculation-Rules: "/speculationrules.json"

มีข้อกําหนดเพิ่มเติมบางอย่างเกี่ยวกับวิธีนําส่งและใช้ทรัพยากรกฎ (/speculationrules.json ในตัวอย่างนี้)

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

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

พิจารณาผลกระทบด้านต้นทุน

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

พิจารณาค่าใช้จ่ายสำหรับผู้ใช้

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

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

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

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

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

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

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

พิจารณาการโหลดแบ็กเอนด์เพิ่มเติม

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

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

ทั้งนี้ขึ้นอยู่กับโครงสร้างพื้นฐานของเว็บไซต์และกระบวนการเผยแพร่ของคุณ

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

นอกจากนี้ คุณยังใช้เซิร์ฟเวอร์หรือ CDN เพื่อควบคุมผลการคาดคะเนตามที่ระบุโดยส่วนหัว HTTP ของ sec-purpose ได้ด้วย ตัวอย่างเช่น ผลิตภัณฑ์ Speed Brain ของ Cloudflare จะอนุญาตเฉพาะการคาดการณ์ที่แคชไว้แล้วในเซิร์ฟเวอร์ Edge ของ CDN และจะไม่ส่งคำขอกลับไปที่ต้นทาง

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

ค้นหาจุดสมดุลระหว่างการคาดเดามากเกินไปหรือน้อยเกินไป

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

ในกรณีที่ต้นทุนต่ำ (เช่น หน้าเว็บขนาดเล็กที่สร้างขึ้นแบบคงที่ซึ่งแคชไว้ในโหนด Edge ของ CDN) คุณก็อาจใช้การคาดการณ์ได้มากขึ้น

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

ขั้นตอนในการใช้กฎการคาดเดา

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

เริ่มต้นด้วย prefetch

โดยทั่วไปแล้ว การใช้การเรียกข้อมูลล่วงหน้าในเว็บไซต์ส่วนใหญ่ค่อนข้างปลอดภัย และเป็นแนวทางเริ่มต้นที่หลายรายใช้ รวมถึงการเปิดตัวในวงกว้าง เช่น Cloudflare และ WordPress

ปัญหาหลักที่ควรทราบคือ ในกรณีที่การเรียกข้อมูลหน้าเว็บล่วงหน้าจะทําให้สถานะมีการเปลี่ยนแปลงและเกิดค่าใช้จ่ายฝั่งเซิร์ฟเวอร์ โดยเฉพาะสําหรับหน้าที่แคชไม่ได้ ตามหลักการแล้ว การเปลี่ยนแปลงสถานะ เช่น การโหลดหน้า /logout ล่วงหน้า ไม่ควรใช้ลิงก์ GET แต่น่าเสียดายที่สิ่งนี้พบได้ทั่วไปบนเว็บ

คุณยกเว้น URL ดังกล่าวจากกฎได้โดยเฉพาะ ดังนี้

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

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

การแสดงผลล่วงหน้าที่มีความเสี่ยงต่ำ

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

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

โหลดหน้าเว็บทั่วไปล่วงหน้าเพื่อปรับปรุงการแสดงผลล่วงหน้าแบบไม่กระตือรือร้น

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

<script type="speculationrules">
  {
    "prefetch": [{
      "urls": ["next.html", "next2.html"],
      "eagerness": "eager"
    }],
    "prerender": [{
      "where": {
        "and": [
          { "href_matches": "/*" },
          { "not": {"href_matches": "/logout"}}
        ]
      },
      "eagerness": "moderate"
    }]
  }
</script>

การประมวลผลล่วงหน้าก่อนหน้านี้

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

ซึ่งทำได้โดยใช้รายการ URL แบบคงที่ (เช่น ตัวอย่างการเรียกข้อมูลล่วงหน้าก่อนหน้านี้) หรือใช้ selector_matches เพื่อระบุ URL จํานวนน้อย (ควรเป็น 1-2 หน้า) โดยมีกฎเอกสารครอบคลุม URL อื่นๆ ดังนี้

<script type="speculationrules">
  {
    "prerender": [
      {
        "where": {
          "selector_matches": : ".prerender"
        },
        "eagerness": "eager",
      },
      {
        "where": {
          "and": [
            { "href_matches": "/*" },
            { "not": {"href_matches": "/logout"}}
          ]
        },
        "eagerness": "moderate"
      }
    ]
  }
</script>

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

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

Analytics, โฆษณา และ JavaScript

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

ผู้ให้บริการข้อมูลวิเคราะห์บางราย (เช่น Google Analytics) และผู้ให้บริการโฆษณาบางราย (เช่น แท็กผู้เผยแพร่โฆษณาของ Google) รองรับกฎการคาดคะเนอยู่แล้ว และจะไม่บันทึกการดูจนกว่าหน้าเว็บจะเปิดใช้งาน อย่างไรก็ตาม ผู้ให้บริการรายอื่นหรือข้อมูลวิเคราะห์ที่กําหนดเองที่คุณติดตั้งใช้งานอาจต้องพิจารณาเพิ่มเติม

คุณสามารถเพิ่มการตรวจสอบลงใน JavaScript เพื่อป้องกันการเรียกใช้โค้ดบางรายการจนกว่าหน้าเว็บจะเปิดใช้งานหรือแสดงให้มองเห็น และแม้แต่รวมองค์ประกอบ <script> ทั้งหมดไว้ในการตรวจสอบดังกล่าว เมื่อหน้าเว็บใช้เครื่องมือจัดการแท็กเพื่อแทรกสคริปต์ดังกล่าว คุณอาจจัดการกับปัญหาทั้งหมดได้ในครั้งเดียวโดยการเลื่อนเวลาสคริปต์เครื่องมือจัดการแท็กเอง

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

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

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

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

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

อัปเดตการคาดคะเนการพักหน้าจอ

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

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

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

หรือหน้าเว็บที่แสดงผลล่วงหน้าจะรับการอัปเดตโดยใช้เซิร์ฟเวอร์ได้ (โดยใช้การเชื่อมต่อ fetch() เป็นระยะๆ หรือการเชื่อมต่อ WebSocket) แต่อาจมีความล่าช้าในการอัปเดต

ยกเลิกหรือรีเฟรชการคาดคะเนการแสดงผลล่วงหน้า

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

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

หากต้องการยกเลิกการคาดเดา คุณต้องนํากฎการคาดเดาออกจากหน้าเว็บ หรือนําคลาสหรือเกณฑ์การจับคู่อื่นๆ ออกหากใช้วิธีการดังกล่าว หรือหน้าเว็บที่คาดคะเนจะเรียก window.close() ได้หากตรวจพบว่าหน้าเว็บนั้นไม่ใช่หน้าปัจจุบันอีกต่อไป แต่หากหน้าเว็บตรวจพบปัญหานี้ ตัวเลือกที่ดีกว่าคือการอัปเดตสถานะของหน้าเว็บเพื่อให้เป็นปัจจุบันอีกครั้ง

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

async function refreshSpeculations() {
  const speculationScripts = document.querySelectorAll('script[type="speculationrules"]');

  for (const speculationScript of speculationScripts) {
    // Get the current rules as JSON text
    const ruleSet = speculationScript.textContent;

    // Remove the existing script to reset prerendering
    speculationScript.remove();
    
    // Await for a microtask before re-inserting.
    await Promise.resolve();

    // Reinsert rule in a new speculation rules script
    const newScript = document.createElement('script');
    newScript.type = 'speculationrules';
    newScript.textContent = ruleSet;
    console.log(newScript);

    // Append the new script back to the document
    document.body.appendChild(newScript);
  }
}

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

ตัวเลือกการรีเฟรชนี้ไม่ได้จํากัดไว้สําหรับกฎที่แทรกด้วย JavaScript เท่านั้น นอกจากนี้ คุณยังนํากฎแบบคงที่ที่อยู่ใน HTML ออกหรือเปลี่ยนแปลงในลักษณะเดียวกันได้ด้วย เนื่องจากเป็นการเปลี่ยนแปลง DOM มาตรฐาน คุณจะนํากฎการคาดเดา HTTP ออกไม่ได้ แต่สามารถนําเกณฑ์การจับคู่ (เช่น คลาส prerender) ออกและเพิ่มใหม่ด้วย JavaScript ได้

นอกจากนี้ Chrome ยังพิจารณาที่จะเพิ่มการรองรับ Clear-Site-Header เพื่ออนุญาตให้การตอบกลับของเซิร์ฟเวอร์ยกเลิกการแสดงผลล่วงหน้า (เช่น เมื่อมีการขอการอัปเดตตะกร้า)

วัดผลลัพธ์

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

เมื่อติดตั้งใช้งานด้วยหลายขั้นตอน (การเรียกข้อมูลล่วงหน้า การแสดงผลล่วงหน้าที่มีความเสี่ยงต่ำ และการแสดงผลล่วงหน้าขั้นต้น) คุณควรวัดผลในแต่ละขั้นตอน

วิธีวัดความสําเร็จ

กฎการคาดการณ์ควรส่งผลเชิงบวกต่อเมตริกประสิทธิภาพหลัก เช่น LCP (และอาจส่งผลต่อ CLS และ INP ด้วย) แต่อาจไม่ชัดเจนในเมตริกระดับเว็บไซต์โดยรวม เนื่องจากเว็บไซต์อาจประกอบด้วยการนําทางประเภทอื่นๆ เป็นหลัก (เช่น หน้า Landing Page) หรือเนื่องจากการนําทางจากแหล่งที่มาเดียวกันนั้นรวดเร็วอยู่แล้ว แม้ว่าจะปรับปรุงอย่างมากก็อาจไม่ส่งผลต่อเมตริก 75 เปอร์เซ็นต์ไทล์ตามที่รายงานในรายงานประสบการณ์ของผู้ใช้ Chrome (CrUX)

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

วิธีวัดการใช้งานและการสูญเสีย

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

ขออภัย หน้าเว็บที่เริ่มการคาดเดาจะไม่เห็นสถานะของการพยายามคาดเดาโดยตรง นอกจากนี้ เราไม่อาจถือว่ามีการพยายามเกิดขึ้นเนื่องจากเบราว์เซอร์อาจระงับการคาดเดาในบางกรณี ดังนั้นจึงต้องวัดในหน้านั้นๆ นอกจากนี้ ยังต้องตรวจสอบ API 2 รายการเพื่อดูว่าหน้าเว็บคาดเดาหรือคาดเดาหรือไม่

if (document.prerendering) {
  console.log("Page is prerendering");
} else if (performance.getEntriesByType("navigation")[0]?.activationStart > 0) {
  console.log("Page has already prerendered");
} else {
  console.log("This page load was not using prerendering");
}

จากนั้นหน้านี้จะบันทึกการพยายามคาดเดาไปยังเซิร์ฟเวอร์แบ็กเอนด์ได้

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

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

บทสรุป

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

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