Core Web Vitals: المقاييس التي تحدد ترتيبك في Google

53% من المستخدمين يتركون موقعاً إلكترونياً يستغرق أكثر من 3 ثوانٍ للتحميل. لكن Google ذهب أبعد من ذلك: منذ عام 2021، أصبحت Core Web Vitals عامل ترتيب رسمي في SEO.

أين المشكلة؟ 70% من المواقع الإلكترونية تفشل في هذه المقاييس الأساسية، وتفقد مراكز وتحويلات كل يوم.

في هذا الدليل التقني الشامل، ستتقن كل Core Web Vital، وتفهم كيفية قياسها بشكل صحيح، وتطبق تحسينات تحسن من SEO وتجربة المستخدم على حد سواء.

لماذا Core Web Vitals حاسمة لـ SEO الخاص بك

الأرقام التي تغير كل شيء

  • +32% تحويلات مع LCP أقل من 2.5 ثانية
  • -24% معدل الارتداد عبر تحسين CLS
  • +15% متوسط الترتيب مع Core Web Vitals جيدة
  • احتمالية أعلى بـ 2.5 مرة للظهور في المقتطفات المميزة
  • +40% وقت أكثر في الصفحة مع FID محسن

التأثير الحقيقي على عملك

حالة حقيقية - التجارة الإلكترونية:
قبل: LCP 4.2ث، CLS 0.25، FID 180مث
بعد: LCP 1.8ث، CLS 0.05، FID 45مث

النتائج:
• +67% تحويلات
• +23% مراكز متوسطة
• +45% صفحات لكل جلسة
• -38% معدل الارتداد
• عائد استثمار التحسين: 890%

الـ 3 Core Web Vitals: دليل تقني شامل

1. LCP (Largest Contentful Paint): سرعة التحميل المدركة

ماذا يقيس LCP حقاً؟

LCP يقيس الوقت المستغرق لتحميل أكبر عنصر مرئي في منطقة العرض الأولية. ليس التحميل الكامل للصفحة، بل متى يدرك المستخدم أن الصفحة جاهزة.

العناصر التي يحسبها LCP:
✅ الصور <img>
✅ عناصر <image> داخل SVG
✅ الفيديوهات (صورة البوستر)
✅ عناصر مع CSS background-image
✅ كتل النص

❌ لا يحسب:
❌ عناصر خارج منطقة العرض الأولية
❌ صور تتطلب تفاعل
❌ SVG مضمنة بدون <image>

عتبات LCP

🟢 جيد: ≤ 2.5 ثانية
🟡 يحتاج تحسين: 2.5ث - 4.0ث
🔴 ضعيف: > 4.0 ثانية

الهدف الأمثل: < 1.5 ثانية

التحسين التقني لـ LCP

المرحلة 1: تحديد عنصر LCP

// سكريبت لتحديد عنصر LCP
new PerformanceObserver((entryList) => {
  for (const entry of entryList.getEntries()) {
    console.log('LCP candidate:', entry.element, entry.startTime);
  }
}).observe({type: 'largest-contentful-paint', buffered: true});

المرحلة 2: تحسينات حسب نوع العنصر

إذا كان LCP صورة:
1. تحسين التنسيق (WebP/AVIF)
2. تطبيق التحميل الكسول الصحيح
3. التحميل المسبق الحاسم: <link rel="preload" as="image">
4. CDN + ضغط
5. صور متجاوبة مع srcset

إذا كان LCP نص:
1. تحسين الخطوط (preload, display: swap)
2. تقليل CSS الحاسم
3. إزالة موارد حجب العرض
4. CSS حاسم مضمن
5. تأجيل CSS غير حاسم

المرحلة 3: تقنيات متقدمة

<!-- التحميل المسبق للموارد الحاسمة -->
<link rel="preload" as="image" href="/hero-image.webp" fetchpriority="high">
<link rel="preload" as="font" href="/fonts/main.woff2" type="font/woff2" crossorigin>

