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 จะไม่สนใจการเลือกใช้ 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 รายการ)