Core Web Vitals في 2026: شرح LCP وINP وCLS وكيف تقيسها وتحسنها
Core Web Vitals هي مجموعة مقاييس تركز على تجربة المستخدم الفعلية في ثلاثة جوانب أساسية: سرعة ظهور المحتوى الرئيسي، سرعة استجابة الصفحة للتفاعل، والثبات البصري أثناء التحميل. المقاييس الحالية هي LCP وINP وCLS.
لو ظهر لك تقرير Core Web Vitals في Google Search Console أو نتيجة ضعيفة في PageSpeed Insights، لا تبدأ بتحسين كل شيء في الموقع دفعة واحدة. افهم أولًا أي مقياس يفشل، وما العنصر أو السلوك الذي يسببه، ثم أصلح السبب الأكثر تأثيرًا.
الخلاصة السريعة: القيم الجيدة
| المقياس | يقيس | الهدف الجيد |
|---|---|---|
| LCP | سرعة تحميل المحتوى الرئيسي | 2.5 ثانية أو أقل |
| INP | سرعة استجابة الصفحة لتفاعلات المستخدم | 200 ملّي ثانية أو أقل |
| CLS | الثبات البصري | 0.1 أو أقل |
يوصي web.dev بتقييم هذه الأهداف عند الشريحة المئوية 75 من تجارب المستخدمين، مع النظر إلى الهاتف والكمبيوتر المكتبي بصورة مناسبة. معنى ذلك أن تجربة سريعة على جهازك وحدك لا تكفي للحكم على أداء المستخدمين الحقيقيين.
ما هو LCP؟
Largest Contentful Paint يقيس الوقت الذي يستغرقه ظهور أكبر عنصر محتوى مرئي مهم داخل نافذة العرض أثناء التحميل. في كثير من صفحات المقالات يكون هذا العنصر صورة البطل أو العنوان أو كتلة محتوى كبيرة.
الهدف الجيد هو أن يحدث LCP خلال أول 2.5 ثانية من بدء تحميل الصفحة.
أسباب LCP البطيء
- صورة رئيسية ضخمة أو غير مضغوطة.
- تأخر استجابة الخادم.
- تحميل CSS أو JavaScript يحجب العرض.
- تحميل الصورة الرئيسية بطريقة lazy رغم أنها داخل أول الشاشة.
- خطوط ويب تؤخر عرض النص.
- صورة LCP تُكتشف متأخرًا بسبب CSS أو JavaScript.
كيف تحسن LCP؟
- حدد عنصر LCP أولًا من DevTools أو PageSpeed Insights.
- إذا كان صورة، استخدم مقاسًا مناسبًا وformat حديثًا مثل WebP أو AVIF عندما يكون مدعومًا في مسارك.
- لا تجعل صورة hero الأساسية lazy-loaded إذا كانت مطلوبة فورًا في أول الشاشة.
- قلل وقت استجابة الخادم والكاش غير الفعال.
- راجع CSS/JS الذي يمنع العرض.
- اجعل المتصفح يكتشف الموارد المهمة مبكرًا بدل تحميلها عبر طبقات متأخرة.
ما هو INP؟
Interaction to Next Paint يقيس استجابة الصفحة لتفاعلات المستخدم عبر مدة الزيارة، مثل الضغط على زر أو فتح قائمة أو التفاعل مع عنصر. الهدف الجيد هو 200 ملّي ثانية أو أقل.
لو يضغط المستخدم على القائمة ولا يرى أي استجابة لوقت ملحوظ لأن JavaScript يحتل الـmain thread، فقد تكون مشكلة INP حتى لو كانت الصفحة ظهرت بسرعة في البداية.
أسباب INP السيئ
- مهام JavaScript طويلة على الـmain thread.
- Event handlers تنفذ عملًا ثقيلًا قبل تحديث الواجهة.
- إعادة rendering كبيرة بسبب تغيير صغير.
- Third-party scripts كثيرة.
- DOM ضخم يجعل بعض عمليات layout/render أكثر تكلفة.
- تنفيذ متزامن لعمل يمكن تقسيمه أو تأجيله.
كيف تحسن INP؟
- حدد التفاعل البطيء بدل تحسين JavaScript بصورة عامة.
- قسّم long tasks إلى أجزاء أصغر.
- قلل العمل داخل event handlers.
- حدّث الواجهة بسرعة ثم نفذ الأعمال الثانوية لاحقًا عندما يكون ذلك مناسبًا.
- راجع تأثير analytics وads وwidgets الخارجية.
- قلل JavaScript الذي لا يحتاجه المستخدم في الصفحة الحالية.
ما هو CLS؟
Cumulative Layout Shift يقيس مقدار التغير غير المتوقع في أماكن العناصر المرئية أثناء استخدام الصفحة. الهدف الجيد هو 0.1 أو أقل.
مثال شائع: يبدأ المستخدم في قراءة فقرة، ثم تظهر صورة أو إعلان بدون مساحة محجوزة فيدفع النص إلى أسفل فجأة. هذا النوع من الحركة يضر التجربة حتى لو كانت الصفحة سريعة.
أسباب CLS المرتفع
- صور أو iframes بدون أبعاد أو aspect ratio معروف.
- إعلانات أو widgets تدخل في الصفحة بدون مساحة محجوزة.
- خط ويب يغيّر أبعاد النص بقوة بعد التحميل.
- إضافة banner أعلى محتوى موجود بعد بدء العرض.
- تحميل عناصر ديناميكية في أماكن غير مخصصة لها.
كيف تحسن CLS؟
- حدد أبعاد الصور أو نسبة الأبعاد.
- احجز مساحة للإعلانات والـembeds قبل وصول المحتوى.
- لا تدخل عناصر أعلى المحتوى الموجود فجأة إلا نتيجة تفاعل المستخدم.
- راجع استراتيجية تحميل الخطوط وfallback fonts.
- اختبر الصفحات التي تحتوي على widgets متغيرة الارتفاع.
الفرق بين Field Data وLab Data
هذه نقطة تسبب ارتباكًا كبيرًا. Field Data تعكس تجارب مستخدمين حقيقيين عندما تتوفر بيانات كافية، بينما Lab Data تأتي من اختبار في بيئة محكومة ومحاكاة محددة.
قد تصلح مشكلة اليوم وتظل بيانات المستخدمين التاريخية تظهر نتيجة مختلفة لبعض الوقت. وفي المقابل، قد ينجح اختبار Lab واحد بينما يعاني مستخدمون حقيقيون على أجهزة أو شبكات أبطأ.
استخدم النوعين معًا: Field لتعرف المشكلة الواقعية، وLab للتشخيص والتجربة أثناء الإصلاح.
أين تقيس Core Web Vitals؟
- Google Search Console: لمشاهدة مجموعات URLs التي تعاني من مشاكل في بيانات المستخدمين عندما تتوفر.
- PageSpeed Insights: يجمع بين بيانات ميدانية عند توفرها وتحليل Lighthouse.
- Chrome DevTools: للتشخيص أثناء التطوير.
- Chrome UX Report (CrUX): مصدر بيانات المستخدمين الحقيقيين الذي تعتمد عليه عدة أدوات.
- مكتبة web-vitals: لقياس التجارب من داخل موقعك عندما تحتاج RUM أكثر تخصيصًا.
هل Core Web Vitals عامل ترتيب؟
توضح Google أنها توصي بتحقيق نتائج جيدة لنجاح البحث ولتجربة المستخدم عمومًا، وأن Core Web Vitals مع جوانب أخرى من Page Experience تتوافق مع ما تسعى أنظمة الترتيب الأساسية إلى مكافأته.
لكن لا تتعامل معها كمعادلة بسيطة: «خفض LCP نصف ثانية = سأرتفع مركزين». جودة وملاءمة المحتوى وإشارات أخرى تظل أساسية. الهدف الأول من تحسين هذه المقاييس هو تجربة أسرع وأكثر استقرارًا واستجابة للمستخدم.
ابدأ بأي مقياس؟
ابدأ بالذي يفشل فعليًا على الصفحات المهمة، ثم رتّب حسب التأثير والتكرار. مثال:
- إذا كل المقالات تفشل LCP بسبب نفس صورة hero/template، إصلاح القالب قد يحل مجموعة كبيرة مرة واحدة.
- إذا INP سيئ فقط في صفحة تحتوي widget معين، لا تعيد بناء JavaScript للموقع كله.
- إذا CLS يأتي من الإعلان نفسه في كل الصفحات، احجز له مساحة من الـlayout.
خطة تحسين عملية من 7 خطوات
- افتح تقرير Core Web Vitals في Search Console.
- حدد مجموعة URLs المتأثرة ونوع الجهاز.
- اختر URL ممثلة للمجموعة.
- حللها في PageSpeed Insights وDevTools.
- حدد السبب الجذري للمقياس الفاشل.
- نفذ إصلاحًا محدودًا وقِس مرة أخرى.
- انشر التعديل ثم راقب البيانات الميدانية مع الوقت.
مثال: مقال LCP فيه صورة رئيسية
لنفترض أن صورة المقال هي LCP. لا تبدأ بإزالة كل الصور. افحص:
- الحجم الفعلي للملف.
- هل المتصفح يحمل نسخة أكبر بكثير من العرض المطلوب؟
- هل الصورة lazy-loaded؟
- هل الـHTML يتيح اكتشافها مبكرًا؟
- هل CDN والكاش يعملان؟
- هل هناك CSS/JS يؤخر الرسم أصلًا؟
بعد كل تعديل، قارن waterfall والـLCP بدل الاعتماد على درجة Performance الإجمالية فقط.
مثال: INP ضعيف بسبب قائمة
لو فتح القائمة يتأخر، سجل Performance trace للتفاعل. قد تكتشف أن click handler يشغّل filter أو rerender ضخم أو third-party code قبل أن يظهر menu. الحل هنا هو تقليل العمل على المسار الحرج للتفاعل، لا تحسين الصور.
مثال: CLS بسبب الصور
إذا كانت الصور تدخل الصفحة بعد تحميل HTML بدون مساحة محجوزة، أضف أبعادًا أو aspect ratio يناسبها. يستطيع المتصفح عندها تخصيص المكان قبل وصول الملف، فلا يقفز المحتوى عند ظهور الصورة.
أخطاء شائعة أثناء تحسين الأداء
- مطاردة Score 100 بدل تحسين تجربة المستخدم الحقيقية.
- اختبار الصفحة الرئيسية فقط واعتبار الموقع كله مماثلًا.
- الاعتماد على Desktop سريع وإهمال Mobile.
- إزالة وظائف مفيدة فقط لتحسين رقم مخبري.
- إضافة plugins أداء كثيرة فوق بعضها بدون فهم المشكلة.
- الخلط بين Lighthouse score وبين Core Web Vitals field status.
Checklist سريع
- LCP ≤ 2.5s عند الهدف الموصى به.
- INP ≤ 200ms.
- CLS ≤ 0.1.
- قياس الشريحة المئوية 75 عند تقييم بيانات المستخدمين.
- الصور الرئيسية بالحجم المناسب وتُكتشف مبكرًا.
- لا توجد long JavaScript tasks غير ضرورية في التفاعلات المهمة.
- مساحات الصور والإعلانات والـembeds محجوزة.
- تراقب Mobile وDesktop ولا تعتمد على اختبار واحد.
الخلاصة
تحسين Core Web Vitals يصبح أسهل عندما تربط كل مقياس بسبب محدد: LCP للتحميل، INP للاستجابة، CLS للثبات. قِس بيانات المستخدمين عندما تتوفر، استخدم الأدوات المخبرية للتشخيص، ثم أصلح السبب المشترك في القالب أو المورد بدل تنفيذ عشرات التحسينات العشوائية.
