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

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

ALT_TEXT_HERE

เหตุใดจึงต้องสร้างแผงอื่น

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

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

เข้าสู่แผงข้อมูลเชิงลึก ซึ่งคุณจะยังคงดูลำดับเวลาของการติดตามและตรวจสอบข้อมูลได้ ทั้งยังดูรายการที่มีประโยชน์ของเครื่องมือสำหรับนักพัฒนาเว็บที่ถือว่าเป็น "ข้อมูลเชิงลึก" หลักที่ควรดูข้อมูลได้อีกด้วย ข้อมูลเชิงลึกจะระบุปัญหาต่างๆ เช่น คำขอบล็อกการแสดงผล การเปลี่ยนเลย์เอาต์ และงานที่ต้องใช้เวลานาน เป็นต้น ซึ่งทั้งหมดอาจส่งผลเสียต่อประสิทธิภาพการโหลดหน้าเว็บและโดยเฉพาะคะแนน Core Web Vitals (CWV) ของเว็บไซต์ นอกจากการรายงานปัญหาแล้ว ข้อมูลเชิงลึกเกี่ยวกับประสิทธิภาพจะให้คําแนะนําที่นําไปใช้ได้จริงเพื่อปรับปรุงคะแนน CWV และให้ลิงก์ไปยังแหล่งข้อมูลและเอกสารเพิ่มเติม

ลิงก์ความคิดเห็นในแผง

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

วิธีที่เราสร้างข้อมูลเชิงลึกเกี่ยวกับประสิทธิภาพ

เช่นเดียวกับเครื่องมือสำหรับนักพัฒนาเว็บอื่นๆ เราสร้างข้อมูลเชิงลึกเกี่ยวกับประสิทธิภาพใน TypeScript และใช้คอมโพเนนต์ของเว็บที่รองรับโดย lit-html เพื่อสร้างอินเทอร์เฟซผู้ใช้ ข้อมูลเชิงลึกเกี่ยวกับประสิทธิภาพจะแตกต่างกันที่อินเทอร์เฟซ UI หลักคือองค์ประกอบ HTML canvas และไทม์ไลน์จะแสดงบนผืนผ้าใบนี้ ความซับซ้อนมากมายมาจากการจัดการผืนผ้าใบนี้ ไม่เพียงแต่การวาดรายละเอียดที่ถูกต้องในสถานที่ที่เหมาะสมเท่านั้น แต่ยังรวมถึงการจัดการเหตุการณ์เกี่ยวกับเมาส์ (เช่น ผู้ใช้คลิกที่ใดบนผืนผ้าใบ พวกเขาคลิกเหตุการณ์ที่เราวาดไว้หรือไม่) และช่วยให้มั่นใจว่าเราแสดงผลผืนผ้าใบอีกครั้งได้อย่างมีประสิทธิภาพ

หลายแทร็กบนผืนผ้าใบเดียว

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

และขณะที่เรานำฟีเจอร์ต่างๆ เข้ามาเผยแพร่อย่างต่อเนื่อง เราคาดว่าจะเพิ่มแทร็กอื่นๆ เพิ่มเติม

ตอนแรกเราคิดให้แต่ละแทร็กแสดงผล <canvas> ของตัวเองเพื่อให้มุมมองหลักกลายเป็นองค์ประกอบของ Canvas หลายส่วนที่เรียงซ้อนกันในแนวตั้ง ซึ่งจะลดความซับซ้อนในการแสดงผลในระดับแทร็ก เนื่องจากแต่ละแทร็กอาจแสดงผลแยกกันและไม่มีอันตรายจากการแสดงผลแทร็กนอกขอบเขต แต่วิธีการนี้มีปัญหาสำคัญ 2 ประการดังนี้

องค์ประกอบ canvas มีค่าใช้จ่ายในการแสดงผล (ซ้ำ) การมี Canvas หลายใบจะมีราคาแพงกว่า Canvas ขนาดเดียว แม้ว่าผืนผ้าใบนั้นจะมีขนาดใหญ่กว่าก็ตาม การแสดงการวางซ้อนที่อยู่ในหลายแทร็ก (เช่น เส้นแนวตั้งเพื่อทำเครื่องหมายเหตุการณ์อย่างเช่นเวลา FCP) จะกลายเป็นเรื่องซับซ้อน เราต้องแสดงผลบนผืนผ้าใบหลายชุดและตรวจสอบว่าทั้งหมดแสดงผลร่วมกันและจัดวางอย่างเหมาะสม

