ปลดล็อกประสิทธิภาพเว็บ: เจาะลึก Performance Observer API

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

วิธีการแบบดั้งเดิมมักเกี่ยวข้องกับการสำรวจ (polling) ข้อมูลประสิทธิภาพด้วยฟังก์ชันต่างๆ เช่น performance.getEntries() ซึ่งอาจไม่มีประสิทธิภาพ มีแนวโน้มที่จะพลาดเหตุการณ์สำคัญที่เกิดขึ้นระหว่างการสำรวจ และยังสามารถเพิ่มภาระด้านประสิทธิภาพที่พยายามจะวัดผลได้อีกด้วย Performance Observer API ปฏิวัติกระบวนการนี้โดยการให้กลไกแบบอะซิงโครนัสและมีภาระต่ำในการสมัครรับข้อมูลเหตุการณ์ด้านประสิทธิภาพที่เกิดขึ้น คู่มือนี้จะนำคุณเจาะลึก API ที่จำเป็นนี้ โดยแสดงให้คุณเห็นถึงวิธีการใช้ประโยชน์จากพลังของมันเพื่อตรวจสอบ Core Web Vitals ระบุปัญหาคอขวด และท้ายที่สุดคือการสร้างประสบการณ์เว็บที่เร็วและสนุกสนานยิ่งขึ้นสำหรับผู้ชมทั่วโลก

Performance Observer API คืออะไร?

โดยแก่นแท้แล้ว Performance Observer API เป็นอินเทอร์เฟซที่ให้วิธีการสังเกตและรวบรวมเหตุการณ์การวัดประสิทธิภาพ ซึ่งเรียกว่า performance entries ลองนึกภาพว่ามันเป็น listener เฉพาะสำหรับกิจกรรมที่เกี่ยวข้องกับประสิทธิภาพภายในเบราว์เซอร์ แทนที่คุณจะต้องถามเบราว์เซอร์อย่างแข็งขันว่า "มีอะไรเกิดขึ้นหรือยัง?" เบราว์เซอร์จะบอกคุณในเชิงรุกว่า "มีเหตุการณ์ด้านประสิทธิภาพใหม่เกิดขึ้น! นี่คือรายละเอียด"

สิ่งนี้ทำได้ผ่านรูปแบบ observer pattern คุณสร้างอินสแตนซ์ของ observer บอกมันว่าคุณสนใจเหตุการณ์ด้านประสิทธิภาพประเภทใด (เช่น large paints, user inputs, layout shifts) และระบุฟังก์ชัน callback เมื่อใดก็ตามที่มีการบันทึกเหตุการณ์ใหม่ของประเภทที่ระบุในไทม์ไลน์ประสิทธิภาพของเบราว์เซอร์ ฟังก์ชัน callback ของคุณจะถูกเรียกใช้พร้อมกับรายการของ entry ใหม่ๆ โมเดลแบบ push-based ที่เป็นอะซิงโครนัสนี้มีประสิทธิภาพและเชื่อถือได้มากกว่าโมเดลแบบ pull-based รุ่นเก่าที่ต้องเรียกใช้ performance.getEntries() ซ้ำๆ

วิธีเก่า vs. วิธีใหม่

เพื่อให้เห็นคุณค่าของนวัตกรรมของ Performance Observer เรามาเปรียบเทียบสองแนวทางนี้กัน:

• วิธีเก่า (Polling): คุณอาจใช้ setTimeout หรือ requestAnimationFrame เพื่อเรียก performance.getEntriesByName('my-metric') เป็นระยะๆ เพื่อดูว่าเมตริกของคุณถูกบันทึกแล้วหรือยัง นี่เป็นปัญหาเพราะคุณอาจตรวจสอบช้าเกินไปและพลาดเหตุการณ์ หรือตรวจสอบบ่อยเกินไปและสิ้นเปลืองรอบการทำงานของ CPU คุณยังเสี่ยงต่อการทำให้บัฟเฟอร์ประสิทธิภาพของเบราว์เซอร์เต็มหากคุณไม่ล้าง entry เป็นประจำ
• วิธีใหม่ (Observing): คุณตั้งค่า PerformanceObserver เพียงครั้งเดียว มันจะทำงานเงียบๆ อยู่เบื้องหลังโดยใช้ทรัพยากรน้อยที่สุด ทันทีที่มีการบันทึก performance entry ที่เกี่ยวข้อง ไม่ว่าจะเป็นหนึ่งมิลลิวินาทีหลังจากการโหลดหน้าเว็บหรือสิบนาทีในเซสชันของผู้ใช้ โค้ดของคุณจะได้รับการแจ้งเตือนทันที สิ่งนี้ทำให้มั่นใจได้ว่าคุณจะไม่พลาดเหตุการณ์ใดๆ และโค้ดการตรวจสอบของคุณมีประสิทธิภาพมากที่สุดเท่าที่จะเป็นไปได้

