دليل Core Web Vitals الكامل 2026

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

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

ما هي Core Web Vitals (وما الذي تقيسه فعلاً)

دعنا نزيح الغموض عن المصطلح أولاً. مؤشرات الويب الأساسية (Core Web Vitals) هي مجموعة من ثلاثة مقاييس رسمية أطلقتها Google لتقيس تجربة المستخدم الفعلية على صفحتك — وتحديداً ثلاثة جوانب: سرعة التحميل المرئي، وسرعة الاستجابة للتفاعل، والثبات البصري. والكلمة المفتاحية هنا هي «الفعلية»: هذه المؤشرات لا تقيس رأيك أنت في موقعك، بل تجربة زائر حقيقي على جهاز حقيقي وشبكة حقيقية.

ما يجعل هذه المؤشرات مختلفة عن مئات المقاييس التقنية الأخرى أن Google اختارتها بعناية لتكون «الأساسية» — أي الثلاثة التي تختصر تجربة المستخدم خير اختصار. كل واحد منها يجيب على سؤال بسيط يطرحه كل زائر دون أن ينطق به:

• هل ظهر المحتوى بسرعة؟ — يقيسه مؤشر LCP (Largest Contentful Paint / أكبر عنصر مرئي).
• هل استجاب الموقع حين تفاعلت معه؟ — يقيسه مؤشر INP (Interaction to Next Paint / التفاعل حتى الرسم التالي).
• هل بقي التصميم ثابتاً دون أن يقفز؟ — يقيسه مؤشر CLS (Cumulative Layout Shift / إزاحة التخطيط التراكمية).

“

Core Web Vitals is a set of metrics that measure real-world user experience for loading performance, interactivity, and visual stability of the page. … This, along with other page experience aspects, aligns with what our core ranking systems seek to reward.

هذا التعريف الرسمي يحسم نقطتين مهمتين كثيراً ما يخلط فيهما المحتوى العربي. الأولى أن Core Web Vitals تقيس «تجربة العالم الحقيقي» (real-world)، أي بيانات ميدانية من مستخدمين فعليين، لا مجرد اختبار معملي مثالي على جهاز قوي. والثانية أنها جزء من «تجربة الصفحة» (Page Experience) وتتوافق مع ما تكافئه أنظمة الترتيب — لاحظ الصياغة الدقيقة: «تتوافق مع» وليس «تحدد وحدها». سنعود لهذه النقطة الحساسة في قسم عامل الترتيب.

وكما تختصرها Ahrefs في تعريف عملي واضح، فإن جوهر الأمر بسيط رغم كثرة المصطلحات.

“

Core Web Vitals are 3 metrics that Google uses to measure a user’s experience on a webpage by looking at visual load speed, visual stability, and interactivity / responsiveness.

إذن نحن أمام ثلاثة أرقام فقط، لكنها أرقام تختصر شعور زائرك في أول ثلاث ثوانٍ — وهي الثوانٍ التي تقرر إن كان سيبقى أو يرحل. في الأسواق التي أعمل فيها، حيث غالبية الزيارات تأتي من الجوال على شبكات متفاوتة الجودة بين مدينة وأخرى، تتحوّل هذه الثوانٍ من رفاهية تقنية إلى فارق حقيقي بين بيعٍ يكتمل وعربة تُهجر.

العتبات الرسمية لاجتياز المؤشرات في 2026

السؤال الذي يطرحه كل صاحب موقع بمجرد أن يفهم المؤشرات الثلاثة هو: ما الرقم الذي يجب أن أصل إليه لأنجح؟ والإجابة محددة وموثّقة في وثائق Google نفسها. هذه هي العتبات الرسمية المعتمدة حتى عام 2026:

