لماذا تختلف بيانات CrUX عن بيانات RUM؟

تعرَّف على الأسباب التي قد تؤدي إلى عرض أرقام مختلفة في "مؤشرات أداء الويب الأساسية" عن CrUX في بيانات RUM.

يوفّر تقرير تجربة المستخدم في Chrome (CrUX) مقاييس لتقييم تجربة المستخدم وفقًا لتجربة مستخدمي Chrome في الوجهات الرائجة على الويب. يجمع Chrome هذه البيانات تلقائيًا من المستخدمين الذين وافقوا على ذلك، ويتم توفيرها استنادًا إلى معايير أهلية CrUX.

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

تشبه ميزة مراقبة المستخدم الفعلي (RUM) نظام CrUX، ولكن بدلاً من أن يجمع Chrome تلقائيًا مقاييس تجربة المستخدم، يتم تضمين الرمز في المواقع الإلكترونية لإجراء هذه المجموعة وإعادتها إلى موفّر RUM أو حل إحصاءات لإجراء المزيد من التحليل.

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

فوائد استكمال CrUX باستخدام حل RUM

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

ومع ذلك، للتعمق أكثر في التحقيق في أسباب ظهور الأرقام للأرقام، يمكن أن يمنحك الاستثمار في حل RUM كامل لاستكمال "تقرير تجربة المستخدم" (CrUX) إمكانية الوصول إلى معلومات أكثر تفصيلاً مما يمكن إتاحتها في مجموعة بيانات يمكن طلبها بشكل علني. ويمكن أن يساعدك ذلك في شرح مقاييسك وتحسينها بعدة طرق.

تحليل أعمق للتحقيق في المشاكل

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

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

الارتباط بمقاييس الأعمال الأخرى

كما تسمح لك أداة RUM بمقارنة مقاييس أداء الويب مباشرةً بأيّ مقاييس أنشطة تجارية، ما يُظهر قيمة الاستثمار في الأداء ومقاييس الأداء الأخرى التي يجب تحديد أولوياتها. لدينا دراسات حالة متعددة تشمل أنشطة تجارية تُجري هذا الارتباط، مثل Farfetch أو The Economic Times.

جمع بيانات الأداء الأخرى

يسمح حل RUM باستخدام مجموعة من المقاييس المخصّصة الأخرى المرتبطة مباشرةً بنشاطك التجاري المحدّد. ومن الأمثلة الأكثر شهرة مقياس "حان الوقت لنشر أول تغريدة" على Twitter. ويمكن بعد ذلك ربط هذه الإجراءات الخاصة بالموقع الإلكتروني بتحسينات "مؤشرات أداء الويب الأساسية" ومقاييس الأعمال.

الاختلافات بين مجموعتَين من بيانات الحقول

الرجل الذي يرتدي الساعة يعرف الوقت، ولكن لا يعرف الرجل الذي يرتدي ساعتَين أبدًا.

قانون "سيغال"

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

بيانات المعمل مقابل بيانات المجال

عليك أولاً التحقّق مما إذا كنت تنظر إلى مقاييس معملية (تركيبية) أو مقاييس حقل (RUM). في حين أنه من الطبيعي افتراض أن منتجات RUM تنظر فقط إلى البيانات الميدانية، فإن العديد منها يوفر مكونًا اختباريًا أيضًا.

تعد بيانات المعمل مفيدة للغاية بسبب الظروف الثابتة التي تقيسها في ظل. ويمكن استخدامه لرصد التغييرات أو الانحدارات غير المتوقعة في بيئة إنتاج بدون إحداث ضجيج في سكان المجال المتغيرين. ومع ذلك، قد لا تمثّل البيانات المعملية تجربة المستخدم الحقيقية، وبالتالي يمكن للمقاييس الميدانية أن تعرض نتائج مختلفة تمامًا.

السكان

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

المتصفّحات المضمَّنة

