صفحة المنتج في ووكومرس تُحمَّل عادةً بشكل مقبول. أما صفحة المتجر وقوائم التصنيفات ونتائج البحث فغالباً لا، ويفاجأ أصحاب المتاجر بذلك باستمرار لأن المنتجات منفردةً تبدو على ما يرام. الفارق حسابي بحت. صفحة المنتج تعرض صورة رئيسية واحدة. وصفحة تصنيف تعرض أربعة وعشرين منتجاً تعرض أربعاً وعشرين صورة على الأقل، وضعف ذلك في الغالب متى حسبنا تأثيرات التمرير ومعاينات المعرض.
هذا الضرب هو سبب كون صفحات الكتالوج عادةً أبطأ ما في المتجر، وسبب كونها في الوقت نفسه أهم الصفحات تجارياً. فهي تقف بين زائر يصل وزائر يجد ما يشتريه.
النمط الكامن خلف معظم الكتالوجات البطيئة: يطلب القالب حجم مصغّرة لم يولّده ووردبريس قط، فينزّل المتصفح الملف المرفوع بحجمه الكامل ويصغّره داخل الصفحة. أربعة وعشرون منتجاً، يرسل كل منها صورة بحجم ميغابايتين لعرضها عند ثلاثمئة بكسل، يعطي صفحة تصنيف بخمسين ميغابايت تحصل على درجة سيئة مهما أضفت من تخزين مؤقت.
لماذا تتصرف صفحات الكتالوج بشكل مختلف
ثلاثة أمور تتراكم في صفحة القوائم ولا تتراكم في صفحة المنتج.
الكمّ. كل منتج في الشبكة يضيف طلب صورة واحداً على الأقل. وإعدادات ووكومرس الافتراضية تعرض غالباً ستة عشر أو أربعة وعشرين منتجاً في الصفحة، وترفع المتاجر الأكبر هذا الرقم لتقليل التصفّح بالصفحات.
صور التمرير والمعرض. كثير من القوالب يحمّل مسبقاً صورة ثانية لكل منتج من أجل التبديل عند التمرير. وهذا يضاعف بصمت عدد صور الصفحة، ولأن الصورة الثانية لا تظهر أبداً قبل التفاعل، فهي لا تسهم بشيء في العرض الأول بينما تكلّف النطاق نفسه.
عدم استقرار التخطيط. الشبكات التي لا تحجز مساحة للصور تتزحزح كلما وصلت صورة. وفي صفحة منتج يمكن احتمال زحزحة واحدة. أما في شبكة من أربعة وعشرين فالحركة المتراكمة هي التي تنتج درجة Cumulative Layout Shift رديئة، وتُحسّ وكأن الصفحة تقفز بينما تحاول النقر.
والنتيجة أن صفحات الكتالوج تسقط في Core Web Vitals لأسباب لا توجد في صفحة المنتج، وأن تحسين قالب المنتج لا يفعل لها شيئاً.
عدم تطابق الأحجام الذي يسبب معظم المشكلة
يولّد ووردبريس مجموعة أحجام عند الرفع. ويسجّل ووكومرس أحجامه فوقها. ثم تسجّل القوالب المزيد. وما يتلقاه المتصفح فعلاً يعتمد على أي من هذه الأحجام يطلبه القالب، وعلى وجود ذلك الحجم أصلاً.
نمط الفشل صامت. فإن طلب قالبٌ حجماً سُجّل بعد رفع منتجاتك، لم يولّده ووردبريس قط، فيرتد إلى الأصل بحجمه الكامل. وتظل الصفحة تبدو صحيحة لأن المتصفح يصغّر الصورة لتناسب. لكنها ببساطة تنقل عدة ميغابايتات لعرض مصغّرة.
يمكنك رصد ذلك دون أي أدوات. افتح صفحة تصنيف، وافتح لوحة الشبكة، ورتّب طلبات الصور حسب الحجم. فإن كانت الأحجام المنقولة قريبة من وزن الملفات المرفوعة الأصلية بدل أن تكون جزءاً منها، فالحجم المقدَّم خاطئ. قارن الأبعاد الأصلية لصورة محمّلة بالمساحة التي تشغلها على الشاشة. فصورة تصل بعرض ألفي بكسل لملء بلاطة بثلاثمئة بكسل هي المشكلة كلها في ملاحظة واحدة.
والعلاج إما إعادة توليد المصغّرات كي توجد الأحجام المطلوبة، أو تقديم الحجم الصحيح عند التسليم كي لا يُطرح السؤال أصلاً.
التحميل الكسول وأين يختل
يحمّل ووردبريس الصور تحميلاً كسولاً افتراضياً، وهذا يفيد صفحات الكتالوج أكثر من أي نوع صفحات آخر تقريباً، لأن معظم الشبكة الطويلة يقع أسفل الطية.
وخطآن يبطلان هذه الفائدة.
تحميل الصف الأول تحميلاً كسولاً. الصور الظاهرة عند الوصول ينبغي أن تُحمَّل فوراً. فإن حُمّلت أكبرها تحميلاً كسولاً، اكتشفها المتصفح متأخراً، ولأنها عادةً عنصر Largest Contentful Paint، يتضرر القياس مباشرة. ومعظم القوالب تخطئ هنا إذ تطبّق التحميل الكسول بشكل موحّد على كل بلاطة منتج.
إضافات تحميل كسول تتصارع مع التنفيذ الأصلي. تشغيل إضافة تضيف تحميلها الكسول فوق تحميل المتصفح ينتج صوراً لا تُحمَّل أبداً، أو تُحمَّل مرتين، أو ترتجف. فإن كانت لديك إضافة أداء مثبّتة، تحقّق مما إذا كانت تكرّر شيئاً يفعله المتصفح أصلاً.
التسليم: الجزء الذي يتوسّع
إعادة توليد المصغّرات تصلح كتالوج اليوم، لكنها لا تصلح كتالوج الشهر المقبل حين يرسل مورّد جديد صوراً بنسبة عرض إلى ارتفاع مختلفة، أو حين تبدّل القالب فتتغير الأحجام المطلوبة من جديد.
تحويل الصور عند التسليم يتجنّب هذه الدوامة. يبقى الأصل كما رُفع، ويقرّر الرابط الحجم المقدَّم بدل ما وُلّد قبل شهور. غيّر الشبكة، غيّر المعامل. لا تشغيل لإعادة التوليد، ولا خطر أن يرتد حجم مفقود إلى الأصل الكامل.
وهذا يناسب الكتالوجات خصوصاً، لأن صورة المنتج نفسها تظهر عادةً بثلاثة أحجام: بلاطة شبكة، وصورة صفحة منتج، وعرض تكبير أو صندوق ضوئي. وفي نموذج الفوترة لكل صورة يعني ذلك ثلاثة رسوم لكل منتج. أما في نموذج كلاودفلير فهي ثلاث نسخ مستقلة بغض النظر عن عدد منتجاتك، والطلبات المتكررة خلال الشهر لا تكلّف شيئاً.
وتتناول مقارنتنا بين Cloudflare Image Transformations وإضافات الصور في ووردبريس اختلاف نماذج الفوترة وأيها يناسب أي شكل من المكتبات.
ماذا تغيّر، بالترتيب
اعمل على هذه النقاط بالتسلسل. كل واحدة قابلة للقياس وحدها، والقيام بها خارج الترتيب يجعل من الصعب معرفة ما الذي ساعد.
ابدأ بمعرفة إن كان لديك عدم تطابق الأحجام، لأنه إن وُجد فلا شيء آخر يهم قبل إصلاحه. افحص الحجم المنقول لصور الشبكة مقابل المساحة التي تشغلها.
ثم قلّل عدد الصور التي تطلبها الصفحة. أوقف صور التمرير إن كان القالب يحمّلها مسبقاً وكان بوسعك الاستغناء عن التأثير. وفكّر إن كان أربعة وعشرون منتجاً في الصفحة يخدم أحداً، أم أن ستة عشر بتحميل أسرع تحقق تحويلاً أفضل.
ثم صحّح حدّ التحميل الكسول كي يُحمَّل الصف الأول الظاهر فوراً ولا يُحمَّل ما تحته.
ثم عالج التسليم، كي تطابق الأحجام المقدَّمة الأحجام المعروضة وتبقى صحيحة حين يتغير الكتالوج.
وبعد كل ذلك فقط يفيد التخزين المؤقت فائدة تُذكر. فتخزين صفحة بطيئة يجعلها بطيئة باطّراد لا سريعة، وهي الخطوة التي يلجأ إليها الناس أولاً لأنها الأسهل تثبيتاً.
وللصورة الأوسع خارج نطاق الصور، يتناول أداء ووكومرس استعلامات قاعدة البيانات وعبء الإضافات والأجزاء غير المخزّنة مؤقتاً التي تبطئ المتاجر أيضاً.
قياسه كما ينبغي
أصحاب المتاجر يعرفون عادةً أن المتجر يبدو بطيئاً ولا يعرفون أي سبب من عشرات الأسباب المحتملة هو المسؤول. والتخمين مكلف، لأن الحلول البديهية هي نفسها التي جُرّبت من قبل.
تجري Mecanik تدقيقات أداء ووردبريس تقيس صفحات الكتالوج تحديداً بدل اختبار صفحة رئيسية واعتبار المهمة منتهية، وتتولى التنفيذ عبر أعمال تطوير ووردبريس حيث يتجاوز الحل مجرد الإعدادات. فإن كانت صفحات تصنيفاتك هي التي تخسر الزوار، فمن هناك ينبغي أن يبدأ القياس.
تدوينات ذات صلة: أداء WooCommerce: لماذا متجرك بطيء وكيف تصلحه ، ترحيل موقع دون فقدان الحركة: دليل 2026 ، Cloudflare Image Transformations مقابل إضافات ووردبريس ، تطوير مواقع التجارة الإلكترونية: Shopify مقابل المخصص .، GEO للمتاجر: بيانات المنتج في إجابات الذكاء الاصطناعي
الأسئلة الشائعة
لماذا صفحات تصنيفات ووكومرس أبطأ من صفحات المنتجات؟ صفحة المنتج تحمّل صورة رئيسية واحدة. وصفحة التصنيف تحمّل واحدة لكل منتج، وتتضاعف غالباً بصور التمرير، فقد يعني أربعة وعشرون منتجاً ثمانية وأربعين طلب صورة. المعالجة نفسها التي لا تضر في صفحة منتج تتراكم بشكل سيئ في شبكة.
كيف أعرف أن ووكومرس يقدّم حجم صورة خاطئاً؟ افتح صفحة تصنيف ولوحة الشبكة في المتصفح، ثم قارن الحجم المنقول لصور الشبكة بالملفات المرفوعة الأصلية. فإن كانت متقاربة بدل أن تكون جزءاً منها، فالقالب يطلب حجماً لم يولّده ووردبريس، ويجري تصغير الأصل الكامل داخل المتصفح.
هل أعيد توليد المصغّرات أم أحوّل الصور عند التسليم؟ إعادة التوليد تصلح الكتالوج الحالي لكن يجب تكرارها مع كل تغيير في الأحجام أو القالب. أما التحويل عند التسليم فيقرّر الحجم من الرابط، فيبقى صحيحاً عبر تبديل القوالب والرفعات الجديدة دون أي إعادة توليد.
هل يفيد التحميل الكسول صفحات كتالوج ووكومرس أم يضرها؟ يفيدها، لأن معظم الشبكة الطويلة أسفل الطية، لكن الصف الأول الظاهر ينبغي أن يُحمَّل فوراً. فتحميل أكبر صورة ظاهرة تحميلاً كسولاً يؤخر قياس Largest Contentful Paint مباشرة، وهذا إعداد افتراضي شائع في القوالب.
كم منتجاً في الصفحة أفضل للأداء؟ صور أقل تعني صفحة أسرع، لكن تصفّحاً أكثر بالصفحات يعني نقرات أكثر للتصفح. والمعتاد من ستة عشر إلى أربعة وعشرين. والعدد أقل أهمية بكثير من كون كل صورة بحجم صحيح، فشبكة من أربعة وعشرين بأحجام صحيحة تتفوق على شبكة من اثني عشر بأحجام مبالغ فيها.
التعليقات