Core Web Vitals: إيه اللي يهمك منها فعلاً

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

محتويات المقال

مين اللي يهمه Core Web Vitals فعلًا

لو موقعك فيه ترافيك من جوجل أو من إعلانات، المؤشرات دي تهمك لسببين:

1. جوجل بيستخدمها كإشارة تجربة صفحة مع عوامل كتير تانية. وجوجل نفسه بيوضح إن المحتوى الجيد والمناسب لسؤال الباحث أهم، يعني صفحة بطيئة قليلًا بمحتوى ممتاز ممكن تتفوق على صفحة سريعة بمحتوى ضعيف.
2. الزائر بيتأثر بيها فعليًا حتى لو جوجل مش موجود. صفحة بتتحرك وإنت بتضغط على الزر فتضغط على حاجة تانية، أو صفحة بتتأخر في الرد، بتخسّرك زيارات وتحويلات.

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

المؤشرات التلاتة بالتفصيل

LCP: سرعة ظهور أهم عنصر (Largest Contentful Paint)

بتقيس الوقت اللي بيستغرقه أكبر عنصر ظاهر في أول شاشة (غالبًا صورة رئيسية أو بنر أو عنوان كبير) عشان يتحمّل ويظهر.

• الحد الجيد اللي بيعلنه جوجل: 2.5 ثانية أو أقل.
• التقدير بيكون على أغلب زوار الصفحة (جوجل بيقيس على نسبة كبيرة منهم، مش أسرع زائر).
• أشهر أسبابه: صورة البنر ضخمة، أو سيرفر بطيء، أو الاستضافة بعيدة، أو أكواد بتعطّل الرسم، أو خطوط بتتأخر.

INP: سرعة الاستجابة للتفاعل (Interaction to Next Paint)

بتقيس مدى سرعة الصفحة في الرد لما الزائر يتفاعل معاها: ضغطة على زر، فتح قايمة، كتابة في حقل. وهي حلّت محل مؤشر قديم اسمه FID في 2024.

• الحد الجيد اللي بيعلنه جوجل: 200 ميلي ثانية أو أقل.
• أشهر أسبابه: جافاسكريبت تقيل كتير، وإضافات وأكواد تتبع وقوالب بتشغّل سكريبتات كتيرة، وصفحة معقدة جدًا.

CLS: ثبات التخطيط (Cumulative Layout Shift)

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

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

الأرقام دي حدود منشورة من جوجل في وقت كتابة المقال، وممكن تتحدّث. راجع صفحة web.dev الرسمية لو عايز تتأكد من آخر قيم.

ملاحظة مهمة: بيانات المعمل مقابل بيانات الزوار الفعليين

دي أكتر نقطة بتلخبط الناس.

• بيانات المعمل (Lab Data): اختبار بيتعمل لمرة واحدة في ظروف محددة بأداة زي Lighthouse أو PageSpeed Insights (القسم التشخيصي). مفيد جدًا للتشخيص والإصلاح، لكنه ممكن يختلف من مرة للتانية.
• بيانات الميدان (Field Data): بتتجمع من زوار حقيقيين استخدموا متصفح كروم على مدى فترة، ومتاحة في تقرير Core Web Vitals في Search Console وفي أول جزء من PageSpeed Insights. دي اللي جوجل بيعتمد عليها في تقييم تجربة الصفحة.

يعني لو درجة الاختبار اللحظي متوسطة وبيانات الزوار الفعلية «جيدة»، متقلقش. والعكس: لو بيانات الميدان ضعيفة، الدرجة اللحظية الحلوة مش كفاية.

وفي المواقع الصغيرة اللي ترافيكها قليل، ممكن مفيش بيانات ميدانية كافية للعرض، وساعتها بتعتمد على المعمل للتشخيص.

إزاي تقيس Core Web Vitals

1. Google Search Console ← تقرير Core Web Vitals: بيعرض مجموعات الصفحات (جيدة، تحتاج تحسين، ضعيفة) للموبايل والكمبيوتر، حسب الزوار الفعليين. ولو مش مستخدم Search Console، شوف دليل Search Console.
2. PageSpeed Insights: اكتب رابط الصفحة، وشوف بيانات الميدان فوق وبيانات المعمل والتوصيات تحت.
3. Lighthouse في متصفح كروم: للاختبار المحلي والتشخيص.
4. اختبر من الموبايل أولًا: زوارك غالبًا منه، وهو الأضعف أداءً.
5. اختبر 3 أنواع صفحات: الرئيسية وصفحة المنتج أو المقال وصفحة الدفع، لأن كل نوع بتتصرف مختلف.

أنهي رقم يستاهل تشتغل عليه الأول

الترتيب العملي:

• لو فيه صفحات «ضعيفة» في Search Console: ابدأ بالمؤشر المسمّى فيها كسبب. ده بيقولك فين المشكلة بالضبط.
• LCP عادةً أسهل وأكتر تأثير: غالبًا بتتحسّن بضغط الصورة الرئيسية وتحسين الاستضافة والكاش.
• CLS أسهل في الإصلاح التقني: غالبًا بتحط أبعاد للصور والعناصر المتأخرة.
• INP أصعب: محتاج تقلّل جافاسكريبت وإضافات، وده بيحتاج جرد دقيق.