إنّ تقرير تجربة المستخدم على Chrome، كما يوحي اسمه، هو Chrome فقط. في حين أنّ هناك العديد من المتصفحات المستندة إلى Chromium (Edge وOpera وBrave وغير ذلك الكثير) والتي تتيح أيضًا المقاييس نفسها المتوفّرة في Chrome وفقًا لقاعدة الرموز الأساسية المشتركة، يستطيع مستخدمو Chrome فقط إدخال البيانات في تقرير تجربة المستخدم على Chrome. ويعني هذا التقييد أيضًا أنه لا يتم تضمين مستخدمي Chrome على نظام التشغيل iOS، لأنه يستخدم محرك متصفح Webkit الأساسي. ولا يتم أيضًا احتساب مكوّنات Android WebView على أنّها "Chrome"، وبالتالي لا يتم تضمين بيانات من هؤلاء المستخدمين، على الرغم من تضمين علامات التبويب المخصَّصة في Chrome.

وعلى الرغم من أنّ متصفّح Chrome هو أحد أشهر المتصفحات حول العالم، وبالتالي من المحتمل أن يقدّم تمثيلاً واسعًا لأداء موقعك الإلكتروني في معظم الحالات. فقياس هذا المتصفّح فقط لا يعني بأي حال من الأحوال مقياس جميع المستخدمين. قد يفسر هذا اختلافًا رئيسيًا بين RUM وCrUX. وينطبق هذا بوجهٍ خاص على أساليب الأداء التي تعتمد على واجهات برمجة التطبيقات أو تنسيقات الصور التي لا تتوفّر إلا في Chrome، على سبيل المثال.

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

يمكن لحلول RUM أن تحصل على بيانات للمتصفّحات الأخرى بخلاف Chrome، لا سيما من المتصفّحات المستندة إلى Chromium التي غالبًا ما تتضمّن المقاييس نفسها (مثل "مؤشرات أداء الويب الأساسية"). يتم أيضًا قياس المتصفحات التي لا تستند إلى Chromium باستخدام حلول RUM، ولكن قد تحتوي على مجموعة محدودة من المقاييس. على سبيل المثال، لا يتوفّر متغيّرات التصميم التراكمية (CLS) والتفاعل إلى سرعة عرض اللقطة (INP) حاليًا إلا في المتصفّحات المستندة إلى Chromium. يمكن قياس بعض المقاييس الأخرى، مثل سرعة عرض المحتوى على الصفحة (FCP) بشكل مختلف تمامًا (يُرجى الاطّلاع على لاحقًا).

المستخدمون الذين فعّلوا الميزة

بالإضافة إلى حصر تجربة المستخدم على Chrome لمستخدِمي Chrome، يتم فرض قيود إضافية على تقرير تجربة المستخدم على Chrome من خلال قياسه فقط لمجموعة فرعية من مستخدمي Chrome الذين وافقوا على مشاركة بيانات هذه التجربة عندما يكون المتصفّح مثبّتًا.

يفحص موفرو RUM أيضًا مجموعة فرعية من المستخدمين فقط، وعادةً ما يكون هذا بسبب طلبات بانر ملفات تعريف الارتباط - التي تطلب من المستخدمين تفعيل جمع بيانات RUM - أو أدوات حظر التتبع. ويمكن أن يؤثر ذلك سلبًا في بعض عمليات التحميل الأولية للصفحات في حال عدم تلقّي التأكيد إلى أن تظهر الصفحة الثانية أو التي تليها، عندما تكون بعض مواد عرض الموقع الإلكتروني مخزَّنة مؤقتًا من الصفحات السابقة. إذا تكرّر ذلك، قد تبدو المقاييس أكثر إيجابية في RUM مقارنةً بأحجامها الفعلية إذا تم استبعاد عمليات التحميل الأولية الأبطأ للصفحات في عدد كافٍ من الحالات.

المواقع الإلكترونية المضمّنة

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

مع ذلك، إذا تم تصنيف صفحات معيّنة من الموقع الإلكتروني على أنّها قابلة للفهرسة بينما لا يمكن فهرستها على صفحات أخرى، قد تظهر لك مجموعة فرعية فقط من عناوين URL في تقرير تجربة المستخدم على Chrome. إذا كان المصدر قابلاً للاكتشاف بشكل علني، سيتم تضمين كل مشاهدات الصفحة ضمن هذا المصدر في البيانات على مستوى المصدر، ولكن قد لا تتوفّر البيانات على مستوى عنوان URL.

الأجهزة

