تحسين سرعة متجر سلة: ما تملكه وما لا تملكه داخل المنصة

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

لماذا يختلف تحسين سرعة متجر سلة عن موقع مستقل

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

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

ما يتحكم به التاجر وما لا يتحكم به

العمود الثالث هو المقال كله تقريباً. كل ما يلي شرح لصفوفه بالترتيب الذي يُنفذ به.

مقاييس Core Web Vitals بكلمات بسيطة

Core Web Vitals هي 3 مقاييس يستخدمها جوجل لتقييم سرعة الصفحة واستقرارها كما يراها الزائر الحقيقي. جوجل يجمعها من متصفحات الزوار الفعليين خلال 28 يوماً ويعرضها في Search Console في تقرير باسم Core Web Vitals.

جوجل يصنف الصفحة «جيدة» إذا كان 75% من زياراتها ضمن الحد الجيد لكل مقياس. أي أن تحسين صفحة واحدة على جهازك لا يكفي، المطلوب أن تكون أغلب زيارات الجوال ضمن الحد. والمقياس الذي يفشل فيه أغلب متاجر سلة التي فحصتها هو LCP على الجوال، وسببه الصور في أغلب الحالات.

كيف تقيس قبل أي تعديل

ما أطلبه من التاجر قبل أن يغيّر شيئاً:

1. يفتح تقرير Core Web Vitals في Search Console ويسجل عدد الروابط «الضعيفة» و«التي تحتاج إلى تحسين» على الجوال. إن كان المتجر جديداً أو قليل الزيارات فقد لا يظهر التقرير لعدم كفاية البيانات، وهذا طبيعي.
2. يفحص 3 صفحات في أداة PageSpeed Insights: الصفحة الرئيسية، أهم تصنيف، أكثر منتج مبيعاً. يسجل LCP وINP وCLS ونتيجة الأداء على الجوال لكل صفحة.
3. يحتفظ بالأرقام في جدول بتاريخ اليوم. بدون أرقام «قبل» لا يمكن معرفة ما إذا كان التعديل نفع أو أضر.

نتيجة الأداء في PageSpeed رقم مختبري من جهاز واحد ومحاكاة لشبكة بطيئة، والمهم فيها الاتجاه لا الرقم بذاته. الأرقام التي يعتد بها جوجل هي بيانات الزوار الحقيقيين التي تظهر في أعلى التقرير حين تتوفر.

لماذا تختلف النتيجة من فحص إلى فحص

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

الصور: أكبر عامل بيد التاجر

في كل متجر سلة فحصته كانت الصور أول سبب لبطء LCP. التاجر يرفع صورة المنتج كما خرجت من الكاميرا أو من المصمم: 4,000 بكسل عرضاً وحجم 2 إلى 5 ميجابايت، بينما الشاشة التي تعرضها لا يتجاوز عرضها 400 بكسل.

ما يفعله التاجر:

• يغير أبعاد الصورة قبل الرفع. صورة المنتج لا تحتاج أكثر من 1,200 بكسل عرضاً في أغلب الثيمات، والبانر لا يحتاج أكثر من 1,920 بكسل.
• يضغط الصورة. الهدف أقل من 200 كيلوبايت لصورة المنتج وأقل من 300 كيلوبايت للبانر. أدوات الضغط المجانية على الإنترنت تنجز هذا في ثوان لكل صورة، وبعضها يقبل 20 صورة دفعة واحدة.
• يستخدم صيغة WebP حين يقبلها نظام الرفع، فحجمها أقل من JPG بنحو الربع إلى الثلث عند الجودة نفسها.
• يقلل عدد صور المنتج الواحد إلى ما يحتاجه المشتري فعلاً: 4 إلى 6 صور بدل 15.
• يستبدل السلايدر ذا الصور الخمس في الصفحة الرئيسية ببانر واحد ثابت. أغلب الزوار لا ينتظرون الصورة الثالثة، والسلايدر يحمّل الصور الخمس كلها.

للمتجر الذي يملك 3,000 منتج مرفوعة بصور ثقيلة، يبدأ التاجر بالصفحة الرئيسية والتصنيفات وأعلى 100 منتج زيارة حسب تقرير التحليلات، ثم يستكمل على دفعات أسبوعية. المنتجات التي لا يزورها أحد لا تستحق الأولوية.

الصفحة الرئيسية: عدد الأقسام والمنتجات المعروضة

كل قسم في الصفحة الرئيسية (بانر، شريط منتجات، تصنيفات مميزة، آراء العملاء، شركاء) يضيف صوراً وكوداً. صفحة رئيسية فيها 14 قسماً و80 صورة منتج ستكون بطيئة على أي منصة وأي خادم.

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