لكن قبل أن تركض لتفحص موقعك، هناك تفصيل واحد يغيّر كل شيء ويغفل عنه أغلب من يكتب عن هذا الموضوع: هذه العتبات يجب تحقيقها عند النسبة المئوية 75 (75th percentile) من زياراتك الحقيقية. ماذا يعني ذلك بلغة بسيطة؟ يعني أنه لا يكفي أن يكون متوسط زوارك سريعاً؛ بل يجب أن يحصل ثلاثة أرباع زوّارك على الأقل على تجربة تحت العتبة. هذا تصميم ذكي من Google: فهو يحميك من أن يخفي زائر واحد قوي الجهاز معاناة عشرة زوار على هواتف متوسطة.

الجدول التالي يلخّص المستويات الثلاثة لكل مؤشر كما تصنّفها Google — «جيد»، و«يحتاج تحسيناً»، و«ضعيف» — وهي التصنيفات نفسها التي ستراها بالألوان الأخضر والأصفر والأحمر في أدوات القياس:

المؤشر	جيد (تجتاز)	يحتاج تحسيناً	ضعيف	ما يقيسه
LCP	أقل من 2.5 ثانية	2.5 إلى 4 ثوانٍ	أكثر من 4 ثوانٍ	سرعة ظهور أكبر عنصر مرئي
INP	أقل من 200 مللي ثانية	200 إلى 500 مللي ثانية	أكثر من 500 مللي ثانية	سرعة الاستجابة لتفاعلات الزائر
CLS	أقل من 0.1	0.1 إلى 0.25	أكثر من 0.25	مقدار قفز العناصر أثناء التحميل

والآن، إلى أي مدى يجتاز الويب فعلاً هذه العتبات؟ الأرقام تكشف أن الطريق ليس سهلاً، وأن من ينجح فيه يكسب ميزة حقيقية على منافس متعثر.

لاحظ الرقم الأول: نحو ثلث المواقع فقط تجتاز كل المؤشرات الثلاثة معاً وفق تحليل Ahrefs لبيانات CrUX على أكثر من 5.2 مليون صفحة (بارتفاع نحو 10% عن العام السابق). وفي دراسة Backlinko على 208 ألف صفحة، بلغ متوسط زمن LCP نحو 2.8 ثانية — أي أعلى من عتبة 2.5 ثانية الموصى بها. الرسالة واضحة: الويب بطيء في المتوسط، وهذا يعني أن من يبذل الجهد الصحيح يتفوّق على الأغلبية. هنا تماماً تبدأ الفرصة.

مؤشر LCP: سرعة ظهور المحتوى وكيف تحسّنه

نبدأ بأشهر المؤشرات وأكثرها بداهة. مؤشر LCP — Largest Contentful Paint، أو «أكبر عنصر مرئي» — يقيس الزمن الذي يستغرقه أكبر عنصر مرئي في الجزء الظاهر من شاشتك حتى يكتمل عرضه. هذا العنصر غالباً ما يكون الصورة البطلة في أعلى الصفحة (hero image)، أو عنواناً رئيسياً كبيراً، أو فيديو الغلاف. ببساطة: متى يشعر زائرك أن «الصفحة ظهرت»؟ العتبة الجيدة: أقل من 2.5 ثانية.

لماذا هذا المؤشر مهم نفسياً؟ لأن الزائر لا يحكم على سرعتك بمقاييس تقنية، بل باللحظة التي يرى فيها شيئاً ذا قيمة. صفحة بيضاء فارغة لثلاث ثوانٍ تشعره بأنه ينتظر إلى الأبد، حتى لو اكتملت بقية العناصر سريعاً بعد ذلك.

ما الذي يبطئ LCP عادةً؟

في تجربتي العملية مع عشرات المواقع، تتكرر الأسباب نفسها بشكل ممل تقريباً — وهذه أخبار جيدة، لأن المشكلات المتكررة لها حلول مجرّبة:

• صورة بطلة ضخمة غير مضغوطة — أكبر سبب منفرد، خصوصاً على المتاجر التي ترفع صور المنتجات بأحجامها الأصلية.
• استضافة بطيئة أو بعيدة جغرافياً عن جمهورك في الخليج ومصر، فيطول زمن استجابة الخادم.
• ملفات CSS وجافا سكريبت تحجب العرض (render-blocking) فتؤخر رسم المحتوى الأساسي.
• خطوط تُحمّل متأخرة فيظهر النص بعد تأخير.

