Core Web Vitals: تشخيص تجربة الصفحة من دون وعود بالترتيب

يبدأ تشخيص مؤشرات Core Web Vitals بملاحظة ما يواجهه المستخدمون فعلاً، ثم بإعادة إنتاج المشكلة في اختبار مضبوط. تساعد المؤشرات على كشف تأخر المحتوى الرئيسي، أو بطء التفاعل، أو تحرك التخطيط بلا توقع. وهي ليست حكماً واحداً على جودة الموقع أو SEO أو النتائج التجارية.

ما الذي نثبته قبل تغيير الصفحة؟

تقيس Core Web Vitals التحميل والاستجابة والاستقرار البصري. يشير Largest Contentful Paint (LCP) إلى ظهور المحتوى الرئيسي؛ ويقيس Interaction to Next Paint (INP) استجابة الصفحة بعد النقر أو اللمس أو الكتابة؛ بينما يقيس Cumulative Layout Shift (CLS) تحركات التخطيط غير المتوقعة. تقترح Google أن يكون LCP في 2.5 ثانية أو أقل، وINP في 200 مللي ثانية أو أقل، وCLS في 0.1 أو أقل، عند الشريحة المئوية 75 من الزيارات وبفصل بين الجوال وسطح المكتب.[^google]

يسجل مخطط الموضوع للعبارة «Core Web Vitals» حجم بحث 70؛ KD 73؛ نية معلوماتية — تقدير Ahrefs المغرب، 22 أكتوبر 2026. هذا تقدير في قاعدة بيانات الكلمات المفتاحية، وليس توقعاً للزيارات أو الترتيب أو العملاء المحتملين.

ابدأ بتسمية المسار الذي تريد حمايته: صفحة خدمة، أو صفحة هبوط لحملة، أو صفحة منتج، أو إرسال نموذج. دوّن الجهاز والرابط والمقياس والفترة. بهذه الخطوة لا ننسب إلى صفحة بعينها نتيجة تخص النطاق كله.

تشخيص LCP وINP وCLS بحسب الآلية

LCP: ما هو العنصر الرئيسي ولماذا تأخر؟

قد يكون LCP صورة الواجهة أو صورة منتج أو ملصق فيديو أو كتلة نصية كبيرة. النتيجة المرتفعة لا تعني تلقائياً أن الصورة كبيرة الحجم. تقسم web.dev زمن LCP إلى زمن استجابة الخادم (TTFB)، وتأخر بدء تحميل مورد LCP، ومدة تحميله، وتأخر رسم العنصر.[^lcp]

حدد العنصر في PageSpeed Insights أو Chrome DevTools، ثم راجع تسلسل طلبات الشبكة. هل يصل HTML ببطء؟ هل يكتشف المتصفح الصورة الرئيسية بعد JavaScript فقط؟ هل تؤخر الخطوط أو CSS أو السكربتات الرسم؟ هل اكتمل تنزيل الملف وبقي العنصر مخفياً؟ تحدد الإجابة الإجراء: تحسين استجابة الخادم، أو إتاحة المورد الحاسم مبكراً، أو ضبط أبعاد وصيغة الصورة، أو تقليل عمل الرسم. ضغط الصورة وحده لا يعالج عنصراً لا يظهر إلا بعد انتهاء سكربت.

INP: اختبر فعلاً حقيقياً لا مجرد تحديث الصفحة

يتتبع INP التفاعلات المؤهلة خلال الزيارة. قد يكون السبب قائمة تنقل أو فلتر أو اختيار تاريخ أو تحقق نموذج أو مكوّناً خارجياً. أعد اختبار المسار الواقعي على سيناريو جوال مناسب: افتح القائمة، طبق فلترًا، اختر خياراً، ثم املأ النموذج وأرسله.

