Seovix مقدمة
ما هي Core Web Vitals ولماذا تُهمّك؟
في مايو 2021، أطلق جوجل تحديثاً جوهرياً أعاد تشكيل قواعد لعبة SEO — تحديث Page Experience. منذ ذلك الحين، أصبحت مقاييس Core Web Vitals عاملاً رسمياً في خوارزمية الترتيب، وليست مجرد توصيات اختيارية.
Core Web Vitals هي مجموعة من المقاييس التي طوّرها جوجل لقياس جودة تجربة المستخدم على موقعك. تركّز على ثلاثة جوانب: سرعة التحميل، الاستجابة للتفاعل، واستقرار التخطيط البصري.
70%
من المستخدمين يغادرون الموقع البطيء قبل 5 ثوانٍ
24%
زيادة في التحويلات عند تحسين Core Web Vitals
3X
أعلى احتمالية للتصدر عند الوصول للدرجات الجيدة
هل تعلم؟
وفقاً لأبحاث جوجل، الصفحات التي تحقق درجات "جيدة" في Core Web Vitals تشهد معدل مغادرة أقل بنسبة 24% مقارنةً بالصفحات الضعيفة.
75%
LCP
أقل من 2.5 ثانية
70%
INP
أقل من 200ms
60%
CLS
أقل من 0.1
80%
TTFB
أقل من 800ms
كيف يستخدم جوجل هذه المقاييس في الترتيب؟
لا يعني تحقيق درجة 90+ في PageSpeed أنك ستتصدر تلقائياً — Core Web Vitals هي عامل ترجيح وليست العامل الوحيد. جوجل يستخدم Field Data (البيانات الحقيقية من متصفح Chrome) وليس Lab Data المصطنعة. إذا لم يكن لموقعك بيانات CrUX كافية (عادةً تحتاج لأكثر من 1000 زيارة شهرياً)، لن تظهر بياناته في Search Console.
عوامل Page Experience الكاملة
Core Web Vitals ليست وحدها — هي جزء من منظومة Page Experience الأشمل:
HTTPS
الموقع يجب أن يعمل على اتصال آمن SSL.
Mobile-Friendly
تصميم متجاوب يعمل بشكل مثالي على الجوال.
بدون Intrusive Interstitials
لا نوافذ منبثقة تحجب المحتوى الرئيسي.
Core Web Vitals
LCP + INP + CLS تحقق الحدود الخضراء.
التاريخ
تطور Core Web Vitals عبر السنوات
لم تأتِ Core Web Vitals دفعة واحدة — تطوّرت تدريجياً مع فهم جوجل المتعمق لتجربة المستخدم. معرفة هذا التاريخ يساعدك على فهم لماذا هذه المقاييس بالذات وليس غيرها.
مايو 2020
الإعلان الرسمي عن Core Web Vitals
أعلن جوجل لأول مرة عن المقاييس الثلاثة: LCP وFID وCLS كمقاييس أساسية لقياس تجربة المستخدم.
مايو 2021
تحديث Page Experience
أصبحت Core Web Vitals عاملاً رسمياً في الترتيب. بدأ التطبيق تدريجياً على الجوال أولاً ثم امتد للـ Desktop.
فبراير 2022
الإعلان عن استبدال FID بـ INP
أعلن جوجل أن INP سيحل محل FID كمقياس أفضل وأشمل لقياس استجابية التفاعل.
مارس 2024
INP يصبح مقياساً رسمياً
انتهى دور FID رسمياً. INP أصبح المقياس الثالث في Core Web Vitals بجانب LCP وCLS.
2025 وما بعده
المستقبل: مقاييس جديدة على الأفق
يبحث جوجل في مقاييس جديدة مثل Smoothness وResponsiveness. المتوقع أن تُضاف تدريجياً خلال السنوات القادمة.
المقياس الأول
LCP — Largest Contentful Paint
يقيس LCP الوقت الذي يستغرقه أكبر عنصر مرئي في الصفحة للظهور أمام المستخدم. قد يكون هذا العنصر صورة رئيسية، فيديو، أو كتلة نصية كبيرة. يمثّل LCP ما يراه المستخدم أولاً حين يفتح الصفحة — لذا تأثيره على الانطباع الأول ضخم جداً.
Largest Contentful Paint
وقت ظهور أكبر عنصر مرئي في الصفحة
يُحسب LCP من لحظة بدء التنقل إلى الصفحة حتى يُرسَم العنصر الأكبر على الشاشة. يعكس هذا المقياس مدى سرعة تحمّل المستخدم لمحتوى الصفحة الرئيسي.
≤ 2.5 ث
جيد
2.5 – 4 ث
يحتاج تحسين
> 4 ث
ضعيف
ما الذي يقيسه LCP بالضبط؟
الصور: سواء في عنصر img أو SVG أو كخلفية CSS بشرط أن تُحمَّل عبر CSS image().
الفيديو: الإطار الأول من الفيديو إذا كان العنصر video موجوداً في الجزء المرئي.
كتل النص: أي عنصر block-level يحتوي نصاً كبيراً — عناوين H1 وH2 أو فقرات.
بطاقات Hero: القسم البارز أعلى الصفحة (Above the fold) الذي يظهر فور التحميل.
أبرز أسباب ضعف LCP وكيف تُصلحها
1
تحسين الخادم وتقليل TTFB
استخدم CDN لتوزيع المحتوى جغرافياً، فعّل HTTP/2 أو HTTP/3، واضبط Cache-Control headers. TTFB أعلى من 600ms يرفع LCP بشكل مباشر.
2
إزالة موارد تعيق الرسم (Render-Blocking)
ضع Critical CSS مباشرةً في الـ head، أخّر JavaScript غير الضروري بـ defer أو async، وأخّر CSS غير الحيوي.
3
تحسين الصور بالصيغ الحديثة
حوّل صورك إلى WebP أو AVIF (توفير 30-50%)، أضف fetchpriority="high" لصورة LCP، استخدم srcset لصور Responsive.
4
Preload موارد LCP المهمة
أضف في الـ head: link rel="preload" as="image" لضمان تحميل صورة LCP أولاً قبل معالجة باقي الموارد.
5
تقليل JavaScript الزائد
احذف المكتبات غير المستخدمة، فعّل Tree Shaking، وافصل الكود إلى chunks صغيرة (Code Splitting).
تأثير كل عامل على LCP
المكوّنات الفرعية لـ LCP — تشخيص دقيق
قدّم جوجل في 2023 مفهوم LCP Subparts لمساعدة المطورين على تحديد أين بالضبط يضيع الوقت. يتقسّم LCP إلى أربعة أجزاء:
| الجزء | التعريف | الهدف | أبرز الحلول |
|---|---|---|---|
| Time to First Byte (TTFB) | وقت استجابة الخادم | < 600ms | CDN، تحسين الخادم |
| Resource Load Delay | تأخير اكتشاف مورد LCP | < 200ms | Preload، إزالة Render-Blocking |
| Resource Load Duration | وقت تحميل المورد نفسه | < 200ms | ضغط الصور، WebP/AVIF |
| Element Render Delay | تأخير رسم العنصر بعد التحميل | < 50ms | تقليل JavaScript، Main Thread |
المقياس الثاني
INP — Interaction to Next Paint
في مارس 2024، استبدل جوجل رسمياً مقياس FID بـ INP كمقياس أساسي. INP أشمل وأدق — إذ يقيس أبطأ تفاعل بين المستخدم والصفحة طوال فترة زيارته.
Interaction to Next Paint (INP)
استجابة الصفحة لتفاعلات المستخدم — خلف FID منذ مارس 2024
يرصد INP كل تفاعل (نقر، لمس، كتابة) ويقيس الوقت حتى يظهر التغيير البصري. يأخذ القيمة في النسبة المئوية الـ 98 من جميع التفاعلات.
≤ 200ms
جيد
200–500ms
يحتاج تحسين
> 500ms
ضعيف
FID (القديم)
يقيس أول تفاعل فقط
يتجاهل التفاعلات اللاحقة
لا يقيس وقت الرسم البصري
صورة غير مكتملة للاستجابية
INP (الجديد)
يقيس جميع التفاعلات
يأخذ أسوأ سيناريو (P98)
يشمل وقت الرسم البصري
صورة واقعية وشاملة
كيف تُحسّن INP؟
تقليل Long Tasks: أي مهمة JavaScript تستمر أكثر من 50ms تحجب الـ Main Thread. قسّمها باستخدام setTimeout أو scheduler.yield().
نقل المهام للـ Web Workers: أي حسابات ثقيلة انقلها إلى Thread منفصل لا يؤثر على واجهة المستخدم.
تقليل سكريبتات الطرف الثالث: Google Analytics، Facebook Pixel، Hotjar — راجعها وأخّر غير الضروري منها.
تحسين Input Handlers: تجنب عمليات ثقيلة داخل onClick أو onChange. استخدم Debouncing/Throttling.
تقليل DOM Size: DOM ضخم يُبطئ كل تحديث. استهدف أقل من 1,500 عنصر. استخدم Virtualization للقوائم الطويلة.
تنبيه مهم عن FID مقابل INP
إذا كان موقعك يسجّل FID ممتازاً لكن INP ضعيفاً، هذا شائع جداً — خاصة في مواقع التجارة الإلكترونية. INP يكشف مشاكل خفية لم يكشفها FID.
تشريح INP: من أين يأتي التأخير؟
يتكون INP من ثلاثة أجزاء رئيسية. فهمها يساعدك على تحديد مكان المشكلة بدقة:
1
Input Delay — تأخير المدخلات
الوقت من لحظة النقر/اللمس حتى يبدأ الـ Event Handler بالتنفيذ. السبب الرئيسي: Long Tasks أخرى تشغل الـ Main Thread. الحل: تقليل مهام JavaScript الطويلة.
2
Processing Time — وقت المعالجة
الوقت الذي يستغرقه Event Handler لإنهاء تنفيذه. إذا كان handler يحتوي منطقاً معقداً أو DOM manipulation كبيرة — هنا يكمن البطء.
3
Presentation Delay — تأخير العرض
الوقت من انتهاء المعالجة حتى يُرسم الإطار التالي على الشاشة. قد يتأثر بـ Layout/Paint/Composite. استخدم requestAnimationFrame لتحسينه.
المقياس الثالث
CLS — Cumulative Layout Shift
يقيس CLS مقدار الاضطراب البصري الذي تسببه عناصر الصفحة عند تحميلها. إذا لاحظت يوماً أنك كنت ستنقر على زر فانزلق فجأة لأسفل — هذا بالضبط ما يقيسه CLS.
Cumulative Layout Shift
مجموع الاضطرابات البصرية غير المتوقعة أثناء التحميل
يحسب CLS مجموع درجات تحوّل التخطيط لكل عنصر يتحرك بشكل غير متوقع. الصيغة: Impact Fraction × Distance Fraction. كلما انخفض الرقم، كانت التجربة أفضل.
≤ 0.1
جيد
0.1 – 0.25
يحتاج تحسين
> 0.25
ضعيف
أبرز أسباب CLS المرتفع والحلول
صور بدون أبعاد محددة: أضف دائماً width وheight لعناصر img. استخدم CSS aspect-ratio كبديل مرن.
إعلانات بدون حجز مساحة: احجز مساحة ثابتة لحاوية الإعلان. استخدم min-height على الحاوية.
تغيّر الخطوط (Font Swap): استخدم font-display: optional بدلاً من swap. أو preload الخطوط الحيوية.
حقن محتوى ديناميكي: البانرات التي تظهر أعلى الصفحة تدفع المحتوى لأسفل. استخدم transform للرسوم المتحركة.
Skeleton Loading: استبدل الفراغات بـ Skeleton Screens تحتل نفس المساحة النهائية للمحتوى الحقيقي.
تحديث CLS 2024: Sessionized
عدّل جوجل طريقة حساب CLS في 2024. لم يعد يحسب كل التحولات مجتمعة، بل يُقسّمها إلى نوافذ جلسات ويأخذ أعلى نافذة. هذا أفاد المواقع ذات التفاعلات الديناميكية كالـ SPA.
الفرق بين Layout Shift المقبول وغير المقبول
لا تُعامل كل حركة في الصفحة كأنها CLS مشكلة. جوجل يُفرّق بين نوعين:
يُحتسب في CLS (مشكلة)
صورة تحمّلت وتدفع النص للأسفل
إعلان يظهر فجأة في منتصف الصفحة
خط يُحمّل ويُغيّر حجم الكلمات
عنصر يتحرك دون إجراء مستخدم
لا يُحتسب في CLS (مقبول)
Animation بعد نقر المستخدم
Transition باستخدام transform/opacity
Scroll ناعم أو انتقال بين صفحات
عناصر تتحرك داخل viewport مخصص
الأدوات
أفضل الأدوات لقياس Core Web Vitals
قبل أن تبدأ التحسين، تحتاج لقياس دقيق. هناك نوعان: Lab Data (بيانات اصطناعية في بيئة محكومة) وField Data (بيانات حقيقية من مستخدميك). جوجل يستخدم Field Data للترتيب.
Google PageSpeed Insights
أهم أداة. تجمع Lab Data (Lighthouse) وField Data (CrUX). درجة من 100 مع توصيات مفصّلة.
فتح الأداة
Google Search Console
تقرير Core Web Vitals يُظهر حالة صفحاتك كـ Good/Need Improvement/Poor بناءً على Field Data الحقيقي.
فتح الأداة
Seovix Speed Test
أداة فحص السرعة العربية من Seovix — تقرير مفصّل بالعربية مع توصيات قابلة للتطبيق مباشرة.
فتح الأداة
Chrome DevTools Performance
الغوص العميق. سجّل أداء الصفحة وحلّل كل مهمة JavaScript وكل Layout Shift بدقة millisecond.
الدليل الرسمي
WebPageTest
اختبار من مواقع جغرافية متعددة وأجهزة حقيقية، مع شريط فيلم مرئي يُظهر كيف تُبنى الصفحة ثانية بثانية.
فتح الأداة
GTmetrix
واجهة سهلة مع تقارير مرئية مفصّلة وتتبع التحسينات عبر الزمن. مفيد للمقارنة قبل وبعد أي تعديل.
فتح الأداة
| الأداة | نوع البيانات | LCP | INP | CLS | مجاني |
|---|---|---|---|---|---|
| PageSpeed Insights | Lab + Field | نعم | نعم | نعم | مجاني |
| Search Console | Field فقط | نعم | نعم | نعم | مجاني |
| Seovix Speed Test | Lab + تقرير | نعم | نعم | نعم | مجاني |
| WebPageTest | Lab متقدم | نعم | نعم | نعم | محدود |
| GTmetrix | Lab | نعم | جزئي | نعم | محدود |
كيف تقرأ تقرير PageSpeed Insights بذكاء؟
كثير من أصحاب المواقع يفتحون PageSpeed ويُركّزون على الرقم الكبير فقط. هذا خطأ شائع. إليك ما يجب أن تركّز عليه:
1
ابدأ بقسم "بيانات الحقل" (Field Data)
هذا ما يراه جوجل فعلاً. إذا لم تظهر هذه البيانات، موقعك لم يجمع بعد حركة مرور كافية في Chrome UX Report.
2
راجع قسم "الفرص" (Opportunities)
مُرتّبة تلقائياً حسب الأثر. الفرصة في الأعلى = أكبر تأثير. ابدأ منها دائماً لأعلى عائد على جهدك.
3
لا تتجاهل قسم "التشخيصات" (Diagnostics)
يكشف مشاكل لا تظهر في الفرص كحجم DOM الضخم وعدد الطلبات الكثيرة وCache Policy الضعيف.
4
قيّم الجوال والـ Desktop بشكل منفصل
جوجل يستخدم بيانات الجوال للترتيب. درجة الـ Desktop قد تكون 95 بينما الجوال 40 — ركّز على الجوال أولاً.
الاستراتيجية
استراتيجية الوصول إلى الدرجة 90+ خطوة بخطوة
الوصول للدرجة 90+ في PageSpeed ليس حظاً — إنه نتيجة تطبيق منهجي ومنظّم. إليك الخارطة الكاملة:
1
افحص الوضع الحالي وحدد الأولويات
شغّل PageSpeed Insights على أهم 5 صفحات. لاحظ المقاييس الأسوأ وابدأ منها. الـ Opportunities مرتبة حسب الأثر — ابدأ من الأعلى.
2
حسّن الخادم والاستضافة أولاً
إذا كان TTFB أعلى من 600ms، فلا يمكن لأي تحسين آخر أن يعوّض ذلك. انتقل لاستضافة SSD سريعة، فعّل Redis/Memcached، وفعّل Gzip أو Brotli.
3
أضف CDN لتوزيع المحتوى
Cloudflare (مجاني ومتميز) أو BunnyCDN أو CloudFront. الـ CDN يقرّب ملفاتك من المستخدم جغرافياً ويوفر 200-400ms إضافية.
4
تحسين الصور بشكل شامل
أضف width/height لكل صورة. حوّل للـ WebP/AVIF. استخدم srcset. أضف loading="lazy" لكل شيء خارج الـ viewport. Preload صورة LCP الرئيسية.
5
أزل JavaScript والـ CSS الزائد
استخدم Chrome Coverage tool لاكتشاف الكود غير المستخدم. أخّر الـ JavaScript غير الحيوي بـ defer. استخرج Critical CSS وضعه inline.
6
تحسين الخطوط وتجنب FOUT
استضف الخطوط على نفس الخادم. أضف font-display: optional. Preload الخط الرئيسي. قلّل عدد الخطوط والأوزان المستخدمة.
7
معالجة سكريبتات الطرف الثالث
Google Analytics، Facebook Pixel، Hotjar — استخدم Google Tag Manager بشكل صحيح، أخّر تحميلها بعد التفاعل الأول (Facade Pattern).
8
قيّس وراقب باستمرار
اضبط تنبيهات في Search Console. شغّل PageSpeed أسبوعياً. Core Web Vitals لا تُحسَّن مرة واحدة — كل تحديث للموقع قد يؤثر عليها.
أخطاء شائعة تحول دون وصولك للدرجة 90+
الاعتماد فقط على درجة Desktop: جوجل يُرتّب بناءً على الجوال. حقّق 90+ على الجوال أولاً حتى لو كان Desktop 60.
اختبار الصفحة الرئيسية فقط: كل صفحة منفردة لها درجتها. اختبر صفحات المنتجات والمدونة والتصنيفات.
تركيب إضافات متعددة للـ Caching: تعارض إضافات التخزين المؤقت يُضاعف المشاكل بدل حلّها.
تحسين Lab Data وإهمال Field Data: درجة 95 في PageSpeed Lab لا تعني شيئاً إذا كان مستخدموك الحقيقيون يعانون.
تحسين مرة واحدة والنسيان: كل تحديث WordPress، إضافة جديدة، أو صورة ضخمة قد يُعيدك للنقطة الصفر.
"المواقع التي تستثمر في تجربة المستخدم لا تفوز فقط في ترتيبات جوجل — بل تفوز في معدلات التحويل والاحتفاظ بالزوار. Core Web Vitals ليست عن إرضاء الخوارزمية، بل عن بناء موقع يستحق الترتيب الأول."
فريق Seovix — دليل تحسين الأداء 2025
WordPress
تحسين Core Web Vitals على WordPress
WordPress يُشغّل أكثر من 43% من مواقع الإنترنت. لحسن الحظ، لديه بيئة غنية من الإضافات تُسهّل تحسين Core Web Vitals دون الحاجة لتعديل الكود يدوياً.
WP Rocket: أفضل إضافة أداء مدفوعة. تُحسّن تلقائياً الـ Caching وضغط CSS/JS وتأجيل التحميل وLazyLoad وعشرات الإعدادات الأخرى.
Imagify / ShortPixel: تحويل تلقائي للـ WebP وضغط الصور عند رفعها. تتكاملان مع WP Rocket لنتائج أفضل.
LiteSpeed Cache: مجانية ومتكاملة مع خوادم LiteSpeed. ميزاتها بمستوى إضافات مدفوعة وهي الأفضل على الاستضافات التي تدعم LiteSpeed.
Autoptimize: مجانية لتحسين CSS/JS/HTML. مفيدة كإضافة مساعدة لكنها أقل شمولاً من WP Rocket.
Cloudflare (مجاني): CDN عالمي، ضغط Brotli تلقائي، Caching متقدم، وحماية. أضف موقعك لـ Cloudflare أولاً قبل أي إضافة.
اختر قالباً سريعاً: GeneratePress وAstra وKadence خفيفة بدون code bloat. تجنب قوالب Page Builders الثقيلة مع تحميل كامل خياراتها.
أكبر أخطاء WordPress تُدمّر Core Web Vitals
تفعيل أكثر من إضافة caching في نفس الوقت، استخدام قالب ثقيل مع Elementor بدون تحسين، وتثبيت إضافات "كل في واحد" ضخمة يُحمّل كل كودها على كل صفحة.
الإعدادات المثالية لـ WP Rocket للحصول على 90+
إذا كنت تستخدم WP Rocket، فإليك الإعدادات الأكثر أثراً على Core Web Vitals:
| الإعداد | القسم | التوصية | التأثير |
|---|---|---|---|
| Enable Caching | Cache | مفعّل دائماً | TTFB ↓ |
| Minify CSS/JS | File Optimization | مفعّل | حجم الملفات ↓ |
| Defer JS Execution | File Optimization | مفعّل | LCP ↓ |
| Delay JS Execution | File Optimization | مفعّل (تفاعل مستخدم) | INP ↓ |
| LazyLoad Images | Media | مفعّل — ماعدا LCP | LCP ↓ |
| Remove Unused CSS | File Optimization | بحذر (قد يكسر التصميم) | CSS ↓ |
| Preload LCP Image | Preload | مفعّل مع تحديد الصورة | LCP ↓↓ |
التجارة الإلكترونية
تحسين Core Web Vitals في متاجر التجارة الإلكترونية
متاجر التجارة الإلكترونية تواجه تحديات فريدة في Core Web Vitals — صفحات المنتجات مليئة بالصور، سكريبتات الدفع، نماذج التقييم، وأدوات التخصيص. هذه النصائح مخصصة لها:
100ms
كل 100ms تأخير = 1% انخفاض في التحويل (Amazon)
+32%
زيادة في التحويلات بعد تحسين LCP في متجر Tokopedia
53%
من مستخدمي الجوال يتركون الصفحة إذا تجاوزت 3 ثوانٍ
قائمة تحسينات خاصة بالمتاجر
معرض الصور (Image Gallery): حمّل الصورة الرئيسية فقط أولاً بـ fetchpriority="high". حمّل باقي الصور المصغّرة بـ loading="lazy". استخدم WebP وsrcset لكل صورة.
سكريبتات الدفع: Stripe وPayPal وغيرها — حمّلها فقط عند فتح صفحة الـ Checkout وليس على كل صفحة منتج.
تقييمات المنتجات: تقييمات Yotpo أو Judge.me تحمّل سكريبتات ثقيلة. أخّر تحميلها بعد تفاعل المستخدم أو استخدم Facade Pattern.
فلاتر المنتجات: صفحات التصنيف مع الفلاتر الديناميكية قد تُعاني من CLS. احرص على أن تظهر الفلاتر بأبعاد ثابتة قبل تحميل النتائج.
البحث الفوري (Live Search): استخدم Debouncing (300ms) لمنع تشغيل طلبات API مع كل ضغطة مفتاح. هذا يُحسّن INP بشكل ملحوظ.
Recently Viewed / Recommendations: هذه العناصر الديناميكية غالباً تسبب CLS. خصّص لها مساحة ثابتة أو احملها بعد التحميل الرئيسي باستخدام Intersection Observer.
نصيحة ذهبية للمتاجر
أكبر تأثير لـ INP في المتاجر يأتي من أزرار "أضف للسلة". تأكد أن onClick handler يستجيب خلال أقل من 100ms — حتى لو أظهرت Spinner انتظار، يجب أن يظهر فورياً.
المراقبة
مراقبة Core Web Vitals بشكل مستمر
تحسين Core Web Vitals ليس حدثاً لمرة واحدة. كل تحديث للإضافات، كل صورة جديدة، كل سكريبت — قد يُراجع نتائجك. المراقبة المستمرة ضرورية للحفاظ على التقدم الذي حققته.
فعّل تنبيهات Search Console: اذهب لتقرير Core Web Vitals واضبط إشعارات البريد الإلكتروني عند اكتشاف مشاكل جديدة.
جدولة فحص أسبوعي: شغّل PageSpeed Insights على أهم 3 صفحات كل أسبوع. سجّل النتائج لتتبع الاتجاه عبر الزمن.
اختبر قبل النشر: أي تحديث جوهري — اختبر على Staging أولاً وقيس PageSpeed قبل النشر للـ Production.
لا تنسَ الجوال: جوجل يستخدم Mobile-First Indexing. نتائج الجوال في PageSpeed أهم من Desktop.
أدوات المراقبة المتقدمة
CrUX Dashboard
لوحة تحكم مجانية من جوجل تعرض Field Data الحقيقي لموقعك عبر الزمن. تحتاج Google Data Studio.
فتح الأداة
DebugBear
خدمة مدفوعة لمراقبة Core Web Vitals تلقائياً مع تنبيهات فورية عند أي تدهور في الأداء.
فتح الأداة
web-vitals JS Library
مكتبة JavaScript رسمية من جوجل لقياس Core Web Vitals مباشرة في متصفح مستخدميك الحقيقيين.
GitHub
Lighthouse CI
دمج Lighthouse في CI/CD pipeline الخاص بك. يمنع نشر أي كود يُتراجع بأداء الموقع عن حدٍّ محدد.
GitHub
الأسئلة الشائعة
أسئلة شائعة حول Core Web Vitals
إجابات على أكثر الأسئلة التي يسألها أصحاب المواقع والمطورون عن Core Web Vitals:
هل Core Web Vitals تؤثر فعلاً على ترتيبي في جوجل؟
نعم، لكن تأثيرها نسبي وليس مطلقاً. جوجل يستخدمها كعامل ترجيح — إذا تساوى موقعان في المحتوى والروابط والعوامل الأخرى، يفوز الذي لديه Core Web Vitals أفضل. لكنها لن تُصعد موقعاً بمحتوى ضعيف على موقع بمحتوى قوي فقط بسبب السرعة.
ما الفرق بين Lab Data وField Data؟
Lab Data هي نتائج اصطناعية تُجمع في بيئة محكومة (مثل Lighthouse). مفيدة للتشخيص لكن جوجل لا يستخدمها للترتيب. Field Data هي البيانات الحقيقية التي يجمعها Chrome من زوارك الفعليين وتُرسَل لـ Chrome UX Report (CrUX) — هذا ما يؤثر على ترتيبك فعلاً.
موقعي صغير ولا يظهر له Field Data — هل يُعاقَب؟
لا، جوجل لا يُعاقب المواقع التي ليس لديها بيانات CrUX كافية. في هذه الحالة يعتمد على بيانات المجموعة المشابهة (origin-level data) أو لا يُطبّق تأثير Core Web Vitals على ترتيبها. لكن كلما نما موقعك، كلما أصبح هذا العامل أكثر تأثيراً.
كيف أعرف أي عنصر يُعتبر LCP في صفحتي؟
افتح Chrome DevTools (F12) ← Performance ← سجّل تحميل الصفحة ← ابحث عن علامة "LCP" في الشريط الزمني. بديلاً أسرع: افتح PageSpeed Insights وفي قسم الـ Diagnostics ستجد "Largest Contentful Paint element" يُظهر العنصر بالضبط مع مقتطف من كوده.
هل تحسين Core Web Vitals يكفي للتصدر في جوجل؟
لا، Core Web Vitals عامل واحد ضمن مئات العوامل. التصدر يتطلب: محتوى ذو قيمة وعمق، روابط خارجية قوية (Backlinks)، EAT (Expertise, Authoritativeness, Trustworthiness) قوي، تحسين On-Page SEO، وسيارة الموقع. Core Web Vitals تُقوّي موقفك التنافسي لكنها لا تُعوّض ضعف العوامل الأخرى.
كم من الوقت يستغرق جوجل لملاحظة التحسينات؟
CrUX يجمع بيانات على نافذة متحركة لآخر 28 يوماً. هذا يعني أنك بحاجة لـ 28 يوماً على الأقل حتى تنعكس التحسينات الجديدة بالكامل في بيانات Field Data. أما أثر التحسينات على الترتيب الفعلي فقد يستغرق أسابيع إضافية.
جاهز لاختبار موقعك الآن؟
اكتشف نتائج Core Web Vitals لموقعك وتقرير مفصّل بالعربية مع توصيات قابلة للتطبيق فوراً — مجاناً تماماً.
افحص موقعك الآن مجاناً