مؤشرات Core Web Vitals للمتاجر الإلكترونية: شرح LCP وINP وCLS

ما الذي تقيسه LCP وINP وCLS، وحدود «جيد» و«ضعيف» عند المئين 75، والفرق بين بيانات المختبر والبيانات الميدانية، والإصلاحات المعتادة في متاجر Shopify وWooCommerce.

فريق تحرير FixReportsمدة القراءة: 12 دقيقة

مؤشرات أداء الويب الأساسية (Core Web Vitals) هي ثلاثة مقاييس من Google تصف تجربة الزوار الحقيقيين مع الصفحة: Largest Contentful Paint (LCP) للتحميل، وInteraction to Next Paint (INP) للاستجابة، وCumulative Layout Shift (CLS) للاستقرار البصري. وتجتاز الصفحة التقييم عندما تقع 75% من الزيارات على الأقل ضمن النطاق «الجيد»: LCP خلال 2.5 ثانية، وINP خلال 200 ms، وCLS بقيمة 0.1 أو أقل، مع قياس الهاتف المحمول وسطح المكتب كلٌّ على حدة. وفي المتاجر الإلكترونية، تعود النتائج المتعثرة عادةً إلى صور الواجهة الرئيسية وصور المنتجات الكبيرة أو المحمّلة تحميلًا مؤجّلًا، وسكربتات التطبيقات والتتبّع، وخطوط الويب، واللافتات أو أدوات المراجعات التي تدفع المحتوى إلى الأسفل بعد ظهور الصفحة.

أبرز النقاط

ما حدود مؤشرات Core Web Vitals؟

تستوفي الصفحة مؤشرات Core Web Vitals عندما يقع المئين 75 من مرات تحميلها ضمن النطاق الجيد في المقاييس الثلاثة جميعها.

المقياسما الذي يقيسهجيديحتاج إلى تحسينضعيف
LCPالوقت حتى يُعرض أكبر عنصر صورة أو فيديو أو كتلة نصية في منطقة العرض2.5 ثانية أو أقلأكثر من 2.5 ثانية حتى 4.0 ثانيةأكثر من 4.0 ثانية
INPالوقت من النقر أو اللمس أو الضغط على مفتاح حتى رسم الإطار التالي200 ms أو أقلأكثر من 200 ms حتى 500 msأكثر من 500 ms
CLSمقدار تحرّك المحتوى المرئي بشكل غير متوقع0.1 أو أقلأكثر من 0.1 حتى 0.25أكثر من 0.25

الحدود مأخوذة من أدلة web.dev الخاصة بـLCP (يفتح في علامة تبويب جديدة) وINP (يفتح في علامة تبويب جديدة) وCLS (يفتح في علامة تبويب جديدة)، كما كانت في أكتوبر 2026.

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

في المتجر، يكون عنصر LCP غالبًا لافتة الواجهة الرئيسية (hero) أو صورة المنتج الرئيسية، ولهذا تكتسب طريقة التعامل مع الصور كل هذه الأهمية.

لماذا حلّ INP محل FID في مارس 2024؟

حلّ INP محل FID لأن FID كان يقيس التفاعل الأول فقط وجزءًا من تأخيره فقط، بينما ينظر INP إلى التفاعلات طوال الزيارة.

أعلنت Google في مايو 2023 أن INP سيصبح من مؤشرات Core Web Vitals، ودخل التغيير حيز التنفيذ في 12 مارس 2024 (يفتح في علامة تبويب جديدة). كان FID يرصد التفاعل الأول فقط، وتأخير الإدخال فيه فقط، دون الوقت المستغرق في تشغيل معالجات الأحداث أو رسم النتيجة. أما INP فيرصد النقرات واللمسات وضغطات المفاتيح طوال الزيارة ويُبلغ عن أطولها، مع تجاهل القيم الشاذة؛ ولا يُحتسب التمرير ولا مرور المؤشر فوق العناصر. وكان أمام مستخدمي واجهتي CrUX وPageSpeed Insights البرمجيتين مهلة حتى 9 سبتمبر 2024 للتحوّل (web.dev (يفتح في علامة تبويب جديدة)).

