اختبار سرعة الموقع: الفرق بين PageSpeed وLighthouse وCrUX
لماذا لا تتطابق نتائج اختبار سرعة الموقع؟ ما يقيسه PageSpeed وLighthouse وCrUX، الفرق بين بيانات الميدان والمختبر، والترتيب الصحيح للقراءة.
بقلم Roozbeh Nazari · CEO
يعيش كل من يجري اختبار سرعة الموقع الحيرة نفسها: PageSpeed Insights يعطي 62، وLighthouse يعطي 91، وتقرير Core Web Vitals في Search Console يقول "يحتاج إلى تحسين"، ويبدو أن الثلاثة قاسوا الصفحة نفسها. هذا ليس تناقضًا؛ فثلاث أدوات تقيس ثلاثة أشياء مختلفة، وإجابة كل منها تخص سؤالًا مختلفًا. تشرح هذه المقالة ما الذي يقيسه PageSpeed Insights وLighthouse وتقرير تجربة مستخدمي Chrome (CrUX)، وعمّن، وفي أي ظروف؛ ثم تعرض الترتيب الذي يجب أن يُقرأ به اختبار سرعة الموقع، وأي رقم يمكن أن يستند إليه أي قرار. الهدف تحسين السرعة التي يعيشها المستخدم فعلًا بدل "رفع الدرجة".
بيانات المختبر مقابل بيانات الميدان
الفرق الأساسي هو التالي: بيانات المختبر (lab) محاكاة تحميل تُنفَّذ الآن على جهاز افتراضي واحد بظروف شبكة ثابتة. أما بيانات الميدان (field) فهي مجموع ما عاشه مستخدمون حقيقيون على أجهزة واتصالات حقيقية خلال فترة ماضية. ترسم وثائق PageSpeed Insights من Google هذا الخط بوضوح: بيانات الميدان تجمع تجارب المستخدمين في FCP وINP وLCP وCLS بأثر رجعي؛ أما بيانات المختبر فمحاكاة على جهاز قياسي، ولهذا قد تعطي الاثنتان نتائج مختلفة. بيانات المختبر قابلة للتكرار ومناسبة لتصحيح الأخطاء؛ وبيانات الميدان هي واقع المستخدم، وهي الجانب الذي تستخدمه Google في تقييم تجربة الصفحة. السؤال الأول عند قراءة اختبار سرعة الموقع يجب أن يكون: هل الرقم الذي أنظر إليه محاكاة أم مستخدم؟
ما تقيسه الأدوات الثلاث
Lighthouse أداة تدقيق مفتوحة المصدر مدمجة في Chrome؛ تحمّل الصفحة من الصفر وتنتج درجات في فئات مثل إمكانية الوصول وSEO إلى جانب الأداء. درجة الأداء التي تنتجها بيانات مختبر بالكامل وتتغير بحسب الجهاز والإضافات والشبكة التي تشغّلها عليها؛ وقد يختلف قياسان متتاليان للصفحة نفسها. CrUX مجموعة بيانات مجمّعة من التجربة الحقيقية لمستخدمي Chrome؛ تحتوي بيانات فقط للنطاقات والصفحات العلنية ذات الزيارات الكافية، ولهذا تقول "لا توجد بيانات كافية" للصفحات الجديدة أو قليلة الزيارات. يعرض PageSpeed Insights الاثنتين في شاشة واحدة: في الأعلى بيانات الميدان القادمة من CrUX (إن وُجدت)، وفي الأسفل نتيجة مختبر Lighthouse المنفَّذة في تلك اللحظة. أي أن الجزء العلوي من PageSpeed يستند إلى المصدر نفسه الذي يستند إليه تقرير Core Web Vitals في Search Console؛ والجزء السفلي هو Lighthouse بعينه. هذا سبب إعطاء الأدوات الثلاث "ثلاث درجات مختلفة للصفحة نفسها": يوجد في الحقيقة مصدرا بيانات وشكلا تلخيص مختلفان.
عتبات Core Web Vitals والترتيب الصحيح للقراءة
المقاييس الرئيسية الثلاثة في بيانات الميدان هي Core Web Vitals. بحسب التعريف الحالي في web.dev تحتاج التجربة الجيدة إلى LCP خلال 2.5 ثانية، وINP عند 200 مللي ثانية أو أقل، وCLS لا يتجاوز 0.1؛ ويُجرى التقييم عند الشريحة المئوية 75 من المستخدمين. الترتيب الصحيح للقراءة: انظر أولًا إلى بيانات الميدان؛ إذا اجتازت الصفحة العتبات في CrUX فلا مشكلة لدى المستخدم حتى لو كانت درجة المختبر منخفضة، وأولوية التحسين في صفحة أخرى. إذا لم تجتز بيانات الميدان العتبة فانظر في أي مقياس تعثرت؛ إن كانت المشكلة في LCP فابحث عن صورة كبيرة أو زمن استجابة الخادم أو مورد يعيق العرض؛ وإن كانت في INP فعن السكربتات التي تشغل الخيط الرئيسي؛ وإن كانت في CLS فعن الصور بلا أبعاد والكتل متأخرة التحميل. عند هذه النقطة فقط انتقل إلى Lighthouse: يُظهر تقرير المختبر سطرًا سطرًا ما الذي يعطّل المقياس الذي أشارت إليه بيانات الميدان. الفرق التي تعمل بالترتيب المعكوس، أي تبدأ من درجة Lighthouse، قد تقضي أسابيع في إصلاح مشكلات لا يعيشها المستخدمون. وتوجد طبقة ثالثة: يعرض تقرير Core Web Vitals في Search Console بيانات CrUX نفسها مجمّعة في مجموعات صفحات ويكشف بنظرة واحدة أي قالب (صفحة منتج، تدوينة، فئة) هو المشكلة؛ والنظر إلى هذا التقرير قبل اختبار الصفحات فرادى يوجّه العمل إلى القالب الصحيح. في خدمة SEO التقني لدينا يُجرى تدقيق السرعة بهذا الترتيب، ويُوسم كل استنتاج في التقرير بـ "ميدان" أو "مختبر".
ملاحظات إضافية للمواقع متعددة اللغات والجوال
تُقسَّم بيانات CrUX بحسب نوع الجهاز، وفي معظم المواقع التركية شريحة الجوال أسوأ بوضوح من سطح المكتب؛ وقراءة اختبار سرعة الموقع على سطح المكتب فقط تعني تجاهل معظم مستخدميك. وفي المواقع متعددة اللغات فخ ثانٍ: يعطي CrUX بيانات على مستوى النطاق (origin) وعلى مستوى الصفحة؛ وقد تنتج الصفحات العربية والفارسية LCP وCLS مختلفين عن الصفحات التركية بسبب ملفات الخطوط المنفصلة والتخطيط من اليمين إلى اليسار، لكنها لكونها قليلة الزيارات قد لا تظهر لها بيانات على مستوى الصفحة. في هذه الحالة تحمل بيانات مستوى النطاق ثقل الصفحات التركية وتختفي المشكلة. الحل متابعة مجموعات الصفحات بحسب اللغة على حدة في تقرير Core Web Vitals في Search Console، وتكرار قياس المختبر بانتظام بملف الجهاز نفسه للغات التي لا بيانات لها. تتناول مقالة Core Web Vitals للمرضى الدوليين هذا التمييز بمثال مواقع العيادات.
أي رقم يستند إليه أي قرار
الرقم الذي يدخل تقرير الإدارة يجب أن يكون من بيانات الميدان: مثل "نسبة الصفحات التي يتجاوز LCP فيها 2.5 ثانية على الجوال". والرقم الذي يدخل مهمة المطوّر من بيانات المختبر: مثل "3 سكربتات تعيق العرض في هذه الصفحة". إذا طلبت الوكالة أو المطوّر موافقتك بعبارة "رفعنا درجة PageSpeed إلى 90" فاسأل عن أي قسم يتحدثون؛ قد تتغير درجة المختبر في يوم واحد، بينما تتراكم بيانات الميدان في نافذة 28 يومًا ولا يظهر التحسن إلا بعد أسابيع. هذا التأخير ليس عيبًا بل ثمن استناد القياس إلى مستخدم حقيقي. الفرق التي تقرأ اختبار سرعة الموقع كأداة تشخيص من طبقتين لا كسباق درجات تحسّن السرعة التي يراها المستخدم ومحرك البحث معًا؛ أما الفرق التي ترفع الدرجة وتترك المستخدم في مكانه فلا تنتج سوى لقطات شاشة.
بروتوكول اختبار سرعة الموقع في خمس دقائق
يُجرى تشخيص سريع لصفحة واحدة كالتالي. أدخل عنوان الصفحة في PageSpeed Insights وانظر أولًا إلى القسم العلوي في تبويب الجوال: إن وُجدت بيانات ميدان فدوّن حالة الاجتياز أو التعثر لمقاييس Core Web Vitals الثلاثة؛ وإن لم توجد فانتقل إلى بيانات مستوى النطاق واذكر في التقرير أنها متوسط الموقع لا الصفحة. ثم اقرأ من تدقيقات Lighthouse في القسم السفلي فقط ما يخص المقياس المتعثر: أكبر عنصر محتوى وزمن استجابة الخادم لـ LCP، والمهام الطويلة لـ INP، والعناصر بلا أبعاد لـ CLS. أوصل الاستنتاجات إلى المطوّر باسم المقياس والعنصر لا بعبارة "ارفع الدرجة". بعد نشر الإصلاح أعد قراءة Lighthouse في اليوم نفسه وبيانات الميدان بعد أربعة أسابيع؛ تحسّن الاثنين مكسب حقيقي، أما تحسّن الأول وحده فتغيير لم يصل إلى المستخدم بعد.