تعرَّف على الأسباب التي قد تؤدي إلى اختلاف أرقام Core Web Vitals في بيانات RUM عن تلك الواردة في تقرير CrUX.
تاريخ النشر: 15 أغسطس 2022، تاريخ آخر تعديل: 17 ديسمبر 2025
يوفّر تقرير تجربة المستخدم على Chrome مقاييس لتقييم تجربة المستخدم وفقًا لتجربة مستخدمي Chrome في الوجهات الرائجة على الويب. يجمع Chrome هذه البيانات تلقائيًا من المستخدمين الذين وافقوا على ذلك، وتتم إتاحتها استنادًا إلى معايير أهلية CrUX.
وبالتالي، تتوفّر بيانات CrUX لملايين المواقع الإلكترونية. لم يتمكّن العديد من مالكي المواقع الإلكترونية من الوصول إلى البيانات الميدانية من قبل، وقد أتاح تقرير تجربة المستخدم على Chrome للعديد من المواقع الإلكترونية الاطّلاع على قيمة هذه البيانات للمرة الأولى. بما أنّ تقرير CrUX هو مجموعة بيانات عامة، يمكن استخدامه أيضًا لإجراء تحليل تنافسي وقياس مقاييس تجربة المستخدم.
مراقبة المستخدمين الحقيقيين (RUM) تشبه CrUX، ولكن بدلاً من أن يجمع Chrome مقاييس تجربة المستخدم تلقائيًا، يتم تضمين رمز في المواقع الإلكترونية لإجراء عملية الجمع هذه وإرسالها إلى مقدّم خدمة RUM أو حلّ إحصاءات لإجراء مزيد من التحليل.
بما أنّ كلا الحلّين يقيسان مقاييس تجربة المستخدم، من الطبيعي افتراض أنّهما متكافئان. قد يكون من المربك أن نرى اختلافات. سيشرح هذا الدليل سبب حدوث ذلك، ويقدّم اقتراحات بشأن ما يجب فعله عندما لا تتطابق الأرقام.
مزايا استخدام حلّ RUM مع CrUX
يُعدّ CrUX أداة رائعة للحصول على عرض متّسق على مستوى المواقع الإلكترونية، وبما أنّه مجموعة بيانات Google لبرنامج Core Web Vitals، من المرجّح أن ترغب المواقع الإلكترونية في متابعة ما يعرضه. يهدف تقرير CrUX إلى تقديم نظرة عامة ذات صلة إحصائيًا لملايين المواقع الإلكترونية لإجراء مقارنة بينها.
ومع ذلك، لإجراء نظرة متعمّقة في التحقيق في سبب عرض البيانات للأرقام التي تعرضها، فإن الاستثمار في حل RUM كامل لتكملة CrUX يمكن أن يمنحك الوصول إلى معلومات أكثر تفصيلاً مما يمكن توفيره في مجموعة بيانات يمكن الاستعلام عنها بشكل عام. يمكن أن يساعدك ذلك في شرح مقاييسك وتحسينها بعدة طرق.
تحليل أعمق للتحقيق في المشاكل
يمكن استخدام CrUX غالبًا للإشارة إلى وجود مشكلة في موقعك الإلكتروني، ولكن ليس بالضرورة تحديد مكان المشكلة بالضبط أو سببها. يمكن أن تساعد حلول RUM في سد هذه الفجوة، سواء كانت محلية من خلال مكتبة web-vitals أو بعض المنتجات التجارية العديدة.
يتيح لك استخدام حلّ RUM الوصول إلى بيانات أكثر دقة لجميع صفحاتك وعلى جميع المتصفّحات. ويتيح لك أيضًا تقسيم هذه البيانات وتحليلها بطرق لا يوفّرها تقرير CrUX، ما يتيح لك التوغّل في التفاصيل والتحقيق في المشاكل التي تواجه الموقع الإلكتروني. هل تتأثر بشريحة معيّنة من المستخدمين؟ أو المستخدمين الذين يتّخذون إجراءات معيّنة؟ متى بدأت المشكلة بالضبط؟ هذه أسئلة يسهل الإجابة عنها باستخدام البيانات الإضافية التي يمكن أن توفّرها أداة RUM.
الربط بمقاييس الأنشطة التجارية الأخرى
تتيح لك RUM أيضًا مقارنة مقاييس أداء الويب مباشرةً بأي مقاييس خاصة بالنشاط التجاري، ما يوضّح قيمة الاستثمار في الأداء، وما هي أعمال الأداء الأخرى التي يجب منحها الأولوية. لدينا العديد من دراسات الحالة مع أنشطة تجارية تُجري هذا الربط، مثل Farfetch أو The Economic Times.
جمع بيانات أخرى عن الأداء
يتيح حلّ RUM جمع مقاييس مخصّصة أخرى مرتبطة مباشرةً بنشاطك التجاري المحدّد. ومن الأمثلة المعروفة على ذلك مقياس "الوقت المستغرَق لنشر أول تغريدة" في Twitter. ويمكن بعد ذلك ربط هذه الإجراءات الخاصة بالموقع الإلكتروني بتحسينات Core Web Vitals ومقاييس النشاط التجاري.
الاختلافات بين مجموعتَين من البيانات الميدانية
الرجل الذي يرتدي ساعة واحدة يعرف الوقت، أما الرجل الذي يرتدي ساعتين فلا يكون متأكدًا أبدًا.
قانون سيغال
عندما يكون لديك مصدران للبيانات، قد يكون من المربك والمحبط معرفة سبب اختلافهما. كما أنّه من المهم فهم الفرق بين المقاييس الاختبارية والميدانية، يمكن أن تكون هناك أيضًا اختلافات بين مصدرَي البيانات الميدانية. على الرغم من أنّ البيانات ستكون متطابقة في عالم مثالي، هناك العديد من الأسباب التي قد تؤدي إلى اختلافها.
بيانات المختبر مقابل بيانات تجارب المستخدمِين الحقيقيين
أول ما يجب التحقّق منه هو ما إذا كنت تطّلع على مقاييس المختبر (الاصطناعية) أو مقاييس الميدان (RUM). على الرغم من أنّه من الطبيعي افتراض أنّ منتجات RUM تركّز فقط على بيانات الحقل، يقدّم العديد منها مكوّنًا معمليًا أيضًا.
تُعدّ بيانات المختبر مفيدة للغاية بسبب الشروط الثابتة التي يتم قياسها بموجبها. ويمكن استخدامها لمراقبة التغييرات أو التراجعات غير المتوقّعة في بيئة التشغيل الفعلي بدون التشويش الناتج عن تغيُّر مجموعة المستخدمين في المجال. ومع ذلك، قد لا تكون بيانات المختبر ممثلة لتجربة المستخدم الحقيقية، لذا يمكن أن تعرض المقاييس الميدانية نتائج مختلفة تمامًا.
السكّان
قد تختلف مجموعات البيانات التي تستخدمها حلول CrUX وRUM بسبب الاختلافات في زيارات الصفحات التي يتم قياسها استنادًا إلى المتصفحات والمستخدمين والمواقع الإلكترونية والأجهزة التي تتم مقارنتها.
المتصفّحات المضمّنة
يقتصر "تقرير تجربة المستخدم على Chrome" على متصفّح Chrome فقط، كما يشير اسمه. على الرغم من توفّر العديد من المتصفّحات المستندة إلى Chromium (مثل Edge وOpera وBrave وغيرها) والتي تشارك الكثير من قاعدة الرموز البرمجية في Chrome، فإنّ مستخدمي Chrome فقط هم من يقدّمون البيانات إلى تقرير تجربة المستخدم على Chrome. يعني هذا القيد أيضًا أنّه لا يتم تضمين مستخدمي Chrome على أجهزة iOS، لأنّه يستخدم محرّك متصفّح Webkit الأساسي. لا يتم أيضًا احتساب Android WebViews على أنّها "Chrome"، لذا لا يتم تضمين البيانات من هؤلاء المستخدمين، على الرغم من تضمين علامات التبويب المخصّصة في Chrome.
على الرغم من أنّ Chrome هو أحد المتصفّحات الأكثر رواجًا في العالم، وبالتالي من المرجّح أن يقدّم تمثيلاً واسعًا لأداء موقعك الإلكتروني في معظم الحالات، فإنّ قياس أداء هذا المتصفّح فقط لا يمثّل بأي حال من الأحوال جميع المستخدمين. قد يفسّر ذلك أحد الاختلافات الرئيسية بين RUM وCrUX. وينطبق ذلك بشكل خاص على أساليب الأداء التي تعتمد على واجهات برمجة التطبيقات أو تنسيقات الصور المتوفّرة في Chrome فقط، على سبيل المثال.
ويمكن أن يؤدي عدم توفّر بيانات iOS أيضًا إلى حدوث انحياز. على سبيل المثال، بما أنّ مستخدمي iOS عادةً ما يستخدمون أجهزة ذات أداء أفضل أو يزورون موقعك الإلكتروني من بلدان أكثر لديها بنية أساسية أفضل للشبكة، فإنّ تضمينهم يمكن أن يؤدي إلى ارتفاع مقاييس الأداء العام. من ناحية أخرى، يمكن أن يؤدي استبعادها، كما يفعل تقرير CrUX، إلى بيانات منحرفة نحو الحد الأدنى لزوار الموقع الإلكتروني (مثال على دراسة حالة). يستخدم مستخدمو Android عادةً مجموعة أكبر من الأجهزة وإمكانات الأجهزة والأسواق.
يمكن لحلول RUM الحصول على بيانات للمتصفّحات غير Chrome، وبشكل خاص من المتصفّحات المستندة إلى Chromium والتي غالبًا ما تتضمّن المقاييس نفسها (مثل Core Web Vitals). يتم أيضًا قياس المتصفّحات غير المستندة إلى Chromium من خلال حلول RUM، ولكن قد تتضمّن مجموعة محدودة من المقاييس. على سبيل المثال، لا يتوفّر مقياس متغيّرات التصميم التراكمية (CLS) إلا في المتصفّحات المستندة إلى Chromium. يمكن قياس بعض المقاييس الأخرى المستندة إلى العرض، مثل LCP وINP وحتى سرعة عرض أول محتوى مرئي (FCP)، بطريقة مختلفة تمامًا (انظر أدناه).
المستخدمون الذين وافقوا على الميزة
بالإضافة إلى اقتصار CrUX على مستخدمي Chrome، يتم فرض قيود إضافية عليه من خلال قياس مجموعة فرعية فقط من مستخدمي Chrome الذين وافقوا على مشاركة بيانات CrUX عند تثبيت المتصفّح.
لا يطّلع مقدّمو خدمات RUM أيضًا إلا على مجموعة فرعية من المستخدمين، وذلك عادةً بسبب طلبات بانر ملفات تعريف الارتباط التي تطلب من المستخدمين الموافقة على جمع بيانات RUM أو أدوات حظر التتبُّع. ويمكن أن يؤثر ذلك سلبًا في بعض عمليات تحميل الصفحات الأولية إذا لم يتم تقديم التأكيد حتى الصفحة الثانية أو الصفحات اللاحقة، عندما تكون بعض مواد عرض الموقع الإلكتروني قد تم تخزينها مؤقتًا من الصفحات السابقة. إذا حدث ذلك بشكل متكرر، قد تظهر المقاييس في RUM بشكل أفضل مما هي عليه في الواقع إذا تم استبعاد عمليات تحميل الصفحات الأولية الأبطأ في عدد كافٍ من الحالات.
المواقع الإلكترونية المضمّنة
تم تصميم CrUX لإعداد تقارير عن المواقع الإلكترونية المتاحة للجميع فقط، لذا هناك معايير أهلية أخرى قد تؤدي إلى عدم تسجيل البيانات في CrUX. وأبرز هذه المعايير هو أن يكون الموقع الإلكتروني قابلاً للاكتشاف بشكل علني وأن يكون رائجًا بما يكفي لضمان الحد الأدنى من حجم العينة الذي يمكن من خلاله استخلاص استنتاجات مفيدة. في معظم الحالات، سيؤدي ذلك إلى عدم توفّر أي بيانات في CrUX. هذا الاختلاف أقل إرباكًا مقارنةً بالبيانات المتاحة ولكن المختلفة، ولكنه يفسّر سبب حدوث ذلك.
ومع ذلك، إذا تم وضع علامة على صفحات معيّنة من موقع إلكتروني على أنّها قابلة للفهرسة ولم يتم وضع علامة على صفحات أخرى، قد تظهر لك مجموعة فرعية فقط من عناوين URL في CrUX. إذا كان المصدر قابلاً للاكتشاف بشكل علني، سيتم تضمين جميع مشاهدات الصفحات ضمن هذا المصدر في البيانات على مستوى المصدر، ولكن قد لا تكون البيانات على مستوى عنوان 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، أي بالنظر إلى القيمة التي حقّقتها% 75 من مشاهدات الصفحة. ستكون هناك قيم قصوى في البيانات الميدانية، وستتم إزالة أسوأ% 25 من التجارب، والهدف من ذلك هو تقديم قيمة يمكن أن يتوقع غالبية الزوّار تحقيقها بشكل معقول.
غالبًا ما توفّر منتجات RUM عددًا أكبر من الخيارات لكيفية تجميع المقاييس، بما في ذلك الشريحة المئوية الخامسة والسبعون والمتوسط والشرائح المئوية الأخرى. عند مقارنة قيم RUM ببيانات CrUX، من الضروري التأكّد من أنّك تنظر إلى بيانات الشريحة المئوية الـ 75 لإجراء مقارنة دقيقة.
وتشمل بيانات المدرّج التكراري في CrUX جميع البيانات المتاحة، وليس فقط الشريحة المئوية الخامسة والسبعين، وتعرض عدد مشاهدات الصفحة في كل تقييم، ولكن النتيجة الإجمالية ستستند إلى الشريحة المئوية الخامسة والسبعين. تظهر بيانات CrUX هذه في أدوات مثل إحصاءات PageSpeed:
الاختلافات في المقاييس
هناك العديد من المقاييس المستخدَمة لقياس أداء الويب، لذا عند مقارنة مجموعتَين مختلفتَين من البيانات، من المهم فهم المقاييس التي يتم قياسها وكيفية استخدامها.
المقاييس التي يتم قياسها
بيانات CrUX هي مجموعة بيانات Google لمبادرة Core Web Vitals، وهي تقيس بشكل أساسي هذه المقاييس (LCP وCLS وINP)، مع بعض المقاييس الإضافية لتكملة هذه المقاييس.
تتضمّن أدوات RUM عادةً مؤشرات Core Web Vitals هذه، ولكنّها غالبًا ما تتضمّن العديد من المقاييس الأخرى أيضًا. يقيس بعض مقدّمي خدمات RUM أيضًا تجربة المستخدم باستخدام مجموعة من كل هذه المقاييس، ربما لتقديم "مؤشر السعادة" أو ما شابه. عند مقارنة بيانات RUM ببيانات CrUX، تأكَّد من أنّك تقارن بيانات متشابهة.
يجب أن تعتبر الأدوات التي تقيّم حالة النجاح أو الفشل في "مؤشرات أداء الويب الأساسية" أنّ الصفحة ناجحة إذا كانت تستوفي الأهداف المقترَحة عند الشريحة المئوية الخامسة والسبعين لجميع "مؤشرات أداء الويب الأساسية". إذا لم يتوفّر مقياس INP للصفحات التي لا تتضمّن تفاعلات، يجب أن تجتاز هذه الصفحات مقياسَي LCP وCLS فقط.
الاختلافات في المقاييس على مستوى المتصفّحات
لا يقيس CrUX إلا في متصفّحات Chrome، ويمكنك الرجوع إلى سجلّات تغييرات Web Vitals لمعرفة كيفية تغيّرها مع كل إصدار من Chrome.
ومع ذلك، فإنّ حلول RUM ستقيس من مجموعة متنوعة من المتصفّحات. من المرجّح أن تكون المتصفّحات المستندة إلى Chromium (مثل Edge وOpera وما إلى ذلك) مشابهة لمتصفّح Chrome، ما لم يكن Chrome يطبّق تغييرات جديدة كما هو موضّح في سجلّ التغييرات.
بالنسبة إلى المتصفّحات غير المستندة إلى Chromium، يمكن أن تكون الاختلافات أكثر وضوحًا، فالمقاييس المستندة إلى العرض، مثل LCP وINP وFCP، تتوفّر في Safari وFirefox، ولكن يتم قياسها بطريقة مختلفة. وقد يؤدي ذلك إلى اختلافات كبيرة في الأوقات المسجَّلة. كما ذكرنا سابقًا، إذا أردت مقارنة بيانات RUM ببيانات CrUX، من الأفضل فلترة مستخدمي Chrome فقط للسماح بإجراء مقارنة مماثلة.
توقيت المقاييس
يتم توفير مقاييس Core Web Vitals من خلال واجهات برمجة تطبيقات متصفّح الويب، ولكن هذا لا يعني أنّه لا يمكن أن تختلف القيم التي يتم تسجيلها باستخدامها. الوقت الذي يتم فيه قياس المقياس، سواء عند تحميل الصفحة أو طوال رحلة المستخدم في الصفحة، يمكن أن يؤدي إلى اختلافات. قد لا تقيس أدوات RUM دائمًا المقاييس بالطريقة نفسها، حتى في حال استخدام الأسماء نفسها وواجهات برمجة التطبيقات نفسها في المتصفّح للحصول على البيانات، ما قد يكون مربكًا.
سرعة عرض أكبر محتوى مرئي (LCP) هو مقياس لسرعة تحميل الصفحة. يمكن أن تسجّل واجهة برمجة التطبيقات على الويب عددًا من عناصر LCP إذا تم تحميل عناصر أكبر حجمًا بعد العرض الأولي. يتم تحديد عنصر LCP النهائي عندما تنتهي الصفحة من التحميل أو عندما يتفاعل المستخدم مع الصفحة. لذلك، يمكن أن تظهر اختلافات إذا تم الإبلاغ عن عنصر LCP قبل هذين الحدثين.
بالإضافة إلى ذلك، في بيانات الحقول، يمكن أن يختلف عنصر LCP حسب كيفية تحميل الصفحة. بالنسبة إلى تحميل الصفحة التلقائي الذي يعرض الجزء العلوي من محتوى الصفحة، سيعتمد عنصر LCP بشكل أساسي على حجم الشاشة. ومع ذلك، إذا تم فتح الصفحة باستخدام رابط إلى موضع ثابت في أسفل المستند، أو تم فتحها بشكل مشابه باستخدام رابط عميق في تطبيق من صفحة واحدة (SPA)، وهو ما سنتناوله بمزيد من التفصيل لاحقًا، يمكن أن يكون عنصر LCP مختلفًا.
لا تفترض أنّ توقيتات LCP المقدَّمة في CrUX أو RUM تستند إلى العنصر نفسه الذي تستند إليه الأدوات الاختبارية. في حين أنّ CrUX سيمنحك قيمة LCP الإجمالية لكل صفحة أو مصدر، يمكن لـ RUM تقسيم هذه القيمة بشكل أكبر لتحديد جلسات مشاكل LCP الفردية.
يتم قياس متغيّرات التصميم التراكمية (CLS) طوال عمر الصفحة، لذا قد لا تكون متغيّرات التصميم التراكمية الأولية لتحميل الصفحة ممثلة للصفحات التي تسبب تغييرات أكبر لاحقًا بعد تحميل الصفحة وتفاعل المستخدم معها. وبالتالي، فإنّ أخذ قيمة CLS بعد تحميل الصفحة فقط، كما تفعل العديد من منتجات RUM، سيؤدي إلى نتيجة مختلفة عن أخذ قيمة CLS بعد انتهاء المستخدم من الصفحة.
يتطلّب مقياس سرعة الاستجابة مدى استجابة الصفحة لتفاعلات المستخدم (INP) إدخالاً ليتم قياسه، ويرصد جميع التفاعلات المتعلقة بالنقر والضغط على لوحة المفاتيح طوال مدة عرض الصفحة، بطريقة مشابهة لمقياس "متغيّرات التصميم التراكمية" (CLS)، وبالتالي قد تختلف القيمة المسجّلة لمقياس INP بشكل كبير إذا تم قياسها بعد أن أجرى المستخدم عددًا من التفاعلات على الصفحة.
سيتبع تقرير CrUX مستندات Core Web Vitals وسيقيس هذه المؤشرات طوال مدة صلاحية الصفحة. ويختار العديد من مقدّمي خدمات RUM بدلاً من ذلك قياس هذه المقاييس إما بعد تحميل الصفحة أو في وقت آخر (على سبيل المثال، عند النقر على عبارة رئيسية تحث المستخدم على اتخاذ إجراء) لأسباب مختلفة.
من المهم أن تفهم من مزوّد خدمة RUM متى يتم قياس Core Web Vitals، وذلك عندما تلاحظ اختلافات غير مفسّرة بين مصدرَي البيانات.
التطبيقات من صفحة واحدة
تعمل التطبيقات من صفحة واحدة (SPA) من خلال تعديل المحتوى على الصفحة الحالية، بدلاً من إجراء عمليات التنقل في الصفحة الفعلية على مستوى المتصفّح. وهذا يعني أنّ المتصفّح لا يعتبرها عمليات تنقّل في الصفحة، على الرغم من أنّ المستخدمين يختبرونها على هذا النحو. لن تأخذ واجهات برمجة تطبيقات Core Web Vitals التي يوفّرها المتصفّح هذه الحالات في الاعتبار، وبالتالي لا يتيح تقرير CrUX عمليات التنقّل هذه في الصفحة. ويجري العمل على حلّ هذه المشكلة. يمكنك الاطّلاع على مشاركة قياس عمليات التنقّل السلس لمزيد من المعلومات.
يحاول بعض مقدّمي خدمات RUM رصد "عمليات التنقّل السلسة" في تطبيقات الصفحة الواحدة، ولكن إذا كانوا ينسبون أيضًا مقاييس Core Web Vitals إلى "عمليات التنقّل السلسة" هذه، سيؤدي ذلك إلى اختلافات مع CrUX لأنّ واجهات برمجة التطبيقات الأساسية لا تتيح ذلك للعديد من المقاييس.
الاختلافات بين CrUX وWeb API
بالإضافة إلى الاختلافات في طريقة قياس مشاهدات الصفحة وما يتم قياسه، هناك بعض السيناريوهات الأخرى الأكثر تعقيدًا التي يجب الانتباه إليها والتي يمكن أن تؤدي إلى اختلافات في بيانات CrUX وRUM. يرجع بعض هذه الاختلافات إلى القيود المفروضة على واجهات برمجة التطبيقات على الويب المستخدَمة لقياس المقاييس، وبعضها الآخر إلى أنّ النتائج التي تعرضها واجهة برمجة التطبيقات يجب التعامل معها بشكل مختلف في سيناريوهات معيّنة. تسرد مستندات Core Web Vitals هذه الاختلافات في ما يتعلق LCP وCLS، ولكن يتم أيضًا توضيح الاختلافات الرئيسية في الأقسام التالية.
ميزة "التخزين المؤقت للصفحات"
يأخذ تقرير تجربة المستخدم على Chrome في الاعتبار عمليات استعادة ميزة "التخزين المؤقت للصفحات" (أو bfcache) على أنّها عمليات تنقّل في الصفحة، على الرغم من أنّها لا تؤدي إلى تحميل صفحة تقليدية. بما أنّ واجهات برمجة التطبيقات على الويب لا تعتبر هذه الصفحات كعملية تحميل للصفحة، على حلول RUM اتّخاذ خطوات إضافية لاحتساب هذه الصفحات إذا أرادت مطابقة CrUX. تكون عمليات تحميل هذه الصفحات أسرع بكثير، ما قد يؤدي إلى تسجيل أداء عام أفضل للموقع الإلكتروني، وبالتالي فإنّ عدم تضمينها قد يؤدي إلى تراجع مقاييس الأداء العام للصفحة. يمكنك الرجوع إلى حلّ RUM لمعرفة ما إذا كان يتعامل مع الصفحات التي تمت استعادتها من bfcache.
إطارات iframe
لأسباب تتعلّق بالأمان والخصوصية، لا يمكن للصفحات ذات المستوى الأعلى الوصول إلى المحتوى داخل إطارات iframe (حتى إطارات iframe من المصدر نفسه). وهذا يعني أنّه لا يمكن قياس مقاييس الأداء للمحتوى في هذه الإطارات إلا من خلال إطار iframe نفسه، وليس من خلال واجهات برمجة تطبيقات الويب على الصفحة التي تتضمّن الإطار. إذا كان محتوى iframe يتضمّن عنصر LCP أو محتوى يؤثر في مقياسَي CLS أو INP اللذين يواجههما المستخدم، لن يكون ذلك متاحًا لحلول RUM (بما في ذلك مكتبة JavaScript لمؤشرات أداء الويب من Google).
في المقابل، لا يواجه تقرير تجربة المستخدم على Chrome هذه القيود، لأنّه يتم قياسه من خلال متصفّح Chrome نفسه وليس من خلال JavaScript على الصفحة، وبالتالي يقيس المقاييس ضمن إطارات iframe عند إعداد تقارير Core Web Vitals. يعكس هذا الإجراء تجربة المستخدم بدقة أكبر، ولكنّه قد يكون سببًا آخر للاختلافات في المواقع الإلكترونية التي تستخدم إطارات iframe.
من الأمثلة الملموسة على كيفية حدوث اختلافات بين بيانات LCP في CrUX وRUM هو <video> المضمّن. يمكن احتساب الإطار الأول المرسوم لعنصر <video> الذي يتم تشغيله تلقائيًا على الشاشة نفسها كمرشح لـ LCP، ولكن قد تضع عمليات تضمين خدمات بث الفيديو الرائجة هذه العناصر في <iframe>. يمكن لتقرير CrUX احتساب هذه البيانات لأنّه يمكنه الوصول إلى محتوى <iframe>، ولكن لا يمكن لحلول RUM الوصول إليه.
الموارد المتعدّدة المصادر
قد لا توفّر وسائط LCP التي يتم عرضها من نطاقات أخرى الوقت المستغرَق للعرض في PerformanceObserver API، ما لم يتم توفير العنوان Timing-Allow-Origin (TAO)، وذلك بسبب قيود أمان المتصفّح للحدّ من هجمات التوقيت. يتم الرجوع إلى وقت تحميل المورد، ولكن قد يختلف ذلك كثيرًا عن وقت عرض المحتوى فعليًا.
ويمكن أن يؤدي ذلك إلى حالة تبدو مستحيلة، حيث يتم الإبلاغ عن مقياس LCP من خلال واجهات برمجة تطبيقات الويب على أنّه أقدم من مقياس FCP. هذا ليس صحيحًا، ولكن يبدو الأمر كذلك بسبب قيود الأمان هذه.
تم حلّ هذه المشكلة في أواخر عام 2024، ويتوفّر الوقت المستغرَق للعرض تقريبي بعض الشيء في الإصدار 133 من Chrome حتى في حال عدم توفّر Timing-Allow-Origin.
مرة أخرى، يقدّم تقرير CrUX بيانات الوقت المستغرَق للعرض في ما يتعلّق بـ Core Web Vitals. ننصح المواقع الإلكترونية بالحدّ من المحتوى المتعدّد المصادر الذي يؤثر في مقاييس Core Web Vitals، وبتفعيل عنوان TAO حيثما أمكن إذا أرادت قياس ذلك بدقة أكبر. قد تخضع الموارد الأخرى المتعدّدة المصادر لقيود مماثلة.
علامات التبويب في الخلفية
وعندما لا يتم فتح صفحة في علامة تبويب في الخلفية، ستستمر في إرسال المقاييس باستخدام واجهات برمجة تطبيقات الويب. ومع ذلك، لا يتم الإبلاغ عنها من خلال CrUX لأنّها تقدّم توقيتات غير متوافقة مع تجربة المستخدم. يجب أن تأخذ حلول RUM في الاعتبار أيضًا تجاهل هذه المشاهدات، أو على الأقل شرح كيفية التعامل مع مشاهدات الصفحة هذه.
إذًا، ما الذي يمكننا فعله حيال ذلك؟
لقد أوضحنا الأسباب المحتملة للاختلافات بين بيانات CrUX وRUM، إما بسبب الاختلافات في المنهجية التي يستخدمها كل منهما أو بسبب المستخدمين ومشاهدات الصفحات التي يتم تضمينها أو استبعادها. من الناحية المثالية، ستظل مجموعتا البيانات تمثّلان أداء موقعك الإلكتروني لتكونا مفيدتَين، ولكن الأسباب المذكورة يجب أن توضّح سبب عدم احتمال الحصول على الأرقام نفسها في كل منهما.
عندما تكون الاختلافات طفيفة (على سبيل المثال، الإبلاغ عن مقياس LCP يبلغ ثانيتين مقابل 2.2 ثانية)، ستكون كلتا مجموعتَي البيانات مفيدتَين ويمكن اعتبارهما متزامنتَين تقريبًا.
عندما تجعلك الاختلافات الواضحة تشكّك في دقة البيانات، عليك محاولة فهم هذه الاختلافات. هل يمكن فلترة بيانات RUM لتكون أكثر توافقًا مع CrUX (النظر فقط إلى مستخدمي Chrome، على أجهزة الكمبيوتر المكتبي أو الأجهزة الجوّالة، مع قيم الشريحة المئوية الخامسة والسبعين على مدار 28 يومًا) لتقليل هذه الاختلافات؟
إذا كان الأمر كذلك - ويمكنك الحصول على البيانات لتتطابق بشكل أوثق - فلا يزال يتعين عليك أن تسأل عن سبب رؤيتك لهذه الاختلافات في البيانات الإجمالية وما يعنيه ذلك. هل يحرّف مستخدمو المتصفّحات الأخرى غير Chrome مقاييسك بطريقة إيجابية أو سلبية؟ هل يمنحك هذا مزيدًا من الإحصاءات حول أماكن حدوث مشاكل في الأداء يمكنك تحديد أولوياتها؟
إذا كان مستخدمو المتصفحات الأخرى يحصلون على نتائج مختلفة، يمكنك استخدام هذه الإحصاءات القيّمة التي يوفّرها لك RUM لإجراء التحسين بشكل مختلف. على سبيل المثال، لا تتوفّر بعض واجهات برمجة التطبيقات في متصفّحات معيّنة، ولكن يمكنك استخدام بدائل للمتصفّحات غير المتوافقة لتحسين تجاربها أيضًا. أو يمكنك تقديم تجربة مختلفة ولكن أكثر فعالية للمستخدمين على الأجهزة أو الشبكات المحدودة. يقتصر تقرير تجربة المستخدم على Chrome على بيانات Chrome، ولكن عليك مراعاة تجارب جميع زوّار موقعك الإلكتروني للمساعدة في تحديد أولويات التحسينات. ويمكن لبيانات RUM سد هذه الفجوة.
بعد فهم أسباب أي اختلافات، يمكن أن تكون كلتا الأداتين مفيدتَين للغاية في فهم تجارب المستخدمين على موقعك الإلكتروني، والمساعدة في تحسينها حتى لو لم تكن الأرقام متطابقة. استخدِم بيانات RUM لتكملة بيانات CrUX والسماح لك بالتعمّق في ما تخبرك به CrUX على مستوى عالٍ من خلال تقسيم عدد الزيارات لمساعدتك في تحديد ما إذا كانت هناك مناطق معيّنة في موقعك الإلكتروني أو قاعدة المستخدمين التي تستدعي الانتباه.
إنّ الاطّلاع على المؤشرات لمعرفة ما إذا كانت التحسينات التي أجريتها تحقّق التأثيرات الإيجابية المتوقعة هو غالبًا أكثر أهمية من مطابقة كل رقم بدقة بين مصدرَي البيانات. كما ذكرنا سابقًا، تتيح لك RUM الاطّلاع على أُطر زمنية مختلفة للحصول على نظرة مسبقة على نتائج CrUX لمدة 28 يومًا، مع العلم أنّ الاطّلاع على أُطر زمنية قصيرة جدًا يمكن أن يؤدي إلى بيانات مشوّشة، ولهذا السبب تستخدم CrUX 28 يومًا.
غالبًا ما لا تكون هناك إجابة "صحيحة" أو "خاطئة" في هذه المقاييس المختلفة، فهي مجرد عدسة مختلفة على المستخدمين وكيفية تجربتهم لموقعك الإلكتروني. طالما أنّك تفهم سبب حدوث هذه الاختلافات، وما يمكن أن تفعله لتوجيه عملية اتخاذ القرار، فهذا هو الأهم لتقديم خدمة أفضل لزوّار موقعك الإلكتروني.