يعمل تقرير تجربة المستخدم على تقسيم البيانات حسب الأجهزة الجوّالة وأجهزة الكمبيوتر المكتبي والأجهزة اللوحية، مع أنّ العديد من الأدوات تركّز على الأولَين وقد لا تعرض بيانات الجهاز اللوحي أو قد تتضمّنها على الأجهزة الجوّالة أو أجهزة الكمبيوتر المكتبي. يمكن أن تكون خصائص الأداء على الهاتف المحمول مقابل سطح المكتب مختلفة تمامًا - سواء من حيث المحتوى الذي يتم تقديمه أو إمكانات الأجهزة التي تعرضها.

ستتيح بيانات RUM أن يتم تقسيم الزيارات بطريقة مماثلة، ولكنها غالبًا ما تعرض بيانات موحدة بشكل افتراضي. قد تسمح RUM فقط بالتقسيم حسب نوع الجهاز (على سبيل المثال، الجوّال) أو المتصفح (على سبيل المثال، Chrome)، ولكن ليس بإمكان الاثنين معًا الاطلاع على زيارات Chrome للجوّال فقط. عند المقارنة ببيانات CrUX، عليك التأكّد من أنك تقارِن بين النتائج من خلال الفلترة حسب نوع الجهاز ومتصفّح Chrome.

أخذ العينات

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

تجميع البيانات

ستتضمّن بيانات الحقول بطبيعتها العديد من نقاط البيانات ذات المقاييس نفسها مقارنةً ببيانات المعمل، والتي ستعطي قيمة واحدة. وإذا تم تجميع هذه البيانات بشكل مختلف لإعداد التقارير، قد يؤدّي ذلك إلى سبب آخر للاختلافات بين CrUX وRUM.

الفترة الزمنية

تستند بيانات تقرير تجربة المستخدم على Chrome إلى فترة مرور متدرّجة تبلغ 28 يومًا، ولا يمكن تغيير هذا الإطار الزمني. ومع ذلك، يتم تخزين بيانات CrUX BigQuery لكل شهر، ما يسمح لك بالاطّلاع على الأشهر السابقة، كما تقدّم CrUX History API أيضًا بيانات سابقة على مدار فترة أسبوعية. ولا يزال كلاهما يقدّم البيانات استنادًا إلى الفترة الممتدة التي تبلغ 28 يومًا.

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

تجميع الإحصاءات

ويتم قياس مقاييس CrUX عند الشريحة المئوية الخامسة والسبعين، أي بالنظر إلى القيمة التي حققتها% 75 من مشاهدات الصفحة على الويب. ستشمل البيانات الميدانية أساليب استثنائية وإزالة أسوأ تجارب بنسبة 25%، ويهدف إلى إعطاء قيمة يُتوقع من غالبية الزوار تحقيقها بشكل معقول.

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

تشتمل بيانات المدرج التكراري في CrUX على جميع البيانات المتاحة، وليس فقط الشريحة المئوية الخامسة والسبعين، كما تعرض عدد مرات مشاهدة الصفحة في كل تقييم، ولكن ستعتمد النتيجة المجمّعة على الشريحة المئوية الخامسة والسبعين. تظهر بيانات CrUX في أدوات مثل إحصاءات PageSpeed:

الاختلافات بين المقاييس

تتوفّر عدة مقاييس تُستخدم لقياس أداء الويب، لذا عند مقارنة مجموعتين مختلفتين من البيانات، من المهم فهم المقاييس التي يتم قياسها وكيفية استخدام هذه المقاييس.

المقاييس التي تم قياسها

بيانات CrUX هي مجموعة البيانات الرسمية لمبادرة مؤشرات أداء الويب الأساسية، وهي تقيس هذه المقاييس في المقام الأول (LCP وCLS وINP)، مع بعض المقاييس الإضافية مكمّلة لها.

عادةً ما تتضمّن أدوات RUM مؤشرات أداء الويب الأساسية هذه، ولكنها غالبًا ما تتضمّن العديد من المقاييس الأخرى أيضًا. يقيس بعض موفري RUM أيضًا تجربة المستخدم باستخدام مجموعتهم الخاصة من جميع هذه المقاييس ربما لتقديم "مؤشر السعادة" أو ما شابه. عند مقارنة بيانات RUM بـ CrUX، تأكد من أنك تقارن النتائج المتشابهة.