وما تطاردش الدرجة الكاملة 100. الهدف إن بيانات الزوار تبقى في النطاق الجيد، مش إنك تعمل «سكور» مثالي في الأداة.

إصلاحات عملية في ووردبريس وووكومرس

لتحسين LCP

• الصورة الرئيسية في أول الصفحة: اضغطها وحدّد حجمها المناسب، ومتعملهاش Lazy Load لأنها أهم عنصر.
• استضافة وكاش مناسبين: زمن استجابة السيرفر الأول بيأثر مباشرة. راجع تسريع ووكومرس.
• قلّل الخطوط: استخدم خطين على الأكتر وأوزان قليلة، وخلّي الخطوط تتحمّل بشكل سريع.
• قلّل الأكواد اللي بتعطّل الرسم في أول الصفحة.

لتحسين CLS

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

لتحسين INP

• راجع الإضافات والسكريبتات: كل إضافة وكود تتبع (بيكسل، تحليلات، شات) بيضيف جافاسكريبت. امسح اللي مش بتستخدمه. وده نفس مبدأ مقال ليه موقع ووردبريس بطيء.
• أجّل السكريبتات غير الضرورية لحد ما الصفحة تفاعلية.
• بسّط القوالب المعقدة وقلّل استخدام Page Builder التقيل.
• راقب صفحة السلة والدفع: فيها سكريبتات دفع وتتبع كتير.

بالنسبة لأكواد التتبع، ما تشيلهاش عشان السرعة بس؛ بيكسل ميتا وتتبع التحويلات مهمين لحملاتك. بدل ما تشيلهم، حمّلهم بشكل أذكى (مثلًا عن طريق Google Tag Manager أو Conversions API كما في إعداد Conversions API) وقيس الأثر.

كام تأثير Core Web Vitals على الترتيب فعلًا؟

الصراحة: جوجل بيقول إنها جزء من عوامل كتير، ومحدّش برّه جوجل يعرف الوزن بالظبط. القاعدة العملية:

• لو عندك مشكلة كبيرة (صفحات بطيئة جدًا وبتتحرك)، إصلاحها بيحسّن التجربة والتحويل وغالبًا بيساعد في السيو.
• لو نتايجك «جيدة» أصلًا، تحسين إضافي بسيط جدًا مش هيعمل فرق ترتيب ملحوظ، والأفضل تستثمر الوقت في المحتوى.
• ما تتوقّعش قفزات في الترتيب من مجرد تحسين المؤشرات.

أخطاء شائعة

• الهوس بدرجة الاختبار بدل بيانات الزوار.
• تحسين صفحة واحدة وإهمال باقي أنواع الصفحات.
• تركيب 3 إضافات تسريع فوق بعض. بتتعارض وممكن تبطّأ.
• شيل أكواد التتبع وفقد بيانات الحملات.
• صور بدون أبعاد. أشهر سبب لـ CLS.
• عدم إعادة القياس. البيانات الميدانية بتتحدّث على فترة، فاستنى قبل ما تحكم.
• تجاهل الموبايل.

للتأكد من أحدث التفاصيل، راجع شرح Core Web Vitals الرسمي من web.dev، لأن الواجهات والسياسات بتتغيّر باستمرار.

مقالات ذات صلة بتفيدك:

• سيو تقني: قائمة فحص لموقعك من غير ما تكون مبرمج
• الظهور في إجابات ChatGPT و Gemini: السيو في عصر الذكاء الاصطناعي
• أدوات سيو مجانية تكفيك في أول سنة
• البيانات المنظمة Schema للمتاجر والمقالات

أسئلة شائعة

هل Core Web Vitals عامل ترتيب فعلًا؟

جوجل بيعتبرها جزء من إشارات تجربة الصفحة، لكنها واحدة من عوامل كتير، والمحتوى المفيد لسه الأهم. هي مفيدة أكتر كتجربة للزائر.

ليه الأرقام بتتغيّر كل مرة أختبر؟

لأن الاختبار اللحظي بيتأثر بحمولة السيرفر والشبكة. كرّر الاختبار وركّز على الاتجاه العام وبيانات الزوار الفعليين.

ليه Search Console مفيهوش بيانات لموقعي؟

الموقع الجديد أو قليل الزيارات ممكن ما يوصلش لحد كافي من البيانات الميدانية. اعتمد على الاختبار المعملي وحسّن الأساسيات.

أبدأ بإيه لو كل حاجة حمرا؟

ابدأ بالصفحات الأهم (الرئيسية والمنتجات الأكثر زيارة) وبالمشكلة اللي التقرير بيسمّيها. حسّن حاجة واحدة وقيس، بدل ما تغيّر كل حاجة مرة واحدة.

لو موقعك أو متجرك بيعاني من بطء أو مؤشرات ضعيفة وعايز حد يشخّص السبب بدقة ويرتّب لك الإصلاحات، تقدر تحجز استشارة معايا.