فتح أداء الويب: نظرة متعمقة على واجهة برمجة تطبيقات مراقب الأداء

في عالم اليوم الرقمي سريع الخطى، لم يعد أداء الويب ترفًا؛ بل ضرورة. يمكن أن يؤدي موقع الويب البطيء أو غير المستجيب إلى إحباط المستخدمين وارتفاع معدلات الارتداد وتأثير سلبي مباشر على أهداف العمل، سواء كانت مبيعات أو إيرادات إعلانية أو مشاركة المستخدم. لسنوات، اعتمد المطورون على الأدوات التي تقيس الأداء في نقطة زمنية واحدة، وعادةً ما تكون أثناء التحميل الأولي للصفحة. في حين أن هذا النهج مفيد، إلا أنه يفوت جزءًا حرجًا من القصة: تجربة المستخدم بأكملها أثناء تفاعله مع الصفحة. هذا هو المكان الذي تأتي فيه مراقبة أداء وقت التشغيل، وأكثر أدواتها قوة هي واجهة برمجة تطبيقات مراقب الأداء.

غالبًا ما تتضمن الطرق التقليدية استطلاع بيانات الأداء باستخدام وظائف مثل performance.getEntries(). يمكن أن يكون هذا غير فعال، وعرضة لفقد الأحداث الحاسمة التي تحدث بين عمليات الاستطلاع، ويمكن أن يضيف حتى إلى عبء الأداء الذي يحاول قياسه. تُحدث واجهة برمجة تطبيقات مراقب الأداء ثورة في هذه العملية من خلال توفير آلية غير متزامنة ومنخفضة التكلفة للاشتراك في أحداث الأداء أثناء حدوثها. سيرشدك هذا الدليل في نظرة متعمقة على واجهة برمجة التطبيقات الأساسية هذه، موضحًا لك كيفية تسخير قوتها لمراقبة مقاييس الويب الأساسية، وتحديد الاختناقات، وبناء تجارب ويب أسرع وأكثر متعة لجمهور عالمي.

ما هي واجهة برمجة تطبيقات مراقب الأداء؟

في جوهرها، واجهة برمجة تطبيقات مراقب الأداء هي واجهة توفر طريقة لمراقبة وجمع أحداث قياس الأداء، والمعروفة باسم إدخالات الأداء. فكر فيها على أنها مستمع مخصص للأنشطة المتعلقة بالأداء داخل المتصفح. بدلاً من أن تطلب بنشاط من المتصفح، "هل حدث أي شيء حتى الآن؟"، يخبرك المتصفح بشكل استباقي، "لقد حدث حدث أداء جديد! إليك التفاصيل."

يتحقق ذلك من خلال نمط المراقب. يمكنك إنشاء مثيل مراقب، وإخباره بأنواع أحداث الأداء التي تهتم بها (على سبيل المثال، الرسومات الكبيرة، مدخلات المستخدم، تحولات التخطيط)، وتوفير وظيفة رد الاتصال. كلما تم تسجيل حدث جديد من نوع محدد في الجدول الزمني للأداء الخاص بالمتصفح، يتم استدعاء وظيفة رد الاتصال الخاصة بك بقائمة بالإدخالات الجديدة. هذا النموذج غير المتزامن والقائم على الدفع أكثر كفاءة وموثوقية من النموذج القديم المستند إلى السحب المتمثل في استدعاء performance.getEntries() بشكل متكرر.

الطريقة القديمة مقابل الطريقة الجديدة

لتقدير ابتكار مراقب الأداء، دعنا نقارن النهجين:

