ใช้แผงประสิทธิภาพของเครื่องมือสำหรับนักพัฒนาเว็บใน Chrome เพื่อสร้างโปรไฟล์แอป Angular

Andrés Olivares

Pawel Kozlowski

เฟรมเวิร์กของเว็บ เช่น Angular, React, Vue และ Svelte ช่วยให้การเขียนและดูแลเว็บแอปพลิเคชันที่ซับซ้อนในวงกว้างเป็นเรื่องง่ายขึ้น

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

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

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

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

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

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

API ความสามารถในการขยายแผงประสิทธิภาพคืออะไร

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

• User Timing API
• console.timeStamp API

User Timing API

คุณใช้ performance.mark และ performance.measure เพื่อเพิ่มรายการได้ดังนี้

// Mark used to represent the start of some activity you want to measure.
// In this case, the rendering of a component.
const renderStart = performance.now();

// ... later in your code

performance.measure("Component rendering", {
  start: renderStart,
  detail: {
    devtools: {
      dataType: "track-entry",
      track: "Components",
      color: "secondary",
      properties: [
        ["Render reason", "Props changed"],
        ["Priority", "low"]
      ],
    }
  }
});

ซึ่งจะส่งผลให้แทร็กคอมโพเนนต์เพิ่มลงในไทม์ไลน์พร้อมการวัดผลดังนี้

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

ดูข้อมูลเพิ่มเติมเกี่ยวกับ API นี้และออบเจ็กต์ devtools ในเอกสาร

console.timeStamp API

API นี้เป็นทางเลือกที่มีน้ำหนักเบาแทน User Timing API จากตัวอย่างเดิม คุณอาจมี

// Mark used to represent the start of some activity you want to measure.
// In this case, the rendering of a component.
const renderStart = performance.now();

// ... later in your code

console.timeStamp(
"Component rendering",
/* start time */ renderStart,
/* end time (current time) */ undefined,
/* track name */ "Components",
 /* track group name */ undefined,
 /* color */ "secondary"
);

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

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

วิธีที่ Angular ผสานรวม API ความสามารถในการขยายของเครื่องมือสำหรับนักพัฒนาเว็บ

เราจะมาดูวิธีที่ทีม Angular ใช้ Extensibility API เพื่อผสานรวมกับเครื่องมือสำหรับนักพัฒนาเว็บใน Chrome

หลีกเลี่ยงค่าใช้จ่ายเพิ่มเติมด้วย console.timestamp

การตรวจสอบของ Angular ด้วย API ความสามารถในการขยายแผงประสิทธิภาพพร้อมใช้งานแล้วตั้งแต่เวอร์ชัน 20 ระดับความละเอียดที่ต้องการสำหรับข้อมูลประสิทธิภาพในเครื่องมือสำหรับนักพัฒนาเว็บต้องใช้ API ที่รวดเร็ว ดังนั้นคำขอ Pull (60217) ที่เพิ่มการวัดจึงเลือกใช้ API console.timeStamp ซึ่งจะช่วยป้องกันไม่ให้ประสิทธิภาพรันไทม์ของแอปพลิเคชันได้รับผลกระทบจากค่าใช้จ่ายที่อาจเกิดขึ้นของ Profiling API

ข้อมูลที่วัด

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

• การเริ่มต้นแอปพลิเคชันและคอมโพเนนต์
• การสร้างและอัปเดตคอมโพเนนต์
• การดำเนินการ Listener เหตุการณ์และฮุกวงจร
• และอื่นๆ อีกมากมาย (เช่น การสร้างคอมโพเนนต์แบบไดนามิกและการเลื่อนการแสดงผลบล็อก)

การเขียนโค้ดสี

การกำหนดรหัสสีใช้เพื่อส่งสัญญาณให้นักพัฒนาซอฟต์แวร์ทราบเกี่ยวกับหมวดหมู่ของรายการการวัดที่เฉพาะเจาะจง เช่น สีที่ใช้สำหรับรายการที่ทำเครื่องหมายการดำเนินการของโค้ด TypeScript ที่นักพัฒนาซอฟต์แวร์เขียนขึ้นจะแตกต่างจากสีที่ใช้สำหรับโค้ดที่คอมไพเลอร์ Angular สร้างขึ้น

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