<!-- تحسين الصور الحاسمة -->
<img src="/hero.webp" 
     fetchpriority="high"
     decoding="async"
     width="800" 
     height="600"
     alt="وصف محسن">

<!-- CSS حاسم مضمن -->
<style>
  /* CSS حاسم لعنصر LCP */
  .hero { display: block; width: 100%; height: auto; }
</style>

2. FID (First Input Delay): التفاعلية الحقيقية

ماذا يقيس FID؟

FID يقيس الوقت من أول تفاعل للمستخدم (نقرة، لمسة، ضغطة مفتاح) حتى يتمكن المتصفح من الاستجابة. إنه مقياس التفاعلية الحقيقية.

التفاعلات التي يحسبها FID:
✅ النقرات على الروابط/الأزرار
✅ اللمسات على عناصر اللمس
✅ ضغط المفاتيح في حقول الإدخال
✅ مستمعي الأحداث المخصصة

❌ لا يحسب:
❌ التمرير
❌ التكبير
❌ التمرير الفوقي (بدون نقرة)

عتبات FID

🟢 جيد: ≤ 100 مللي ثانية
🟡 يحتاج تحسين: 100مث - 300مث
🔴 ضعيف: > 300 مللي ثانية

الهدف الأمثل: < 50مث

التحسين التقني لـ FID

المرحلة 1: تحديد انسدادات الخيط الرئيسي

// قياس FID الحقيقي
new PerformanceObserver((entryList) => {
  for (const entry of entryList.getEntries()) {
    const FID = entry.processingStart - entry.startTime;
    console.log('FID:', FID);
  }
}).observe({type: 'first-input', buffered: true});

المرحلة 2: تحسين JavaScript

التقنيات الرئيسية:
1. تقسيم الكود حسب المسارات
2. التحميل الكسول للمكونات غير الحاسمة
3. Web Workers للمهام الثقيلة
4. Debounce/throttle في مستمعي الأحداث
5. RequestIdleCallback للمهام غير العاجلة

تحسين التجميع:
• فصل vendor chunks
• استيرادات ديناميكية
• Tree shaking قوي
• ضغط متقدم
• ضغط Gzip/Brotli

المرحلة 3: التنفيذ العملي

// تقسيم الكود مع الاستيرادات الديناميكية
const loadHeavyComponent = async () => {
  const { HeavyComponent } = await import('./HeavyComponent');
  return HeavyComponent;
};

// Web Worker للحسابات الثقيلة
const worker = new Worker('heavy-calculations.js');
worker.postMessage({data: heavyData});

// RequestIdleCallback للمهام غير الحاسمة
requestIdleCallback(() => {
  // التحليلات، التتبع، إلخ.
  initializeNonCriticalFeatures();
});

// تفويض الأحداث لأداء أفضل
document.addEventListener('click', (e) => {
  if (e.target.matches('.button')) {
    // التعامل مع النقرة بكفاءة
  }
});

3. CLS (Cumulative Layout Shift): الاستقرار البصري

ماذا يقيس CLS؟

CLS يقيس الاستقرار البصري لصفحتك. يحدد كمية حركة العناصر المرئية أثناء التحميل، مما يخلق تجربة محبطة للمستخدم.

الأسباب الرئيسية لـ CLS:
• صور بدون أبعاد
• إعلانات يتم إدراجها ديناميكياً
• خطوط تتغير أثناء التحميل
• محتوى ديناميكي بدون عناصر نائبة
• عناصر CSS بدون ارتفاع محدد

عتبات CLS

🟢 جيد: ≤ 0.1
🟡 يحتاج تحسين: 0.1 - 0.25
🔴 ضعيف: > 0.25

الهدف الأمثل: < 0.05

الحساب التقني لـ CLS

// معادلة CLS
CLS = كسر التأثير × كسر المسافة

// المراقبة في الوقت الفعلي
new PerformanceObserver((entryList) => {
  for (const entry of entryList.getEntries()) {
    if (!entry.hadRecentInput) {
      console.log('Layout shift:', entry.value);
    }
  }
}).observe({type: 'layout-shift', buffered: true});

التحسين التقني لـ CLS