كيفية تحسين LCP عملياً

الحلول مرتّبة حسب الأثر، وهذه هي خطتي حين أعالج LCP بطيئاً:

1. اضغط الصور وحوّلها إلى صيغ حديثة مثل WebP أو AVIF. هذه الخطوة وحدها قد تقلّص حجم الصورة بشكل كبير دون أن تلاحظ العين فرقاً في الجودة.
2. استخدم شبكة توصيل محتوى (CDN) واستضافة سريعة قريبة من جمهورك، فتقطع المسافة الجغرافية التي تكلّفك أجزاء الثانية الثمينة.
3. فعّل التحميل المسبق (preload) للصورة البطلة حتى يبدأ المتصفح بجلبها مبكراً بدلاً من اكتشافها متأخراً.
4. استخرج CSS الحرج (critical CSS) وحمّله مباشرة في الصفحة، وأجّل بقية الأنماط غير الضرورية للعرض الأول.

هذا تحديداً نوع العمل الذي طبّقته في مشاريعي. في حالة متجر Roseberry بالسعودية، كان الأساس التقني — وضمنه ضغط الصور وتسريع التحميل — هو ما سمح للمحتوى والروابط بأن تتراكم لاحقاً، حتى ارتفع الموقع من نحو 25 ظهوراً في اليوم إلى 51.5 مليون ظهور. السرعة لم تكن النجم في تلك القصة، لكنها كانت المنصة التي وقف عليها كل شيء آخر. وهذا جوهر السيو التقني: إصلاحات صامتة تطلق نمواً صاخباً.

مؤشر INP: المؤشر الأصعب والأكثر إهمالاً

إن كان هناك مؤشر واحد يستحق أن تركّز عليه قراءتك بانتباه مضاعف، فهو هذا. مؤشر INP — Interaction to Next Paint، أو «التفاعل حتى الرسم التالي» — يقيس سرعة استجابة صفحتك حين يتفاعل معها الزائر: حين يضغط زراً، أو يفتح قائمة، أو يكتب في حقل بحث. كم من الوقت يمر بين لمسته وبين أن يرى الشاشة تستجيب فعلاً؟ العتبة الجيدة: أقل من 200 مللي ثانية.

لماذا حلّ INP محل FID؟

هنا تكمن نقطة محورية كثيراً ما تُشرح خطأً. حتى مارس 2024، كان المؤشر الثالث هو FID (First Input Delay / تأخير الإدخال الأول). لكن Google استبدلته رسمياً بمؤشر INP. ما الفرق الجوهري؟

“

INP considers all page interactions and usually reports the one with the largest delay. First Input Delay only looks at the first interaction.

تأمّل هذا الفرق جيداً: كان FID يقيس التفاعل الأول فقط — أي لحظة واحدة من عمر الزيارة كلها. أما INP فيراقب كل تفاعلات الزائر طوال جلسته، ثم يُبلّغ عادة عن أبطأها. وهذا يجعله أصدق بكثير في وصف التجربة الحقيقية، لكنه في المقابل أقسى وأصعب في النجاح. الجدول التالي يوضح الفرق بإيجاز:

الجانب	FID (السابق)	INP (الحالي منذ مارس 2024)
ماذا يقيس	تأخير التفاعل الأول فقط	كل تفاعلات الزائر طوال الجلسة
ما يُبلّغ عنه	لحظة واحدة	غالباً أبطأ تفاعل حدث
الصعوبة	كان سهل الاجتياز نسبياً	الأصعب بين المؤشرات حالياً
نسبة النجاح	نحو 93% كانت تجتازه	نحو 64% فقط تجتازه

هذا التحوّل من نحو 93% نجاح إلى نحو 64% هو السبب في أن INP صار «الجدار» الذي تصطدم به مواقع كثيرة في 2026 — خصوصاً المتاجر والمواقع الثقيلة بالجافا سكريبت والإضافات.

