سرعة الموقع ومؤشرات Core Web Vitals: دليل عملي

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

هذه ليست مشكلة تصميم فقط. هي ثلاثة مقاييس تراقبها جوجل بالاسم وتسميها مؤشرات أداء الويب الأساسية (Core Web Vitals)، وتنصح أصحاب المواقع بتحقيق نتائج جيدة فيها. والأهم أنها تقيس تجربة زوارك الحقيقيين، لا تجربتك أنت على حاسوب المكتب.

في هذا الدليل نشرح سرعة الموقع بلغة صاحب المشروع: ما المؤشرات الثلاثة وحدودها الرسمية، ولماذا حلّ INP محل FID، وهل تؤثر فعلاً في ترتيبك، وكيف تقرأ تقاريرها، ثم ما الذي يصلح كل مؤشر عملياً.

الخلاصة السريعة

• مؤشرات أداء الويب الأساسية: ثلاثة مقاييس من جوجل لتجربة المستخدم هي LCP للتحميل، وINP للاستجابة، وCLS للاستقرار البصري.
• الحدود الجيدة: أن يكون LCP بحد أقصى 2.5 ثانية، وINP بحد أقصى 200 ملي ثانية، وCLS بحد أقصى 0.1، عند الشريحة المئوية 75 من زيارات الصفحة.
• مؤشر INP: حلّ محل FID رسمياً كمؤشر أساسي في 12 مارس 2024، لأنه يقيس كل التفاعلات خلال الزيارة لا التفاعل الأول فقط.
• الترتيب في جوجل: تقول جوجل إن أنظمة الترتيب تستخدم هذه المؤشرات، لكن الصلة بموضوع البحث تأتي أولاً، ولا توجد إشارة واحدة اسمها تجربة الصفحة.
• الواقع في 2025: بحسب Web Almanac، اجتازت 48% فقط من مواقع الجوال المؤشرات الثلاثة، وكان LCP أصعبها.

ما هي مؤشرات أداء الويب الأساسية؟

مؤشرات أداء الويب الأساسية هي مجموعة من ثلاثة مقاييس تحددها جوجل لقياس جودة تجربة المستخدم في الصفحة: سرعة ظهور المحتوى الرئيسي، وسرعة استجابة الصفحة للنقر والكتابة، وثبات العناصر أثناء التحميل. ويشرح موقع web.dev التابع لجوجل أن الصفحة تجتاز التقييم حين تحقق الحدود الموصى بها في المقاييس الثلاثة معاً.

LCP: متى يظهر المحتوى الرئيسي؟

مقياس أكبر عرض للمحتوى (Largest Contentful Paint) يقيس الوقت حتى يظهر أكبر عنصر مرئي في الشاشة الأولى، وغالباً يكون صورة المنتج الرئيسية أو صورة البانر أو فقرة نص كبيرة. هو أقرب مقياس لإحساس الزائر بأن «الصفحة فتحت».

INP: هل تستجيب الصفحة حين أضغط؟

مقياس التفاعل مع العرض التالي (Interaction to Next Paint) يراقب النقرات واللمسات وضغطات لوحة المفاتيح طوال الزيارة، ويقيس المدة بين التفاعل وظهور نتيجته على الشاشة، ثم يعتمد أطولها مع تجاهل القيم الشاذة، كما يوضح شرح INP على web.dev.

CLS: هل تقفز العناصر أمام الزائر؟

مقياس التحول التراكمي للتخطيط (Cumulative Layout Shift) يقيس الإزاحات غير المتوقعة للعناصر المرئية. كل مرة يتحرك فيها نص أو زر لأن شيئاً ظهر فوقه فجأة، ترتفع قيمة CLS.

ما الحدود الرسمية لكل مؤشر؟

