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

Barry Pollard

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

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

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

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

กฎของเอกสาร

ก่อนหน้านี้ Speculation Rules 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>

นอกจากนี้ คุณยังใช้ตัวเลือก 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 มีวิธีการแก้ปัญหาแบบเฮuristic ดังต่อไปนี้

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

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

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

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

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

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

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

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

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

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

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

ไม่บังคับ source

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

<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

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

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

Speculation-Rules: "/speculationrules.json"

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

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

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

การนำแคชมาใช้ซ้ำได้ดียิ่งขึ้น

เราได้ทำการปรับปรุงการแคชใน 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 นั้นไว้ล่วงหน้าและ 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 กลุ่ม ได้แก่ โหมดการคาดการณ์และการตั้งค่าความกระตือรือร้น ดังนี้

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

Akamai

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

NitroPack

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

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

Astro

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

บทสรุป

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

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

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

ขอขอบคุณ

ภาพปกโดย Robbie Down จาก Unsplash