بالنسبة إلى الأدوات التي تقيّم مدى النجاح أو الإخفاق في "مؤشرات أداء الويب الأساسية"، يجب أن تأخذ الصفحة في الاعتبار إذا كانت تستوفي الأهداف المقترَحة عند نسبة %75 لجميع مؤشرات أداء الويب الأساسية. إذا لم يكن مقياس INP متوفّرًا للصفحات التي لا تتضمّن تفاعلات، يجب اجتياز LCP وCLS فقط.

الاختلافات في المقاييس على مستوى المتصفحات

لا يقيس CrUX سوى في متصفّحات Chrome، ويمكنك الرجوع إلى سجلات التغييرات في مؤشرات أداء الويب لمعرفة مدى تغيّر هذه المؤشرات في كل إصدار من إصدارات Chrome.

ومع ذلك، ستقيس حلول RUM من مجموعة متنوعة من المتصفحات. من المرجح أن تكون المتصفحات التي تستند إلى Chromium (Edge وOpera وما إلى ذلك) مشابهة لمتصفِّح Chrome، ما لم ينفّذ Chrome تغييرات جديدة كما هو موضّح في "سجلّ التغييرات".

بالنسبة إلى المتصفّحات التي لا تستخدم Chromium، يمكن أن تكون الاختلافات أكثر وضوحًا. على سبيل المثال، يتوفّر سرعة عرض المحتوى على الصفحة (FCP) في Safari وFirefox، ولكن يتم قياسه بطريقة مختلفة. وقد يؤدي هذا إلى تفاوتات كبيرة في الأوقات التي يتم الإبلاغ عنها. كما ذُكر سابقًا، إذا كنت ترغب في مقارنة RUM بـ CrUX، فمن الأفضل التصفية على مستخدمي Chrome فقط للسماح بمقارنة التشابه.

توقيت المقاييس

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

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

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

لا تفترض أنّ توقيتات LCP المقدّمة في CrUX أو RUM تستند إلى العنصر نفسه الذي تتّبعه أدوات التمرين المعملي. سيمنحك تقرير CrUX القيمة الإجمالية لسرعة LCP لكل صفحة أو مصدر، ولكن يمكن لذاكرة RUM أن تقسّمها أيضًا لتحديد جلسات فردية لمشاكل LCP.

يتم قياس متغيّرات التصميم التراكمية (CLS) طوال عمر الصفحة، لذلك قد لا تمثّل متغيّرات التصميم التراكمية (CLS) التي يتم تحميلها في الصفحة الأولى الصفحات التي تؤدي إلى حدوث تغيّرات أكبر في وقت لاحق بعد تحميل الصفحة وتفاعل المستخدم معها. وبالتالي، إنّ أخذ قيمة متغيّرات التصميم التراكمية (CLS) بعد تحميل الصفحة فقط، كما تفعل العديد من منتجات RUM، سيعطي نتيجة مختلفة عن أخذ قيمة متغيّرات التصميم التراكمية (CLS) بعد أن ينتهي المستخدم من تحميل الصفحة.

يتطلّب مقياس استجابة مدى استجابة الصفحة لتفاعلات المستخدم (INP) إدخالاً لقياسه، ويلاحظ جميع تفاعلات النقر والنقر ولوحة المفاتيح طوال مدة بقاء الصفحة، على غرار متغيّرات التصميم التراكمية (CLS)، وبالتالي قد تكون قيمة مقياس مدى استجابة الصفحة لتفاعلات المستخدم (INP) مختلفة جدًا إذا تم قياسها بعد إجراء المستخدم لعدد من التفاعلات على الصفحة.

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

من المهمّ الحصول على معلومات من موفّر RUM عن وقت قياس "مؤشرات أداء الويب الأساسية" عند رصد اختلافات غير مبرّرة بين مصدرَي البيانات.

تطبيقات من صفحة واحدة

تعمل تطبيقات الصفحة الواحدة (SPA) عن طريق تحديث محتوى الصفحة الحالية، بدلاً من إجراء التنقل التقليدي في الصفحة على مستوى المتصفح. ويعني هذا أنّ المتصفّح لا يرى هذه التنقّلات في الصفحات، على الرغم من أنّ المستخدمين يختبرونها على هذا النحو. لن تأخذ واجهات برمجة التطبيقات "مؤشرات أداء الويب الأساسية" التي يوفّرها المتصفّح هذه في الاعتبار، وبالتالي لا يتوافق تقرير تجربة المستخدم على Chrome مع عمليات التنقّل هذه في الصفحات. لا يزال العمل قيد التنفيذ لحل هذه المشكلة. يُرجى الاطّلاع على المشاركة تجربة قياس عمليات التنقّل اللينة للحصول على مزيد من المعلومات.