لكل تفاعل ثلاثة أجزاء: تأخير الإدخال (انتظار السكربتات المشغولة)، ومدة المعالجة (تشغيل المعالجات)، وتأخير العرض (رسم الإطار التالي) (web.dev (يفتح في علامة تبويب جديدة)).

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

ما الفرق بين بيانات المختبر والبيانات الميدانية؟

تأتي بيانات المختبر من اختبار واحد في ظروف ثابتة، بينما تُجمع البيانات الميدانية من زوار حقيقيين على مدى فترة من الزمن، وتوصي Google باستخدام البيانات الميدانية لتحديد ما يجب إصلاحه أولًا (web.dev (يفتح في علامة تبويب جديدة)).

بيانات المختبرالبيانات الميدانية
المصدرتحميل صفحة واحد بالمحاكاة (Lighthouse، وChrome DevTools، وقسم المختبر في PageSpeed Insights)زوار Chrome الحقيقيون (Chrome UX Report)، أو نظامك الخاص لمراقبة المستخدمين الحقيقيين
الظروفجهاز وشبكة ثابتان. يستخدم اختبار الهاتف المحمول الافتراضي في Lighthouse (يفتح في علامة تبويب جديدة) ملف «Slow 4G» (زمن ذهاب وإياب 150 ms، وسرعة تنزيل 1.6 Mbps) وإبطاءً للمعالج بمقدار 4xأي أجهزة وشبكات ومواقع جغرافية لدى زوارك
INPلا يُقاس عند تحميل صفحة عادي. ويُعدّ Total Blocking Time (TBT) بديلًا تقريبيًايُقاس من تفاعلات حقيقية
الأنسب لـتصحيح الأخطاء والتحقق من التغيير قبل إطلاقهمعرفة ما يحصل عليه الزوار فعلًا

يجمع TBT الجزء الذي يتجاوز 50 ms من كل مهمة على الخيط الرئيسي؛ ويقترح web.dev أن يكون أقل من 200 ms على أجهزة الهاتف المتوسطة، لكنه يقول إنه ليس بديلًا عن INP (web.dev (يفتح في علامة تبويب جديدة)).

ثلاث تفاصيل في تقرير تجربة مستخدمي Chrome (CrUX) تهمّ المتاجر:

  • هو متوسط متحرك لمدة 28 يومًا (يفتح في علامة تبويب جديدة) يُحدَّث يوميًا.
  • يغطي Chrome على سطح المكتب وAndroid للمستخدمين الذين يستوفون شروط الإبلاغ في Chrome. ويُستثنى Chrome على iOS، لذا فإن المتجر الذي يغلب على متسوقيه مستخدمو iPhone لا يرى بيانات ميدانية إلا من جزء من جمهوره (المنهجية (يفتح في علامة تبويب جديدة)).
  • لا تظهر الصفحات والنطاقات الأصلية (origins) إلا إذا كانت قابلة للاكتشاف علنًا وتحظى بشعبية كافية، لذا قد لا تتوفر للمتجر قليل الزيارات إلا بيانات على مستوى النطاق الأصلي، أو لا تتوفر له بيانات على الإطلاق.

كما تعرض لوحة أداء الويب (يفتح في علامة تبويب جديدة) في Shopify قيم LCP وINP وCLS من المستخدمين الحقيقيين عند المئين 75، لكن على مدى 30 يومًا بدلًا من 28، لذا توقّع بعض الاختلافات عن CrUX.

ما الذي يبطئ LCP في صفحات المتجر؟