โปรดทราบว่าอาร์กิวเมนต์สีที่ส่งไปยัง API ไม่ใช่ค่าสี CSS แต่เป็นโทเค็นเชิงความหมายที่แมปกับสีที่ตรงกับ UI ของ DevTools ค่าที่เป็นไปได้คือ primary, secondary และ tertiary, พร้อมด้วยตัวแปร -dark และ -light ที่เกี่ยวข้อง รวมถึงสี error

แทร็ก

ในขณะที่เขียนบทความนี้ ระบบจะเพิ่มข้อมูลรันไทม์ของ Angular ทั้งหมดลงในแทร็กเดียวกัน (มีป้ายกำกับว่า "🅰️ Angular") อย่างไรก็ตาม คุณสามารถเพิ่มหลายแทร็กลงในร่องรอย และแม้แต่จัดกลุ่มแทร็กได้ ตัวอย่างเช่น หากมีการเรียก console.timeStamp API ดังนี้

console.timeStamp("Component 1", componentStart1, componentEnd1, "Components", "Client", "primary");
console.timeStamp("Component 2", componentStart2, componentEnd2, "Components", "Client", "primary");
console.timeStamp("Hook 1", hookStart, hookEnd, "Hooks", "Client", "primary");
console.timeStamp("Fetch data base", fetchStart, fetchEnd, "Server", "primary");

คุณจะเห็นข้อมูลที่จัดระเบียบเป็นแทร็กในลักษณะต่อไปนี้

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

เหตุใดจึงสำคัญต่อนักพัฒนา Angular

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

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

การเปิดใช้การผสานรวม

การใช้งาน Extensibility API พร้อมให้ใช้งานอย่างเป็นทางการในบิลด์การพัฒนาตั้งแต่ Angular เวอร์ชัน 20 เป็นต้นไป หากต้องการเปิดใช้ คุณต้องเรียกใช้ยูทิลิตีส่วนกลาง `ng.enableProfiling()` ในแอปหรือในคอนโซลเครื่องมือสำหรับนักพัฒนาเว็บ ดูข้อมูลเพิ่มเติมเกี่ยวกับการผสานรวมได้ใน [เอกสารประกอบของ Angular](https://angular.dev/best-practices/profiling-with-chrome-devtools)

ข้อควรพิจารณาอื่นๆ

ข้อควรพิจารณาที่สำคัญบางประการที่ควรนำมาพิจารณา

การแมปแหล่งที่มาและโค้ดที่มีการลดขนาด

แผนที่แหล่งที่มาเป็นเครื่องมือที่ใช้กันอย่างแพร่หลายซึ่งมีจุดมุ่งหมายเพื่อเชื่อมช่องว่างระหว่างโค้ดที่รวม / ลดขนาดแล้วกับโค้ดที่เขียนขึ้นมา ดังนั้น...

Source Map ไม่ควรแก้ปัญหาโค้ดที่มีการลดขนาดในแอปที่รวมกลุ่มใช่ไหม

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

ส่วนขยายเครื่องมือสำหรับนักพัฒนาเว็บใน Chrome:

ส่วนขยาย Chrome ที่ใช้ DevTools API เป็นเครื่องมือที่ใช้กันอย่างแพร่หลายในการขยายเครื่องมือสำหรับนักพัฒนาเว็บ

ตอนนี้ API นี้พร้อมใช้งานแล้ว เรายังจำเป็นต้องใช้ Profiler เฉพาะ (เช่น ส่วนขยายเครื่องมือสำหรับนักพัฒนาเว็บใน Chrome) หรือไม่

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

เส้นทางข้างหน้า

โอกาสของ Extensibility API

ทำงานกับเฟรมเวิร์กและการแยกส่วนเพิ่มเติม

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

เวอร์ชันที่ใช้งานจริง

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