مراقبة المستخدمين الفعليين وWeb Vitals

توفر حزمة npm المسماة web-vitals من Google واجهة API بسيطة لقياس مؤشرات أداء الويب الأساسية Core Web Vitals في متصفحات المستخدمين الفعليين. ثبّتوها باستخدام npm install web-vitals واستوردوا دوال الاستدعاء الخاصة بالمؤشرات: onLCP وonFID (مهملة) وonCLS وonFCP وonTTFB، بالإضافة إلى onINP الحديثة لقياس Interaction to Next Paint.

تتلقى كل دالة استدعاء (onLCP وonCLS وonINP وغير ذلك) كائن مؤشر يحتوي على: name ('LCP')، وvalue (بالمللي ثانية أو درجة بلا وحدة)، وrating ('good' أو 'needs-improvement' أو 'poor')، وid (معرّف فريد لإزالة التكرار). تُستدعى الدالة بعد تثبيت قيمة المؤشر.

استخدموا Navigator.sendBeacon API أو fetch لإرسال المؤشرات إلى نقطة نهاية التحليلات الخاصة بكم. يُفضَّل sendBeacon لأنه يواصل العمل حتى بعد إلغاء تحميل الصفحة — وهذا أمر بالغ الأهمية لمؤشرات مثل CLS التي تُثبَّت عند إخفاء الصفحة. اجمعوا تقارير المؤشرات كلها في beacon واحد متى أمكن.

لدمج مؤشرات أداء الويب في OpenTelemetry، أنشئوا أدوات Gauge لكل مؤشر، مثل: const lcp = meter.createObservableGauge('web_vitals.lcp'). في كل دالة استدعاء onLCP، سجّلوا القيمة مع السمات ذات الصلة (مسار الصفحة ونوع الجهاز). يمكن لواجهة المراقبة الخلفية بعد ذلك إطلاق تنبيه عند حدوث تراجعات في P75 LCP.

لقياس أداء خاص بـ React لا تغطيه مؤشرات أداء الويب، استخدموا User Timing API: استدعوا performance.mark('render-start') قبل العرض، وperformance.mark('render-end') بعده، ثم performance.measure('component-render', 'render-start', 'render-end'). ستظهر هذه القياسات في علامة التبويب Performance ضمن Chrome DevTools.

يغلّف مكوّن React Profiler شجرة فرعية ويستدعي دالة الاستدعاء onRender الخاصة به مع بيانات التوقيت: id (معرّف Profiler)، وphase ('mount' أو 'update')، وactualDuration (مدة العرض)، وbaseDuration (مدة العرض المقدّرة من دون memoization). استخدموا ذلك أثناء التطوير لتحديد المكوّنات البطيئة.

يمكن التقاط الأخطاء غير المعالجة وعمليات رفض Promise باعتبارها OTel spans ذات حالة خطأ. أعدّوا مستمعين عامّين: window.addEventListener('error', handler) وwindow.addEventListener('unhandledrejection', handler). أنشئوا span، واضبطوا حالته باستخدام span.setStatus({ code: SpanStatusCode.ERROR })، وأضيفوا رسالة الخطأ وتتبّع المكدس باعتبارهما سمات، ثم أنهوا span.

تلتقط React Error Boundaries أخطاء العرض في شجرة المكوّنات. في الطريقة componentDidCatch، أنشئوا OTel span يمثّل الخطأ، واضبطوا حالته على ERROR، وأرفقوا error.message وcomponentStack باعتبارهما سمات، ثم استدعوا span.end(). يؤدي ذلك إلى توجيه أخطاء عرض React إلى مسار التتبّع الموزّع الخاص بكم.

ينتج JavaScript المصغّر في بيئة الإنتاج تتبّعات مكدس يتعذّر قراءتها، مثل "a.b at bundle.min.js:1:84721". ارفعوا خرائط المصدر إلى Sentry أو Datadog أو مسار OTel أثناء عملية البناء في CI/CD، حتى تُحلّ تتبّعات المكدس الأولية تلقائيًا إلى أسماء ملفات TypeScript الأصلية وأرقام الأسطر.

إن إرسال بيانات التتبّع الكاملة لكل جلسة مكلف. نفّذوا أخذ عينات للجلسات: عيّنوا عشوائيًا علامة sessionSampled عند تحميل الصفحة لأول مرة، وخزّنوها في sessionStorage. هيّئوا OTel SDK وأرسلوا عمليات التتبّع للجلسات التي أُخذت منها عينات فقط (مثلًا، 10%). احرصوا دائمًا على أخذ عيّنة بنسبة 100% من الجلسات التي تتضمن أخطاءً.

تتيح مؤشرات أداء الويب المُرسلة باعتبارها مقاييس OTel إطلاق تنبيهات تستند إلى SLO: فإذا تجاوز P75 LCP مدة 2.5 ثانية لأكثر من 5% من الجلسات خلال فترة مدتها ساعة واحدة، فأطلقوا تنبيهًا. يمنح ذلك فرق الهندسة إشارات قابلة للتنفيذ مرتبطة مباشرة بتجربة المستخدم، بدلًا من مقاييس البنية التحتية للواجهة الخلفية.

متى تُستدعى دالة الاستدعاء onLCP من مكتبة web-vitals؟

توفر مكتبة web-vitals دوال استدعاء بسيطة لقياس LCP وINP وCLS وFCP وTTFB في متصفحات المستخدمين الفعليين. أرسلوا هذه القيم باعتبارها مقاييس OTel لإطلاق تنبيهات تستند إلى SLO، والتقطوا الأخطاء عبر المستمعين العامّين وReact Error Boundaries باعتبارها OTel spans، وارفعوا خرائط المصدر لحلّ تتبّعات المكدس المصغّرة. خذوا عينات من الجلسات للتحكم في حجم البيانات مع الحفاظ على تغطية كاملة للأخطاء بنسبة 100%.