يكون LCP بطيئًا في المتاجر عادةً لأن الصورة الرئيسية ثقيلة جدًا، أو تُكتشف متأخرة، أو تُؤخَّر عمدًا بالتحميل المؤجّل أو بحركة انتقالية.

  • التحميل المؤجّل لصورة LCP. يقول web.dev إنه لا ينبغي فعل ذلك أبدًا (web.dev (يفتح في علامة تبويب جديدة)). ووجد تحليله لصفحات WordPress أن LCP عند المئين 75 كان أبطأ في المواقع التي تستخدم التحميل المؤجّل الأصلي في المتصفح، وأن إلغاء التحميل المؤجّل للصور الظاهرة في الشاشة الأولى أزال هذا التراجع (web.dev (يفتح في علامة تبويب جديدة)).
  • صورة تُكتشف متأخرة. صورة الواجهة الرئيسية المضبوطة كخلفية CSS عبر background-image، أو التي يحقنها سكربت شرائح العرض، ليست موجودة في HTML الذي يفحصه المتصفح أولًا. وتنصح Shopify بعدم استخدام خلفيات CSS لمحتوى الواجهة الرئيسية، وبعدم استخدام تأثيرات الظهور التدريجي على صورة LCP (Shopify (يفتح في علامة تبويب جديدة)).
  • أولوية منخفضة. تُحمَّل الصور بأولوية منخفضة حتى يكتمل التخطيط، لذا توصي Shopify باستخدام fetchpriority="high" على صورة LCP (Shopify (يفتح في علامة تبويب جديدة)). ويشير web.dev إلى أن ضبطها على أكثر من صورة أو صورتين يقلل فائدتها (web.dev (يفتح في علامة تبويب جديدة)).
  • CSS والسكربتات التي تحجب العرض. تؤخر أوراق الأنماط الكبيرة والسكربتات المتزامنة في <head> العرض حتى بعد وصول الصورة (web.dev (يفتح في علامة تبويب جديدة)).
  • حجم الملفات والخطوط. استخدم الصيغ الحديثة، وsrcset وsizes، وشبكة توصيل محتوى (CDN). ولخطوط الويب، استخدم قيمة font-display غير auto أو block.
<!-- Main product image: real src in the HTML, eager, high priority -->
<img src="/images/linen-shirt-1200.webp"
     srcset="/images/linen-shirt-600.webp 600w, /images/linen-shirt-1200.webp 1200w"
     sizes="(min-width: 990px) 50vw, 100vw"
     width="1200" height="1500"
     fetchpriority="high"
     alt="Natural linen shirt, front view">

<!-- Gallery images below the first screen: lazy -->
<img src="/images/linen-shirt-back-600.webp" loading="lazy"
     width="600" height="750" alt="Natural linen shirt, back view">

ما الذي يجعل INP بطيئًا في صفحات المتجر؟

يعني بطء INP في المتاجر عادةً وجود قدر كبير جدًا من JavaScript على الخيط الرئيسي، معظمه من التطبيقات ووسوم التتبّع وميزات القالب، فتضطر اللمسات إلى الانتظار.

إذا لمس المتسوق زر «أضف إلى السلة» بينما لا تزال سكربتات المراجعات والدردشة والتحليلات قيد التشغيل، فإن اللمسة تنتظر. ومحدد الخيارات الذي يعيد عرض نموذج المنتج بالكامل يضيف وقتًا إلى المعالجة. أما القوائم الضخمة وشبكات المجموعات التي تحتوي على عينات ألوان (swatches) كثيرة فتضيف تأخيرًا إلى العرض.

يوصي web.dev بتقسيم المهام الطويلة وإفساح المجال للخيط الرئيسي (yielding)، وتحديث الشاشة أولًا وتأجيل الباقي، والإبقاء على DOM أصغر حجمًا (web.dev (يفتح في علامة تبويب جديدة)). وتضيف Shopify خطوات خاصة بالمتاجر: راجع كل تطبيق وبكسل تتبّع وسكربت في القالب، وأجّل ما ليس ضروريًا، وحمّل الميزات عند التفاعل، وأوقف مقتطفات منع الوميض (anti-flicker) الخاصة باختبارات A/B عندما لا يكون هناك اختبار قيد التشغيل (Shopify (يفتح في علامة تبويب جديدة)).

ما الذي يسبب إزاحات التخطيط في صفحات المنتجات والمجموعات؟

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

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

لا تُحتسب الإزاحات التي تحدث خلال 500 ms من إدخال المستخدم، لكن الإزاحات أثناء التمرير تُحتسب، وكثيرًا ما تفوتها أدوات المختبر (web.dev (يفتح في علامة تبويب جديدة)). امنح الصور width وheight أو خاصية CSS aspect-ratio، واحجز مساحة للأدوات، واعرض اللافتات كطبقات فوق المحتوى، وقلّل إزاحات تبديل الخطوط باستخدام size-adjust، واستخدم transform في الحركات بدلًا من top أو left.