طريقة سريعة لمعرفة وزن الصفحة الرئيسية: يفتح التاجر أداة PageSpeed Insights ويقرأ في قسم التشخيص حجم الصفحة الكلي وعدد الطلبات. صفحة رئيسية يتجاوز حجمها 3 ميجابايت على الجوال فيها ما يُحذف، وأغلب هذا الحجم في الصور.

التطبيقات والأكواد المضافة

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

ما يفعله التاجر مرة كل 3 أشهر:

1. يفتح قائمة التطبيقات المثبتة ويكتب أمام كل تطبيق ما الذي يفعله فعلاً اليوم.
2. يحذف ما لم يُستخدم في آخر 30 يوماً.
3. يراجع أكواد التتبع: بكسل واحد لكل منصة إعلانية وأداة تحليلات واحدة تكفي. وجود كودين لمنصة واحدة خطأ شائع بعد تغيير المسوّق أو الوكالة.
4. يراجع أدوات الدردشة: أداة الدردشة الواحدة قد تزن أكثر من كل الثيم. إن كانت ضرورية فتبقى واحدة فقط.

ما لا يُحذف من التطبيقات يُراجع وقت تحميله: بعض التطبيقات تتيح في إعداداتها تأخير ظهورها حتى يبدأ الزائر بالتمرير أو التفاعل، وهذا يخفف أثرها على INP بلا حذف. والتاجر يسجل في جدول التطبيقات تاريخ التثبيت وسبب الإبقاء، فيسهل القرار في المراجعة التالية.

الخطوط والفيديو والتضمينات

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

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

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

اختيار الثيم وإعداداته

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

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

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

عدد المنتجات في صفحة التصنيف

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

خطة التنفيذ خطوة بخطوة

1. اليوم 1: التاجر يسجل أرقام «قبل» من Search Console وPageSpeed للصفحات الثلاث.
2. اليوم 2: يحذف التطبيقات غير المستخدمة وأكواد التتبع المكررة.
3. اليوم 3 إلى 4: يستبدل السلايدر ببانر واحد مضغوط، ويقلل أقسام الصفحة الرئيسية إلى 8 أو أقل.
4. اليوم 5 إلى 7: يضغط صور التصنيفات وأعلى 100 منتج زيارة ويعيد رفعها.
5. اليوم 8: يراجع إعدادات الثيم ويوقف التأثيرات الحركية والنوافذ المنبثقة والفيديو في الصفحة الرئيسية.
6. اليوم 9: يقلل الخطوط إلى خط واحد أو اثنين، ويضبط عدد منتجات صفحة التصنيف.
7. اليوم 10: يعيد الفحص في PageSpeed بالطريقة نفسها (3 مرات لكل صفحة) ويقارن مع أرقام اليوم 1.
8. الأسابيع 2 إلى 6: يستكمل ضغط صور باقي المنتجات على دفعات أسبوعية.
9. اليوم 40 تقريباً: يراجع تقرير Core Web Vitals في Search Console، لأن بيانات الزوار الحقيقيين تحتاج 28 يوماً لتعكس التغيير كاملاً.

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

ما لا يمكن إصلاحه من لوحة التحكم

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

في هذه الحالات، ما أراه عملياً هو تحقيق أفضل نتيجة ممكنة فيما يملكه التاجر. متجر سلة بصور مضغوطة و3 تطبيقات و7 أقسام يسجل أرقاماً مقبولة في Core Web Vitals في أغلب الحالات التي رأيتها، ومتجر على المنصة نفسها بصور ثقيلة و15 تطبيقاً يفشل في LCP وINP معاً.

كيف تعرف أن التحسين نجح

المقياس الأول: تقرير Core Web Vitals في Search Console بعد 28 يوماً من آخر تعديل. الهدف انتقال الروابط من «ضعيفة» إلى «تحتاج إلى تحسين» ثم إلى «جيدة» على الجوال.

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

المقياس الثالث: سرعة فهرسة المنتجات الجديدة في تقرير الفهرسة في Search Console. المتجر الأسرع يسمح لجوجل بزيارة صفحات أكثر في الوقت نفسه، فتظهر المنتجات الجديدة في التقرير خلال أيام أقل مما كانت تحتاجه قبل التحسين.

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

الخلاصة

• في سلة لا يتحكم التاجر في الخادم أو CDN أو كود الثيم الأساسي، ويتحكم في الصور والتطبيقات والأقسام والخطوط والفيديو والثيم المختار.
• الصور الكبيرة هي السبب الأول لبطء LCP، والتطبيقات المتراكمة هي السبب الأول لمشاكل INP.
• تُسجل الأرقام قبل التعديل من PageSpeed وSearch Console، ثم يُعاد القياس بالطريقة نفسها بعد 28 يوماً.
• خطة 10 أيام ينفذها التاجر بنفسه تغطي أغلب ما يمكن تحسينه بلا مبرمج.