ทำไมคุณควรใช้ Performance Observer

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

• การตรวจสอบที่ไม่รบกวน: โดยปกติแล้ว callback ของ observer จะทำงานในช่วงเวลาที่ไม่มีการใช้งาน (idle periods) ทำให้มั่นใจได้ว่าโค้ดการตรวจสอบประสิทธิภาพของคุณจะไม่รบกวนประสบการณ์ของผู้ใช้หรือบล็อกเธรดหลัก มันถูกออกแบบมาให้มีน้ำหนักเบาและมีผลกระทบต่อประสิทธิภาพน้อยมาก
• ข้อมูลขณะทำงานที่ครอบคลุม: เว็บเป็นสิ่งที่เปลี่ยนแปลงตลอดเวลา ปัญหาด้านประสิทธิภาพไม่ได้เกิดขึ้นเฉพาะตอนโหลดเท่านั้น ผู้ใช้อาจกระตุ้นแอนิเมชันที่ซับซ้อน โหลดเนื้อหาเพิ่มเติมโดยการเลื่อน หรือโต้ตอบกับส่วนประกอบที่หนักหน่วงหลังจากที่หน้าเว็บเริ่มแรกได้โหลดเสร็จแล้ว Performance Observer จะจับภาพเหตุการณ์ขณะทำงานเหล่านี้ ทำให้คุณเห็นภาพรวมที่สมบูรณ์ของเซสชันผู้ใช้ทั้งหมด
• รองรับอนาคตและเป็นมาตรฐาน: นี่คือมาตรฐานที่แนะนำโดย W3C สำหรับการรวบรวมข้อมูลประสิทธิภาพ เมตริกและ API ด้านประสิทธิภาพใหม่ๆ ถูกออกแบบมาเพื่อทำงานร่วมกับมัน ทำให้เป็นตัวเลือกที่ยั่งยืนและมองไปข้างหน้าสำหรับโครงการของคุณ
• รากฐานของ Real User Monitoring (RUM): เพื่อให้เข้าใจอย่างแท้จริงว่าไซต์ของคุณทำงานอย่างไรสำหรับผู้ใช้ในประเทศ อุปกรณ์ และเงื่อนไขเครือข่ายที่แตกต่างกัน คุณต้องการข้อมูลจากเซสชันจริง Performance Observer เป็นเครื่องมือที่เหมาะอย่างยิ่งสำหรับการสร้างโซลูชัน RUM ที่แข็งแกร่ง ช่วยให้คุณสามารถรวบรวมเมตริกที่สำคัญและส่งไปยังบริการวิเคราะห์เพื่อรวบรวมและวิเคราะห์ผล
• ขจัด Race Conditions: ด้วยการ polling คุณอาจพยายามเข้าถึง performance entry ก่อนที่มันจะถูกบันทึก โมเดล observer จะขจัด race condition นี้ออกไปโดยสิ้นเชิง เนื่องจากโค้ดของคุณจะทำงานหลังจากที่ entry พร้อมใช้งานแล้วเท่านั้น

เริ่มต้นใช้งาน: พื้นฐานของ Performance Observer

การใช้ API นั้นตรงไปตรงมา กระบวนการนี้ประกอบด้วยสามขั้นตอนหลัก: การสร้าง observer, การกำหนด callback และการบอก observer ว่าจะให้จับตาดูอะไร

1. การสร้าง Observer พร้อม Callback

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

const observer = new PerformanceObserver((entryList) => { for (const entry of entryList.getEntries()) { console.log('Entry Type:', entry.entryType); console.log('Entry Name:', entry.name); console.log('Start Time:', entry.startTime); console.log('Duration:', entry.duration); } });

