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 รองรับเฉพาะใน 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 จัดเตรียมข้อมูลพร็อพเพอร์ตี้ใหม่และรับสแนปชอต แต่ผู้ใช้จะยังคงมองเห็นมุมมองเดิมได้ ด้วยเหตุนี้ ผู้ใช้จึงเห็นหน้าเก่าได้นานกว่าขณะที่ไม่ได้เปลี่ยนมุมมองเล็กน้อย แต่การหน่วงเวลานี้อาจไม่สำคัญ แต่ในความเป็นจริงจะมีเพียงไม่กี่เฟรมเท่านั้น ตัวอย่างเช่น ผลกระทบของ pageswap ใน Chrome คือเฟรมที่ไม่อัปเดตมากที่สุด 2 เฟรม โดยที่ 1 เฟรมสำหรับเรียกใช้ตรรกะและอีก 1 เฟรมเพื่อผสมสแนปชอตและแคช
นอกจากนี้ ข้อมูลสำหรับสแนปชอตจะมาจากเครื่องมือทำคอมโพสเซอร์โดยตรง ดังนั้นจึงไม่ต้องมีการระบุการออกแบบเพิ่มเติมหรือทำซ้ำขั้นตอนใดๆ เพื่อให้ได้ข้อมูลสแนปชอต
ความเข้าใจผิดเพิ่มเติม: เป็น View Transitions API
เมื่อพูดถึงการเปลี่ยนมุมมอง ผู้คนมักพูดถึง "View Transitions API" ข้อมูลนี้ไม่ถูกต้อง API นี้เรียกว่า "View Transition API" โปรดสังเกตคำเอกพจน์ "Transition"
ความเข้าใจผิดเกิดจากบางบทความ รวมถึงเอกสารของเราเองเกี่ยวกับ DCC ในขณะนั้นที่ใช้คําที่ผิด
เคล็ดลับในการจำชื่อที่ถูกต้องคือ คุณใช้ View Transition API (1 รายการ) เพื่อสร้างการเปลี่ยนมุมมอง (อย่างน้อย 1 รายการ)