تقيس جوجل كل مؤشر عند الشريحة المئوية 75 من زيارات الصفحة، مع فصل الجوال عن سطح المكتب. بمعنى أن 75% من الزيارات على الأقل يجب أن تحقق الحد الجيد حتى تُصنف الصفحة «جيدة» في هذا المؤشر. هذه هي الحدود كما يعرضها تقرير Search Console وصفحات web.dev:

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

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

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

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

لذلك طورت جوجل INP ليقيس الاستجابة طوال الزيارة. وبحسب إعلان فريق Chrome على web.dev، أصبح INP مؤشراً أساسياً رسمياً بدلاً من FID في 12 مارس 2024، وأُزيل FID من Search Console في التاريخ نفسه، مع فترة إيقاف تدريجي مدتها ستة أشهر في أدوات أخرى مثل PageSpeed Insights وCrUX. إن كنت تقرأ تقريراً أو مقالاً ما زال يتحدث عن FID كمؤشر أساسي، فهو قديم.

هل تؤثر سرعة الموقع على ترتيبك في جوجل؟

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

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

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

أين تقف أغلب المواقع اليوم؟

إن كانت صفحاتك لا تجتاز التقييم، فأنت لست وحدك. يرصد فصل الأداء في تقرير Web Almanac لعام 2025، المبني على بيانات HTTP Archive وتقرير تجربة مستخدمي Chrome (CrUX)، أن 48% من مواقع الجوال حققت نتائج جيدة في المؤشرات الثلاثة في 2025، صعوداً من 44% في 2024 و36% في 2023. أما على سطح المكتب فبلغت النسبة 56%.

وعند النظر إلى كل مؤشر على حدة في الجوال، حققت 62% من المواقع نتيجة جيدة في LCP، و77% في INP، بينما حققت 81% من الصفحات نتيجة جيدة في CLS. أي أن التحميل السريع للمحتوى الرئيسي هو العقبة الأكبر لأغلب المواقع، وهو المكان الأول الذي نبدأ منه عادة.

كيف تقيس سرعة موقعك: بيانات حقيقية أم بيانات مختبر؟

هنا يخطئ كثيرون. هناك نوعان من البيانات، ولكل منهما دور:

• بيانات الميدان (Field data): قياسات من زوار حقيقيين يستخدمون Chrome، تُجمع في تقرير CrUX. هذه هي البيانات التي يعتمد عليها تقرير مؤشرات أداء الويب الأساسية في Search Console.
• بيانات المختبر (Lab data): اختبار محاكى لتحميل الصفحة، مثل درجة Lighthouse في PageSpeed Insights. مفيدة لتشخيص السبب وتجربة الإصلاح، لكنها لا تمثل تجربة زوارك بالضرورة.

بحسب مركز مساعدة Search Console، يجمع التقرير الصفحات المتشابهة في التجربة ضمن مجموعات، وتأخذ كل مجموعة حالة أضعف مؤشر فيها لكل نوع جهاز. وبعد إصلاح مشكلة يمكنك بدء تتبع الإصلاح من داخل التقرير (Start Tracking)، فتبدأ فترة مراقبة مدتها 28 يوماً. لا تتوقع أن تتغير الأرقام في اليوم التالي.

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

كيف تحسّن LCP؟

يقسّم دليل تحسين LCP على web.dev زمن LCP إلى أربعة أجزاء: زمن وصول أول بايت من الخادم (TTFB)، والتأخير قبل بدء تحميل الصورة الرئيسية، ومدة تحميلها، ثم التأخير حتى تُعرض. معرفة الجزء الأطول تحدد أين تبدأ.

• لا تؤجل تحميل الصورة الرئيسية: يقول الدليل صراحة إن التحميل الكسول (Lazy loading) لصورة LCP يضيف دائماً تأخيراً غير ضروري. استخدمه للصور أسفل الصفحة فقط.
• اجعلها قابلة للاكتشاف مبكراً: ضع الصورة في HTML مباشرة، لا عبر JavaScript أو خلفية CSS فقط، وأعطها الأولوية بالسمة fetchpriority بقيمة high.
• خفف حجمها: مقاس مناسب للجوال، وصيغ حديثة، وضغط جيد، وشبكة توصيل محتوى (CDN).
• قلل ما يعطل العرض: ملفات CSS الكبيرة والسكربتات المتزامنة في رأس الصفحة تؤخر ظهور المحتوى حتى بعد وصول الصورة.