• الطريقة القديمة (الاستطلاع): قد تستخدم setTimeout أو requestAnimationFrame لاستدعاء performance.getEntriesByName('my-metric') بشكل دوري لمعرفة ما إذا تم تسجيل مقياسك. هذا أمر إشكالي لأنه قد تتحقق في وقت متأخر جدًا وتفوت الحدث، أو تتحقق بشكل متكرر جدًا وتضيع دورات وحدة المعالجة المركزية. أنت تخاطر أيضًا بملء مخزن الأداء في المتصفح إذا لم تقم بمسح الإدخالات بانتظام.
• الطريقة الجديدة (المراقبة): يمكنك إعداد PerformanceObserver مرة واحدة. يجلس بهدوء في الخلفية، ويستهلك الحد الأدنى من الموارد. بمجرد تسجيل إدخال أداء ذي صلة — سواء كان ذلك بعد ميللي ثانية واحدة بعد تحميل الصفحة أو بعد عشر دقائق في جلسة المستخدم — يتم إعلام التعليمات البرمجية الخاصة بك على الفور. يضمن هذا أنك لن تفوت أي حدث وأن رمز المراقبة الخاص بك فعال قدر الإمكان.

لماذا يجب عليك استخدام مراقب الأداء

يوفر دمج واجهة برمجة تطبيقات مراقب الأداء في سير عمل التطوير لديك العديد من الفوائد التي تعتبر بالغة الأهمية لتطبيقات الويب الحديثة التي تهدف إلى الوصول إلى نطاق عالمي.

• مراقبة غير تدخّلية: يتم تنفيذ رد اتصال المراقب عادةً خلال فترات التوقف، مما يضمن عدم تداخل رمز مراقبة الأداء الخاص بك مع تجربة المستخدم أو حظر السلسلة الرئيسية. إنه مصمم ليكون خفيف الوزن وله بصمة أداء ضئيلة.
• بيانات شاملة لوقت التشغيل: الويب ديناميكي. لا تحدث مشكلات الأداء فقط في وقت التحميل. قد يؤدي المستخدم إلى تشغيل رسم متحرك معقد أو تحميل المزيد من المحتوى عن طريق التمرير أو التفاعل مع مكون ثقيل بعد فترة طويلة من استقرار الصفحة الأولية. يلتقط مراقب الأداء أحداث وقت التشغيل هذه، مما يمنحك صورة كاملة للجلسة بأكملها.
• جاهز للمستقبل وموحد: إنه المعيار الموصى به من W3C لجمع بيانات الأداء. تم تصميم مقاييس الأداء وواجهات برمجة التطبيقات الجديدة للتكامل معه، مما يجعله خيارًا مستدامًا وتطلعيًا لمشاريعك.
• أساس مراقبة المستخدم الحقيقية (RUM): لفهم أداء موقعك حقًا للمستخدمين عبر البلدان والأجهزة وظروف الشبكة المختلفة، تحتاج إلى بيانات من جلسات حقيقية. يعد Performance Observer الأداة المثالية لبناء حل RUM قوي، مما يسمح لك بجمع المقاييس الحيوية وإرسالها إلى خدمة تحليلات للتجميع والتحليل.
• يزيل حالات السباق: باستخدام الاستطلاع، قد تحاول الوصول إلى إدخال أداء قبل تسجيله. يزيل نموذج المراقب حالة السباق هذه تمامًا، حيث يتم تشغيل التعليمات البرمجية الخاصة بك فقط بعد توفر الإدخال.

البدء: أساسيات مراقب الأداء

يعد استخدام واجهة برمجة التطبيقات أمرًا بسيطًا. تتضمن العملية ثلاث خطوات رئيسية: إنشاء مراقب، وتحديد رد اتصال، وإخبار المراقب بما يجب مراقبته.

1. إنشاء مراقب باستخدام رد اتصال

أولاً، تقوم بإنشاء مثيل كائن PerformanceObserver، وتمرير وظيفة رد اتصال إليه. سيتم تنفيذ هذه الوظيفة كلما تم اكتشاف إدخالات جديدة.

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); } });

يتلقى رد الاتصال كائن PerformanceObserverEntryList. يمكنك استدعاء طريقة getEntries() في هذه القائمة للحصول على مصفوفة لجميع إدخالات الأداء التي تمت مراقبتها حديثًا.

2. مراقبة أنواع الإدخالات المحددة

لا يفعل المراقب شيئًا حتى تخبره بما يجب مراقبته. يمكنك القيام بذلك باستخدام طريقة .observe(). تأخذ هذه الطريقة كائنًا له خاصية entryTypes (أو في بعض الحالات الحديثة، فقط type لنوع واحد)، وهي مصفوفة من السلاسل التي تمثل أنواع إدخالات الأداء التي تهتم بها.