/* Reserve space for a reviews summary that loads after the page */
.product-reviews-summary { min-height: 24px; }

/* Keep product cards from jumping while images load */
.product-card img { width: 100%; height: auto; aspect-ratio: 4 / 5; }

كيف تحسّن مؤشرات Core Web Vitals في Shopify؟

في Shopify، تأتي معظم المكاسب من تحميل الصورة الأولى فورًا بأولوية عالية، وتقليص سكربتات التطبيقات، والتحقق من النتيجة في تقارير أداء الويب في لوحة الإدارة.

تحقّق من البيانات في لوحة الإدارة

يظهر ملخص في صفحة Online Store > Themes، وتوجد تقارير LCP وINP وCLS الكاملة ضمن Analytics > Reports. وقد تتأخر البيانات حتى 36 ساعة، ويجب أن يكون الوضع الخاص (private mode) معطّلًا (مركز مساعدة Shopify (يفتح في علامة تبويب جديدة)).

تحكّم في تحميل الصور في Liquid

يحمّل فلتر image_tag الصور تحميلًا مؤجّلًا في الأقسام الأبعد أسفل الصفحة ما لم تضبط preload (مرجع image_tag (يفتح في علامة تبويب جديدة)): تحميل فوري للأقسام من 1 إلى 3، وتحميل مؤجّل بدءًا من القسم 4. ولأن قيمة section.index تكون nil في محرر القالب، اختبر الشرط > 3 بدلًا من <= 3:

{%- if section.index == 1 -%}
  {{ section.settings.image | image_url: width: 1600 | image_tag: loading: 'eager', fetchpriority: 'high', widths: '600, 900, 1200, 1600', sizes: '100vw' }}
{%- elsif section.index > 3 -%}
  {{ section.settings.image | image_url: width: 1600 | image_tag: loading: 'lazy', sizes: '100vw' }}
{%- else -%}
  {{ section.settings.image | image_url: width: 1600 | image_tag: sizes: '100vw' }}
{%- endif -%}

في شبكات المنتجات، تقترح Shopify التحميل الفوري لأول بضع بطاقات فقط (مثلًا forloop.index <= 4) (Shopify (يفتح في علامة تبويب جديدة)). واستخدم preload: true باعتدال؛ إذ توصي Shopify بالتحميل المسبق لمورد واحد أو موردين فقط من الموارد التي تُكتشف متأخرة.

أزل ما تتركه التطبيقات خلفها

أوقف تضمينات التطبيقات غير المستخدمة ضمن Online Store > Edit theme > App embeds (مركز مساعدة Shopify (يفتح في علامة تبويب جديدة)). إلغاء تثبيت التطبيق يزيل كتله، لكن التطبيقات التي عدّلت ملفات القالب مباشرةً قد تترك «شيفرة شبحية» (ghost code) تقول Shopify إنها قد تسبب مشكلات في الجودة والأداء (Shopify (يفتح في علامة تبويب جديدة)). وتقول Shopify أيضًا إن وسوم السكربت (script tags) ستتوقف عن العمل في 1 مارس 2027. وبالنسبة إلى الخطوط، توصي Shopify باستخدام شبكة CDN الخاصة بها أو خطوط النظام بدلًا من خدمات الخطوط الخارجية (Shopify (يفتح في علامة تبويب جديدة)).