كيفية تحسين INP عملياً

INP في جوهره مشكلة «خيط رئيسي مشغول» (main thread). حين ينقر الزائر، يكون متصفّحه منشغلاً بتنفيذ جافا سكريبت ثقيلة، فلا يجد وقتاً للاستجابة فوراً. الحلول تدور حول تخفيف هذا الانشغال:

1. قلّل عمل الخيط الرئيسي بتقسيم المهام الطويلة في الجافا سكريبت إلى مهام أصغر تترك فجوات يتنفّس فيها المتصفح.
2. أجّل (defer) ملفات الجافا سكريبت غير الضرورية للعرض الأول، فلا تُنفَّذ إلا بعد أن تصبح الصفحة جاهزة للتفاعل.
3. احذف السكربتات الخارجية الزائدة — أدوات التتبّع والدردشة والإعلانات والودجات التي تتراكم على المتاجر هي القاتل الصامت لمؤشر INP.
4. راجع إضافات ووردبريس بصرامة إن كنت تعمل عليه؛ فكل إضافة تحمّل سكربتاتها الخاصة، وكثرتها تخنق الخيط الرئيسي.

مؤشر CLS: الثبات البصري وإصلاح القفزات المزعجة

المؤشر الثالث ربما يكون الأقل شهرة، لكنه الأكثر إزعاجاً للزائر حين يفشل. مؤشر CLS — Cumulative Layout Shift، أو «إزاحة التخطيط التراكمية» — يقيس مدى ثبات تصميم صفحتك أثناء التحميل، أو بعبارة أوضح: كم تقفز العناصر من أماكنها فجأة. العتبة الجيدة: أقل من 0.1.

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

الأسباب الشائعة لارتفاع CLS

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

كيفية إصلاح CLS عملياً

الخبر الجميل أن CLS غالباً هو الأسهل إصلاحاً بين الثلاثة، لأن حلوله محددة ومباشرة:

1. حدّد أبعاد width وheight لكل صورة وفيديو صراحةً، حتى يحجز المتصفح المساحة الصحيحة قبل وصول الملف.
2. احجز مساحة ثابتة للإعلانات والبانرات الديناميكية بحاوية محددة الأبعاد، فلا تدفع ما حولها حين تظهر.
3. استخدم font-display: swap مع استراتيجية خطوط مدروسة، لتقليل أثر تبديل الخطوط على التخطيط.
4. تجنّب حقن المحتوى فوق محتوى موجود؛ وإن لزم، احجز له مكانه من البداية.

الأرقام تطمئنك هنا: في دراسة Backlinko لـ208 ألف صفحة، حصل نحو 65% من الصفحات على تقييم «جيد» في CLS — وهي أعلى نسبة نجاح بين المؤشرات الثلاثة. هذا يعني أن الإصلاح ممكن، وأن غالبية من اهتمّ بالأمر نجح فيه. لا عذر إذن لترك تصميمك يقفز تحت أعين عملائك.

هل Core Web Vitals عامل ترتيب حقيقي؟ الحقيقة الكاملة

نصل الآن إلى السؤال الأكثر حساسية، والأكثر تشويهاً في المحتوى العربي. كثير من المقالات تصرخ بأن «السرعة هي مفتاح التصدّر» وتعطي المؤشرات وزناً أكبر بكثير من حقيقتها. دعني أعطيك الصورة الدقيقة كما توثّقها Google نفسها.

نعم، Core Web Vitals عامل ترتيب — لكنه عامل ثانوي. هي جزء من إشارات «تجربة الصفحة» وتدخل ضمن أنظمة الترتيب، لكن المحتوى وثيق الصلة (relevance) يبقى الأهم على الإطلاق. الأدق أن تتخيّلها «عامل ترجيح» (tiebreaker): حين يتقارب موقعان في جودة المحتوى وملاءمته، تصبح السرعة والثبات والاستجابة هي الفارق الذي يرجّح كفة أحدهما. أما أن تتوقّع أن سرعة خارقة وحدها ستقفز بصفحة محتواها ضعيف إلى الصدارة، فهذا وهم.