يحاول بعض موفّري RUM اكتشاف "عمليات التنقّل المصغّرة" في SPA، ولكن إذا كانوا ينسبون أيضًا مقاييس "مؤشرات أداء الويب الأساسية" إلى "عمليات التنقّل البسيطة" هذه، سيؤدي ذلك إلى اختلافات مع CrUX لأنّ واجهات برمجة التطبيقات الأساسية لا تتيح ذلك للعديد من المقاييس.

الاختلافات في CrUX وWeb API

بالإضافة إلى الاختلافات في أي مشاهدات الصفحة يتم قياسها وأنواعها، هناك بعض السيناريوهات الأخرى الأكثر تعقيدًا التي يجب أن تكون على دراية بها والتي يمكن أن تؤدي إلى اختلافات في بيانات CrUX وRUM. ويرجع بعض هذه الأسباب إلى القيود المفروضة على واجهات برمجة تطبيقات الويب المستخدَمة لقياس المقاييس، وبعضها بسبب الحاجة إلى التعامل مع النتائج التي تعرضها واجهة برمجة التطبيقات بطريقة مختلفة في سيناريوهات معيّنة. تتضمّن مستندات "مؤشرات أداء الويب الأساسية" هذه الاختلافات في مقياسَي LCP وCLS، غير أنّ الاختلافات الرئيسية تظهر أدناه.

ميزة "التخزين المؤقت للصفحات"

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

إطارات iframe

لأسباب تتعلق بالأمان والخصوصية، لا يمكن لصفحات المستوى الأعلى الوصول إلى المحتوى داخل إطارات iframe (وليس حتى إطارات iframe من المصدر نفسه). ويعني هذا أنّه لا يمكن قياس مقاييس الأداء الخاصة بالمحتوى في تلك المنصّات إلا باستخدام إطار iframe نفسه، وليس من خلال Web APIs في صفحة الإطار. إذا كان محتوى iframe يتضمّن عنصر LCP أو محتوًى يؤثر في متغيّرات التصميم التراكمية (CLS) أو مقياس INP الذي يواجهه المستخدم، لن يكون هذا العنصر متاحًا لحلول RUM (بما في ذلك مكتبة JavaScript لـ "مؤشرات Google على الويب").

ومع ذلك، لا يتم فرض هذه القيود عند قياس تقرير تجربة المستخدم على Chrome باستخدام متصفِّح Chrome نفسه بدلاً من JavaScript على الصفحة، وكذلك يتم قياس المقاييس في إطارات iframe عند إعداد تقارير "مؤشرات أداء الويب الأساسية". وهذا يعكس بدقة أكبر ما يمر به المستخدم، ولكن يمكن أن يكون سببًا آخر للاختلافات في المواقع التي تستخدم إطارات iframe.

وهناك مثال واضح على كيفية تحقيق الاختلافات بين بيانات سرعة عرض أكبر جزء من المحتوى على الصفحة (LCP) في CrUX وRUM <video>. يمكن احتساب أول إطار ملوَّن تلقائيًا لعنصر <video> كمرشّح لمقياس LCP، إلا أنّ اللقطات المضمَّنة لخدمات بث الفيديو الرائجة قد تضع هذه العناصر في <iframe>. ويمكن أن يراعي CrUX هذا، حيث يمكنه الوصول إلى محتوى <iframe>، ولكن لا يمكن لحلول RUM أن تفعل ذلك.

المراجع المشتركة المصادر

لا تمنح وسائط LCP المعروضة من نطاقات أخرى وقتًا للعرض في واجهة برمجة تطبيقات PerformanceMonitorer، ما لم يتم توفير عنوان Timing-Allow-Origin (TAO)، بسبب القيود الأمنية في المتصفِّح للحد من الهجمات ذات التوقيت. ويشير هذا إلى وقت تحميل المورد، غير أنّ ذلك قد يكون مختلفًا تمامًا عن الوقت الذي تم فيه عرض المحتوى.

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