callback จะได้รับอ็อบเจ็กต์ PerformanceObserverEntryList คุณสามารถเรียกใช้เมธอด getEntries() บนลิสต์นี้เพื่อรับอาร์เรย์ของ performance entry ที่เพิ่งสังเกตได้ทั้งหมด

2. การสังเกตการณ์ Entry Type ที่เฉพาะเจาะจง

observer จะไม่ทำอะไรเลยจนกว่าคุณจะบอกให้มันตรวจสอบ คุณทำสิ่งนี้โดยใช้เมธอด .observe() เมธอดนี้รับอ็อบเจ็กต์ที่มีพร็อพเพอร์ตี้ entryTypes (หรือในบางกรณีที่ทันสมัยกว่าคือ type สำหรับประเภทเดียว) ซึ่งเป็นอาร์เรย์ของสตริงที่แสดงถึงประเภทของ performance entry ที่คุณสนใจ

// เริ่มสังเกตการณ์ entry สองประเภท observer.observe({ entryTypes: ['mark', 'measure'] });

entry type ที่พบบ่อยที่สุดบางส่วน ได้แก่:

• 'resource': รายละเอียดเกี่ยวกับการร้องขอเครือข่ายสำหรับแอสเซทต่างๆ เช่น สคริปต์ รูปภาพ และสไตล์ชีต
• 'paint': เวลาสำหรับ first-paint และ first-contentful-paint
• 'largest-contentful-paint': เมตริก Core Web Vital สำหรับความเร็วในการโหลดที่รับรู้ได้
• 'layout-shift': เมตริก Core Web Vital สำหรับความเสถียรของภาพ
• 'first-input': ข้อมูลเกี่ยวกับการโต้ตอบครั้งแรกของผู้ใช้ ซึ่งใช้สำหรับ First Input Delay Core Web Vital
• 'longtask': ระบุงานบนเธรดหลักที่ใช้เวลานานกว่า 50 มิลลิวินาที ซึ่งอาจทำให้เกิดการไม่ตอบสนอง
• 'mark' & 'measure': มาร์กเกอร์และการวัดผลแบบกำหนดเองที่คุณกำหนดในโค้ดของคุณเองโดยใช้ User Timing API

3. การหยุด Observer

เมื่อคุณไม่จำเป็นต้องรวบรวมข้อมูลอีกต่อไป เป็นแนวทางปฏิบัติที่ดีที่จะยกเลิกการเชื่อมต่อ observer เพื่อเพิ่มทรัพยากรคืน

observer.disconnect();

กรณีการใช้งานจริง: การติดตาม Core Web Vitals

Core Web Vitals คือชุดของปัจจัยเฉพาะที่ Google ถือว่ามีความสำคัญต่อประสบการณ์ผู้ใช้โดยรวมของหน้าเว็บ การตรวจสอบสิ่งเหล่านี้เป็นหนึ่งในแอปพลิเคชันที่ทรงพลังที่สุดของ Performance Observer API มาดูกันว่าจะวัดแต่ละตัวได้อย่างไร

การติดตาม Largest Contentful Paint (LCP)

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

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

// สังเกตการณ์ LCP และบันทึกค่าสุดท้าย let lcpValue = 0; const lcpObserver = new PerformanceObserver((entryList) => { const entries = entryList.getEntries(); // entry สุดท้ายคือผู้ท้าชิง LCP ที่เป็นปัจจุบันที่สุด const lastEntry = entries[entries.length - 1]; lcpValue = lastEntry.startTime; console.log(`LCP updated: ${lcpValue.toFixed(2)}ms`, lastEntry.element); }); lcpObserver.observe({ type: 'largest-contentful-paint', buffered: true }); // เป็นแนวทางปฏิบัติที่ดีที่จะยกเลิกการเชื่อมต่อ observer หลังจากที่ผู้ใช้โต้ตอบ // เนื่องจากการโต้ตอบสามารถหยุดผู้ท้าชิง LCP ใหม่ไม่ให้ถูกส่งออกไป // window.addEventListener('beforeunload', () => lcpObserver.disconnect());