وحتى لا تظنّ أنني أقلّل من شأن عملي، اسمع ما قاله محلل من داخل Google نفسها:

“

I don’t think most sites will see a great benefit from working on Core Web Vitals.

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

فلماذا أهتم بها إذن، ولماذا يجب أن تهتم أنت؟ لسببين لا علاقة لأحدهما المباشرة بخوارزمية الترتيب:

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

شائعات يجب الحذر منها (فجوة المحتوى العربي)

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

• «تحديث مارس 2026 يغيّر المؤشرات» — لا يوجد في وثائق Google الرسمية أي تحديث بهذا الوصف يغيّر تعريف Core Web Vitals أو عتباتها في مارس 2026. تعامل مع أي ادّعاء كهذا بحذر شديد حتى يظهر في مصدر رسمي.
• «Core Web Vitals 2.0 / Visual Stability Index» — مصطلحات تتردد في بعض المدونات بلا أي سند من Google. لا تبنِ قراراً عليها.
• «عتبة LCP انخفضت إلى ثانيتين» — العتبة الرسمية حتى الآن لا تزال أقل من 2.5 ثانية. لم تعلن Google خفضها إلى 2.0 ثانية في أي وثيقة رسمية.
• «السرعة وحدها تتصدّر بك» — كما رأينا في القسم السابق، هذا مبالغة؛ المؤشرات عامل ثانوي وترجيحي.
• أرقام أرباح عامة منسوبة بلا مصدر — تحذير منهجي مهم: ربط تحسين المؤشرات بزيادة أرباح بنسبة محددة يجب أن يُبنى على بياناتك أنت عبر Search Console وGoogle Analytics، لا على أرقام عامة من مدونات غير موثقة.

لماذا أصرّ على هذا؟ لأن مصداقيتك — ومصداقيتي — تُبنى على الدقة. حين يقرأ عميل محتوى عربياً يبالغ ويختلق، ثم يكتشف الحقيقة لاحقاً، يخسر ثقته في الجميع. الفجوة الحقيقية في السوق العربي ليست نقص المقالات، بل ندرة محتوى عربي محدّث لعام 2026 يربط المؤشرات بأدوات القياس العملية وبأمثلة من سوق الخليج والجوال — وهذا بالضبط ما أحاول سدّه هنا.

كيف تقيس وتختبر Core Web Vitals لموقعك

كل ما سبق يبقى نظرياً حتى تقيس موقعك بنفسك. والخطأ الأكثر شيوعاً هنا هو الخلط بين نوعين مختلفين تماماً من البيانات. فهم هذا الفرق وحده يضعك في مرتبة متقدمة على غالبية من يكتب عن الموضوع:

• البيانات الميدانية (Field Data): من مستخدمين حقيقيين، تُجمع عبر تقرير Chrome UX Report (CrUX). هذه هي البيانات التي تُرتّب عليها Google فعلاً.
• البيانات المعملية (Lab Data): من اختبار محاكى في بيئة محكومة. مفيدة للتشخيص، لكنها ليست ما يُرتّب عليه.

القاعدة الذهبية: حسّن للبيانات الميدانية، وشخّص بالبيانات المعملية. الجدول التالي يرتّب لك الأدوات بحسب دورها:

الأداة	نوع البيانات	متى تستخدمها
تقرير Core Web Vitals في Search Console	ميدانية (CrUX، نافذة 28 يوماً)	نقطة البداية: تكشف مجموعات الصفحات الفاشلة على نطاق الموقع كله
PageSpeed Insights	ميدانية + معملية	تشخيص كل صفحة على حدة ومعرفة سبب البطء
Chrome UX Report (CrUX)	ميدانية	المصدر الخام للبيانات الميدانية
Chrome DevTools / Lighthouse	معملية	التعمّق في تحليل الأداء لحظة بلحظة أثناء التطوير

خطوات القياس الصحيحة