وإن كان زمن استجابة الخادم هو الجزء الأطول، فالمشكلة قبل الصورة أصلاً. ينصح الدليل هنا بتقليل التحويلات (Redirects) قدر الإمكان، والتأكد من أن شبكة توصيل المحتوى تقدّم النسخ المخزنة فعلاً، وتجنب معاملات الروابط الفريدة التي تتجاوز التخزين المؤقت، فبعض معاملات التتبع في الروابط قد تجعل كل طلب يبدو كصفحة جديدة لم تُخزَّن من قبل.

مثال افتراضي: صفحة منتج على الجوال

لنفترض متجر عبايات تُظهر بيانات الميدان أن LCP لصفحة المنتج على الجوال 4.6 ثانية، أي في خانة «ضعيف». بالفحص في PageSpeed Insights يتبين أن الصورة الرئيسية بعرض 3000 بكسل، ومحمّلة بأسلوب كسول لأن القالب يطبق ذلك على كل الصور، ويسبقها ملف CSS كبير يعطل العرض.

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

كيف تحسّن INP؟

كل تفاعل يمر بثلاث مراحل كما يشرح دليل تحسين INP: انتظار قبل بدء المعالجة، ثم المعالجة نفسها، ثم تأخير حتى يرسم المتصفح النتيجة. والسبب المشترك في الغالب هو انشغال الخيط الرئيسي للمتصفح بمهام JavaScript طويلة.

في المتاجر الإلكترونية تحديداً، المتهم الأول عادة هو تراكم السكربتات: أدوات المحادثة، والبكسلات، والنوافذ المنبثقة، وتطبيقات المراجعات. كل واحدة تبدو خفيفة، ومجموعها يجعل زر الإضافة إلى السلة بطيئاً. راجع كل سكربت واسأل: هل ما زلنا نستخدمه؟ وهل يمكن تأجيل تحميله؟ أما على مستوى البرمجة، فينصح الدليل بتخفيف العمل داخل معالجات الأحداث، وتقسيم المهام الطويلة، وتقليل حجم DOM.

كيف تحسّن CLS؟

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

خطوات عملية لتحسين سرعة موقعك

1. افتح تقرير مؤشرات أداء الويب الأساسية في Search Console وابدأ بقسم الجوال، وحدد المؤشر الأضعف ومجموعات الصفحات المتأثرة.
2. اختر صفحة نموذجية من كل مجموعة وافحصها في PageSpeed Insights لتقارن بيانات الميدان ببيانات المختبر.
3. ابدأ بالقوالب لا بالصفحات: إصلاح قالب صفحة المنتج يصلح مئات الصفحات دفعة واحدة.
4. عالج LCP أولاً: الصورة الرئيسية، وأولوية تحميلها، وحجمها، وزمن استجابة الخادم.
5. نظّف السكربتات الخارجية: احذف ما لا تستخدمه، وأجّل ما ليس ضرورياً للتفاعل الأول.
6. ثبّت التخطيط: أبعاد لكل صورة، ومساحات محجوزة للعناصر المتغيرة.
7. ابدأ تتبع الإصلاح في Search Console وتابع فترة الـ 28 يوماً، ثم أعد القياس بعد أي إضافة جديدة للموقع.

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

أخطاء شائعة في تحسين سرعة الموقع