การใช้ canvas อันเดียวสำหรับ UI ทั้งหมดทำให้เราต้องหาวิธีตรวจสอบว่าแต่ละแทร็กแสดงผลในพิกัดที่ถูกต้องและไม่ล้นออกมาเป็นอีกแทร็กหนึ่ง ตัวอย่างเช่น หากแทร็กใดมีความสูง 100 พิกเซล เราจะไม่สามารถให้แทร็กนั้นแสดงเนื้อหาที่มีความสูง 120 พิกเซลได้และจะทำให้แทร็กนั้นไหลลงไปยังแทร็กที่อยู่ต่ำกว่า เราสามารถใช้ clip เพื่อแก้ไขปัญหานี้ ก่อนที่จะแสดงผลแต่ละแทร็ก เราจะวาดรูปสี่เหลี่ยมผืนผ้าที่แสดงถึงหน้าต่างแทร็กที่มองเห็นได้ วิธีนี้ช่วยให้มั่นใจว่าเส้นทางใดๆ ที่วาดนอกขอบเขตเหล่านี้จะถูกตัดออกโดยผืนผ้าใบ

canvasContext.beginPath();
canvasContext.rect(
    trackVisibleWindow.x, trackVisibleWindow.y, trackVisibleWindow.width, trackVisibleWindow.height);
canvasContext.clip();

เราไม่ต้องการให้แต่ละแทร็กต้องรู้ตำแหน่งของแทร็กในแนวตั้งด้วย โดยแต่ละแทร็กควรแสดงผลเหมือนกับว่ากำลังแสดงผลที่ (0, 0) และเรามีคอมโพเนนต์ระดับที่สูงกว่า (ซึ่งเราเรียกว่า TrackManager) เพื่อจัดการตำแหน่งแทร็กโดยรวม ซึ่งทำได้ด้วย translate ซึ่งจะแปล Canvas ตามตําแหน่ง (x, y) เช่น

canvasContext.translate(0, 10); // Translate by 10px in the y direction
canvasContext.rect(0, 0, 10, 10); // draw a rectangle at (0, 0) that’s 10px high and wide

แม้ว่าจะมีการตั้ง rect เป็น 0, 0 เป็นตำแหน่ง แต่การแปลโดยรวมที่ใช้จะทำให้สี่เหลี่ยมผืนผ้าแสดงผลที่ 0, 10 วิธีนี้ช่วยให้เราทำงานได้แบบแทร็กราวกับว่าเรากำลังแสดงผลที่ (0, 0) และให้ Track Manager แปลแทร็กในการแสดงผลแต่ละแทร็กเพื่อให้แน่ใจว่าแต่ละแทร็กจะแสดงต่ำกว่าแทร็กก่อนหน้า

ผืนผ้าใบนอกจอสำหรับแทร็กและไฮไลต์

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

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

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

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

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

ทดสอบการแยกวิเคราะห์การติดตามที่ครอบคลุม

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

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

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

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

การทดสอบภาพหน้าจอสำหรับ UI ของ Canvas

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

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

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

บทสรุป

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

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

ดาวน์โหลดช่องตัวอย่าง

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

ติดต่อทีมเครื่องมือสำหรับนักพัฒนาเว็บใน Chrome

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

  • ส่งคำแนะนำหรือความคิดเห็นถึงเราผ่าน crbug.com
  • รายงานปัญหาเกี่ยวกับเครื่องมือสำหรับนักพัฒนาเว็บโดยใช้ตัวเลือกเพิ่มเติม   เพิ่มเติม   > ความช่วยเหลือ > รายงานปัญหาเกี่ยวกับเครื่องมือสำหรับนักพัฒนาเว็บในเครื่องมือสำหรับนักพัฒนาเว็บ
  • ทวีตที่ @ChromeDevTools
  • แสดงความคิดเห็นเกี่ยวกับ "มีอะไรใหม่ในวิดีโอ YouTube สำหรับเครื่องมือสำหรับนักพัฒนาเว็บ" หรือเคล็ดลับเครื่องมือสำหรับนักพัฒนาเว็บวิดีโอ YouTube