1. ابدأ من Search Console. افتح تقرير «مؤشرات أداء الويب الأساسية»، وستجد صفحاتك مجمّعة حسب الحالة (جيدة، تحتاج تحسيناً، ضعيفة) ومصنّفة بنوع المشكلة. هذه البيانات حقيقية ومجمّعة على نافذة 28 يوماً، وتعطيك صورة الموقع كله لا صفحة واحدة.
2. شخّص بـ PageSpeed Insights. خذ نموذجاً من كل مجموعة فاشلة، وافحص كل صفحة لتعرف أي مؤشر يسقط ولماذا، مع توصيات محددة.
3. طبّق الإصلاحات بحسب الخطة التي سنضعها في القسم التالي.
4. انتظر بصبر. وهنا تنبيه حاسم.

هذا الصبر تحديداً هو ما يميّز العمل الاحترافي عن العشوائي. كثيرون يطبّقون إصلاحاً صحيحاً، ثم يلغونه بعد يومين لأنهم لم يروا تغيّراً فورياً — فيخسرون مكسباً كان في الطريق إليهم.

خطة تحسين عملية: من القياس إلى التصدّر

الآن نجمع كل ما سبق في خطة متسلسلة تطبّقها بالترتيب. هذا تماماً المنطق الذي أتبعه حين أتولّى مشروعاً، مرتّباً من الأعلى أثراً إلى الأدق:

1. قِس أولاً، لا تخمّن. ابدأ من Search Console ثم PageSpeed Insights لتحدّد أي المؤشرات يسقط على أي مجموعة صفحات. لا تطبّق إصلاحاً عشوائياً قبل أن تعرف المشكلة الحقيقية.
2. عالج LCP بالصور والاستضافة. اضغط الصور وحوّلها إلى WebP/AVIF، وفعّل CDN واستضافة سريعة قريبة من جمهورك، واعمل preload للصورة البطلة، واستخرج critical CSS. هذا غالباً يعطي أكبر مكسب وأسرعه.
3. عالج INP بترشيق الجافا سكريبت. قلّل عمل الخيط الرئيسي، وأجّل السكربتات غير الضرورية، واحذف الزائد منها، وراجع كل إضافة. هذا الأصعب لكنه الأكثر تمييزاً لك عن منافسيك في 2026.
4. عالج CLS بحجز المساحات. حدّد أبعاد كل صورة وإعلان، واحجز مساحة للعناصر الديناميكية، واستخدم font-display: swap.
5. انتظر 28 يوماً ثم أعد القياس. قارن بيانات Search Console قبل وبعد، وثبّت ما نجح، وعالج ما تبقّى.
6. اجعلها روتيناً، لا حملة واحدة. كل إضافة جديدة أو قالب أو حملة إعلانية قد تكسر ما أصلحته. المراقبة المستمرة تحمي مكسبك.

هذه الخطة ليست نظرية. على متجر متخصص في السعودية، كان العلاج التقني — وضمنه الأداء والبنية — جزءاً من رحلة قادته إلى المركز الأول في السعودية خلال 166 يوماً. وعلى Conscent، ساهم وضع الأساس التقني والمحتوى المنظّم في نمو الظهور من 61 ألفاً إلى 1.2 مليون. وعلى Oxford Egypt، كانت المعالجة التقنية بوابة لظهور أوسع. في كل حالة، لم تكن السرعة هي البطل وحدها، لكنها كانت الأرض التي وقف عليها كل نمو لاحق.

أسئلة شائعة عن Core Web Vitals

ما هي مؤشرات Core Web Vitals بالضبط؟

هي ثلاثة مقاييس رسمية من Google تقيس تجربة المستخدم الفعلية على صفحتك: LCP يقيس سرعة ظهور أكبر عنصر مرئي، وINP يقيس سرعة استجابة الصفحة لتفاعلات الزائر، وCLS يقيس ثبات التصميم وعدم قفز العناصر أثناء التحميل. ووفق Google Search Central، تدخل هذه المؤشرات ضمن إشارات «تجربة الصفحة» التي تكافئها أنظمة الترتيب.

