View Transition API เป็นเทคโนโลยีที่ปฏิวัติการพัฒนาเว็บ ไม่ว่าเว็บไซต์ของคุณจะมีหน้าเดียวหรือหลายหน้า API ที่มีประสิทธิภาพนี้จะช่วยให้คุณสร้างการเปลี่ยนระหว่างมุมมองได้อย่างราบรื่น ซึ่งจะส่งผลให้ผู้ใช้ได้รับประสบการณ์การใช้งานที่ดึงดูดใจราวกับว่ากำลังใช้แอป ขณะนี้ฟีเจอร์นี้พร้อมใช้งานใน Chrome และการเปลี่ยนมุมมองเอกสารแบบเดียวกันจะพร้อมใช้งานใน Safari เร็วๆ นี้
เมื่อผู้คนเริ่มหันมาใช้ View Transition API กันมากขึ้น เราจึงอยากไขข้อสงสัยที่เข้าใจผิด
ข้อเข้าใจผิดที่ 1: View Transition API จะถ่ายภาพหน้าจอ
เมื่อเรียกใช้การเปลี่ยนมุมมอง API จะจับภาพหน้าจอของสถานะเก่าและใหม่ของเนื้อหา จากนั้นภาพนิ่งเหล่านี้จะเคลื่อนไหวตามที่อธิบายไว้อย่างละเอียดในส่วน "วิธีการทํางานของทรานซิชันเหล่านี้" ของเอกสารประกอบ
แม้ว่าคุณจะใช้คำว่าภาพหน้าจอกับสแนปชอตเก่าได้ แต่สแนปชอตใหม่ไม่ใช่ภาพหน้าจอ แต่เป็นการแสดงภาพนิ่งของโหนดแบบเรียลไทม์ ให้คิดว่าเป็นองค์ประกอบที่แทนที่
::view-transition
└─ ::view-transition-group(root)
└─ ::view-transition-image-pair(root)
├─ ::view-transition-old(root) 👈 Screenshot
└─ ::view-transition-new(root) 👈 Live representation
เดโมลักษณะนี้จึงใช้งานได้ด้วยการแสดงภาพสดนี้ วิดีโอที่มาจากภาพนิ่งใหม่จะเล่นต่อไปขณะที่มุมมองเปลี่ยน
ตรรกะและ CSS ที่ใช้สำหรับการดำเนินการนี้มีรายละเอียดอยู่ในเอกสารประกอบ
คําเข้าใจผิดที่ 2: การจับภาพองค์ประกอบมากกว่า 1 รายการทําให้ภาพสไลด์แสดงหลายรายการ
เมื่อจับภาพองค์ประกอบหลายรายการ กระบวนการจับภาพหน้าจอจะจับภาพสถานะเก่าและใหม่ทั้งหมด เมื่อจับภาพ .box
นอกเหนือจากองค์ประกอบ :root
คุณจะได้รับต้นไม้จำลองนี้
::view-transition
└─ ::view-transition-group(root)
| └─ ::view-transition-image-pair(root)
| ├─ ::view-transition-old(root)
| └─ ::view-transition-new(root)
└─ ::view-transition-group(box)
└─ ::view-transition-image-pair(box)
├─ ::view-transition-old(box)
└─ ::view-transition-new(box)
แม้ว่าต้นไม้นี้จะมีคู่สแนปชอตหลายคู่ แต่ระบบจะเรียกใช้การเปลี่ยนมุมมองเพียงรายการเดียวเท่านั้น
ปัจจุบัน Chrome จำกัดให้ใช้การเปลี่ยนมุมมองได้ 1 รายการต่อเอกสารพร้อมกัน ลองคลิกอย่างรวดเร็วในการสาธิตนี้เพื่อเริ่มการเปลี่ยนมุมมองใหม่ คุณจะเห็นว่าทรานซิชันที่กำลังดำเนินอยู่จะข้ามไปยังส่วนท้ายเมื่อทรานซิชันใหม่เริ่มขึ้น
ข้อเข้าใจผิดที่ 3: คุณใช้ทรานซิชันของมุมมองไม่ได้เนื่องจากเบราว์เซอร์ไม่รองรับ
นักพัฒนาแอปจํานวนมากกังวลว่าจะใช้ทรานซิชันของมุมมองไม่ได้เนื่องจากมีเพียง Chrome เท่านั้นที่รองรับ ข่าวดีคือ Safari กำลังดำเนินการแก้ไขเรื่องนี้และจะรวมไว้ในรุ่น Safari 18 ที่กำลังจะเปิดตัว
แต่อย่างไรก็ตาม อย่าปล่อยให้การรองรับเบราว์เซอร์ที่ไม่แน่นอนเป็นอุปสรรคในการใช้การเปลี่ยนมุมมองในวันนี้ การเปลี่ยนมุมมองเป็นเนื้อหาที่เหมาะสำหรับการเพิ่มประสิทธิภาพแบบเป็นขั้นเป็นตอน เอกสารประกอบฉบับเดิมจะแชร์วิธีการเพิ่มวิธีการนี้ลงในโค้ด
function handleClick(e) {
// Fallback for browsers that don't support this API:
if (!document.startViewTransition) {
updateTheDOMSomehow();
return;
}
// With a View Transition:
document.startViewTransition(() => updateTheDOMSomehow());
}
หากเบราว์เซอร์รองรับการเปลี่ยนมุมมองเอกสารเดียวกัน คุณจะเห็นเวอร์ชันที่มีภาพเคลื่อนไหวและรายละเอียด หากเบราว์เซอร์ไม่รองรับ คุณจะใช้งานเวอร์ชันปัจจุบัน เมื่อเวลาผ่านไป ผู้ใช้จำนวนมากขึ้นจะได้สัมผัสประสบการณ์การใช้งานเวอร์ชันที่สมบูรณ์ยิ่งขึ้นนี้โดยอัตโนมัติ เนื่องจากมีเบราว์เซอร์จำนวนมากขึ้นที่รองรับการเปลี่ยนมุมมอง
เช่นเดียวกันกับการเปลี่ยนมุมมองข้ามเอกสาร เบราว์เซอร์ที่ไม่รองรับจะไม่สนใจการเลือกใช้ CSS เมื่อแยกวิเคราะห์สไตล์ชีต
แนวทางนี้นำมาใช้ในอีคอมเมิร์ซได้อย่างประสบความสำเร็จ ตามที่ระบุไว้ในกรณีศึกษานี้
คําเข้าใจผิดที่ 4: การเปลี่ยนมุมมองจะรบกวนการแสดงผลแบบเพิ่ม
มีการกล่าวอ้างว่าการเปลี่ยนมุมมองทำให้การแสดงผลแบบเพิ่มประสิทธิภาพใช้งานไม่ได้ ไม่เป็นความจริง เราได้ระบุการเปลี่ยนมุมมองข้ามเอกสารเพื่อไม่ให้ทำลายแง่มุมพื้นฐานนี้ของเว็บ
เบราว์เซอร์จะเริ่มแสดงผลหน้าเว็บเมื่อมีเนื้อหา "เพียงพอ" ซึ่งในเบราว์เซอร์ส่วนใหญ่จะเกิดขึ้นหลังจากโหลดสไตล์ชีตทั้งหมดใน <head>
, แยกวิเคราะห์ JavaScript ทั้งหมดที่บล็อกการแสดงผลใน <head>
และโหลดมาร์กอัปที่เพียงพอ การเปลี่ยนมุมมองข้ามเอกสารจะไม่เปลี่ยนแปลงข้อมูลนี้ เนื้อหาที่จําเป็นสําหรับ First Contentful Paint จะไม่เปลี่ยนแปลง หลังจากการแสดงผลครั้งแรกนี้ เบราว์เซอร์จะแสดงผลเนื้อหาที่ได้รับใหม่อย่างต่อเนื่อง
คุณเลือกบล็อกการแสดงผลได้จนกว่าจะมีองค์ประกอบบางอย่างใน DOM ซึ่งจะสะดวกในกรณีที่คุณต้องการตรวจสอบว่าองค์ประกอบที่เข้าร่วมการเปลี่ยนมุมมองอยู่ในหน้าใหม่
โดยให้ใช้แท็กลิงก์นี้
<link rel="expect" blocking="render" href="#elementId">
ซึ่งจะลบล้างการประเมินของเบราว์เซอร์ที่ใช้ตัดสินใจว่าจะแสดงผลครั้งแรกเมื่อใด การแสดงผลครั้งแรกจะล่าช้าจนกว่าองค์ประกอบที่ระบุจะปรากฏในต้นไม้ DOM
การบล็อกด้วยตนเองนี้มีการป้องกันบางอย่างในตัว เช่น เมื่อระบบพบแท็ก </html>
ที่ปิดอยู่แต่ไม่พบองค์ประกอบการบล็อก ระบบจะไม่บล็อกการแสดงผลอีกต่อไป นอกจากนี้ คุณยังเพิ่มตรรกะการหมดเวลาของคุณเองซึ่งจะนำแอตทริบิวต์การบล็อกออกได้ทุกเมื่อ
เห็นได้ชัดว่าควรใช้การบล็อกการแสดงผลอย่างระมัดระวัง ผลกระทบของการบล็อกการแสดงผลต้องได้รับการประเมินเป็นรายกรณี โดยค่าเริ่มต้น ให้หลีกเลี่ยงการใช้ blocking=render
เว้นแต่คุณจะวัดและประเมินผลกระทบที่มีต่อผู้ใช้ได้โดยการวัดผลกระทบต่อเมตริกประสิทธิภาพ
ความเข้าใจผิดข้อ 5: กระบวนการถ่ายภาพหน้าจอทำงานช้าหรือมีค่าใช้จ่ายสูง
ขณะที่ View Transition API เตรียมมุมมองใหม่และรับภาพรวม ผู้ใช้จะยังคงเห็นมุมมองเก่า ด้วยเหตุนี้ ผู้ใช้จึงเห็นหน้าเก่านานกว่าเล็กน้อยเมื่อเทียบกับกรณีที่ไม่มีการเปลี่ยนมุมมอง อย่างไรก็ตาม ความล่าช้านี้แทบจะมองไม่เห็นเลย จริง ๆ แล้วมีเพียงไม่กี่เฟรมเท่านั้น ใน Chrome ผลกระทบของ pageswap
เช่น จะมีเฟรมที่ล้าสมัยไม่เกิน 2 เฟรม ได้แก่ 1 เฟรมสําหรับเรียกใช้ตรรกะบวกอีก 1 เฟรมเพื่อให้แน่ใจว่ามีการคอมโพสและแคชภาพนิ่งแล้ว
นอกจากนี้ ระบบจะดึงข้อมูลสแนปชอตมาจากคอมโพสิตโดยตรง จึงไม่ต้องจัดวางหรือวาดภาพใหม่เพิ่มเติมเพื่อรับข้อมูลสแนปชอต
ข้อเข้าใจผิดเพิ่มเติม: แท้จริงแล้วคือ View Transitions API
เมื่อพูดถึงการเปลี่ยนมุมมอง ผู้คนมักจะพูดถึง "View Transitions API" ข้อมูลนี้ไม่ถูกต้อง API นี้เรียกว่า "View Transition API" โปรดสังเกต "Transition" ที่เป็นตัวเอก
ความเข้าใจผิดนี้มาจากบทความบางบทความ ซึ่งรวมถึงเอกสารของเราเองเกี่ยวกับ DCC ที่ใช้คําที่ไม่ถูกต้องในบางจุด
เคล็ดลับในการจดจำชื่อที่ถูกต้องคือ คุณใช้ View Transition API (1 รายการ) เพื่อสร้างการเปลี่ยนฉาก (อย่างน้อย 1 รายการ)