// بدء مراقبة نوعين من الإدخالات observer.observe({ entryTypes: ['mark', 'measure'] });

تتضمن بعض أنواع الإدخالات الأكثر شيوعًا ما يلي:

• 'resource': تفاصيل حول طلبات الشبكة للأصول مثل البرامج النصية والصور وأوراق الأنماط.
• 'paint': توقيت للرسم الأول والرسم الأول للمحتوى.
• 'largest-contentful-paint': مقياس الويب الأساسي الحيوي لسرعة التحميل المتصورة.
• 'layout-shift': مقياس الويب الأساسي الحيوي للاستقرار المرئي.
• 'first-input': معلومات حول تفاعل المستخدم الأول، المستخدمة في مقياس الويب الأساسي الحيوي لتأخير الإدخال الأول.
• 'longtask': يحدد المهام الموجودة في السلسلة الرئيسية التي تستغرق أكثر من 50 مللي ثانية، والتي يمكن أن تتسبب في عدم الاستجابة.
• 'mark' & 'measure': علامات وقياسات مخصصة تحددها في التعليمات البرمجية الخاصة بك باستخدام واجهة برمجة تطبيقات توقيت المستخدم.

3. إيقاف المراقب

عندما لا تعد بحاجة إلى جمع البيانات، من الجيد فصل المراقب لتحرير الموارد.

observer.disconnect();

حالات الاستخدام العملية: مراقبة مقاييس الويب الأساسية

تعد مقاييس الويب الأساسية مجموعة من العوامل المحددة التي تعتبرها Google مهمة في تجربة المستخدم الشاملة لصفحة الويب. تعد مراقبتها واحدة من أقوى تطبيقات واجهة برمجة تطبيقات مراقب الأداء. لنرى كيف نقيس كل واحدة.

مراقبة أكبر رسم محتوى (LCP)

يقيس LCP أداء التحميل. إنه يحدد النقطة في الجدول الزمني لتحميل الصفحة عندما يتم تحميل المحتوى الرئيسي على الأرجح. نتيجة LCP الجيدة هي 2.5 ثانية أو أقل.

يمكن أن يتغير عنصر LCP أثناء تحميل الصفحة. في البداية، قد يكون العنوان هو عنصر LCP، ولكن لاحقًا، قد يتم تحميل صورة أكبر وتصبح عنصر LCP الجديد. هذا هو السبب في أن Performance Observer مثالي - فهو يخطرك بكل مرشح LCP محتمل أثناء عرضه.

// مراقبة LCP وتسجيل القيمة النهائية let lcpValue = 0; const lcpObserver = new PerformanceObserver((entryList) => { const entries = entryList.getEntries(); // الإدخال الأخير هو مرشح 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 }); // من الجيد فصل المراقب بعد تفاعل المستخدم، // حيث يمكن للتفاعلات أن تمنع إرسال مرشحي LCP الجدد. // window.addEventListener('beforeunload', () => lcpObserver.disconnect());

لاحظ استخدام buffered: true. هذا خيار حاسم يوجه المراقب لتضمين الإدخالات التي تم تسجيلها *قبل* استدعاء طريقة observe(). هذا يمنعك من فقدان حدث LCP مبكر.

مراقبة تأخير الإدخال الأول (FID) والتفاعل مع الرسم التالي (INP)

تقيس هذه المقاييس التفاعلية. فهي تحدد تجربة المستخدم كميًا عندما يحاول للمرة الأولى التفاعل مع الصفحة.

يقيس تأخير الإدخال الأول (FID) الوقت من المرة الأولى التي يتفاعل فيها المستخدم مع صفحة (على سبيل المثال، ينقر فوق زر) إلى الوقت الذي يكون فيه المتصفح قادرًا فعليًا على بدء معالجة معالجات الأحداث استجابة لهذا التفاعل. FID الجيد هو 100 مللي ثانية أو أقل.

