Core Web Vitals في 2026: ما الذي يؤثر فعلًا في الترتيب

ماذا تقيس مؤشرات Core Web Vitals اليوم

مؤشرات Core Web Vitals ثلاثة مقاييس تصف شعور الزوار الحقيقيين تجاه الصفحة. يقيس Largest Contentful Paint (LCP) التحميل: كم يستغرق ظهور الصورة الرئيسية أو كتلة النص الأساسية. ويقيس Interaction to Next Paint (INP) الاستجابة: كم تستغرق الصفحة لتتفاعل بشكل مرئي بعد لمسة أو نقرة أو ضغطة مفتاح. ويقيس Cumulative Layout Shift (CLS) الثبات البصري: مقدار تحرك المحتوى أثناء التحميل.

تنجح الصفحة عندما تكون 75% على الأقل من الزيارات في النطاق «الجيد»: LCP لا يتجاوز 2.5 ثانية، وINP لا يتجاوز 200 مللي ثانية، وCLS لا يتجاوز 0.1. يُقيَّم الجوال وسطح المكتب كلٌّ على حدة، والجوال هو الأصعب في الغالب.

حلّ INP محل First Input Delay (FID) ضمن Core Web Vitals في مارس 2024. كان FID يقيس تأخير أول تفاعل فقط، أما INP فينظر إلى أبطأ التفاعلات خلال الزيارة كلها. كثير من المواقع التي كانت خضراء بسهولة مع FID أصبحت صفراء أو حمراء مع INP.

ما مدى تأثيرها في الترتيب؟

مؤشرات Core Web Vitals جزء من إشارات تجربة الصفحة لدى Google. لكنها لا تتقدم على الملاءمة: الصفحة البطيئة ذات أفضل إجابة ستظل تتفوق على صفحة سريعة بإجابة ضعيفة. تبرز أهميتها بين الصفحات المتقاربة في الجودة، وقبل كل شيء في التحويل؛ فالزوار يغادرون الصفحات البطيئة والمهتزة مهما كان ترتيبها.

لهذا نعامل هذه المؤشرات كمقياس تجاري أولًا ثم كمقياس لتحسين الظهور. الصفحات الأسرع تبيع أكثر وتجلب استفسارات أكثر وتخفض تكلفة الزيارات المدفوعة.

البيانات الميدانية مقابل بيانات المختبر

تشغّل Lighthouse ونتائج المختبر في PageSpeed Insights زيارة محاكاة واحدة على جهاز مقيَّد السرعة. هي مفيدة لتتبع الأخطاء، لكن Google ترتّب وفق البيانات الميدانية من Chrome User Experience Report (CrUX)، المجمّعة من مستخدمي Chrome الحقيقيين خلال 28 يومًا.

ابدأ بتقرير Core Web Vitals في Search Console لترى أي مجموعات الروابط تفشل وفي أي مؤشر. ثم استخدم PageSpeed Insights لأرقام رابط محدد، ولوحة Performance في Chrome DevTools لإيجاد السبب.

إصلاح LCP

تأتي معظم مشكلات LCP من أربعة مصادر: استجابة خادم بطيئة، أو صورة رئيسية يكتشفها المتصفح متأخرًا، أو CSS وخطوط تعطل العرض، أو صورة ثقيلة جدًا ببساطة.

• اخفض Time to First Byte إلى أقل من نحو 800 مللي ثانية: تخزين مؤقت للصفحة كاملة للزوار المجهولين، وشبكة CDN، واستعلامات قاعدة بيانات سريعة.
• لا تستخدم التحميل الكسول لصورة LCP أبدًا. امنحها fetchpriority="high" وحمّلها مسبقًا إذا كانت محددة في CSS.
• قدّم صور AVIF أو WebP بالحجم المناسب مع srcset وsizes بدل ملف JPEG ضخم.
• ضمّن CSS الحرج داخل الصفحة وحمّل الباقي دون تعطيل، واستضف الخطوط بنفسك مع font-display: swap.

إصلاح INP

مشكلة INP هي في الغالب مشكلة JavaScript. عندما يكون الخيط الرئيسي مشغولًا بمهمة طويلة — أي مهمة تتجاوز 50 مللي ثانية — لا يستطيع المتصفح الاستجابة للمسة المستخدم حتى تنتهي.

راجع أولًا سكربتات الأطراف الثالثة: أدوات الدردشة والخرائط الحرارية واختبارات A/B وحاويات الوسوم المتعددة تضيف غالبًا مئات المللي ثانية. حمّلها بعد التفاعل أو في صفحات محددة فقط. وفي كودك، أبقِ معالجات الأحداث صغيرة، واستخدم التأخير (debounce) لمعالجات الإدخال، وقسّم العمل الطويل إلى أجزاء صغيرة ليتمكن المتصفح من الرسم بينها. كما يبطئ DOM الضخم (آلاف العناصر) كل تفاعل، وهو شائع مع أدوات بناء الصفحات.

// Let the browser paint between chunks of heavy work
async function processInChunks(items, handle) {
  for (const item of items) {
    handle(item);
    await new Promise((resolve) => setTimeout(resolve, 0));
  }
}

إصلاح CLS

• حدد دائمًا width وheight (أو aspect-ratio) للصور والفيديو وإطارات iframe.
• احجز مساحة للإعلانات والتضمينات ولافتات ملفات الارتباط بدل دفع المحتوى للأسفل عند تحميلها.
• تجنب إدراج لافتات أو تنبيهات فوق المحتوى الموجود بعد عرض الصفحة.
• استخدم خطوطًا احتياطية بمقاييس مطابقة (size-adjust) حتى لا يتحرك النص عند وصول خط الويب.

خصوصيات Laravel وWordPress

في Laravel، المكاسب السريعة هي ذاكرات الإنتاج المؤقتة (php artisan config:cache وroute:cache وview:cache) وOPcache وRedis للتخزين المؤقت والجلسات، والتحميل المسبق (eager loading) لإزالة استعلامات N+1 التي تبطئ البايت الأول. ابنِ الأصول باستخدام Vite لتصغير CSS وJavaScript وترقيم إصداراتها، وانقل الأعمال البطيئة كرسائل البريد واستدعاءات الواجهات البرمجية إلى الطوابير.

في WordPress، تأتي معظم المشكلات من الإضافات. احذف غير الضروري منها، واستخدم تخزينًا مؤقتًا جيدًا للصفحات (يعمل LiteSpeed Cache جيدًا على خوادم LiteSpeed)، وحسّن الصور عند رفعها، وأبقِ PHP على إصدار 8.x مدعوم، واحذر من أدوات بناء الصفحات الثقيلة.

قِس ثم انتظر

أضف مكتبة web-vitals مفتوحة المصدر لإرسال قيم LCP وINP وCLS الحقيقية إلى GA4 أو إلى نقطة استقبال خاصة بك، فترى التغييرات خلال أيام دون انتظار CrUX. يستخدم تقرير Search Console نافذة متحركة مدتها 28 يومًا، لذا يستغرق تحوّل الحالة إلى الأخضر نحو أربعة أسابيع بعد الإصلاح. تحقّق من الإصلاح هناك بعد وصول البيانات الجديدة.

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