المرحلة 1: عناصر الوسائط المتعددة

<!-- ❌ يسبب CLS -->
<img src="image.jpg" alt="وصف">

<!-- ✅ يمنع CLS -->
<img src="image.jpg" 
     alt="وصف"
     width="800" 
     height="600"
     style="aspect-ratio: 800/600;">

<!-- ✅ مع CSS حديث -->
<style>
  .image-container {
    aspect-ratio: 16/9;
    background: #f0f0f0;
  }
  
  .image-container img {
    width: 100%;
    height: 100%;
    object-fit: cover;
  }
</style>

المرحلة 2: المحتوى الديناميكي

/* عنصر نائب للإعلانات */
.ad-container {
  min-height: 250px;
  background: linear-gradient(90deg, #f0f0f0 25%, transparent 37%, #f0f0f0 63%);
  background-size: 400% 100%;
  animation: loading 1.5s ease-in-out infinite;
}

/* شاشات الهيكل العظمي */
.skeleton {
  background: linear-gradient(90deg, #f0f0f0 25%, #e0e0e0 37%, #f0f0f0 63%);
  background-size: 400% 100%;
  animation: skeleton-loading 1.5s ease-in-out infinite;
}

@keyframes skeleton-loading {
  0% { background-position: 100% 0; }
  100% { background-position: -100% 0; }
}

المرحلة 3: تحسين الخطوط

/* منع انزياحات التخطيط مع الخطوط */
@font-face {
  font-family: 'CustomFont';
  src: url('custom-font.woff2') format('woff2');
  font-display: fallback; /* أو swap بحذر */
}

body {
  font-family: 'CustomFont', 'Arial', sans-serif;
  /* خط احتياطي مشابه في المقاييس */
}

/* Size-adjust لمطابقة الخطوط الاحتياطية */
@font-face {
  font-family: 'CustomFont-fallback';
  src: local('Arial');
  size-adjust: 95%;
  ascent-override: 95%;
  descent-override: 25%;
  line-gap-override: 0%;
}

أدوات القياس المهنية

1. Google PageSpeed Insights (PSI)

المزايا:
• بيانات المستخدمين الحقيقية (CrUX)
• بيانات المختبر (Lighthouse)
• تشخيصات محددة
• اقتراحات التحسين

القيود:
• URL عامة فقط
• لقطة في الوقت
• لا تتبع مستمر

الاستخدام المهني لـ PSI:

# API للأتمتة
curl "https://www.googleapis.com/pagespeed/insights/v5/runPagespeed?url=https://example.com&key=YOUR_API_KEY&category=performance"

# معاملات متقدمة
&strategy=mobile          # أو desktop
&category=performance     # أو accessibility, seo, pwa
&locale=ar               # لغة التقرير

2. Chrome DevTools (تبويب الأداء)

سير العمل المهني:
1. فتح DevTools → Performance
2. تكوين الشروط:
   • CPU: إبطاء 4x
   • الشبكة: Fast 3G
   • مسح التخزين المؤقت
3. تسجيل التفاعل الحقيقي
4. تحليل الخط الزمني:
   • First Paint (FP)
   • First Contentful Paint (FCP)
   • Largest Contentful Paint (LCP)
   • Layout shifts

3. امتداد Web Vitals

التثبيت:
Chrome Web Store → "Web Vitals"

الخصائص:
• قياس في الوقت الفعلي
• طبقة على الصفحة
• تاريخ المقاييس
• مقارنة زمنية

4. Search Console (تقرير Core Web Vitals)

المزايا الفريدة:
• بيانات المستخدمين الحقيقية
• تجميع حسب نوع الصفحة
• اتجاهات زمنية
• مشاكل محددة لكل URL

التفسير:
• URLs ضعيفة: > 25% مستخدمين تجربة ضعيفة
• URLs تحتاج تحسين: تجربة مختلطة
• URLs جيدة: > 75% مستخدمين تجربة جيدة

تقنيات التحسين المتقدمة

1. تحسين المسار الحاسم

<!-- CSS حاسم مضمن -->
<style>
  /* أنماط فوق الطية فقط */
  .header, .hero, .main-content { /* أنماط حاسمة */ }
</style>

<!-- CSS غير حاسم مؤجل -->
<link rel="preload" href="/styles/non-critical.css" as="style" onload="this.onload=null;this.rel='stylesheet'">
<noscript><link rel="stylesheet" href="/styles/non-critical.css"></noscript>

2. تلميحات الموارد الاستراتيجية

<!-- DNS prefetch للنطاقات الخارجية -->
<link rel="dns-prefetch" href="//fonts.googleapis.com">
<link rel="dns-prefetch" href="//www.google-analytics.com">

<!-- Preconnect للموارد الحاسمة -->
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>

<!-- Prefetch للتنقل المستقبلي -->
<link rel="prefetch" href="/next-page.html">

<!-- Preload للموارد الحاسمة -->
<link rel="preload" href="/critical-image.webp" as="image">
<link rel="preload" href="/main.js" as="script">

3. تحسين الصور المتقدم

<!-- صور متجاوبة محسنة -->
<picture>
  <source media="(min-width: 800px)" 
          srcset="/large.avif 1x, /large-2x.avif 2x" 
          type="image/avif">
  <source media="(min-width: 800px)" 
          srcset="/large.webp 1x, /large-2x.webp 2x" 
          type="image/webp">
  <source media="(min-width: 400px)" 
          srcset="/medium.avif 1x, /medium-2x.avif 2x" 
          type="image/avif">
  <source media="(min-width: 400px)" 
          srcset="/medium.webp 1x, /medium-2x.webp 2x" 
          type="image/webp">
  <img src="/medium.jpg" 
       alt="وصف محسن"
       width="800" 
       height="600"
       loading="lazy"
       decoding="async">
</picture>

4. Service Worker للأداء

// service-worker.js
const CACHE_NAME = 'v1';
const CRITICAL_RESOURCES = [
  '/',
  '/styles/critical.css',
  '/js/main.js',
  '/images/hero.webp'
];

// تخزين مسبق للموارد الحاسمة
self.addEventListener('install', event => {
  event.waitUntil(
    caches.open(CACHE_NAME)
      .then(cache => cache.addAll(CRITICAL_RESOURCES))
  );
});

// استراتيجية Cache First للأصول
self.addEventListener('fetch', event => {
  if (event.request.destination === 'image') {
    event.respondWith(
      caches.match(event.request)
        .then(response => response || fetch(event.request))
    );
  }
});

الأخطاء الحاسمة التي يجب تجنبها

الأخطاء الـ 10 الأكثر تكلفة

  1. القياس في المختبر فقط (-30% دقة)

    ❌ استخدام Lighthouse فقط
    ✅ دمج بيانات المختبر + بيانات الحقل (RUM)
    
  2. عدم تحديد أبعاد الصور (+0.15 CLS)

    ❌ <img src="image.jpg" alt="desc">
    ✅ <img src="image.jpg" width="800" height="600" alt="desc">
    
  3. تحميل JavaScript متزامن (+200مث FID)

    ❌ <script src="heavy.js"></script>
    ✅ <script src="heavy.js" defer></script>
    
  4. تحميل خطوط غير محسن (+0.2 CLS، +800مث LCP)

    @import url('https://fonts.googleapis.com/css?family=Font');
    ✅ <link rel="preconnect" href="https://fonts.gstatic.com">
        <link rel="preload" href="font.woff2" as="font" crossorigin>
    
  5. سكريبتات طرف ثالث بدون تحكم (+500مث FID)

    ❌ تحميل جميع السكريبتات في <head>
    ✅ تحميل كسول، async، و defer استراتيجي
    
  6. CSS حاجب للعرض (+1ث LCP)

    ❌ <link rel="stylesheet" href="all-styles.css">
    ✅ CSS حاسم مضمن + preload الباقي
    
  7. صور غير محسنة (+2ث LCP)

    ❌ JPEG 2MB بدون ضغط
    ✅ WebP/AVIF + ضغط + متجاوب
    
  8. عدم استخدام CDN (+40% LCP)

    ❌ تقديم الأصول من المصدر
    ✅ CDN عالمي + HTTP/2 + Brotli
    
  9. إعلانات بدون عناصر نائبة (+0.25 CLS)

    ❌ إدراج ديناميكي بدون حجز مساحة
    ✅ حاويات ثابتة + تحميل كسول
    
  10. عدم المراقبة المستمرة (-50% تحسين)

    ❌ تحسين مرة واحدة والنسيان
    ✅ RUM + تنبيهات + تحسين مستمر
    

خريطة طريق التنفيذ

الأسبوع 1: التشخيص والإعداد

اليوم 1-2: مراجعة شاملة
□ PageSpeed Insights (موبايل + سطح مكتب)
□ تحليل Chrome DevTools
□ مراجعة Search Console
□ تحديد عناصر LCP

اليوم 3-4: إعداد المراقبة
□ تثبيت امتداد Web Vitals
□ تنفيذ RUM
□ تحديد ميزانية الأداء
□ توثيق مقاييس الأساس

اليوم 5-7: التخطيط
□ ترتيب التحسينات حسب التأثير
□ الموارد المطلوبة
□ جدول زمني واقعي
□ تحديد مقاييس النجاح

الأسبوع 2-3: المكاسب السريعة

تحسينات سريعة:
□ إضافة أبعاد الصور
□ JavaScript defer/async
□ CSS حاسم مضمن
□ تنفيذ preload الخطوط
□ ضغط الصور إلى WebP

التحقق:
□ اختبار في التطوير
□ مقارنة قبل/بعد
□ اختبار متعدد الأجهزة
□ قياس تأثير الأداء

الأسبوع 4-6: تحسينات متقدمة

تقنيات متقدمة:
□ تنفيذ تقسيم الكود
□ تخزين Service worker
□ تحسين الصور المتقدم
□ تحسين سكريبتات طرف ثالث
□ تنفيذ CDN

المراقبة:
□ مراجعات أداء أسبوعية
□ ارتباط تجربة المستخدم
□ تأثير مقاييس الأعمال
□ تحسين مستمر

الخاتمة: Core Web Vitals كميزة تنافسية

Core Web Vitals ليست مجرد مقاييس تقنية مجردة. إنها مؤشرات مباشرة للتجربة التي تقدمها لمستخدميك وبالتالي عوامل حاسمة لنجاحك على الإنترنت.

واقع السوق:

  • 90% من المواقع تتجاهل هذه المقاييس
  • Google يستخدمها أكثر فأكثر للترتيب
  • المستخدمون يكافئون السرعة بالتحويلات
  • التحسين التقني له عائد استثمار قابل للقياس

ميزتك التنافسية تكمن في:

  1. القياس الصحيح (بيانات المختبر + بيانات الحقل)
  2. التحسين المنهجي (تقني + تجربة مستخدم)
  3. المراقبة المستمرة (RUM + تنبيهات)
  4. التكرار المبني على البيانات (اختبار A/B + مقاييس)

الفرق بين موقع سريع وموقع بطيء ليس تقنياً فقط. إنه الفرق بين عمل ينمو وعمل يتوقف في عصر الانتباه المحدود.

خطوتك التالية؟ نفذ تشخيص الأسبوع 1 اليوم. قس، حسن، قس مرة أخرى. Core Web Vitals المحسنة هي تذكرتك للدخول إلى أفضل 10% من المواقع التي يكافئها Google والمستخدمون حقاً.


تذكر: Core Web Vitals مقاييس متطورة. Google يحدثها ويحسنها باستمرار، لذا يجب أن يكون تحسينك عملية مستمرة، وليس مهمة لمرة واحدة. ركز أولاً على الحصول على درجات “جيدة” في المقاييس الثلاثة كلها قبل السعي للكمال في واحد فقط. التأثير الأكبر يأتي من التحسين المتوازن لـ LCP و FID و CLS معاً، وليس من تحسين مقياس واحد على حساب الآخرين.