قياس Core Web Vitals: الأدوات والخطوات لقراءة البيانات بشكل صحيح
قياس Core Web Vitals يتم بنوعين من البيانات: بيانات المستخدمين الحقيقيين التي تعرضها Search Console وPageSpeed Insights من تقرير CrUX، وبيانات المختبر التي يولدها Lighthouse لتشخيص المشكلات. البيانات الحقيقية تخبرك بما يعيشه زوارك فعلًا، وبيانات المختبر تخبرك بالسبب ومكان الإصلاح.
كثير من أصحاب المواقع ينظرون إلى درجة الأداء الملونة في PageSpeed Insights ويظنونها هي ما تستخدمه Google، وهذا خطأ شائع. في هذا الدليل نشرح المؤشرات الثلاثة وحدودها الرسمية، والفرق بين مصادر البيانات، ثم خطوات عملية لقياس موقعك وقراءة النتائج بشكل صحيح.
أهم النقاط باختصار
- مؤشرات Core Web Vitals ثلاثة: LCP لسرعة التحميل، وINP لسرعة الاستجابة، وCLS لثبات التصميم.
- القيم الجيدة هي: LCP خلال 2.5 ثانية، وINP عند 200 ملي ثانية أو أقل، وCLS عند 0.1 أو أقل.
- تُقاس النتيجة عند المئين 75 من زيارات الصفحة مع الفصل بين الجوال والكمبيوتر.
- تقرير Search Console وقسم البيانات الميدانية في PageSpeed Insights يعتمدان على آخر 28 يومًا من بيانات CrUX.
- درجة Lighthouse للتشخيص فقط، وليست المقياس الذي يُحكم به على تجربة الصفحة.
ما هي Core Web Vitals وما حدودها الرسمية؟
Core Web Vitals هي مجموعة مؤشرات حددتها Google لقياس تجربة المستخدم الفعلية في التحميل والتفاعل والثبات البصري. وفق web.dev وتقرير Search Console تُصنف القيم كالتالي:
| المؤشر | ماذا يقيس | جيد | يحتاج إلى تحسين | ضعيف |
|---|---|---|---|---|
| LCP | زمن ظهور أكبر عنصر مرئي | 2.5 ثانية أو أقل | حتى 4 ثوانٍ | أكثر من 4 ثوانٍ |
| INP | سرعة استجابة الصفحة للنقر واللمس والكتابة | 200 ملي ثانية أو أقل | حتى 500 ملي ثانية | أكثر من 500 ملي ثانية |
| CLS | مقدار التحرك غير المتوقع للعناصر | 0.1 أو أقل | حتى 0.25 | أكثر من 0.25 |
لكل مؤشر دليل تحسين مستقل على المدونة: تحسين LCP وتحسين INP وتحسين CLS. أما هذا المقال فيركز على القياس وقراءة البيانات.
الفرق بين بيانات المستخدمين الحقيقيين وبيانات المختبر
البيانات الميدانية تأتي من تقرير تجربة مستخدمي Chrome المعروف باسم CrUX، وهو مجموعة بيانات تعكس تجربة مستخدمي Chrome الحقيقيين مع المواقع. وهذه البيانات هي التي تغذي PageSpeed Insights وSearch Console، وتستخدمها Google في عامل تجربة الصفحة. لكن ليست كل الصفحات موجودة فيها، فالصفحة يجب أن تكون عامة وقابلة للاكتشاف وأن يكون لها عدد كافٍ من الزوار.
أما بيانات المختبر فينتجها Lighthouse من تحميل محاكى للصفحة، وفي الجوال يحاكي هاتفًا متوسط المواصفات على شبكة جوال. هذه البيانات ممتازة للتشخيص والاختبار قبل النشر، لكنها لا تمثل أجهزة زوارك وشبكاتهم بالضرورة. ولأن INP يعتمد على تفاعل حقيقي من المستخدم، فإن قياسه الدقيق يأتي من البيانات الميدانية أو من اختبار تفاعل يدوي في المتصفح.
أدوات قياس Core Web Vitals ومتى تستخدم كل أداة
| الأداة | نوع البيانات | أفضل استخدام |
|---|---|---|
| تقرير Core Web Vitals في Search Console | ميدانية من CrUX | رؤية مجموعات الصفحات المتأثرة على مستوى الموقع |
| PageSpeed Insights | ميدانية ومختبرية معًا | فحص صفحة محددة مع توصيات للإصلاح |
| CrUX عبر لوحة البيانات أو الواجهة البرمجية | ميدانية | تتبع الاتجاه عبر الوقت والمقارنة بالمنافسين |
| Lighthouse وChrome DevTools | مختبرية | تحديد العنصر أو السكربت المسبب للمشكلة |
| مكتبة web-vitals مع GA4 | ميدانية من زوارك أنت | قياس كل الصفحات حتى غير الموجودة في CrUX |
لا تحتاج إلى استخدام كل هذه الأدوات في كل مرة. القاعدة البسيطة أن تبدأ بالأداة التي تعطيك صورة عن المستخدمين الحقيقيين، ثم تنتقل إلى أداة التشخيص عندما تعرف أين المشكلة. فإذا أظهر تقرير Search Console أن مجموعة صفحات المقالات ضعيفة في LCP على الجوال، فافتح صفحة من هذه المجموعة في PageSpeed Insights، ثم استخدم DevTools لمعرفة العنصر الذي يؤخر التحميل. وبهذا الترتيب توفر وقت فريقك وتركز على الإصلاح الذي يغير تجربة الزوار فعلًا.
خطوات قياس Core Web Vitals لموقعك
1. ابدأ بتقرير Core Web Vitals في Search Console
افتح التقرير من قسم تجربة الصفحة وانظر إلى الجوال والكمبيوتر كلًا على حدة. يجمع التقرير عناوين URL المتشابهة في مجموعات، ويعطي كل مجموعة حالة أسوأ مؤشر فيها: جيدة أو تحتاج إلى تحسين أو ضعيفة. وإذا لم تتوفر بيانات كافية لمجموعة ما يعرض التقرير بيانات النطاق كاملًا، ولا تظهر إلا الصفحات المفهرسة. لفهم بقية تقارير الأداة راجع مقاييس تتبع السيو للمبتدئين.
2. افحص الصفحات المهمة في PageSpeed Insights
أدخل رابط الصفحة وابدأ بقسم تجربة المستخدمين الحقيقيين في الأعلى، فهو يعرض بيانات CrUX لآخر 28 يومًا ويتحدث يوميًا. إذا لم تكن للصفحة بيانات كافية فسترى بيانات النطاق كاملًا بدلًا منها، وإذا لم تتوفر أيضًا فلن تظهر بيانات ميدانية. بعدها انتقل إلى قسم التشخيص المختبري لقراءة الفرص والتوصيات.
3. اقرأ القيم عند المئين 75 وافصل الأجهزة
المئين 75 يعني أن ثلاثة أرباع الزيارات على الأقل كانت تجربتها بهذه القيمة أو أفضل، ولذلك لا يكفي أن يكون الموقع سريعًا على جهازك أنت. افصل الجوال عن الكمبيوتر دائمًا، لأن معظم زوار المواقع في السعودية والخليج يصلون عبر الهاتف، وقد تكون نتائج الكمبيوتر جيدة بينما يعاني الجوال.
4. شخّص السبب باستخدام Lighthouse وDevTools
بعد أن تعرف المؤشر الضعيف من البيانات الميدانية، استخدم لوحة Performance في Chrome DevTools وتقرير Lighthouse لتحديد السبب: صورة رئيسية ثقيلة تؤخر LCP، أو سكربت طويل يبطئ الاستجابة، أو إعلان بلا أبعاد يحرك المحتوى. في مواقع ووردبريس تجد أشيع المشكلات وحلولها في دليل تسريع موقع ووردبريس.
5. قِس من زوارك مباشرة عبر مكتبة web-vitals
كثير من صفحات المواقع العربية لا تملك زيارات كافية للظهور في CrUX. الحل هو إضافة مكتبة web-vitals مفتوحة المصدر إلى الموقع وإرسال قيم LCP وINP وCLS كأحداث إلى Google Analytics 4 عبر Google Tag Manager، ثم تحليلها حسب الصفحة والجهاز والدولة. هكذا تحصل على بيانات ميدانية لكل صفحة بدل انتظار CrUX.
6. أصلح ثم ابدأ التحقق من الإصلاح
بعد تطبيق الإصلاح استخدم زر التحقق من الإصلاح في تقرير Search Console، وتذكر أن البيانات الميدانية تغطي آخر 28 يومًا، لذلك لن يظهر التحسن فورًا. خلال هذه الفترة راقب بيانات web-vitals في GA4 لتتأكد مبكرًا أن الإصلاح نجح فعلًا عند المستخدمين الحقيقيين. ولأن السرعة تؤثر في المبيعات أيضًا، اربط التحسن بمعدل التحويل كما شرحنا في زيادة مبيعات المتجر الإلكتروني.
ومن المفيد أن تحتفظ بجدول بسيط يسجل تاريخ كل تعديل ونوعه والصفحات التي شملها، حتى تربط أي تغير في البيانات الميدانية بالسبب الحقيقي بدل التخمين بعد أسابيع، خصوصًا عندما يعمل أكثر من شخص على الموقع.
أخطاء شائعة عند قياس Core Web Vitals
- الاعتماد على درجة الأداء في Lighthouse وتجاهل البيانات الميدانية.
- اختبار الصفحة الرئيسية فقط ونسيان صفحات المنتجات والمقالات التي تجلب أغلب الزيارات.
- المقارنة بين اختبارين مختبريين متتاليين مع أن النتائج تتذبذب بطبيعتها.
- توقع ظهور التحسن في Search Console في اليوم التالي للإصلاح.
- إهمال السكربتات الخارجية مثل أدوات الدردشة والإعلانات التي تؤثر في INP وCLS.
الأسئلة الشائعة
لماذا تختلف نتائج PageSpeed Insights عن Search Console؟
لأن PageSpeed Insights يعرض بيانات صفحة واحدة بالإضافة إلى اختبار مختبري، بينما يجمع Search Console الصفحات المتشابهة في مجموعات، وقد يعرض كلاهما بيانات النطاق كاملًا عند نقص بيانات الصفحة.
لماذا لا تظهر بيانات ميدانية لموقعي؟
يشترط CrUX أن تكون الصفحة عامة وقابلة للاكتشاف وأن يكون لها عدد كافٍ من الزوار. المواقع الجديدة أو قليلة الزيارات لا تظهر فيه، ويمكنها الاعتماد على مكتبة web-vitals للقياس المباشر.
هل تؤثر Core Web Vitals في ترتيب Google؟
نعم، تستخدم Google بيانات CrUX ضمن عامل تجربة الصفحة، لكنها إشارة واحدة من إشارات كثيرة، والمحتوى المفيد والملائم للبحث يبقى الأساس. فائدتها الأكبر عادة في تجربة الزائر والتحويل.
ما الفرق بين FID وINP؟
كان FID يقيس تأخير أول تفاعل فقط، بينما يقيس INP سرعة الاستجابة للتفاعلات طوال زيارة الصفحة، ولذلك أصبح INP هو المؤشر المعتمد ضمن Core Web Vitals بدلًا من FID.
كم مرة يجب أن أقيس Core Web Vitals؟
راجع تقرير Search Console شهريًا، وافحص الصفحات المهمة بعد كل تغيير كبير مثل تغيير القالب أو إضافة إضافات أو سكربتات جديدة، واجعل بيانات web-vitals في GA4 لوحة متابعة دائمة.
الخلاصة
القياس الصحيح يبدأ من البيانات الميدانية لمعرفة المشكلة، ثم بيانات المختبر لمعرفة السبب، ثم التحقق بعد الإصلاح ببيانات حقيقية مرة أخرى. استخدم Search Console للصورة العامة، وPageSpeed Insights للصفحات المهمة، وDevTools للتشخيص، ومكتبة web-vitals لسد فجوة الصفحات التي لا يغطيها CrUX. بهذا تعرف بدقة ما يعيشه زوارك بدل التخمين من درجة ملونة. وإذا كان موقعك متجرًا أو موقع خدمات يعتمد على الجوال، فاجعل صفحات الهبوط والمنتجات أولوية القياس لأنها الأقرب إلى قرار الشراء.
المصادر
- web.dev: Web Vitals
- Search Console Help: Core Web Vitals report
- Chrome for Developers: Chrome UX Report
- PageSpeed Insights: About