• مطاردة درجة 100 في Lighthouse: الدرجة اختبار مختبر، وما يهم هو تجربة زوارك الحقيقيين في بيانات الميدان.
• الاختبار من حاسوب المكتب فقط: زوارك على جوالات متفاوتة القوة وشبكات مختلفة، والحدود تُقاس للجوال منفصلة.
• التحميل الكسول لكل الصور: بما فيها الصورة الرئيسية، وهو ما يرفع LCP بدل أن يخفضه.
• تثبيت إضافة جديدة بلا مراجعة: كل تطبيق أو بكسل إضافي له كلفة على الاستجابة.
• الاعتماد على FID في التقارير: أي تقرير يقيّم الاستجابة بـ FID لم يعد يعكس المعيار الحالي.

السرعة واحدة من أركان السيو التقني، لا كلها. لترى أين تقع ضمن الصورة الكاملة، راجع دليل السيو الشامل.

أسئلة شائعة

ما هي حدود مؤشرات أداء الويب الأساسية الجيدة؟

تعد جوجل الصفحة جيدة حين يكون LCP بحد أقصى 2.5 ثانية، وINP بحد أقصى 200 ملي ثانية، وCLS بحد أقصى 0.1. يُقاس ذلك عند الشريحة المئوية 75 من زيارات الصفحة، أي أن 75% من الزيارات على الأقل يجب أن تحقق الحد، مع فصل نتائج الجوال عن سطح المكتب.

هل ما زال FID من مؤشرات أداء الويب الأساسية؟

لا. حلّ INP محل FID رسمياً في 12 مارس 2024، وأُزيل FID من Search Console في التاريخ نفسه. السبب أن FID يقيس تأخير أول تفاعل فقط، بينما يقيس INP استجابة الصفحة لكل النقرات واللمسات وضغطات المفاتيح طوال الزيارة، فيعطي صورة أدق عن تجربة الزائر.

هل تؤثر سرعة الموقع على ترتيبه في جوجل؟

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

لماذا تختلف نتيجة PageSpeed Insights عن تقرير Search Console؟

لأن Search Console يعتمد على بيانات الميدان من زوار حقيقيين عبر تقرير CrUX، بينما درجة Lighthouse في PageSpeed Insights اختبار مختبر محاكى لتحميل واحد. بيانات الميدان هي ما يعكس تجربة زوارك، وبيانات المختبر مفيدة لتشخيص المشكلة وتجربة الحلول قبل نشرها.

كم يستغرق ظهور أثر تحسين السرعة في Search Console؟

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

ما أكثر مؤشر تفشل فيه المواقع عادة؟

بحسب تقرير Web Almanac لعام 2025، كان LCP أصعب المؤشرات على الجوال، إذ حققت 62% فقط من مواقع الجوال نتيجة جيدة فيه، مقابل 77% في INP و81% في CLS. لهذا يبدأ التحسين غالباً بالصورة الرئيسية وسرعة الخادم وأولوية تحميل المحتوى الظاهر أولاً.

اقرأ أيضًا

1. دليل السيو الشامل: من الصفر إلى الاحتراف 2026
2. التسويق الإلكتروني: دليلك الشامل من الصفر (2026)
3. الذكاء الاصطناعي في التسويق: الدليل العملي لمضاعفة نتائجك (2026)

موقعك بطيء على الجوال وإعلاناتك تدفع الثمن؟

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

اطلب تصميم موقع سريع ←

المصادر

1. Web Vitals — web.dev (Google Chrome)
2. Interaction to Next Paint becomes a Core Web Vital on March 12 — web.dev (Google Chrome)
3. Interaction to Next Paint (INP) — web.dev (Google Chrome)
4. Understanding page experience in Google Search results — Google Search Central
5. Understanding Core Web Vitals and Google search results — Google Search Central
6. Core Web Vitals report — Google Search Console Help
7. Optimize Largest Contentful Paint — web.dev (Google Chrome)
8. Optimize Interaction to Next Paint — web.dev (Google Chrome)
9. Cumulative Layout Shift (CLS) — web.dev (Google Chrome)
10. Performance chapter, Web Almanac 2025 — HTTP Archive