جاء الزائر إلى موقعك، لكن الصفحة لم تفتح، ضغط على زر فلم يحدث شيء، بدأ القراءة فانزلق النص إلى الأسفل. لكل واحدة من هذه الخيبات الصغيرة الثلاث اسم لدى Google: Core Web Vitals. وأوضح طريق لقياس سرعة الموقع وتحسينها يمر عبر هذه المقاييس الثلاثة.
في هذا المقال نشرح ماهية Core Web Vitals، والعتبات “الجيدة” الحالية لمقاييس LCP وINP وCLS، وبأي أدوات وكيف تقيس هذه القيم بشكل صحيح، والتحسينات الأكثر تأثيرًا لكل منها.
حتى إن لم يكن لديك فريق تقني، ستتمكن في نهاية المقال من فحص وضع موقعك بنفسك وطرح الأسئلة الصحيحة على وكالتك أو مطوّرك.
لماذا سرعة الموقع مسألة تخص العملاء وSEO معًا؟
الموقع البطيء يُفقدك المستخدم أولًا. فالزائر الذي يحدّق في شاشة فارغة لبضع ثوانٍ على اتصال الجوال يعود إلى البحث وينقر على النتيجة التالية. وهذا يعني خسارة مالية مباشرة في الحركة التي جلبتها بالإعلانات.
أما على جانب Google، فإن Core Web Vitals من الإشارات التي تأخذها أنظمة الترتيب في الحسبان ضمن “تجربة الصفحة”. يصرّح Google Search Central بذلك بوضوح؛ لكنه يؤكد في الوثيقة نفسها أن صلة المحتوى لا تزال أكثر حسمًا بكثير. أي أن الصفحة السريعة ضعيفة المحتوى لا ترتقي إلى المراتب العليا؛ أما بين صفحتين متقاربتين في الجودة فقد تُحدث التجربة فرقًا.
السرعة وحدها لا تجعلك الأول، لكن البطء يتركك في الخلف بسهولة.
مقاييس Core Web Vitals وقيم العتبات لعام 2026
تتكون Core Web Vitals من ثلاثة مقاييس. يقيس كل منها جانبًا مختلفًا من تجربة المستخدم: التحميل، والتفاعل، والاستقرار البصري.
| المقياس | ماذا يقيس؟ | جيد | يحتاج إلى تحسين | ضعيف |
|---|---|---|---|---|
| LCP (Largest Contentful Paint) | مدة ظهور أكبر صورة أو كتلة نصية في الصفحة على الشاشة | ≤ 2.5 ث | 2.5–4 ث | > 4 ث |
| INP (Interaction to Next Paint) | مدة استجابة الصفحة بصريًا للنقرات واللمسات وضغطات المفاتيح | ≤ 200 ms | 200–500 ms | > 500 ms |
| CLS (Cumulative Layout Shift) | الانزياح غير المتوقع للعناصر أثناء فتح الصفحة واستخدامها | ≤ 0,1 | 0,1–0,25 | > 0.25 |
تفصيل مهم: يقيّم Google هذه القيم وفق الشريحة المئوية 75 من المستخدمين الحقيقيين. أي يجب أن تبقى 75 بالمئة من الزيارات على الأقل ضمن العتبة “الجيدة”. ولكي تجتاز الصفحة Core Web Vitals يجب أن تكون المقاييس الثلاثة جيدة؛ فإن كان أحدها ضعيفًا لا يُؤخذ المتوسط.
كيف تُقاس Core Web Vitals: البيانات الميدانية وبيانات المختبر
أكثر الأخطاء شيوعًا في القياس هو اتخاذ القرار بالنظر إلى درجة PageSpeed واحدة. فهناك نوعان من البيانات، ولكل منهما دلالة مختلفة:
- البيانات الميدانية (field data): هي بيانات Chrome UX Report (CrUX) المجمّعة من التجارب الحقيقية لمستخدمي Chrome. وهي البيانات التي يأخذها Google في الحسبان عند الترتيب، وتعكس متوسط آخر 28 يومًا.
- بيانات المختبر (lab data): هي اختبار يجريه Lighthouse على جهاز واتصال محاكَيين واحدين. وهي مثالية لتشخيص المشكلات، لكنها لا تعكس تجربة المستخدم الحقيقية حرفيًا. ولا يمكنها قياس INP مباشرة؛ بل يُنظر بدلًا منه إلى قيمة Total Blocking Time (TBT).
أي أداة تُستخدم ولأي غرض؟
- PageSpeed Insights: يعرض البيانات الميدانية وبيانات المختبر معًا لعنوان واحد. اعتمد على قسم “تجربة المستخدم الحقيقية” في الأعلى.
- Search Console — تقرير Core Web Vitals: يقسم موقعك كله إلى مجموعات صفحات متشابهة ويعرض عناوين URL الضعيفة على الجوال وسطح المكتب.
- Chrome DevTools (لوحة Performance): أداة المطوّرين لتحديد أسباب التفاعلات البطيئة والانزياحات سطرًا بسطر.
- مكتبة web-vitals: مكتبة JavaScript صغيرة من Google لإرسال قياسات المستخدمين الحقيقيين إلى أداة التحليلات الخاصة بك.
كيف يُحسَّن LCP: أظهر المحتوى الرئيسي بشكل أسرع
في معظم مواقع الشركات يكون عنصر LCP هو الصورة الكبيرة (hero) أعلى الصفحة أو العنوان الرئيسي. وتتكون مدة LCP من أربعة أجزاء: الاستجابة الأولى للخادم (TTFB)، واكتشاف المورد، وتنزيله، ورسمه على الشاشة. ويُجرى التحسين بهذا الترتيب أيضًا.
- سرّع استجابة الخادم: يعدّ web.dev قيمة 0.8 ثانية فأقل جيدة لـ TTFB. وتقلل ذاكرة التخزين المؤقت للصفحات والاستضافة الجيدة وCDN هذه المدة بشكل ملحوظ.
- اجعل صورة LCP تُكتشف مبكرًا: ضع الصورة مباشرة في HTML لا كخلفية CSS أو عبر JavaScript؛ وأعطها الأولوية باستخدام fetchpriority="high".
- لا تطبّق التحميل الكسول على صورة أعلى الصفحة: التحميل الكسول مخصص للصور أسفل الشاشة؛ وعلى الصورة الرئيسية يؤخر LCP.
- صغّر الصورة: باستخدام صيغة WebP أو AVIF والحجم الصحيح وsrcset، تجنّب تنزيل ملفات كبيرة بلا داعٍ على الجوال.
- قلّل الموارد التي تعيق العرض: قدّم CSS الحرج، وأزل CSS غير المستخدم والسكربتات المحمّلة بشكل متزامن، واستخدم font-display: swap للخطوط.
أما أثر قرارات الاستضافة على السرعة اختيار اسم النطاق والاستضافة ضمن مقال مستقل.
كيف يُحسَّن INP: استجب للنقرات فورًا
تنشأ مشكلة INP عادةً من انشغال الخيط الرئيسي (main thread) للمتصفح بـ JavaScript. يلمس المستخدم القائمة، لكن الاستجابة تتأخر لأن المتصفح ينفّذ في تلك اللحظة سكربت تحليلات أو شيفرة شريط عرض (slider) كبيرة.
- قسّم المهام الطويلة: جزّئ مهام JavaScript التي تتجاوز 50 ms؛ وقدّم الاستجابة البصرية للمستخدم أولًا، ثم نفّذ العمل الثقيل.
- راجع سكربتات الأطراف الثالثة: فقاعات الدردشة، وأدوات الخرائط الحرارية، ووسوم الإعلانات والتحليلات المتعددة هي أكثر المتسببين شيوعًا في INP. أبقِ ما تستخدمه فعلًا، وحمّل الباقي بشكل مؤجل.
- أبقِ DOM صغيرًا: في الصفحات التي تحتوي آلاف العناصر يصبح إعادة الرسم بعد كل تفاعل مكلفًا.
- خفّف عبء الإضافات والقوالب: الشيفرات غير المستخدمة التي تحمّلها القوالب الجاهزة في كل صفحة تبطئ التفاعل، خاصة على الهواتف منخفضة المواصفات.
عند هذه النقطة يصبح اختيار البنية التحتية حاسمًا. أما الفرق بين موقع يكبر بالإضافات وموقع خفيف مكتوب حسب الحاجة WordPress أم برمجيات مخصصة بالتفصيل.
كيف يُحسَّن CLS: امنع انزياح الصفحة
انزلاق السطر الذي تقرؤه فجأة إلى الأسفل، أو تغيّر موضع الزر لحظة النقر عليه، هو ما يقيسه CLS. ولحسن الحظ فإن الحلول بسيطة عادةً:
- حدّد أبعاد الصور ومقاطع الفيديو: بخاصيتي width وheight أو عبر CSS aspect-ratio يحجز المتصفح المساحة مسبقًا.
- خصّص مساحة ثابتة للإعلانات واللافتات والمحتوى المضمّن: لا تدع إشعار ملفات تعريف الارتباط أو شريط الحملة المحمّل لاحقًا يدفع المحتوى؛ بل اجعله يفتح كطبقة علوية (overlay).
- خفّف أثر تبديل الخطوط: حمّل خط الويب مسبقًا واجعل مقاسات الخط الاحتياطي قريبة منه.
- استخدم transform في الحركات: نفّذ الحركات بـ transform وopacity بدلًا من الخصائص التي تؤثر في التخطيط مثل top وleft وheight.
أكثر مشكلات السرعة شيوعًا حسب نوع الموقع
لا تبطؤ كل المواقع للسبب نفسه. وإن لخّصنا ما نصادفه في المشاريع حسب نوع الموقع:
| نوع الموقع | المشكلة الأكثر شيوعًا | أول ما يجب فحصه |
|---|---|---|
| موقع شركة بقالب جاهز | قالب ثقيل، وعدد كبير من الإضافات، وصور شرائح عرض كبيرة | الإضافات غير المستخدمة، وحجم الصورة الرئيسية، وذاكرة التخزين المؤقت للصفحات |
| موقع تجارة إلكترونية | صور المنتجات، والمرشحات، وعدد كبير من وسوم التتبع والتسويق | LCP صفحة الفئة، وسكربتات الأطراف الثالثة، وINP تفاعلات السلة |
| تطبيق صفحة واحدة (React وVue وغيرهما) | حزم JavaScript كبيرة، وتأخر تكوّن المحتوى في المتصفح | العرض من جانب الخادم أو العرض المسبق، وتقسيم الشيفرة |
| موقع أخبار ومدونة | تحميل مساحات الإعلانات لاحقًا وإزاحتها للمحتوى | مساحات ثابتة مخصصة لخانات الإعلانات، CLS |
هذا الجدول نقطة انطلاق؛ فالتشخيص القاطع يكون دائمًا بالقياس. ومع ذلك فإن معرفة الموضع المرجح للمشكلة توفر الوقت عند الحديث مع المطوّر. فمثلًا، إن كانت صفحة تفاصيل المنتج سريعة في موقع تجارة إلكترونية بينما صفحة الفئة بطيئة، فالمشكلة غالبًا هي تنزيل عشرات الصور المعروضة دفعة واحدة وبحجمها الكامل.
إن كنت تستهدف تجربة سريعة وخفيفة تمنح إحساس تطبيق الجوال، فيجب مناقشة ذلك في مرحلة التصميم. فكل ميزة “صغيرة” تُضاف إلى الصفحة لاحقًا تأخذ حصة من ميزانية السرعة.
خطة خطوة بخطوة لزيادة سرعة الموقع
بدلًا من محاولة إصلاح كل شيء دفعة واحدة، ابدأ بالأكبر أثرًا:
- الخطوة 1 — افتح تقرير Core Web Vitals في Search Console، وأدرج مجموعات الصفحات “الضعيفة” على الجوال.
- الخطوة 2 — اختبر عنوانًا نموذجيًا من كل مجموعة في PageSpeed Insights، ودوّن المقياس المتعثر.
- الخطوة 3 — عالج أولًا المشكلات على مستوى القوالب: فمئات الصفحات التي تستخدم القالب نفسه تتحسن بإصلاح واحد.
- الخطوة 4 — طبّق المكاسب السريعة مثل الصور والتخزين المؤقت وCDN؛ ثم انتقل إلى JavaScript وسكربتات الأطراف الثالثة.
- الخطوة 5 — اختر “التحقق من الإصلاح” في Search Console وانتظر تحديث البيانات الميدانية خلال 28 يومًا.
السرعة ليست مشروعًا لمرة واحدة، بل ميزانية يجب الحفاظ عليها باستمرار. فإضافة جديدة أو صورة كبيرة أو شيفرة تتبع إضافية قد تمحو المكاسب خلال أسابيع قليلة. لذلك اطرح قبل إضافة أي ميزة جديدة سؤال: “كم سيبطئ هذا الصفحة؟”. وإن أردت رؤية مكانة السرعة في الظهور في البحث ضمن إطار أوسع قائمة التحقق الخاصة بـ SEO التقني لدينا يمكنك الاطلاع عليها أيضًا.
- هل LCP على الجوال أقل من 2.5 ثانية؟
- هل INP أقل من 200 ms، وهل أُزيلت سكربتات الأطراف الثالثة غير الضرورية؟
- هل CLS أقل من 0.1، وهل الأبعاد محددة في جميع الصور؟
- هل تُحمَّل الصورة الرئيسية بأولوية ودون تحميل كسول؟
- هل الصور بصيغة WebP/AVIF وبالحجم الصحيح؟
- هل ذاكرة التخزين المؤقت للصفحات والضغط وCDN مفعّلة؟
- هل يُتابَع تقرير Core Web Vitals في Search Console بانتظام؟
الأسئلة الشائعة
ما هي Core Web Vitals؟
Core Web Vitals ثلاثة مقاييس حددتها Google لقياس تجربة المستخدم الحقيقية: LCP لسرعة التحميل، وINP للاستجابة للتفاعل، وCLS للاستقرار البصري. وتُستخدم هذه المقاييس في تقييم Google لتجربة الصفحة.
كم ثانية تعدّ قيمة LCP جيدة؟
بحسب Google، يُعدّ LCP جيدًا إن كان 2.5 ثانية أو أقل، وضعيفًا إن تجاوز 4 ثوانٍ. ويُجرى التقييم وفق الشريحة المئوية 75 من زيارات المستخدمين الحقيقيين.
لماذا حلّ INP محل FID؟
كان FID يقيس فقط تأخر التفاعل الأول في الصفحة، وكانت معظم المواقع تجتاز هذا الاختبار بسهولة. أما INP فيتابع جميع التفاعلات في الصفحة ويُبلغ عن أحد أبطئها؛ لذلك يعكس تجربة المستخدم الحقيقية بشكل أفضل. وقد دخل التغيير حيز التنفيذ في مارس 2024.
إن لم تكن درجة PageSpeed 100، فهل يكون SEO لموقعي سيئًا؟
لا. درجة Lighthouse اختبار مختبري وليست إشارة ترتيب مباشرة. المهم أن تكون قيم LCP وINP وCLS في بيانات المستخدمين الحقيقيين ضمن العتبات الجيدة. فالصفحة ذات الدرجة 85 والبيانات الميدانية الجيدة أكثر دلالة من نتيجة اختبار بدرجة 100.
متى تنعكس إصلاحات Core Web Vitals؟
لأن البيانات الميدانية تستند إلى تجربة المستخدمين في آخر 28 يومًا، يستغرق انعكاس الإصلاحات كاملة على التقارير نحو أربعة أسابيع. أما في اختبارات المختبر فيمكنك رؤية التحسن فورًا.
كلمة أخيرة
تختزل Core Web Vitals إحساس الزائر بموقعك في ثلاثة أرقام: أن يظهر المحتوى الرئيسي خلال 2.5 ثانية، وأن تلقى كل نقرة استجابة خلال 200 ميلي ثانية، وأن يبقى انزياح الصفحة أقل من 0.1. وهذه الأهداف لا تتطلب غالبًا إعادة بناء مكلفة، بل تشخيصًا صحيحًا وإصلاحات صغيرة منضبطة.
في CYF Tech نصمم مواقع الويب وبرمجيات الويب التي نطوّرها بميزانية سرعة منذ البداية، كما نجري تحليل Core Web Vitals وتحسينها للمواقع القائمة. وإن أردت أن نكتشف معًا سبب بطء موقعك تواصل معنا.
- web.dev — Web Vitals
- web.dev — How the Core Web Vitals metrics thresholds were defined
- web.dev — Largest Contentful Paint (LCP)
- web.dev — Interaction to Next Paint (INP)
- web.dev — Cumulative Layout Shift (CLS)
- web.dev — Time to First Byte (TTFB)
- Google Search Central — Understanding Core Web Vitals and Google search results
- Google Search Central — Understanding page experience