สังเกตการใช้ buffered: true นี่เป็นตัวเลือกที่สำคัญที่สั่งให้ observer รวม entry ที่ถูกบันทึกไว้ *ก่อน* ที่เมธอด observe() จะถูกเรียกใช้ ซึ่งจะช่วยป้องกันไม่ให้คุณพลาดเหตุการณ์ LCP ที่เกิดขึ้นเร็ว

การติดตาม First Input Delay (FID) และ Interaction to Next Paint (INP)

เมตริกเหล่านี้วัดการโต้ตอบ พวกมันวัดปริมาณประสบการณ์ของผู้ใช้เมื่อพวกเขาพยายามโต้ตอบกับหน้าเว็บเป็นครั้งแรก

First Input Delay (FID) วัดเวลาตั้งแต่ผู้ใช้โต้ตอบกับหน้าเว็บเป็นครั้งแรก (เช่น คลิกปุ่ม) ไปจนถึงเวลาที่เบราว์เซอร์สามารถเริ่มประมวลผล event handlers เพื่อตอบสนองต่อการโต้ตอบนั้นได้จริง FID ที่ดีคือ 100 มิลลิวินาทีหรือน้อยกว่า

Interaction to Next Paint (INP) เป็นเมตริกใหม่ที่ครอบคลุมกว่าซึ่งได้เข้ามาแทนที่ FID ในฐานะ Core Web Vital ในเดือนมีนาคม 2024 ในขณะที่ FID วัดเพียง *ความล่าช้า* ของการโต้ตอบ *ครั้งแรก* เท่านั้น แต่ INP จะประเมิน *เวลาแฝงทั้งหมด* ของการโต้ตอบ *ทั้งหมด* ของผู้ใช้ตลอดวงจรชีวิตของหน้าเว็บ โดยรายงานค่าที่แย่ที่สุด สิ่งนี้ให้ภาพรวมของการตอบสนองโดยรวมที่ดีกว่า INP ที่ดีคือ 200 มิลลิวินาทีหรือน้อยกว่า

คุณสามารถตรวจสอบ FID โดยใช้ entry type 'first-input':

// สังเกตการณ์ FID const fidObserver = new PerformanceObserver((entryList) => { for (const entry of entryList.getEntries()) { const fid = entry.processingStart - entry.startTime; console.log(`FID: ${fid.toFixed(2)}ms`); // ยกเลิกการเชื่อมต่อหลังจากรายงาน input แรก fidObserver.disconnect(); } }); fidObserver.observe({ type: 'first-input', buffered: true });

การตรวจสอบ INP มีความซับซ้อนกว่าเล็กน้อยเนื่องจากต้องดูระยะเวลาทั้งหมดของเหตุการณ์ คุณสังเกตการณ์ entry type 'event' และคำนวณระยะเวลา โดยติดตามค่าที่ยาวที่สุด

// ตัวอย่างการตรวจสอบ INP แบบง่าย let worstInp = 0; const inpObserver = new PerformanceObserver((entryList) => { for (const entry of entryList.getEntries()) { // INP คือระยะเวลาของเหตุการณ์ const inp = entry.duration; // เราสนใจเฉพาะการโต้ตอบที่ยาวกว่าค่าที่แย่ที่สุดในปัจจุบัน if (inp > worstInp) { worstInp = inp; console.log(`New worst INP: ${worstInp.toFixed(2)}ms`); } } }); inpObserver.observe({ type: 'event', durationThreshold: 16, buffered: true }); // durationThreshold ช่วยกรองเหตุการณ์ที่สั้นมากและไม่น่าจะมีความสำคัญออกไป

การติดตาม Cumulative Layout Shift (CLS)

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

คะแนนคือการรวมของคะแนน layout shift แต่ละรายการ Performance Observer มีความจำเป็นอย่างยิ่งในที่นี้ เนื่องจากมันจะรายงานการเปลี่ยนแปลงแต่ละครั้งที่เกิดขึ้น

// สังเกตการณ์และคำนวณคะแนน CLS ทั้งหมด let clsScore = 0; const clsObserver = new PerformanceObserver((entryList) => { for (const entry of entryList.getEntries()) { // เราไม่ต้องการนับการเปลี่ยนแปลงที่เกิดจากอินพุตของผู้ใช้ if (!entry.hadRecentInput) { clsScore += entry.value; console.log(`Current CLS score: ${clsScore.toFixed(4)}`); } } }); clsObserver.observe({ type: 'layout-shift', buffered: true });

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