كيف تحسّن مؤشرات Core Web Vitals في WooCommerce؟

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

  • حافظ على معالجة النواة للصور. منذ WordPress 6.3 (الصادر في 8 أغسطس 2023)، تضيف النواة fetchpriority="high" إلى الصورة المرجّح أن تكون صورة LCP (بمساحة 50,000 بكسل مربع على الأقل افتراضيًا)، وتتخطى التحميل المؤجّل لأول ثلاث صور في المحتوى (Make WordPress Core (يفتح في علامة تبويب جديدة)). وإذا أضافت إضافة تحسين الأداء تحميلًا مؤجّلًا خاصًا بها، فتحقق من أنها تستثني صورة الواجهة الرئيسية وصورة المنتج الرئيسية.
  • خزّن الصفحات مؤقتًا، لا السلال. يوصي دليل WooCommerce بالتخزين المؤقت للصفحات على مستوى الخادم أو عبر إضافة، وباستخدام CDN، مع إبقاء صفحتي السلة وإتمام الشراء خارج التخزين المؤقت (وثائق مطوري WooCommerce (يفتح في علامة تبويب جديدة)).
  • افحص أجزاء السلة (cart fragments). منذ WooCommerce 7.8، لا يُحمَّل سكربت أجزاء السلة إلا حيث توجد أداة Cart widget، لكن بعض القوالب تضمّن هذه الأداة في شيفرتها بشكل ثابت. أما كتلة Mini-Cart فلا تستخدم أجزاء السلة (مدونة مطوري WooCommerce (يفتح في علامة تبويب جديدة)).
  • اعثر على الإضافات الثقيلة. تقترح WooCommerce استخدام Query Monitor للعثور على الإضافات البطيئة، وتأجيل JavaScript غير الضروري.

إذا كان تصميمك يعرض أكثر من ثلاث صور في الشاشة الأولى، يمكنك رفع الحد الذي يستخدمه WordPress:

// functions.php: skip lazy loading for the first 4 content images (default is 3)
add_filter( 'wp_omit_loading_attr_threshold', function () {
    return 4;
} );

كم من الوقت تستغرق الإصلاحات حتى تظهر نتائجها؟

تُظهر اختبارات المختبر أثر الإصلاح فورًا، لكن البيانات الميدانية تحتاج إلى نحو أربعة أسابيع كحد أقصى لتعكسه بالكامل، لأن CrUX يحسب متوسط الأيام الـ28 السابقة.

شغّل اختبار المختبر عدة مرات قبل التغيير وبعده، لأن نتائج التشغيل الواحد تتفاوت، ثم راقب الأرقام الميدانية في PageSpeed Insights أو تقرير Core Web Vitals في Search Console أو تقارير Shopify. ويقدّم الفحص المجاني قراءة أولى في نحو دقيقة. أما تقرير الأداء فيُجري اختبار مختبر للهاتف المحمول مع تقييد السرعة (slow 4G، ومعالج أبطأ بمقدار 4x)، ويضيف البيانات الميدانية من Chrome UX Report، بما فيها INP عندما تتوفر لدى Google بيانات كافية عن متجرك.

الأسئلة الشائعة

هل تؤثر مؤشرات Core Web Vitals في ترتيب نتائج Google؟

تقول Google إن أنظمة الترتيب لديها تستخدم مؤشرات Core Web Vitals، لكن النتائج الجيدة لا تضمن أعلى المراتب، وإنها تظل تعرض المحتوى الأكثر صلة حتى عندما تكون تجربة الصفحة ضعيفة (Google Search Central (يفتح في علامة تبويب جديدة)).

لماذا لا تعرض PageSpeed Insights بيانات ميدانية لمتجري؟

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

هل أحتاج إلى نتيجة 90 أو أكثر في Lighthouse لاجتياز التقييم؟

لا. نتيجة الأداء في Lighthouse نتيجة مختبرية، بينما يعتمد تقييم Core Web Vitals على البيانات الميدانية عند المئين 75، لذا قد تجتاز الصفحة التقييم بنتيجة متواضعة في Lighthouse وتُخفق فيه بنتيجة مرتفعة.

هل يجب أن أحمّل جميع صور المنتجات تحميلًا مؤجّلًا؟

لا. حمّل الصور الموجودة أسفل الشاشة الأولى تحميلًا مؤجّلًا، لكن حمّل صورة الواجهة الرئيسية وصورة المنتج الرئيسية فورًا، مع fetchpriority="high" على إحداهما.

لماذا نتائج الهاتف المحمول أسوأ من نتائج سطح المكتب؟

تقيس Google الهاتف المحمول وسطح المكتب كلًّا على حدة، والهواتف لديها معالجات وشبكات أبطأ. ويحاكي اختبار الهاتف المحمول في Lighthouse ذلك بملف Slow 4G وإبطاء المعالج بمقدار 4x.

المصادر

كل الأدلة