التفاعل مع الرسم التالي (INP) هو مقياس أحدث وأكثر شمولاً حل محل FID كمقياس ويب أساسي حيوي في مارس 2024. بينما يقيس FID فقط *تأخير* التفاعل *الأول*، يقوم INP بتقييم *إجمالي زمن الانتقال* لـ *جميع* تفاعلات المستخدم خلال دورة حياة الصفحة، والإبلاغ عن الأسوأ. يمنح هذا صورة أفضل للاستجابة الإجمالية. INP الجيد هو 200 مللي ثانية أو أقل.

يمكنك مراقبة FID باستخدام نوع الإدخال '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`); // افصل بعد الإبلاغ عن الإدخال الأول fidObserver.disconnect(); } }); fidObserver.observe({ type: 'first-input', buffered: true });

تتطلب مراقبة INP المزيد قليلاً حيث أنها تنظر إلى المدة الكاملة للحدث. يمكنك مراقبة نوع الإدخال '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 يساعد على تصفية الأحداث القصيرة جدًا، والتي من المحتمل أن تكون غير ذات أهمية.

مراقبة تحول التخطيط التراكمي (CLS)

يقيس CLS الاستقرار المرئي. يساعد على تحديد عدد المرات التي يواجه فيها المستخدمون تحولات تخطيط غير متوقعة — وهي تجربة محبطة حيث يتحرك المحتوى على الصفحة دون تحذير. نتيجة CLS الجيدة هي 0.1 أو أقل.

النتيجة هي تجميع لجميع درجات تحول التخطيط الفردية. يعد 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 مهمة. تساعدك على تصفية تحولات التخطيط المشروعة التي تحدث استجابة لإجراء المستخدم (مثل النقر فوق زر يوسع قائمة)، والتي لا ينبغي أن يتم احتسابها ضمن درجة CLS.

إلى جانب مقاييس الويب الأساسية: أنواع إدخالات قوية أخرى

في حين أن مقاييس الويب الأساسية هي نقطة انطلاق رائعة، يمكن لـ Performance Observer مراقبة أكثر من ذلك بكثير. فيما يلي بعض أنواع الإدخالات المفيدة بشكل لا يصدق.

تتبع المهام الطويلة (`longtask`)

تعرض واجهة برمجة تطبيقات المهام الطويلة المهام التي تشغل السلسلة الرئيسية لمدة 50 مللي ثانية أو أكثر. هذه إشكالية لأنه بينما تكون السلسلة الرئيسية مشغولة، لا يمكن للصفحة الاستجابة لإدخال المستخدم، مما يؤدي إلى تجربة بطيئة أو متجمدة. يعد تحديد هذه المهام أمرًا أساسيًا لتحسين INP.

// مراقبة المهام الطويلة const longTaskObserver = new PerformanceObserver((entryList) => { for (const entry of entryList.getEntries()) { console.log(`Long Task Detected: ${entry.duration.toFixed(2)}ms`); // يمكن أن تخبرك خاصية 'attribution' في بعض الأحيان بما تسبب في المهمة الطويلة console.log('Attribution:', entry.attribution); } }); longTaskObserver.observe({ type: 'longtask', buffered: true });

تحليل توقيت الموارد (`resource`)

يعد فهم كيفية تحميل أصولك أمرًا أساسيًا لضبط الأداء. يمنحك نوع الإدخال 'resource' بيانات توقيت شبكة مفصلة لكل مورد في صفحتك، بما في ذلك البحث عن DNS واتصال TCP وأوقات تنزيل المحتوى.

// مراقبة توقيت الموارد 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' ضروريًا دائمًا تقريبًا لتوقيت الموارد // لالتقاط الأصول التي تم تحميلها قبل تشغيل هذا البرنامج النصي. resourceObserver.observe({ type: 'resource', buffered: true });

قياس علامات الأداء المخصصة (`mark` و`measure`)

في بعض الأحيان، تحتاج إلى قياس أداء منطق خاص بالتطبيق. تتيح لك واجهة برمجة تطبيقات توقيت المستخدم إنشاء طوابع زمنية مخصصة وقياس المدة الزمنية بينها.

• performance.mark('start-operation'): ينشئ طابعًا زمنيًا يسمى 'start-operation'.
• performance.mark('end-operation'): ينشئ طابعًا زمنيًا آخر.
• performance.measure('my-operation', 'start-operation', 'end-operation'): ينشئ قياسًا بين العلامتين.

