การปรับปรุง Speculation Rules API

Barry Pollard

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

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

ฟีเจอร์เพิ่มเติม

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

กฎในเอกสาร

ก่อนหน้านี้ API ของกฎการคาดเดาทำงานโดยการระบุรายการ URL ที่จะดึงข้อมูลล่วงหน้าหรือการแสดงผลล่วงหน้า

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

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

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

เรายินดีที่จะนำเสนอตัวเลือกใหม่สำหรับการค้นหาลิงก์อัตโนมัติโดยใช้กฎเอกสาร ซึ่งทํางานโดยการจัดหา URL จากตัวเอกสารเองตามเงื่อนไข where ซึ่งอาจอิงจากลิงก์เอง ดังนี้

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

หมายเหตุ: กฎของเอกสารเวอร์ชันก่อนหน้า (ซึ่งมีให้บริการระหว่างช่วงทดลองใช้จากต้นทาง) มี href_matches ที่ซับซ้อนมากขึ้นซึ่งต้องใช้ไวยากรณ์เพิ่มเติมเพื่อจับคู่พารามิเตอร์และส่วนย่อยของ URL ({"href_matches": "/*\\?*#*"}) ซึ่งช่วยลดความซับซ้อนในเวอร์ชันที่เผยแพร่

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

<script type="speculationrules">
{
  "prerender": [{
    "source": "document",
    "where": {
      "and": [
        { "selector_matches": ".prerender" },
        { "not": {"selector_matches": ".do-not-prerender"}}
      ]
    },
    "eagerness": "moderate"
  }]
}
</script>

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

แน่นอนว่าการแสดงลิงก์ทั้งหมดในหน้าเว็บล่วงหน้านั้นจะต้องเสียเปล่าอย่างแน่นอน เราจึงเปิดตัวการตั้งค่า eagerness ด้วยความสามารถใหม่นี้

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

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

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

การตั้งค่า eagerness ช่วยให้คุณกำหนดได้ว่าเมื่อใดควรเรียกใช้การคาดเดา โดยแยกเวลาที่จะคาดเดา URL ที่จะทำการคาดเดา การตั้งค่า eagerness ใช้ได้กับทั้งกฎแหล่งที่มา list และ document และมีการตั้งค่า 4 รายการ ซึ่ง Chrome มีวิธีการต่อไปนี้

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

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

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

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

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

แม้จะเลือก eagerness ไว้ แต่ Chrome ก็ยังมีข้อจำกัดเพื่อป้องกันไม่ให้มีการใช้ API นี้มากเกินไป ดังนี้

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

ขีดจำกัดการคาดเดาใน Chrome

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

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

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

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

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

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

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

source ไม่บังคับ

Chrome 122 ทำให้คีย์ source เป็นคีย์ที่ไม่บังคับเนื่องจากอาจอนุมานได้จากการมีอยู่ของคีย์ url หรือ where ดังนั้น กฎการคาดเดาทั้งสองนี้จึงเหมือนกัน:

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

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

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

การใช้แคชซ้ำได้ดีขึ้น

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

นอกจากนี้ ยังทำให้การคาดเดาซ้ำ (เช่น สำหรับกฎของเอกสารที่มีการตั้งค่าความตั้งใจ moderate) ถูกลงอย่างมาก เนื่องจาก Chrome จะใช้แคช HTTP สำหรับทรัพยากรที่แคชได้

นอกจากนี้เรายังรองรับข้อเสนอ No-Vary-Search ใหม่เพื่อปรับปรุงการใช้แคชซ้ำให้ดียิ่งขึ้น

ทีมสนับสนุนของ 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://speculative-rules.glitch.me/common-fruits.html ซึ่งสามารถใช้เพื่อดูกฎของเอกสารที่มีการตั้งค่าความกระตือรือร้น moderate ในการดำเนินการ

การสาธิตกฎการคาดเดา

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

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

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

การรองรับแพลตฟอร์มสำหรับกฎการคาดเดา

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

นอกจากนี้เรายังทำงานอย่างหนักสร้างมาตรฐาน API ผ่าน Web Incubator Community Group (WICG) เพื่ออนุญาตให้เบราว์เซอร์อื่นๆ นำ API ที่น่าตื่นเต้นนี้ไปใช้ได้เช่นกัน หากต้องการ

WordPress

ทีมประสิทธิภาพหลักของ WordPress (รวมถึงนักพัฒนาซอฟต์แวร์จาก Google) ได้สร้างปลั๊กอินกฎการคาดเดา ปลั๊กอินนี้ช่วยให้เพิ่มการสนับสนุนกฎเอกสารในเว็บไซต์ WordPress ใดก็ได้ในคลิกเดียว ปลั๊กอินนี้ยังพร้อมให้ติดตั้งผ่านปลั๊กอิน WordPress Performance Lab ซึ่งคุณควรพิจารณาติดตั้งด้วย เนื่องจากจะช่วยให้คุณทราบถึงปลั๊กอินด้านประสิทธิภาพที่เกี่ยวข้องจากทีม

การตั้งค่า 2 กลุ่มคือโหมดการคาดเดาและการตั้งค่าความกระตือรือร้น ซึ่งมีดังนี้

ปลั๊กอินกฎการคาดเดาของ WordPress

สําหรับการตั้งค่าที่ซับซ้อนมากขึ้น เช่น หากต้องการยกเว้นไม่ให้ระบบดึงข้อมูล URL บางรายการล่วงหน้าหรือการแสดงผลล่วงหน้า โปรดอ่านเอกสารประกอบ

อะคามัย

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

NitroPack

NitroPack เป็นโซลูชันการเพิ่มประสิทธิภาพที่ใช้ Navigation AI ที่กำหนดเองของตนเพื่อคาดการณ์หน้าเว็บที่ควรเพิ่มลงในกฎการคาดเดา โดยมีเป้าหมายเพื่อให้เวลาในการส่งมอบนานกว่าการวางเมาส์เหนือลิงก์ แต่ไม่ต้องเสียเวลาคาดเดาลิงก์ทั้งหมดที่สังเกตการณ์โดยไม่จำเป็น ดูข้อมูลเพิ่มเติมในเอกสารประกอบของ Nitropack Speculation Rules API โซลูชันที่สร้างสรรค์นี้แสดงให้เห็นว่ายังมีกฎรายการเก่าอีกมากมายที่จะนำเสนอเมื่อจับคู่กับข้อมูลเชิงลึกเฉพาะไซต์

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

อัสโตร

Astro ได้เพิ่มหน้าการแสดงผลล่วงหน้าโดยใช้ Speculation Rules API ใน 4.2 ในการทดสอบ ซึ่งช่วยให้นักพัฒนาซอฟต์แวร์ที่ใช้ Astro สามารถเปิดใช้ฟีเจอร์นี้ได้อย่างง่ายดาย ในขณะเดียวกันก็กลับไปใช้การดึงข้อมูลล่วงหน้าแบบมาตรฐานสำหรับเบราว์เซอร์ที่ไม่รองรับ Speculation Rules API โปรดอ่านข้อมูลเพิ่มเติมจากเอกสารการแสดงผลล่วงหน้าของไคลเอ็นต์

บทสรุป

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

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

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

ข้อความแสดงการยอมรับ

ภาพปกโดย Robbie Down ใน Unsplash