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

Barry Pollard

การสนับสนุนเบราว์เซอร์

  • 109
  • 109
  • x
  • x

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ภาพหน้าจอของฟีเจอร์ &quot;Typeahead&quot; ในแถบที่อยู่
ฟีเจอร์ "Typeahead" ของแถบที่อยู่

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

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

Speculation Rules API

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

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

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

<script type="speculationrules">
{
  "prerender": [{
    "where": {
      "and": [
        { "href_matches": "/*" },
        { "not": {"selector_matches": ".do-not-prerender"}},
        { "not": {"selector_matches": "[rel=nofollow]"}}
      ]
    }
  }]
}
</script>

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

การสนับสนุนเบราว์เซอร์

  • 121
  • 121
  • x
  • x

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

<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 มากเกินไป ดังนี้

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

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

การสนับสนุนเบราว์เซอร์

  • 121
  • 121
  • x
  • x

แหล่งที่มา

นอกจากนี้ คุณยังส่งกฎการคาดเดาได้โดยใช้ส่วนหัว 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>

มีหลายชุดใน 1 ชุดของ speculationrules

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

การสนับสนุนเบราว์เซอร์

  • 121
  • 121
  • x
  • x

แหล่งที่มา

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

ตรวจหาการรองรับ API ของกฎการคาดเดา

คุณสามารถใช้ฟีเจอร์ตรวจหาการรองรับ 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> แม้ว่าจะมีเฉพาะ JSON เท่านั้น คุณจึงต้องรวมอยู่ใน script-src Content-Security-Policy หากเว็บไซต์ใช้องค์ประกอบนี้ ไม่ว่าโดยใช้แฮชหรือ 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 แสดงว่าหน้าเว็บมีการแสดงผลล่วงหน้า

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

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

การใช้ API เหล่านี้ทำให้ JavaScript ของฟรอนท์เอนด์สามารถตรวจจับและดำเนินการกับหน้าที่แสดงผลล่วงหน้าได้อย่างเหมาะสม

ผลกระทบต่อข้อมูลวิเคราะห์

Analytics จะใช้เพื่อวัดการใช้งานเว็บไซต์ เช่น การใช้ Google Analytics เพื่อวัดการดูหน้าเว็บและเหตุการณ์ หรือโดยการวัดเมตริกประสิทธิภาพของหน้าเว็บโดยใช้ Real User Monitoring (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);
  } else {
    resolve();
  }
});

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

initAnalytics();

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

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

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

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

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

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

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

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

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

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

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

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

ความคิดเห็น

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

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

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