นอกเหนือจาก Core Web Vitals: Entry Type อื่นๆ ที่ทรงพลัง

แม้ว่า Core Web Vitals จะเป็นจุดเริ่มต้นที่ยอดเยี่ยม แต่ Performance Observer สามารถตรวจสอบได้มากกว่านั้นมาก นี่คือ entry type ที่มีประโยชน์อย่างยิ่งอีกสองสามอย่าง

การติดตาม Long Tasks (`longtask`)

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

// สังเกตการณ์ long tasks const longTaskObserver = new PerformanceObserver((entryList) => { for (const entry of entryList.getEntries()) { console.log(`Long Task Detected: ${entry.duration.toFixed(2)}ms`); // พร็อพเพอร์ตี้ 'attribution' บางครั้งสามารถบอกคุณได้ว่าอะไรเป็นสาเหตุของ long task console.log('Attribution:', entry.attribution); } }); longTaskObserver.observe({ type: 'longtask', buffered: true });

การวิเคราะห์ Resource Timings (`resource`)

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

// สังเกตการณ์ resource timings const resourceObserver = new PerformanceObserver((entryList) => { for (const entry of entryList.getEntries()) { // ลองหารูปภาพที่โหลดช้า if (entry.initiatorType === 'img' && entry.duration > 500) { console.warn(`Slow image detected: ${entry.name}`, `Duration: ${entry.duration.toFixed(2)}ms`); } } }); // การใช้ 'buffered: true' แทบจะจำเป็นเสมอสำหรับ resource timings // เพื่อจับแอสเซทที่โหลดก่อนที่สคริปต์นี้จะทำงาน resourceObserver.observe({ type: 'resource', buffered: true });

การวัดผลด้วย Performance Marks แบบกำหนดเอง (`mark` และ `measure`)

บางครั้ง คุณจำเป็นต้องวัดประสิทธิภาพของตรรกะเฉพาะของแอปพลิเคชัน User Timing API ช่วยให้คุณสามารถสร้างการประทับเวลาแบบกำหนดเองและวัดระยะเวลาระหว่างการประทับเวลาเหล่านั้นได้

• performance.mark('start-operation'): สร้างการประทับเวลาชื่อ 'start-operation'
• performance.mark('end-operation'): สร้างการประทับเวลาอีกอัน
• performance.measure('my-operation', 'start-operation', 'end-operation'): สร้างการวัดผลระหว่างมาร์กเกอร์ทั้งสอง

Performance Observer สามารถรับฟัง entry 'mark' และ 'measure' แบบกำหนดเองเหล่านี้ได้ ซึ่งเหมาะอย่างยิ่งสำหรับการรวบรวมข้อมูลเวลาเกี่ยวกับสิ่งต่างๆ เช่น เวลาในการเรนเดอร์คอมโพเนนต์ในเฟรมเวิร์ก JavaScript หรือระยะเวลาของการเรียก API ที่สำคัญและการประมวลผลข้อมูลที่ตามมา

// ในโค้ดแอปพลิเคชันของคุณ: performance.mark('start-data-processing'); // ... การประมวลผลข้อมูลที่ซับซ้อนบางอย่าง ... performance.mark('end-data-processing'); performance.measure('data-processing-duration', 'start-data-processing', 'end-data-processing'); // ในสคริปต์การตรวจสอบของคุณ: const customObserver = new PerformanceObserver((entryList) => { for (const entry of entryList.getEntriesByName('data-processing-duration')) { console.log(`Custom Measurement '${entry.name}': ${entry.duration.toFixed(2)}ms`); } }); customObserver.observe({ entryTypes: ['measure'] });

แนวคิดขั้นสูงและแนวทางปฏิบัติที่ดีที่สุด

เพื่อใช้ Performance Observer API อย่างมีประสิทธิภาพในสภาพแวดล้อมการผลิตระดับมืออาชีพ ให้พิจารณาแนวทางปฏิบัติที่ดีที่สุดเหล่านี้