يبين تسجيل DevTools إن كان الوقت يضيع قبل تشغيل معالج الحدث، أو أثناء معالجته، أو قبل رسم الإطار التالي. المهام الطويلة في JavaScript، والرسم المكلف، وقراءات وكتابات التخطيط المتكررة، وتحديثات DOM الكبيرة احتمالات للتحقيق وليست أحكاماً جاهزة.[^inp] قد يكون الحل تخفيف معالج الحدث أو تجزئة عمل غير عاجل أو تأجيل ما لا يحتاجه الإطار التالي أو تبسيط الرسم. يجب أن تبقى الوظيفة صحيحة: زر يبدو سريعاً لا يفيد إذا أخفى فشل تحقق مهم.

CLS: اعرف ما تحرك ثم ابحث عن مصدره

يرصد CLS تحركات التخطيط غير المتوقعة. يمكن لصورة أو لافتة أو خط أو وحدة متأخرة أن تدفع زرّاً أثناء القراءة فتربك المستخدم أو تسبب نقرة خاطئة. احجز مساحة للصور والفيديو بأبعاد HTML أو بنسبة أبعاد CSS، وراجع أيضاً المحتوى المضمّن والوحدات الديناميكية ولوحات الموافقة حيث يلزم.

قارن CLS الميداني بنتيجة Lighthouse. عندما تكون بيانات الحقل أسوأ بوضوح، قد تقع التحركات بعد التحميل أثناء التمرير أو انتقال في التطبيق. يسجل Performance في Chrome DevTools هذه التحركات ويظهر العناصر المتأثرة. ليس العنصر المتحرك دائماً هو السبب، لكنه يساعد على اكتشاف ما أُضيف أو تغير فوقه.[^cls]

بيانات الحقل والتشخيص المخبري لكل منهما دور

يجمع PageSpeed Insights بيانات CrUX، وهي تجميع لتجارب مستخدمي Chrome الفعلية، مع اختبار Lighthouse المضبوط. تقول البيانات الميدانية ما واجهه المستخدمون، ويساعد المختبر على تكرار سبب محتمل وفحصه. قد تختلف النتائج بسبب الأجهزة والشبكات والتخزين المؤقت والتفاعلات الفعلية.[^psi]

تحقق من مستوى البيانات قبل اتخاذ قرار. يمكن أن تعرض PageSpeed Insights بيانات الرابط ثم ترجع إلى مستوى النطاق عند نقص بيانات الرابط. ويجمع Search Console روابط ذات تجربة متشابهة ويعرض عينة لاكتشاف الأنماط؛ ولا يشكل تشخيصاً كاملاً لكل رابط مفهرس.[^gsc] غياب CrUX ليس نجاحاً ولا فشلاً. يكشف اختبار المختبر تراجعاً واضحاً، وقد يضيف قياس المستخدمين الحقيقيين سياقاً عن الصفحات والتفاعلات عندما يكون مناسباً لسياسات الموافقة.

منهج عملي من ست خطوات

سمِّ التجربة المعرّضة للمشكلة. حدد الصفحة وشريحة الجوال أو سطح المكتب والفعل الذي ينبغي للزائر إتمامه.
وثق الإشارة الميدانية. احتفظ بالمقياس والتوزيع والفترة ومستوى الرابط أو النطاق ومجموعة الصفحات المتأثرة.
اكتب فرضية قابلة للاختبار. مثل: «الصورة الرئيسية تبدأ بعد سكربت» أو «الفلتر يحجز الخيط الرئيسي».
أعد الإنتاج. استخدم Lighthouse لـLCP وCLS، وDevTools مع تفاعلات يدوية للاستجابة. لا يقيس Lighthouse INP كاملاً بلا تفاعل مستخدم؛ Total Blocking Time مؤشر مخبري مساعد وليس بديلاً عن INP الميداني.[^vitals]
نفذ تغييراً محدوداً. وثق المكوّن والمسؤول والاعتمادات وخطر تعطل الوظائف ومعيار القبول. اختبر النموذج والقياس بعد أي تغيير في قالب أو وسم أو سكربت خارجي.
تحقق مع الوقت. أعد الاختبار المخبري فوراً، ثم راجع البيانات الميدانية عند تجددها. يتابع Search Console التحقق 28 يوماً ولا يؤدي ذلك إلى إعادة فهرسة.[^gsc]

