سرعة المتجر وCore Web Vitals: الحدود التي تعتمدها جوجل وأسباب البطء الشائعة

مقاييس Core Web Vitals (مؤشرات أداء الويب الأساسية) هي ثلاثة مقاييس تعتمدها جوجل لتقيس كيف يشعر الزائر الحقيقي بالصفحة: LCP ويقيس سرعة ظهور المحتوى الرئيسي، وINP ويقيس سرعة استجابة الصفحة للمس والنقر، وCLS ويقيس مقدار تحرّك عناصر الصفحة أثناء التحميل. وتعدّ جوجل الصفحة جيدة إذا كان LCP ‏2.5 ثانية أو أقل، وINP ‏200 ملي ثانية أو أقل، وCLS ‏0.1 أو أقل، وذلك عند الشريحة المئوية الخامسة والسبعين من الزيارات الحقيقية. ويُقيَّم الجوال وسطح المكتب كلٌّ على حدة، ولا تنجح الصفحة إلا إذا اجتازت المقاييس الثلاثة. وفي المتجر يعني بطء LCP غالبًا أن المتسوق ينتظر صورة المنتج وسعره، ويعني ارتفاع CLS أن الأزرار تتحرك تحت إصبعه.

ولأخذ فكرة عن الأرقام: في تقرير Web Almanac لعام 2025 حققت 76% من متاجر شوبيفاي و35% من متاجر ووكومرس نتيجة جيدة في Core Web Vitals على الجوال، وكان LCP «أكبر عامل يفرّق بينها». وتضع مجموعة بيانات أخرى الرقمين عند 81.7% و38.9%. ولم أجد أرقامًا منشورة لمتاجر سلة أو زد.

كيف تتحقق

ابدأ ببيانات الزيارات الحقيقية: تقرير Core Web Vitals في Search Console، أو قسم بيانات الزوار الحقيقيين في نتيجة PageSpeed Insights. وكلاهما يعتمد على بيانات Chrome UX Report ‏(CrUX) من زيارات حقيقية خلال 28 يومًا.
توقّع ألا تجد بيانات إذا كان متجرك صغيرًا، فتقرير CrUX لا يضم إلا الصفحات «ذات الزيارات الكافية»، ولا تنشر جوجل الحد المطلوب. وغياب البيانات لا يعني أن المتجر سريع.
استخدم اختبارًا معمليًا (PageSpeed Insights أو Lighthouse) لتعرف أي عنصر هو LCP، وأي السكربتات تُحمَّل أولًا.
اكتب قائمة بكل سكربت ومن أضافه: المنصة، أو القالب (الثيم)، أو تطبيق أو إضافة، أو أكوادك أنت. والثلاثة الأخيرة فقط بيدك.
شغّل الفحص المجاني: إذا كان على خادم الفحص مفتاح Google API مضبوط، يقرأ «فحص المتجر — أحمد فايد» بيانات CrUX للصفحة ثم للموقع. وإذا لم توجد بيانات زيارات حقيقية لمتجرك فلا يظهر ذلك كمشكلة، بل يُذكر الفحص تحت «لم يتم فحصه». ويقدّر الفحص أيضًا حجم الصفحة وعدد طلباتها، وينبّهك إلى سكربتات الطرف الثالث التي تعطّل العرض، وينسب كل سكربت إلى المنصة أو القالب أو التطبيق أو أكوادك، ويتحقق من تأجيل تحميل صورة LCP، وصيغ الصور القديمة، والصور بلا أبعاد، وغياب الضغط، والصفحات الضخمة جدًا. ويضيف الفحص الكامل اختبار سرعة معمليًا (PageSpeed Insights، بشرط وجود المفتاح أيضًا) على قوالب الصفحة الرئيسية والمنتج والقسم.

كيف تصلح المشكلة

إرشادات جوجل لتحسين LCP تنطبق على كل المنصات: لا تؤجّل تحميل صورة LCP أبدًا (lazy-loading)، وأعطها fetchpriority="high"، وإذا كانت صورة خلفية في CSS فحمّلها مسبقًا (preload). وفي LCP السليم يستهلك زمن استجابة الخادم وتنزيل الصورة معظم الوقت، بينما لا يتجاوز تأخر بدء التحميل وتأخر العرض 10% لكلٍّ منهما. وحدّد عرض كل صورة وارتفاعها حتى تحجز الصفحة مكانها مسبقًا، فلا تتحرك العناصر:

<img src="/images/hero.webp" width="1200" height="600" fetchpriority="high" alt="تشكيلة العود الجديدة">

سلة

القالب الافتراضي «رائد» في سلة يستخدم التحميل المؤجّل المدمج في المتصفح وملفات CSS مصغّرة (minified). أما السكربتات التي تحقنها المنصة فلا يستطيع التاجر تغييرها، والذي بيدك هو التطبيقات ووسوم GTM ‏(Google Tag Manager، أداة إدارة الأكواد) والأكواد المخصصة والصور. لم أجد مقياسًا حديثًا لأداء متاجر سلة في Core Web Vitals، والدراسة الوحيدة المقيسة التي وجدتها من 2022 وعلى قالب قديم، فلا أعتبر أرقامها صالحة اليوم. احذف التطبيقات ووسوم GTM التي لم تعد تستخدمها، وارفع الصور بمقاس قريب من مقاس عرضها.

زد

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

شوبيفاي (Shopify)

تقدّم شبكة شوبيفاي الصور بصيغة AVIF أو WebP تلقائيًا حين يُخرج القالب الصور عبر image_url مع تحديد العرض. أما الصور المضافة كخلفيات CSS، والروابط المكتوبة يدويًا، والصور التي تحمّلها التطبيقات، فلا تمر بهذه المعالجة. والتطبيقات المحذوفة قد تترك مقتطفات وسكربتات داخل القالب، فابحث عنها واحذفها. وتأكد أن الصورة الرئيسية في أعلى الصفحة لا تُحمَّل بشكل مؤجل.

ووردبريس وووكومرس (WordPress/WooCommerce)

منذ الإصدار 7.8 من ووكومرس لا يُحمَّل سكربت cart-fragments إلا مع ودجت السلة أو عندما يعتمد عليه سكربت آخر. والقوالب أو الإضافات التي تحمّله في كل صفحة تضيف طلبًا غير مخزّن مؤقتًا إلى كل زيارة. وأدوات بناء الصفحات مثل Elementor وDivi تزيد حجم الصفحة وملفات CSS، ولا أملك مقياسًا حديثًا لمقدار ذلك. وإذا لم يكن في موقعك تخزين مؤقت للصفحات (page caching) فأضفه عبر إضافة تخزين مؤقت أو من الاستضافة.

متجر مبرمج خصيصًا

حسّن زمن استجابة الخادم، وفعّل ضغط gzip أو Brotli على صفحات HTML، واضبط ترويسات التخزين المؤقت للملفات الثابتة، وحمّل سكربتات الطرف الثالث في <head> مع async أو defer.

أخطاء شائعة

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

شغّل «فحص المتجر — أحمد فايد» المجاني لتعرف ما الذي يُبطئ صفحات متجرك. إذا أردت مساعدة في إصلاح ذلك، تواصل معي عبر واتساب ‎+20 102 702 0701 أو عبر ahmed-fayed.com.