ويُعِدّ تقرير CrUX بيانات عن مدة العرض في "مؤشرات أداء الويب الأساسية". ننصح المواقع الإلكترونية بتقييد المحتوى من مصادر متعددة والذي يؤثر في مقاييس "مؤشرات أداء الويب الأساسية" وتفعيل TAO حيثما أمكن إذا أرادت قياس ذلك بدقة أكبر. وقد تخضع الموارد الأخرى المتعددة المصادر لقيود مماثلة.

علامات التبويب في الخلفية

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

إذًا، ما الذي يمكننا فعله حيال ذلك؟

لقد أوضحنا سبب وجود اختلافات بين بيانات CrUX وRUM، سواء بسبب الاختلافات في المنهجية التي يستخدمها كل منهما أو بسبب تضمين المستخدمين ومشاهدات الصفحة أو استبعادها. من المفترَض أن تظل مجموعتي البيانات تمثل أداء موقعك الإلكتروني لتحقيق فائدة، ولكن يجب أن توضّح هذه المقالة سبب عدم احتمال حصول كل منهما على الأرقام نفسها بالضبط.

عندما تكون الاختلافات طفيفة (على سبيل المثال، الإبلاغ عن سرعة عرض أكبر جزء من المحتوى على الصفحة (LCP) بمقدار 2.0 ثانية مقابل 2.2 ثانية)، ستكون مجموعتا البيانات مفيدتان ويمكن اعتبارهما عادةً متزامنتين تقريبًا.

عندما تجعلك الاختلافات الواضحة تشكك في دقة البيانات، يجب أن تحاول فهم تلك الاختلافات. هل يمكن تصفية بيانات RUM لتكون أكثر توافقًا مع CrUX (بالنظر فقط إلى مستخدمي Chrome، على أجهزة الكمبيوتر المكتبي أو الأجهزة الجوّالة، مع قيم الشريحة المئوية الخامسة والسبعين خلال 28 يومًا) لتقليل هذه الاختلافات؟

إذا كان الأمر كذلك - ويمكنك الحصول على مطابقة البيانات بشكل أوثق - فلا يزال يتعين عليك السؤال عن سبب ملاحظة هذه الاختلافات في البيانات الإجمالية وما يعنيه ذلك. هل يُغيّر المستخدمون الذين لا يستخدمون Chrome المقاييس بطريقة إيجابية أو سلبية؟ هل يوفّر لك ذلك المزيد من الإحصاءات حول المشاكل في الأداء التي يمكنك تحديد أولوياتها؟

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

بعد فهم أسباب أي اختلافات، يمكن أن تكون كلتا الأداتين مفيدتين للغاية لفهم تجارب المستخدم على موقع الويب الخاص بك، وللمساعدة في تحسين ذلك حتى إذا لم تكن الأرقام متطابقة. استخدِم بيانات RUM لتكمل بيانات CrUX وتسمح لك بالتعمّق في ما يخبرك به تقرير CrUX على مستوى عالٍ من خلال تقسيم الزيارات لمساعدتك على تحديد ما إذا كانت مناطق معيّنة في موقعك الإلكتروني أو قاعدة مستخدمين تستدعي الانتباه.

غالبًا ما يكون الاطلاع على المؤشرات لرؤية التحسينات التي أجريتها على التأثيرات الإيجابية المتوقعة أكثر أهمية من تطابق كل رقم تمامًا بين مصدري البيانات. كما ذُكر أعلاه، يسمح لك RUM بإلقاء نظرة على أطر زمنية مختلفة للحصول على نظرة مسبقة على نتائج CrUX لمدة 28 يومًا، على الرغم من أن النظر إلى الإطارات الزمنية القصيرة جدًا يمكن أن يؤدي إلى بيانات مزعجة، وبالتالي لماذا يستخدم CrUX 28 يومًا.

ولا تتوفر إجابة "صحيحة" أو "خاطئة" في هذه المقاييس المختلفة، إذ إنّها ببساطة تختلف في منظور المستخدمين عن تجربتهم وتجربتهم. طالما أنك تدرك سبب حدوث هذه الاختلافات، وما يمكن أن يفعله ذلك لدفع اتخاذك للقرار، فهذا هو الأهم لتقديم خدمة أفضل لزوّار موقعك.

شكر وتقدير

صورة مصغّرة من ستيفن ليلهام على UnLaunch