• พิจารณา `buffered: true` เสมอ: สำหรับ entry type ที่สามารถเกิดขึ้นได้ในช่วงต้นของการโหลดหน้าเว็บ (เช่น 'resource', 'paint' หรือ 'largest-contentful-paint') การใช้แฟล็ก buffered เป็นสิ่งจำเป็นเพื่อหลีกเลี่ยงการพลาดข้อมูล
• ตรวจสอบการรองรับของเบราว์เซอร์: แม้ว่าจะรองรับอย่างกว้างขวางในเบราว์เซอร์สมัยใหม่ แต่ควรตรวจสอบการมีอยู่ของมันก่อนใช้งานเสมอ คุณยังสามารถตรวจสอบได้ว่าเบราว์เซอร์เฉพาะรองรับ entry type ใดบ้าง
• if ('PerformanceObserver' in window && PerformanceObserver.supportedEntryTypes.includes('longtask')) { // ปลอดภัยที่จะใช้ PerformanceObserver สำหรับ long tasks }
• ส่งข้อมูลไปยังบริการวิเคราะห์: การบันทึกข้อมูลไปยังคอนโซลนั้นยอดเยี่ยมสำหรับการพัฒนา แต่สำหรับการตรวจสอบในโลกแห่งความเป็นจริง คุณต้องรวบรวมข้อมูลนี้ วิธีที่ดีที่สุดในการส่งข้อมูลทางไกลนี้จากไคลเอนต์คือการใช้ navigator.sendBeacon() API เป็นกลไกที่ไม่ปิดกั้นซึ่งออกแบบมาเพื่อส่งข้อมูลจำนวนเล็กน้อยไปยังเซิร์ฟเวอร์ และทำงานได้อย่างน่าเชื่อถือแม้ในขณะที่หน้าเว็บกำลังจะถูกยกเลิกการโหลด
• จัดกลุ่ม Observers ตามความสนใจ: แม้ว่าคุณจะสามารถใช้ observer เดียวสำหรับ entry type หลายประเภทได้ แต่บ่อยครั้งที่การสร้าง observer แยกกันสำหรับความสนใจที่แตกต่างกันจะสะอาดกว่า (เช่น อันหนึ่งสำหรับ Core Web Vitals, อันหนึ่งสำหรับ resource timings, อันหนึ่งสำหรับเมตริกที่กำหนดเอง) ซึ่งจะช่วยปรับปรุงความสามารถในการอ่านและบำรุงรักษาโค้ด
• ทำความเข้าใจเกี่ยวกับภาระด้านประสิทธิภาพ: API ถูกออกแบบมาให้มีภาระต่ำมาก อย่างไรก็ตาม ฟังก์ชัน callback ที่ซับซ้อนมากซึ่งทำการคำนวณที่หนักหน่วงอาจส่งผลกระทบต่อประสิทธิภาพได้ ทำให้ callback ของ observer ของคุณกระชับและมีประสิทธิภาพ เลื่อนการประมวลผลที่หนักหน่วงไปยัง web worker หรือส่งข้อมูลดิบไปยังแบ็กเอนด์ของคุณเพื่อประมวลผลที่นั่น

บทสรุป: การสร้างวัฒนธรรมที่ให้ความสำคัญกับประสิทธิภาพเป็นอันดับแรก

Performance Observer API เป็นมากกว่าเครื่องมืออีกชิ้นหนึ่ง มันคือการเปลี่ยนแปลงพื้นฐานในวิธีที่เราเข้าถึงประสิทธิภาพของเว็บ มันย้ายเราจากการวัดผลแบบครั้งเดียวที่เป็นปฏิกิริยา ไปสู่การตรวจสอบอย่างต่อเนื่องในเชิงรุกที่สะท้อนถึงประสบการณ์จริงและเปลี่ยนแปลงตลอดเวลาของผู้ใช้ของเราทั่วโลก ด้วยการให้วิธีการที่เชื่อถือได้และมีประสิทธิภาพในการจับภาพ Core Web Vitals, long tasks, resource timings และเมตริกที่กำหนดเอง มันช่วยให้นักพัฒนาสามารถระบุและแก้ไขปัญหาคอขวดด้านประสิทธิภาพก่อนที่จะส่งผลกระทบต่อผู้ใช้จำนวนมาก

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