يمكن أن يرتبط العمل بـSEO في المغرب حين يجب أن تبقى الصفحات المهمة واضحة وقابلة للاكتشاف، وبـإنشاء صفحات الهبوط عندما تسبب مكونات الحملات احتكاكاً، وبـالتتبع والتحليلات عندما يحتاج الفريق إلى دليل موثوق عن المسار الذي يحسنه.

ترتيب الأولويات وحدود المؤشرات

قدّم الاحتكاك الظاهر في مسار مهم، خاصة إن أثر في مكوّن مشترك أو مجموعات صفحات عديدة وكان إصلاحه قابلاً للتحقق. قد تستحق صورة LCP المتأخرة في صفحة خدمة للجوال تحليلاً قبل توصية عامة في رابط نادر الاستخدام. وازن بين أثر المستخدم واتساع المشكلة وجهد التنفيذ وخطر التراجع. فقد تقلل إزالة سكربت العمل على الخيط الرئيسي لكنها تحذف وظيفة مطلوبة؛ وقد يحسن تأجيل المحتوى الرسم الأولي لكنه يخفي معلومة حاسمة للقرار.

هذه الحدود أهداف لتجربة الاستخدام وليست ضماناً للترتيب أو نتيجة تجارية. تضع Google مؤشرات Core Web Vitals ضمن جوانب متعددة لتجربة الصفحة، فيما تستخدم أنظمة الترتيب إشارات كثيرة.[^google] والصفحة السريعة تقنياً قد تبقى غير مقنعة إذا كانت الخدمة أو الدليل أو الخطوة التالية غير واضحة. لذلك يجب أن تذكر كل توصية مصدرها والرابط والشريحة وطريقة إعادة الإنتاج وما يحتاج إلى تأكيد.

الأسئلة الشائعة حول تشخيص Core Web Vitals

هل ينبغي استهداف 100 في Lighthouse؟

لا. يفيد Lighthouse في تكرار فرصة تحسين داخل بيئة مضبوطة. الهدف هو تقليل احتكاك حقيقي من دون إضعاف غرض الصفحة. استخدم بيانات الحقل عند توافرها، ثم استخدم المختبر لتحديد السبب المحتمل.

لماذا تعرض PageSpeed Insights بيانات النطاق بدلاً من الصفحة؟

إذا لم تكن بيانات CrUX للرابط كافية، قد تظهر الأداة تجميعاً على مستوى النطاق. تحقق من هذا الوصف قبل نسبة النتيجة إلى صفحة. قد يشير إلى مشكلة مشتركة، لكنه لا يثبت تطابق سلوك كل الروابط.

هل LCP الجيد يعني أن INP وCLS جيدان؟

لا. قد يظهر المحتوى الرئيسي بسرعة، بينما يستجيب فلتر ببطء أو يتحرك التخطيط عند ظهور وحدة متأخرة. تصف المؤشرات جوانب مختلفة من التجربة، رغم أن تبعية تقنية واحدة قد تؤثر في أكثر من مؤشر.

متى نراجع بعد النشر؟

يمكن إعادة اختبار المختبر فوراً. أما بيانات الحقل فتجمع تجارب حقيقية وتحتاج وقتاً للتجدد. يراقب Search Console طلب التحقق 28 يوماً، ولا يغني ذلك عن اختبار الوظيفة مباشرة بعد النشر.[^gsc]

المصادر

[^google]: https://developers.google.com/search/docs/appearance/core-web-vitals [^vitals]: https://web.dev/articles/vitals [^psi]: https://developer.chrome.com/docs/crux/guides/pagespeed-insights [^lcp]: https://web.dev/articles/optimize-lcp [^inp]: https://web.dev/articles/optimize-inp [^cls]: https://web.dev/articles/optimize-cls [^gsc]: https://support.google.com/webmasters/answer/9205520?hl=ar