ما هي القيم المطلوبة لاجتياز Core Web Vitals في 2026؟

العتبات الرسمية حتى الآن: LCP أقل من 2.5 ثانية، وINP أقل من 200 مللي ثانية، وCLS أقل من 0.1. ويجب تحقيقها عند النسبة المئوية 75 من زياراتك الحقيقية. تنبيه: ما يتردد في بعض المدونات عن خفض عتبة LCP إلى ثانيتين أو عن «تحديث مارس 2026» غير مؤكد ولا يوجد في وثائق Google الرسمية.

هل Core Web Vitals عامل ترتيب حقيقي في Google؟

نعم لكنه عامل ثانوي. تؤكد Google أنها جزء من تجربة الصفحة وتدخل في الترتيب، لكن المحتوى وثيق الصلة يبقى الأهم. وقد صرّح Gary Illyes من Google بأن معظم المواقع لن تجني فائدة كبيرة من العمل على هذه المؤشرات وحدها — فهي أقرب إلى «عامل ترجيح» عند تقارب جودة المحتوى.

ما الفرق بين INP وFID؟ ولماذا تم استبداله؟

استبدلت Google مؤشر FID بمؤشر INP رسمياً في مارس 2024. الفرق أن FID كان يقيس تأخير التفاعل الأول فقط، بينما INP يقيس كل تفاعلات الزائر طوال جلسته ويُبلّغ عادة عن أبطأها — فهو مقياس أدق وأصعب: نحو 64% فقط من المواقع تحقق فيه نتيجة جيدة.

كيف أقيس وأختبر Core Web Vitals لموقعي؟

ابدأ بتقرير «مؤشرات أداء الويب الأساسية» داخل Google Search Console لمعرفة مجموعات الصفحات الفاشلة من بيانات حقيقية، ثم استخدم PageSpeed Insights لتشخيص كل صفحة على حدة. انتبه إلى أن بيانات CrUX الميدانية تُجمع على نافذة 28 يوماً، فقد يستغرق ظهور أثر تحسيناتك حتى 28 يوماً.

كيف أحسّن LCP وINP وCLS عملياً؟

لـ LCP: اضغط الصور بصيغ WebP/AVIF، واستخدم CDN واستضافة سريعة، وفعّل التحميل المسبق للصورة البطلة وcritical CSS. لـ INP: قلّل عمل الخيط الرئيسي، وأجّل ملفات الجافا سكريبت غير الضرورية، واحذف السكربتات الخارجية الزائدة. لـ CLS: حدّد أبعاد width وheight لكل صورة وإعلان واحجز لها مساحة، واستخدم font-display: swap.

هل تحسين سرعة الموقع يزيد المبيعات والتحويلات فعلاً؟

نعم؛ السرعة جزء من تجربة المستخدم التي تؤثر مباشرة في معدلات الارتداد والتحويل، وهي أهم على الجوال الذي يمثّل غالبية حركة الزيارات في مصر والخليج. لكن انتبه: ربط المؤشرات بالأرباح يجب أن يُبنى على بياناتك أنت عبر Search Console وGoogle Analytics، لا على أرقام عامة من مدونات غير موثقة.

---

مؤشرات Core Web Vitals في النهاية ليست هدفاً تقنياً تطارده لأجل لوحة خضراء جميلة؛ إنها مرآة لتجربة كل عميل يطرق باب موقعك. حين تكون صفحتك سريعة، ومستقرة، ومستجيبة، فأنت لا ترضي خوارزمية فحسب — بل تحترم وقت زائرك وثقته، وتبني الانطباع الأول الذي يقرّر إن كان سيبقى ليشتري. اقرأ مؤشراتك في Search Console، طبّق الخطة بالترتيب، واصبر على الميدان 28 يوماً. وإن أردت يداً خبيرة تحوّل هذه الأرقام إلى تصدّر وإيرادات حقيقية، فأنا هنا.