لماذا تختلف نتائج PageSpeed Insights عن Search Console؟
افهم اختلاف نتائج PageSpeed Insights وSearch Console عبر الفصل بين اختبار Lighthouse وبيانات CrUX الحقيقية وتجميع الروابط ونافذة 28 يوماً.
Lighthouse اختبار لحظي مضبوط يساعدك في التشخيص، بينما Search Console يلخص تجربة مستخدمين حقيقيين خلال فترة ويجمع روابط متشابهة. استخدم كل أداة للسؤال المناسب.
قد تحصل على نتيجة ممتازة في PageSpeed Insights بينما يعرض Search Console مشكلة في مؤشرات أداء الويب الأساسية، أو يحدث العكس. لا يعني ذلك بالضرورة أن إحدى الأداتين مخطئة؛ فكل واحدة تجيب عن سؤال مختلف وتعتمد على مجموعة بيانات مختلفة.
قبل مقارنة الأرقام اسأل: هل أنظر إلى Lab Test جديدة أم إلى زيارات حقيقية تراكمت خلال أسابيع؟
افهم الفرق بين بيانات المختبر والبيانات الميدانية
تعرض PageSpeed Insights نوعين عند توفر البيانات:
- Lab Data: تشغيل Lighthouse في بيئة جهاز وشبكة مضبوطة وقت الاختبار.
- Field Data: بيانات CrUX من مستخدمي Chrome المؤهلين عندما يتوفر حجم كافٍ.
تقرير Core Web Vitals في Search Console مبني على Field Data، أي تجربة حقيقية بأجهزة وشبكات ومواقع جغرافية وحالات Cache مختلفة.
Lab Data مفيدة لقراءة Waterfall وMain Thread وRender Blocking وLayout Shifts. أما Field Data فتخبرك بالنتيجة التي عاشها الجمهور فعلاً.
اختبار Lighthouse سريع اليوم لا يمحو زيارات بطيئة موجودة داخل نافذة البيانات.
انتبه إلى نافذة 28 يوماً
يعتمد Search Console على آخر 28 يوماً ويستخدم 75th Percentile للمقاييس. بعد نشر تحسين جديد تدخل الزيارات الجديدة تدريجياً وتخرج الزيارات القديمة تدريجياً.
لذلك قد يتحسن Lighthouse فوراً بينما تظل الحالة Poor في Search Console لفترة. سجل تاريخ Deploy وراقب Trend بدلاً من تغيير الكود كل يوم بلا دليل.
إذا كانت لديك Real User Monitoring فسترى أثر الإصدار أسرع، لكنها لا تستبدل تقرير Google؛ بل تساعدك على تفسيره.
افهم بيانات الرابط والنطاق بالكامل
تحاول PageSpeed عرض بيانات الرابط نفسه عندما يتوفر Sample كافٍ، وقد تنتقل إلى Origin Data التي تجمع صفحات النطاق كله. اقرأ Label الموجود فوق الأرقام.
أما Search Console فيجمع روابط يرى أن لها تجربة متشابهة. قد يكون Example URL سريعاً، لكن صفحة أخرى ذات زيارات أعلى داخل Group بطيئة. الحالة تخص المجموعة وليست المثال وحده.
وفق توثيق Google، يعامل Search Console الروابط ذات Parameters عند التجميع، بينما تزيل PageSpeed Parameters في تقارير CrUX. Redirects ونسخ Mobile والتخصيص قد تزيد الاختلاف.
قارن الجهاز وحالة الصفحة نفسها
يفصل Search Console بين Mobile وDesktop. لا تقارن تقرير Mobile بتشغيل Lighthouse Desktop.
راجع أيضاً:
- زيارة Cold Cache أم Warm Cache.
- قرب المستخدم من Origin.
- Cookie Banner والاختلافات الجغرافية.
- Logged-in أم Anonymous.
- A/B Testing.
- Ads وChat وTag Manager.
- ضغط مؤقت على Database أو PHP لم يظهر في اختبار واحد.
يشمل LCP الميداني Redirect وConnection وTTFB. لذلك قد يفشل مستخدم بعيد أو جهاز بطيء بينما جهاز المطور سريع.
لا تخلط درجة الأداء بالمقاييس نفسها
الرقم العام في Lighthouse Score موزون من عدة Audits. ليس هو LCP أو INP أو CLS.
تطبق Core Web Vitals حدودها على 75th Percentile لكل من Mobile وDesktop. قد يكون Average جيداً بينما يفشل الربع الأبطأ من الزيارات.
كما تصنف Search Console مجموعة الروابط بناءً على أسوأ Metric. نجاح LCP لا يجعل المجموعة جيدة إذا كان INP أو CLS ضعيفاً.
استخدم كل أداة للقرار المناسب
استخدم Search Console وField Data للإجابة عن:
- هل يحقق المستخدمون الحقيقيون Core Web Vitals؟
- أي Device وURL Group تتأثر؟
- هل اتجاه 28 يوماً يتحسن؟
استخدم Lighthouse وDevTools وWaterfall للإجابة عن:
- ما هو LCP Element؟
- لماذا يبدأ طلب الصورة متأخراً؟
- أي Script يؤخر Rendering أو Interaction؟
- ما العنصر الذي تسبب في Layout Shift؟
Field Data تحدد المشكلة، وLab Trace تساعدك على بناء فرضية واختبارها.
خطوات عملية للتحقيق
- اختر Mobile أو Desktop في Search Console.
- سجل Metric الفاشلة وURL Group.
- اختبر عدة روابط حقيقية من المجموعة.
- اعرف هل بيانات PageSpeed على مستوى URL أم Origin.
- شغّل اختبارات متكررة لTemplates ممثلة.
- قسم LCP أو INP إلى أجزائها بدلاً من متابعة Score فقط.
- أصلح سبباً مشتركاً واحداً وانشره مع Release Marker.
- راقب RUM فوراً واترك نافذة Search Console تتحدث.
عند مشكلة LCP قسمها إلى TTFB وResource Load Delay وLoad Duration وRender Delay. يطبق دليل تحسين LCP في ووردبريس هذا النموذج.
أخطاء في تفسير النتائج
لا تقارن Desktop بـMobile، ولا تعتبر Lighthouse Score حكماً على CWV، ولا تتجاهل Origin Data، ولا تختبر Example واحداً، ولا تتوقع إعادة ضبط 28 يوماً بعد Deploy.
ضع Performance Budget في عملية الإصدار. يشرح دليل ميزانية أداء Astro كيفية تحويل القياس إلى شرط مستمر.
أسئلة شائعة
أي نتيجة أعتمد لتحسين Core Web Vitals؟
استخدم Field Data للحكم على تجربة المستخدم، واستخدم Lab Data لتشخيص السبب واختبار الحل. الأداتان تكملان بعضهما ولا تتنافسان.
لماذا تعرض PageSpeed عبارة No Data؟
قد لا يملك الرابط أو Origin عدداً كافياً من عينات CrUX المؤهلة. استخدم Lighthouse وReal User Monitoring الخاصة بك حتى تنمو التغطية.
مراجع رسمية
لديك سؤال عن هذا الدليل أو فكرة لتعاون تقني؟ تواصل مع بكري عبر المركز التقني.
نهاية الملاحظة.