يمكن لـ Performance Observer الاستماع إلى إدخالات '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'] });

المفاهيم والممارسات المتقدمة

لاستخدام واجهة برمجة تطبيقات مراقب الأداء بشكل فعال في بيئة إنتاج احترافية، ضع في اعتبارك أفضل الممارسات هذه.

• ضع في اعتبارك دائمًا `buffered: true`: بالنسبة لأنواع الإدخالات التي يمكن أن تحدث في وقت مبكر من تحميل الصفحة (مثل 'resource' أو 'paint' أو 'largest-contentful-paint')، يعد استخدام العلامة المخزنة المؤقتة أمرًا ضروريًا لتجنب فقدها.
• تحقق من دعم المتصفح: على الرغم من الدعم الواسع النطاق في المتصفحات الحديثة، فمن الحكمة دائمًا التحقق من وجوده قبل استخدامه. يمكنك أيضًا التحقق من أنواع الإدخالات التي يدعمها متصفح معين.
• if ('PerformanceObserver' in window && PerformanceObserver.supportedEntryTypes.includes('longtask')) { // من الآمن استخدام PerformanceObserver للمهام الطويلة }
• إرسال البيانات إلى خدمة تحليلات: يعد تسجيل البيانات في وحدة التحكم أمرًا رائعًا للتطوير، ولكن للمراقبة في العالم الحقيقي، تحتاج إلى تجميع هذه البيانات. أفضل طريقة لإرسال هذه القياسات عن بُعد من العميل هي استخدام واجهة برمجة تطبيقات navigator.sendBeacon(). إنها آلية غير حظر مصممة لإرسال كميات صغيرة من البيانات إلى خادم، وهي تعمل بشكل موثوق حتى عند إلغاء تحميل صفحة.
• تجميع المراقبين حسب الاهتمام: على الرغم من أنه يمكنك استخدام مراقب واحد لأنواع إدخالات متعددة، فغالبًا ما يكون من الأسهل إنشاء مراقبين منفصلين لاهتمامات مختلفة (على سبيل المثال، واحد لمقاييس الويب الأساسية، وواحد لتوقيت الموارد، وواحد للمقاييس المخصصة). هذا يحسن من إمكانية قراءة التعليمات البرمجية وقابليتها للصيانة.
• فهم عبء الأداء: تم تصميم واجهة برمجة التطبيقات لتكون منخفضة للغاية. ومع ذلك، يمكن لوظيفة رد اتصال معقدة للغاية تؤدي عمليات حسابية مكثفة أن تؤثر على الأداء. حافظ على ردود الاتصال الخاصة بالمراقب خفيفة وفعالة. قم بتأجيل أي معالجة مكثفة إلى عامل ويب أو إرسال البيانات الأولية إلى الواجهة الخلفية للمعالجة هناك.

الخلاصة: بناء ثقافة الأداء أولاً

تعد واجهة برمجة تطبيقات مراقب الأداء أكثر من مجرد أداة أخرى؛ إنه تحول أساسي في كيفية تعاملنا مع أداء الويب. إنه ينقلنا من قياسات تفاعلية لمرة واحدة إلى مراقبة استباقية ومستمرة تعكس التجربة الحقيقية والديناميكية لمستخدمينا في جميع أنحاء العالم. من خلال توفير طريقة موثوقة وفعالة لالتقاط مقاييس الويب الأساسية والمهام الطويلة وتوقيت الموارد والمقاييس المخصصة، فإنه يمكّن المطورين من تحديد واختزال اختناقات الأداء قبل أن تؤثر على عدد كبير من المستخدمين.

يعد اعتماد واجهة برمجة تطبيقات مراقب الأداء خطوة حاسمة نحو بناء ثقافة الأداء أولاً في أي فريق تطوير. عندما تتمكن من قياس ما يهم، يمكنك تحسين ما يهم. ابدأ في دمج هؤلاء المراقبين في مشاريعك اليوم. سيشكرك مستخدموك — أينما كانوا في العالم — على التجربة الأسرع والأكثر سلاسة والأكثر متعة.