تعرَّف على الأسباب التي قد تجعل بيانات RUM تعرض أرقامًا مختلفة في تقرير "مؤشرات أداء الويب الأساسية" عن تقرير تجربة المستخدم في Chrome.
يوفّر تقرير تجربة المستخدم (CrUX) مقاييس تجربة المستخدم وفقًا لتجربة مستخدمي Chrome في الوجهات الرائجة على الويب. يجمع Chrome هذه البيانات تلقائيًا من المستخدمين الذين وافقوا على ذلك، ويتم إتاحتها وفقًا لمعايير الأهلية في تقرير تجربة المستخدم على Chrome.
وبالتالي، تتوفّر بيانات تقرير تجربة المستخدم على Chrome لملايين المواقع الإلكترونية. لم يكن بإمكان العديد من مالكي المواقع الإلكترونية الوصول إلى بيانات الحقول من قبل، وأتاح تقرير تجربة المستخدم (CrUX) للعديد من المواقع الإلكترونية الاطّلاع على قيمة هذه البيانات للمرة الأولى. كمجموعة بيانات عامة، يمكن أيضًا استخدام CrUX أيضًا في التحليل التنافسي وقياس مقاييس تجربة المستخدم.
تشبه ميزة تتبُّع المستخدم الفعلي (RUM) أداة CrUX، ولكن بدلاً من أن يجمع Chrome مقاييس تجربة المستخدم تلقائيًا، يتم تضمين الرمز على المواقع الإلكترونية لإجراء هذه المجموعة وتزويدها ب مرة أخرى موفّر خدمة RUM أو أحد حلول الإحصاءات لإجراء المزيد من التحليلات.
من خلال قياس كلا الحلَّين لمقاييس تجربة المستخدم، من الطبيعي افتراض أنّهما يجب أن يكونا متكافئَين. قد يكون من المحير أن نلاحظ الاختلافات. سيشرح هذا الدليل أسباب حدوث ذلك، كما سيقدم اقتراحات لما يجب فعله في حالة عدم تطابق الأرقام.
مزايا استكمال CrUX بحل RUM
وتقرير تجربة المستخدم (CrUX) هو أداة رائعة للحصول على عرض متّسق على مختلف المواقع الإلكترونية، وبما أنّها مجموعة البيانات الرسمية لبرنامج "مؤشرات أداء الويب الأساسية"، من المرجّح أن تحتاج المواقع الإلكترونية إلى متابعة ما تعرضه. الهدف من CrUX هو تقديم نظرة عامة ذات صلة إحصائيًا لملايين من المواقع الإلكترونية لإجراء مقارنة متبادلة.
ومع ذلك، للتعمق في التحقيق في سبب ظهور الأرقام، يمكن أن يمنحك الاستثمار في حل RUM الكامل لاستكمال CrUX إمكانية الوصول إلى معلومات أكثر تفصيلاً مما يمكن إتاحتها في مجموعة بيانات يمكن طلبها بشكل علني. ويمكن أن يساعدك ذلك في شرح المقاييس وتحسينها بعدة طرق.
تحليل أعمق للتحقيق في المشاكل
يمكن استخدام تقرير تجربة المستخدم (CrUX) غالبًا للإشارة إلى ما إذا كانت لديك مشكلة على موقعك الإلكتروني، ولكن ليس بالضرورة في مكان المشكلة على موقعك الإلكتروني أو السبب. يمكن أن تساهم حلول RUM في سدّ هذه الفجوة، سواء كانت منتجات محلية من خلال مثل مكتبة مؤشرات أداء الويب أو بعض المنتجات التجارية العديدة.
ويتيح لك استخدام حل RUM الوصول إلى بيانات أكثر دقة لجميع صفحاتك وعلى جميع المتصفحات. ويتيح لك أيضًا تقسيم هذه البيانات وتحليلها بطرق لا تقتصر على CrUX، مما يتيح لك التوغّل والتحقيق في مناطق المشاكل في الموقع. هل تتأثر بشريحة معينة من المستخدمين؟ أو المستخدمين الذين يتخذون إجراءات معينة؟ متى بدأت المشكلة بالضبط؟ هذه أسئلة يسهل الإجابة عنها بكثير من خلال البيانات الإضافية التي يمكن أن توفرها أداة RUM.
الربط بمقاييس تجارية أخرى
وتتيح لك أداة RUM أيضًا مقارنة مقاييس أداء الويب مباشرةً مع أي مقاييس خاصة بالأنشطة التجارية، ما يوضّح قيمة الاستثمار في الأداء والإجراءات الأخرى التي يجب منحها الأولوية. لدينا العديد من دراسات الحالة على مستوى أنشطة تجارية تُجري هذه العلاقة، مثل Farfetch أو The Economic Times.
جمع بيانات الأداء الأخرى
ويتيح حل RUM مجموعة من المقاييس المخصّصة الأخرى المرتبطة مباشرةً بنشاطك التجاري المحدّد. ومن الأمثلة الأكثر رواجًا على Twitter عبارة "حان الوقت لنشر التغريدات الأولى" على Twitter. المقياس. ويمكن بعد ذلك ربط هذه الإجراءات الخاصة بالموقع الإلكتروني بتحسينات "مؤشرات أداء الويب الأساسية" ومقاييس الأعمال.
الاختلافات بين مجموعتين من بيانات المجال
رجل يرتدي ساعة ويعرف كم الساعة. الرجل الذي يمتلك ساعتين غير متأكد أبدًا.
قانون سيغال
عندما يكون لديك مصدران للبيانات، قد يكون من المحبط والمربك معرفة سبب اختلافهما. مثلما يكون من المهم فهم الفرق بين المقاييس الاختبارية والمقاييس الميدانية، يمكن أيضًا أن تكون هناك اختلافات بين مصدرَين للبيانات الميدانية. في حين أن البيانات ستكون هي نفسها في عالم مثالي، هناك العديد من الأسباب التي قد تؤدي إلى اختلافها.
البيانات المعملية مقابل البيانات الميدانية
عليك التأكّد أولاً مما إذا كنت تطّلع على مقاييس المختبر (الاصطناعي) أو مقاييس الحقول (RUM). ورغم أنه من الطبيعي افتراض أن منتجات RUM لا تنظر إلا إلى البيانات الميدانية، إلا أن العديد منها يوفر مكونًا تطبيقيًا أيضًا.
تعد البيانات المعملية مفيدة للغاية على وجه التحديد بسبب الظروف الثابتة التي تقيسها. ويمكن استخدامه لرصد التغييرات أو الانحدارات غير المتوقعة في بيئة إنتاج بدون ضجيج سكان الحقل المتغير. ومع ذلك، قد لا تمثّل البيانات المختبرية تجربة المستخدم الحقيقية، وبالتالي يمكن أن تعرض المقاييس الميدانية نتائج مختلفة تمامًا.
السكّان
قد تختلف مجموعات البيانات المستخدمة في حلول CrUX وRUM بسبب الاختلافات في قياس زيارات الصفحات اعتمادًا على المتصفحات والمستخدمين والمواقع والأجهزة التي تتم مقارنتها.
المتصفحات المضمَّنة
تقرير تجربة المستخدم على Chrome، كما يوحي اسمه، هو Chrome فقط. هناك العديد من المتصفّحات (Edge وOpera وBrave على سبيل المثال لا الحصر) التي تتوافق أيضًا مع المقاييس نفسها المتوفّرة في Chrome وفقًا لقاعدة الرموز الأساسية المشتركة، ولكنّ مستخدمي Chrome فقط هم الذين يضيفون البيانات إلى CrUX. ويعني هذا القيد أيضًا أنّه لا يتم تضمين مستخدمي Chrome على iOS، لأنّه يستخدم محرّك متصفّح Webkit الأساسي. ولا يتم احتساب مكوّنات Android WebView أيضًا باعتبارها "Chrome"، لذا لا يتم تضمين البيانات من هؤلاء المستخدمين، على الرغم من تضمين علامات تبويب Chrome المخصَّصة.
على الرغم من أن Chrome هو أحد أكثر المتصفحات شيوعًا في العالم، وبالتالي من المرجح أن يوفّر تمثيلاً واسعًا لأداء موقعك الإلكتروني في معظم الحالات، إلا أنّ قياس هذا المتصفح ليس مقياسًا لجميع المستخدمين بأي شكل من الأشكال. وقد يفسر هذا اختلافًا رئيسيًا واحدًا بين RUM وCrUX. وينطبق هذا بوجه خاص على تقنيات الأداء التي تعتمد على واجهات برمجة التطبيقات أو تنسيقات الصور المتوفّرة في Chrome فقط، على سبيل المثال.
يمكن أن يؤدي نقص بيانات iOS أيضًا إلى التحيز. على سبيل المثال، لأنّ مستخدمي iOS يكونون عادةً على أجهزة ذات أداء أعلى، أو يزورون موقعك الإلكتروني من المزيد من البلدان التي تتميّز ببنية أساسية أفضل للشبكة، يمكن أن يؤدي ذلك إلى ارتفاع مقاييس الأداء بشكل عام. من ناحية أخرى، يمكن أن يؤدي استبعادها، كما هو الحال في CrUX، إلى بيانات تميل نحو الحد الأدنى لزوّار الموقع الإلكتروني (مثال على دراسة حالة). يوفّر مستخدمو Android عادةً مجموعة واسعة من الأجهزة وإمكاناتها والأسواق.
ويمكن لحلول RUM الحصول على بيانات خاصة بالمتصفّحات غير Chrome، وخاصةً من المتصفحات المستندة إلى Chromium والتي غالبًا ما تتضمّن المقاييس نفسها (مثل Core Web Vitals). يتم أيضًا قياس المتصفِّحات غير المستندة إلى Chromium باستخدام حلول RUM، ولكن قد تكون مجموعة المقاييس محدودة أكثر. على سبيل المثال، لا تتوفّر ميزتا متغيّرات التصميم التراكمية (CLS) ومدى استجابة الصفحة لتفاعلات المستخدم (INP) إلا في المتصفّحات المستندة إلى Chromium. يمكن قياس بعض المقاييس الأخرى، مثل سرعة عرض المحتوى على الصفحة (FCP)، بشكل مختلف تمامًا (راجِع المعلومات لاحقًا).
المستخدمون الذين وافقوا على الاشتراك
بالإضافة إلى حصر CrUX على مستخدمي Chrome، يتم أيضًا تقييدها من خلال قياس مجموعة فرعية من مستخدمي Chrome فقط الذين وافقوا على مشاركة بيانات CrUX عند تثبيت المتصفّح.
ولا ينظر موفرو RUM أيضًا إلا إلى مجموعة فرعية من المستخدمين، ويكون ذلك عادةً بسبب طلبات بانر لملفات تعريف الارتباط، حيث يطلبون من المستخدمين الاشتراك في جمع بيانات RUM أو أدوات حظر التتبّع. ويمكن أن يؤثر ذلك سلبًا في بعض عمليات تحميل الصفحات الأولية إذا لم يتم التأكيد إلى الصفحة الثانية أو التالية، عندما تكون بعض أصول الموقع الإلكتروني مخزَّنة مؤقتًا من الصفحات السابقة. وإذا تكرَّر حدوث ذلك، قد تبدو المقاييس في تقنية RUM أكثر ملاءمةً مقارنةً بقيمها الفعلية في حال استبعاد تحميل الصفحات الأولية الأبطأ في عدد كافٍ من الحالات.
المواقع المضمَّنة
إنّ الغرض من تقرير تجربة المستخدم على Chrome هو إعداد التقارير على المواقع الإلكترونية المتاحة للجميع فقط، لذا هناك معايير أهلية أخرى قد تؤدي إلى عدم تسجيل البيانات في التقرير حول تجربة المستخدم على Chrome. أبرز هذه المعايير هو أنه يجب أن يكون موقع الويب قابلاً للاكتشاف بشكل علني وأن يكون مشهورًا بما فيه الكفاية لضمان الحد الأدنى من حجم العينة الذي يمكن من خلاله استخلاص استنتاجات ذات مغزى. وفي معظم الحالات، لن يؤدي ذلك إلى عدم توفّر أي بيانات في تقرير تجربة المستخدم على Chrome. وهذا ليس فرقًا محيرًا مقارنةً بالبيانات المتاحة، ولكنه مختلف، ولكنه يشرح سبب حدوث ذلك.
في المقابل، إذا تم وضع علامة على صفحات معيّنة من الموقع الإلكتروني كصفحات قابلة للفهرسة، لكنّ الصفحات الأخرى غير قابلة للفهرسة، قد تظهر لك مجموعة فرعية فقط من عناوين URL في تقرير تجربة المستخدم على Chrome. إذا كان المصدر قابلاً للاكتشاف بشكل علني، سيتم تضمين جميع مشاهدات الصفحة داخل ذلك المصدر في البيانات على مستوى المصدر، ولكن قد لا تتوفّر البيانات على مستوى عنوان URL.
الأجهزة
وتقوم تقرير تجربة المستخدم على Chrome بتقسيم البيانات حسب الأجهزة الجوّالة وأجهزة الكمبيوتر المكتبية والأجهزة اللوحية، مع أن العديد من الأدوات تركز على أول نوعين من الأدوات وقد لا تعرض بيانات الجهاز اللوحي أو قد تُدرِجها ضمن الأجهزة الجوّالة أو أجهزة الكمبيوتر المكتبي. قد تختلف خصائص الأداء على الأجهزة الجوّالة عن أجهزة سطح المكتب إلى حد بعيد، من حيث المحتوى الذي يتم تقديمه وإمكانات الأجهزة التي يشاهدها.
ستسمح بيانات RUM بتقسيم الزيارات بالمثل، لكنها غالبًا ما تعرض بيانات مجمعة بشكلٍ تلقائي. وقد تسمح تقنية RUM بالتقسيم حسب نوع الجهاز فقط (مثل الأجهزة الجوّالة) أو المتصفّح (مثل Chrome)، ولكن ليس كليهما للاطّلاع فقط على زيارات Chrome على الأجهزة الجوّالة. عند المقارنة ببيانات تقرير تجربة المستخدم (CrUX)، تأكَّد من المقارنة بين النتائج المتشابهة من خلال الفلترة حسب نوع الجهاز ومتصفّح Chrome.
أخذ العينات
عادةً ما تسمح حلول RUM بتعديل معدل أخذ العينات للزائرين المشتركين في المكان الذي يتم فيه جمع البيانات. ويمكن استخدامها لتقليل حجم البيانات اللازمة لتحليلها، وفي خفض تكاليف خدمات RUM التجارية. إذا كان حجم العينة هذا صغيرًا جدًا ولا يمثل المجموعة الأوسع نطاقًا، فستكون المقاييس الناتجة منحرفة أيضًا. ناقش مع مقدم خدمة RUM حجم العينات المناسب لموقعك الإلكتروني.
تجميع البيانات
ستتضمّن البيانات الميدانية بطبيعتها الكثير والعديد من نقاط البيانات بالمقاييس نفسها مقارنةً ببيانات المختبر، والتي ستعطي قيمة واحدة. إذا تم تجميع هذه البيانات بشكل مختلف لإعداد التقارير، فقد يؤدي ذلك إلى سبب آخر للاختلافات بين CrUX وRUM.
الفترة الزمنية
تستند بيانات CrUX إلى فترة مرور 28 يومًا، ولا يمكن تغيير هذا الإطار الزمني، على الرغم من أنه يتم تخزين بيانات CrUX في BigQuery كل شهر، ما يسمح لك بالاطّلاع على الأشهر السابقة، وتوفّر لك CrUX History API أيضًا البيانات السابقة على مدار فترة أسبوعية. ولا يزال كلاهما يوفر البيانات استنادًا إلى نافذة الانتقال على آخر 28 يومًا.
عادةً ما تتيح بيانات RUM دقة أكبر بكثير للسماح برؤية تأثير التغييرات في وقت أقرب بكثير. مع ذلك، عند اختيار فترات أصغر، يمكن أن تتأثر بيانات RUM بشكل غير ضروري بالتقلّبات في عدد زيارات الموقع الإلكتروني والزوّار. عند مقارنة بيانات RUM ببيانات CrUX، تأكَّد دائمًا من الاطّلاع على الأداء على مدار 28 يومًا. بعد أن تصبح راضيًا عن البيانات المتشابهة، يمكنك الاطّلاع على إطارات زمنية أخرى للتوغّل في بيانات RUM.
تجميع الإحصاءات
يتم قياس مقاييس CrUX عند الشريحة المئوية الخامسة والسبعين، أي استنادًا إلى القيمة التي حققتها نسبة 75% من مشاهدات الصفحة. ستكون هناك حالات قصوى في البيانات الميدانية وإزالة أسوأ التجارب البالغ عددها 25%، حيث يكون الهدف منها إعطاء قيمة يمكن أن يتوقع معظم الزوّار تحقيقها على نحو معقول.
وتوفر منتجات RUM غالبًا عددًا أكبر من الخيارات المتعلقة بكيفية تجميع المقاييس، بما في ذلك الشريحة المئوية الخامسة والسبعين والمتوسّطة والشرائح المئوية الأخرى. عند مقارنة قيم RUM ببيانات CrUX، يجب التأكد من أنك تنظر إلى بيانات الشريحة المئوية الخامسة والسبعين لمقارنة قيم النتائج المتشابهة.
تتضمن بيانات المدرّج التكراري في CrUX جميع البيانات المتاحة - وليس فقط 75 في المئة - وتعرض عدد مشاهدات الصفحة في كل تقييم، ولكن ستعتمد النتيجة المجمّعة على الشريحة المئوية الخامسة والسبعين. تظهر بيانات CrUX هذه في أدوات مثل إحصاءات PageSpeed:
![لقطة شاشة لـ "إحصاءات PageSpeed" تعرض المدرجات التكرارية لعمليات تحميل صفحة تقييم سرعة عرض أكبر جزء من المحتوى على الصفحة (LCP)](https://web.dev/static/articles/crux-and-rum-differences/image/pagespeed-insights-screen-b135a0cfa5e39.png?authuser=6&hl=ar)
الاختلافات في المقاييس
هناك العديد من المقاييس المستخدمة لقياس أداء الويب، لذا عند مقارنة مجموعتين مختلفتين من البيانات، من المهم فهم المقاييس التي يتم قياسها وكيفية استخدامها.
المقاييس التي يتم قياسها
بيانات CrUX هي مجموعة البيانات الرسمية لمبادرة Core Web Vitals وهي تقيس بشكل أساسي هذه المقاييس (LCP وCLS وINP)، مع بعض المقاييس الإضافية لاستكمالها.
تتضمّن أدوات RUM عادةً "مؤشرات أداء الويب الأساسية" هذه، ولكنّها تتضمّن غالبًا العديد من المقاييس الأخرى أيضًا. يقيس بعض مقدمي خدمة RUM أيضًا تجربة المستخدم باستخدام مجموعتهم الخاصة من كل هذه المقاييس لإعطاء "مؤشر السعادة"؛ أو ما شابه. عند مقارنة بيانات RUM بمقياس CrUX، تأكد من المقارنة بين النتائج المتشابهة.
بالنسبة إلى الأدوات التي تقيّم حالة نجاح أو عدم نجاح "مؤشرات أداء الويب الأساسية"، يجب أن تنجح في اجتياز الصفحة إذا كانت تستوفي الأهداف المقترَحة عند الوصول إلى النسبة المئوية الخامسة والسبعين لجميع مؤشرات "Core Web Vitals". في حال عدم توفّر مقياس INP للصفحات التي لا تتضمّن تفاعلات، يجب اجتياز مقياسَي LCP وCLS فقط.
الاختلافات في المقاييس بين المتصفحات
لا يتم قياس تجربة المستخدم على Chrome إلا في متصفّحات Chrome، ويمكنك الرجوع إلى سجلّات التغييرات في "مؤشرات أداء الويب" للاطّلاع على كيفية تغيّر هذه البيانات مع كل إصدار من إصدارات Chrome.
وعلى الرغم من ذلك، ستقيس حلول RUM مجموعة واسعة من المتصفحات. من المحتمل أن تكون المتصفحات المستندة إلى Chromium (Edge وOpera وما إلى ذلك) مشابهة لمتصفِّح Chrome، ما لم ينفِّذ Chrome تغييرات جديدة كما هو موضّح في سجلّ التغييرات.
بالنسبة إلى المتصفحات التي لا تستخدم Chromium، يمكن أن تكون الاختلافات أكثر وضوحًا. على سبيل المثال، يتوفّر سرعة عرض أول محتوى (FCP) في متصفّح Safari وFirefox، ولكن يتم قياسه بطريقة مختلفة. وقد يؤدي ذلك إلى اختلافات كبيرة في الأوقات المعروضة. كما أشرنا سابقًا، إذا كنت تريد مقارنة RUM بـ CrUX، فمن الأفضل إجراء تصفية على مستخدمي Chrome فقط للسماح بإجراء مقارنة متشابهة.
توقيت المقاييس
يتم توفير مقاييس "مؤشرات أداء الويب الأساسية" من خلال واجهات برمجة التطبيقات لمتصفّح الويب، ولكن هذا لا يعني عدم احتمال ظهور اختلافات في القيم التي تم الإبلاغ عنها من خلالها. ويمكن أن يؤدّي وقت قياس المقياس، عند تحميل الصفحة أو خلال دورة حياة الصفحة بالكامل، إلى اختلافات. قد لا تقيس أدوات RUM المقاييس دائمًا بالطريقة نفسها، حتى في حال استخدام الأسماء نفسها، وواجهات برمجة تطبيقات المتصفّح نفسها للحصول على البيانات، ما قد يكون مربكًا.
سرعة عرض أكبر محتوى مرئي (LCP) هو مقياس لتحميل الصفحة. يمكن لواجهة برمجة تطبيقات الويب الإبلاغ عن عدد من عناصر سرعة عرض أكبر محتوى مرئي في حال تحميل عناصر أكبر حجمًا لاحقًا بعد العرض الأولي. ويكون عنصر 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 اكتشاف "عمليات التنقل البسيطة" في منتجعات الصفحة الرئيسية، ولكن إذا كانت هذه المقاييس تنسب أيضًا مقاييس "مؤشرات أداء الويب الأساسية" إلى "عمليات التنقل البسيطة" هذه وسينتج عن ذلك اختلافات في تقرير تجربة المستخدم على Chrome لأنّ واجهات برمجة التطبيقات الأساسية لا تتوافق مع العديد من المقاييس.
الاختلافات في CrUX وWeb API
بالإضافة إلى الاختلافات في تحديد مشاهدات الصفحات على الويب وأنواعها التي يتم قياسها، هناك بعض السيناريوهات الأخرى الأكثر تعقيدًا يجب أن تكون على دراية بها والتي قد تؤدّي إلى اختلافات في بيانات CrUX وRUM. ويرجع بعض منها إلى القيود المفروضة على واجهات برمجة تطبيقات الويب المستخدمة لقياس المقاييس، وفي بعض الحالات الأخرى، يجب التعامل مع النتائج التي تعرضها واجهة برمجة التطبيقات بشكل مختلف في سيناريوهات معيّنة. تتضمّن مستندات "مؤشرات أداء الويب الأساسية" هذه الاختلافات لـ LCP وCLS، ولكن يمكن ملاحظة الاختلافات الرئيسية أيضًا في الأقسام التالية.
ميزة "التخزين المؤقت للصفحات"
تصنّف CrUX ميزة التخزين المؤقت للصفحات (أو استخدام ميزة "التخزين المؤقت للصفحات" كعمليات تنقل في الصفحة على الرغم من أنها لا تؤدي إلى تحميل الصفحة بالطريقة المعتادة. ولأنّ واجهات برمجة تطبيقات الويب لا تتعامل مع هذه العمليات كتحميل صفحة، تحتاج حلول RUM إلى اتخاذ خطوات إضافية لكي يتم احتساب هذه الصفحات إذا كانت تريد مطابقة CrUX. تؤدي هذه الخطوات إلى تحميل الصفحات بشكل أسرع بكثير، وقد تؤدي إلى تسجيل أداء أفضل بشكل عام في أحد المواقع الإلكترونية، وبالتالي قد يؤدي عدم تضمينها إلى انخفاض مقاييس أداء الصفحة بشكل عام. يمكنك الرجوع إلى حل RUM لمعرفة ما إذا كان يتعامل مع الصفحات التي تتم استعادتها في ميزة Bfcache.
إطارات iframe
لأسباب تتعلق بالأمان والخصوصية، لا يمكن لصفحات المستوى الأعلى الوصول إلى المحتوى داخل إطارات iframe (ولا حتى إطارات iframe من المصدر نفسه). وهذا يعني أنّه لا يمكن قياس مقاييس الأداء للمحتوى في هذه الإطارات إلا من خلال إطار iframe نفسه، وليس من خلال واجهات برمجة تطبيقات الويب في صفحة الإطار. إذا كان محتوى إطار iframe يتضمّن عنصر LCP أو المحتوى الذي يؤثر في متغيّرات التصميم التراكمية (CLS) أو مقياس INP (مدى استجابة الصفحة لتفاعلات المستخدم) الذي يظهر للمستخدم، لن تتوفّر هذه البيانات لحلول RUM (بما في ذلك مكتبة JavaScript لمؤشرات أداء الويب من Google).
ومع ذلك، لا يتم فرض هذه القيود على تقرير تجربة المستخدم (CrUX) عند قياسه بواسطة متصفّح Chrome نفسه بدلاً من JavaScript على الصفحة، وبالتالي يتم قياس المقاييس ضمن إطارات iframe عند الإبلاغ عن "مؤشرات أداء الويب الأساسية". ويعكس ذلك بدقة أكبر ما يجربه المستخدم، ولكن قد يكون سببًا آخر للاختلافات في المواقع الإلكترونية التي تستخدم إطارات iframe.
في ما يلي مثال ملموس على كيفية أن يؤدي ذلك إلى اختلافات بين بيانات مقياس LCP في CrUX وRUM المضمّن في السمة <video>
. يمكن احتساب أول إطار مرسوم لعنصر <video>
يتم تشغيله تلقائيًا كاقتراح لـ LCP، ولكن قد تضع عمليات تضمين خدمات بث الفيديو الرائجة هذه العناصر في <iframe>
. ويمكن أن يفسّر CrUX ذلك، لأنّه يمكنه الوصول إلى محتوى <iframe>
، إلا أنّ حلول RUM لا يمكنها الوصول إليه.
مراجع من مصادر متعددة
لا تمنح وسائط LCP التي يتم عرضها من نطاقات أخرى وقتًا للعرض في PerformanceObserver API ما لم يتم توفير عنوان مؤقت-Allow-Origin (TAO)، وذلك بسبب قيود أمان المتصفّح لتقليل هجمات التوقيت. ويشير ذلك إلى وقت تحميل المورد ولكن قد يكون مختلفًا تمامًا عما إذا تم عرض المحتوى فعليًا.
قد يؤدي ذلك إلى الحالة التي تبدو مستحيلة حيث يتم تسجيل سرعة عرض أكبر محتوى مرئي (LCP) من خلال واجهات برمجة تطبيقات الويب قبل مقياس FCP. إلا أن الأمر ليس كذلك، بل يظهر فقط بسبب هذه القيود الأمنية.
ونذكّر بأنّ تقرير تجربة المستخدم على Chrome يشير إلى بيانات الوقت المستغرق لعرض المحتوى في "مؤشرات أداء الويب الأساسية". وننصح المواقع الإلكترونية بالحدّ من المحتوى المتعدد المصادر الذي يؤثر في مقاييس "مؤشرات أداء الويب الأساسية" وتفعيل TAO حيثما أمكن إذا كانت تريد قياس ذلك بدقة أكبر. وقد يتم فرض قيود مشابهة على الموارد الأخرى المشتركة المصادر.
علامات التبويب في الخلفية
في حال عدم فتح الصفحة في علامة تبويب في الخلفية، سيستمر إصدار المقاييس باستخدام Web APIs. ومع ذلك، لا يتم الإبلاغ عنها بواسطة CrUX لأنها تعطي توقيتات لا تتوافق مع تجربة المستخدم. يجب أن تراعي حلول RUM أيضًا تجاهُلها أو على الأقل شرح كيفية التعامل مع مشاهدات الصفحة هذه.
إذًا، ما الذي يمكننا فعله حيال ذلك؟
وقد أظهرنا سبب وجود اختلافات بين بيانات CrUX وRUM، وذلك إما بسبب الاختلافات في المنهجية التي يستخدمها كل منهما أو بسبب تضمين أو استبعاد المستخدمين ومشاهدات الصفحة. ومن الناحية المثالية، ستظل كلتا المجموعتين من البيانات تمثلان أداء موقعك الإلكتروني حتى يكونا مفيدين، ولكن ينبغي أن توضّح الأسباب المقدَّمة سبب عدم احتمال الحصول على الأرقام نفسها بالضبط في كل منهما.
عندما تكون الاختلافات طفيفة (على سبيل المثال، الإبلاغ عن LCP من 2.0 ثانية مقابل 2.2 ثانية)، ستكون مجموعتا البيانات مفيدتان ويمكن اعتبارهما متزامنتَين تقريبًا.
عندما تجعل الاختلافات الواضحة تشكك في دقة البيانات، يجب أن تحاول فهم تلك الاختلافات. هل يمكن فلترة بيانات RUM لتتوافق بشكل أوثق مع تقرير تجربة المستخدم على Chrome (في ما يتعلّق بمستخدمي Chrome فقط على أجهزة الكمبيوتر المكتبي أو الأجهزة الجوّالة، مع استخدام قيم الشريحة المئوية الخامسة والسبعين على مدار 28 يومًا) لتقليل هذه الاختلافات؟
إذا كان الأمر كذلك - وكان بإمكانك الحصول على البيانات لتتطابق بشكل أوثق - فلا يزال يتعين عليك السؤال عن سبب رؤية هذه الاختلافات في البيانات الإجمالية وما يعنيه ذلك. هل يغيّر المستخدمون الذين لا يستخدمون Chrome المقاييس بطريقة إيجابية أو سلبية؟ هل يمنحك ذلك المزيد من الإحصاءات حول المشاكل التي تواجهك في الأداء ويمكنك منحها الأولوية؟
إذا كانت نتائج المستخدمين غير التابعة لـ Chrome تختلف عن تلك التي حصلوا عليها، يمكنك الاستفادة من هذه الإحصاءات القيّمة التي وفّرها لك RUM لتحسينها بشكل مختلف. على سبيل المثال، لا تتوفّر بعض واجهات برمجة التطبيقات في بعض المتصفّحات، ولكن يمكنك استخدام بدائل للمتصفّحات غير المتوافقة لتحسين تجاربها أيضًا. أو يمكنك منح تجربة مختلفة، لكن أفضل أداءً للمستخدمين على الأجهزة أو الشبكات المقيَّدة. تقتصر بيانات تجربة المستخدم على Chrome على بيانات Chrome، ولكن يجب أن تضع في اعتبارك جميع احتياجات زوّار موقعك الإلكتروني. وخبراتهم للمساعدة في تحديد أولويات التحسينات. ويمكن لبيانات RUM أن يملأ هذه الفجوة.
بعد فهم أسباب أي اختلافات، يمكن أن تكون كلتا الأداتين مفيدتين للغاية لفهم تجارب المستخدمين على موقعك الإلكتروني والمساعدة في تحسين ذلك حتى إذا لم تكن الأعداد متطابقة. استخدِم بيانات RUM لتكملة بيانات CrUX وتتيح لك الاطّلاع على تفاصيل ما يُطلعك عليها في CrUX على مستوى عالٍ من خلال تقسيم الزيارات لمساعدتك في تحديد ما إذا كانت مناطق معيّنة من موقعك أو قاعدة مستخدمين تحتاج إلى اهتمام.
إن النظر إلى الاتجاهات لمعرفة التحسينات التي تجريها له التأثيرات الإيجابية المتوقعة غالبًا ما يكون أكثر أهمية من مطابقة كل رقم تمامًا بين مصدري البيانات. وكما ذكرنا سابقًا، يتيح لك نظام RUM الاطّلاع على أطر زمنية مختلفة لإلقاء نظرة مسبقة على نتائج CrUX لمدة 28 يومًا، على الرغم من أن النظر إلى الأطر الزمنية القصيرة جدًا يمكن أن يؤدي إلى بيانات مزعجة، لذلك يستخدم CrUX مدة 28 يومًا.
غالبًا لا توجد كلمة "صحيح" أو "خاطئ" بالاستناد إلى هذه المقاييس المختلفة - فهي مجرد وجهة نظر مختلفة للمستخدمين وكيفية تجربتهم لموقعك. وما دمت تدرك سبب حدوث هذه الاختلافات، وما يمكن فعله لمساعدتك في اتخاذ القرار، هذا هو المهم تقديم خدمة أفضل لزوّار موقعك الإلكتروني.
شكر وتقدير
صورة مصغّرة لـ ستيفن ليلهام على قناة Unpush