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

ما الذي يهم فعلا إذن
- عدد عمليات PHP المتزامنة. هذا الرقم يحدد كم شخصا يمكنهم الوقوف في طابور الدفع في اللحظة ذاتها. وحين تنفد، ينتظر التالي.
- ذاكرة كائنات دائمة. يطلق ووكومرس عددا كبيرا من الاستعلامات المتكررة لكل صفحة، وبدونها تصل كلها إلى قاعدة البيانات في كل مرة.
- سرعة الكتابة على القرص. كل طلب وكل تغيير في المخزون وكل تسجيل دخول عملية كتابة، والمتجر يكتب أكثر بكثير من موقع تعريفي.
ومساحة القرص لا تكون الاختناق تقريبا أبدا، وهي بالضبط الرقم المطبوع بأكبر خط في إعلان الاستضافة.
الصفحة لا تخزن إلا إن كانت واحدة للجميع
الجملة بديهية، ومعظم المتاعب يأتي من تجاهلها. تخزن ذاكرة الصفحات مخرجات HTML كي لا يضطر PHP للعمل مجددا. وإن اختلفت المخرجات من شخص لآخر، فتخزينها يعني عرض سلة أحدهم على غيره.
فمتجرك إذن نصفان لا يتشابهان: نصف عام ينبغي تخزينه وينبغي أن يكون سريعا، ونصف خاص لا يخزن أبدا ويحتاج خادما حقيقيا خلفه. والاستضافة الجيدة للمتجر هي التي تحتمل النصف الثاني.
كيف تفحص إعدادك أنت
أمر واحد بلا أي أداة:
curl -sI https://example.com/ | grep -i "cache"
على الصفحة الرئيسية ينبغي أن ترى أثرا للتخزين. شغل الأمر نفسه على مسار السلة وحساب العميل، وهناك ينبغي ألا تراه. فإن جاءت النتيجة معكوسة فإما أن صفحاتك العامة لا تخزن بلا داع، وإما أن صفحاتك الخاصة تخزن، والثانية أخطر من الأولى بكثير.
شغلناه على موقعنا ولم تعجبنا النتيجة
في الثامن عشر من أغسطس ٢٠٢٦ شغلنا هذا الأمر نفسه على صفحتنا الرئيسية، فأعاد cf-cache-status: DYNAMIC مع cache-control: no-cache. أي أننا رغم ضبط قاعدة تخزين على شبكة توزيع المحتوى، فإن HTML لدينا لا يخزن على الحافة وكل زيارة تقطع الطريق إلى خادمنا.
أما صفحة الحساب فتصرفت بشكل صحيح ولم تخزن، وهذا ما يجب أن يحدث. لكن النصف العام لا يخزن أيضا، وهذا عيب لا قرار. نعمل عليه، وحين يصلح سننشر الرقم قبله وبعده.
لماذا ننشر عيبا في موقعنا
نكتب هذا لأن وكالة تبيع السرعة ولا تنشر إلا انتصاراتها لا تستحق الثقة. الأمر المكتوب أعلاه يعيد نتيجة سيئة على موقعنا نحن، وبإمكانك تشغيله الآن.
الرقم الذي يضيع في قرار الاستضافة
في اليوم نفسه قسنا وزن HTML الخام لثمانية وثلاثين موقعا فارسيا. كان الوسيط ٣٤٩ كيلوبايت والأثقل ٣٫١ ميجابايت، قبل أي صورة أو سكربت.
ولا خطة استضافة تعوض ذلك. فإن كانت صفحة منتجك ترسل نصف ميجابايت من HTML، فترقية الخطة ترسل الحمولة نفسها أسرع لا أقل. الترتيب هو: التخفيف أولا ثم الاستضافة. الشرح المطول في صفحة السرعة، والعلاقة بين الاستضافة ومقاييس جوجل في مقال الاستضافة والسرعة والسيو.
متى لا تحتاج استضافة ووكومرس
إن كان متجرك يتلقى بضعة طلبات يوميا ولا يجتمع عليه عشرات الزوار في وقت واحد، فالاستضافة المشتركة العادية تكفي ودفع المزيد لا يشتري لك شيئا. الحد العملي هو حيث يبدأ التزامن: حملة أو تخفيض أو أي حدث يرسل مئة شخص إلى صفحة الدفع في اللحظة ذاتها.
وإن لم يكن لديك متجر بعد فالاستضافة أبكر قرار خاطئ يمكن اتخاذه. ابن المتجر أولا، وما يحتاجه يتضح بعد ذلك. المواصفات في صفحة استضافة ووكومرس والخيارات الأوسع في قسم الاستضافة.
أسئلة تصلنا
هل تختلف استضافة ووكومرس عن استضافة ووردبريس؟
لا من حيث البرمجيات، فكلتاهما تشغل ووردبريس نفسه. الفرق في الموارد المخصصة للصفحات التي لا تخزن، وفي تفعيل ذاكرة الكائنات من عدمه.
هل تخزين صفحة السلة مشكلة فعلا؟
نعم وخطيرة. إن خزنت مخرجات شخصية فقد تعرض سلة مشتر على آخر. ويجب استثناء مسارات السلة والدفع والحساب صراحة.
كم طلبا يوميا يعني أن وقت الترقية حان؟
لا رقم ثابتا لدينا، ومن يعطيك رقما يخمن. المؤشر الحقيقي هو تباطؤ صفحة الدفع في ساعة الذروة لا إجمالي الطلبات.
هل الاستضافة السحابية أفضل للمتجر؟
يتوقف كليا على عدد العمليات المتزامنة ونوع القرص في تلك الخطة. اسم الخطة لا يخبرك بذلك، فاسأل.
التعليقات والأسئلة
لديكم سؤال حول هذا المقال؟ اسألوا، سنجيب.
لا توجد تعليقات بعد؛ كونوا الأولين.