استضافة WordPress: ما الذي تدفع مقابله فعلاً

تُباع استضافة WordPress ضمن نطاق سعري يمتد من نحو £3 شهرياً إلى عدة مئات، والخطط عند طرفي هذا النطاق تصف نفسها بكلمات شبه متطابقة. سريعة. آمنة. منسوخة احتياطياً. مدعومة. أما المواصفة التي تتيح للمشتري التفريق بينها، أي أي فرع من PHP يشغّل الموقع، وأي محرك قواعد بيانات يقف خلفه، وكم طبقة تخزين مؤقت موجودة وأيها مُفعّل فعلاً، فهي غائبة عادةً عن الصفحة التي يُطلب منك الشراء منها.

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

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

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

استضافة WordPress اسم فئة لا مواصفة

تفاوت السعر داخل الفئة الواحدة هو الدليل. خطتان تحملان معاً وصف استضافة WordPress المُدارة قد تقفان عند £20 و£250 شهرياً، ولن يشرح النص التسويقي هذه الفجوة، لأن الفجوة مصنوعة من أشياء لا يذكرها النص.

عند الطرف الرخيص أنت تشتري شريحة من جهاز مشترك مع مجموعة PHP-FPM وتخزين مؤقت للصفحات ولوحة تحكم. وعند الطرف الغالي تشتري حوسبة معزولة، وتخزين كائنات دائماً، وبيئة تجربة، وجدار حماية مُداراً، وفريق دعم يقرأ سجل أخطائك، وجهة مسؤولة تعاقدياً حين يكسر تحديث النواة أحد القوالب.

كلاهما منتج مشروع. المشكلة أن المشتري لا يرى أيهما أمامه، فيُتخذ القرار على أساس السعر وعلى أساس مواقع مراجعات ترتّب حسب عمولة الإحالة. والنتيجة متوقعة في الاتجاهين. مواقع تعريفية تنتهي على خطط بـ£150 لن تستنفدها أبداً، ومتاجر WooCommerce تنتهي على خطط بـ£5 تنهار عند الدفع في أول سبت مزدحم.

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

ما الذي يتطلبه WordPress فعلاً من الخادم

ينشر WordPress صفحة متطلبات، وهي قصيرة، وهذا بالضبط سبب تخطّيها. اقرأها بوصفها مواصفة شراء، لأن الخطة التي ترسب فيها مستبعدة قبل أن يبدأ الحديث عن الأداء.

إصدار PHP

تحدد صفحة متطلبات WordPress الحد الأساسي الموصى به بأنه “إصدار PHP 8.3 أو أحدث”. وتحمل أيضاً تحذيراً يفوق التوصية أهمية: WordPress “سيظل يعمل على PHP 7.4+ وMySQL 5.5.5+، لكن تلك الإصدارات بلغت نهاية عمرها الرسمي وقد تعرّض موقعك لثغرات أمنية”.

الفخ كله في هذه الجملة. لن يرفض WordPress الإقلاع على فرع قديم جداً من PHP. سيعمل، وسيبدو طبيعياً، وسيجلس بهدوء على مفسّر لم يتلقَ إصلاحاً أمنياً منذ سنوات.

قاعدة البيانات

الصفحة نفسها تطلب “MariaDB 10.11+ أو MySQL 8.0+”. المحركات الأقدم ما زالت تعمل، ولهذا تجلس عليها مواقع كثيرة. تُظهر إحصاءات الاستخدام التي ينشرها WordPress أن نحو تثبيت واحد من كل ستة يُبلّغ عن إصدار MySQL 5.x، أي أدنى بكثير من الحد المعلن، مع استحواذ MySQL 5.7 وحده على نحو 12 في المئة من المواقع المُبلِّغة.

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

HTTPS والامتدادات

يظهر HTTPS بوصفه “مطلوباً لكل تثبيت”، لا موصى به. والمستضيف الذي ما زال يعامل الشهادة في 2026 كإضافة مدفوعة يخبرك شيئاً عن بقية الخطة.

وإلى جانب ذلك، يسمّي دليل استضافة WordPress الامتدادين json وmysqli مطلوبين، ويسمّي curl وdom وexif وfileinfo وhash وigbinary وimagick وintl وmbstring وopenssl وxml وzip موصى بها بشدة. اثنان منها يستحقان الذكر أمام مندوب المبيعات. فبدون zip لا يمكن فك ضغط حزم تحديث الإضافات والنواة. وبدون imagick تتراجع رفعات الوسائط إلى مكتبة صور أضعف، فتخرج صورك أسوأ قبل أن يلمس أحد إضافة تحسين أصلاً.

إصدار PHP هو أعلى بنود الفاتورة أثراً

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

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

لذلك فأول سؤال لمستضيف محتمل ليس عن السرعة. بل عن فرع PHP الذي تشغّله الخطة افتراضياً، والفروع التي تتيحها، وهل يمكنك تغييره بنفسك دون فتح تذكرة. والمستضيف الذي لا يتيح سوى فرع لم يعد WordPress يوصي به قد أجاب عن كل سؤال آخر في الوقت نفسه.

اختبر في بيئة التجربة، ولا تبدّل الإنتاج أبداً. الموقع الذي ينتقل من PHP 7.4 إلى 8.3 يُظهر عادة إشعارين أو ثلاثة إشعارات إهمال من إضافات غير مصانة، وهذه هي الكلفة الحقيقية. خصّص من نصف يوم إلى يوم من وقت المطوّر، وهو ما يتناوله بتفصيل أكبر دليلنا عن أسعار مطوّري WordPress وما ينبغي سؤاله.

النصف الأمني من حجة PHP

الأداء هو السبب الذي يذكره الناس لترقية PHP. أما الأمن فهو السبب الذي يهم فعلاً، وهو قابل للقياس لا للجدل.

ينشر PHP جدول الإصدارات المدعومة الخاص به. كل فرع يحصل على سنتين من الدعم النشط ثم سنتين إضافيتين من الإصلاحات الأمنية فقط. وبحلول سبتمبر 2026 يضع هذا PHP 8.2 في وضع الأمن فقط حتى 31 ديسمبر 2026، وPHP 8.3 في وضع الأمن فقط حتى 31 ديسمبر 2027 بعد انتهاء دعمه النشط في 31 ديسمبر 2025. ويبقى PHP 8.4 في الدعم النشط حتى 31 ديسمبر 2026 مع إصلاحات أمنية حتى 31 ديسمبر 2028، وPHP 8.5 حتى 31 ديسمبر 2027 مع إصلاحات حتى 31 ديسمبر 2029. وكل ما هو أقدم فقد انتهى: PHP 8.1 انتهى في 31 ديسمبر 2025، وPHP 8.0 في 26 نوفمبر 2023، وPHP 7.4 في 28 نوفمبر 2022.

قارن ذلك بما تشغّله مواقع WordPress فعلاً. تُبلّغ صفحة إحصاءات WordPress عن نحو 38.8 في المئة من التثبيتات على فرع انتهى عمره تماماً، مع نحو 23.2 في المئة ما زالت على PHP 7.4 أو أقدم. ولا يبلغ الحد الأساسي PHP 8.3 الذي يوصي به WordPress سوى نحو 36.4 في المئة، بينما تجلس 24.8 في المئة إضافية على PHP 8.2 الذي يفقد الدعم الأمني نهاية هذا العام.

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

طبقات التخزين المؤقت بالترتيب الذي يقابلها به الطلب

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

تخزين الحافة أو شبكة توصيل المحتوى

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

هذه الطبقة توفّر مسافة الشبكة إلى جانب الحوسبة. الزائر في Manchester الذي يصل إلى عقدة حافة في London يتفادى رحلة عبر الأطلسي. وللأصول الساكنة هي شبه مجانية ودائماً مجدية. أما لـHTML فهي قوية لكن مشروطة، لأنه يجب إخبار الحافة أي الاستجابات شخصية ولا يجوز مشاركتها أبداً.

تخزين الصفحة الكاملة

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

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

تخزين الكائنات

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

جعله دائماً يعني وضع Redis أو Memcached خلفه عبر ملف drop-in، وهو ما يحوّل التخزين من شيء يُعاد بناؤه مع كل تحميل صفحة إلى شيء مشترك بين الطلبات والزوار. وهي الطبقة التي تهم بمجرد أن تتوقف الصفحات عن كونها قابلة للتخزين ككل، وهي الأكثر غياباً عن الخطط الرخيصة.

تخزين الشيفرة التشغيلية

الطبقة الرابعة هي OPcache، التي تحفظ الشيفرة الثنائية المترجَمة لملفات PHP في الذاكرة المشتركة كي لا يعيد المفسّر تحليلها وترجمتها مع كل طلب. ويذكر دليل الاستضافة أنه “بالنسبة لبيئات WordPress الإنتاجية، يوصى بتفعيل OPcache لطلبات الويب وتحجيمه بما يناسب الموقع أو منصة الاستضافة”.

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

لماذا يكون الموقع التعريفي سريعاً على أي مستضيف تقريباً

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

لهذا يستطيع موقع شركة من خمس صفحات على خطة بـ£4 مع تخزين صفحات لائق أن يسجّل زمن استجابة خادم أفضل من موقع متخم على خطة بـ£200. الموقع الرخيص يقدّم ملفات. والموقع الغالي يشغّل PHP.

الرقم الذي يستحق المتابعة هو زمن أول بايت، وهو ليس بحد ذاته من Core Web Vitals. تدرجه نظرة Google العامة على Web Vitals ضمن المقاييس المساندة، المفيدة في “تشخيص مشكلات LCP” الناتجة عن بطء استجابة الخادم. وهذه بالضبط الشريحة من سرعة الصفحة التي يتحكم فيها المستضيف.

ويتفق WordPress مع ذلك بما يكفي ليكتبه في النواة. فاختبار صحة الموقع الخاص بتخزين الصفحة الكاملة، المضاف في WordPress 6.1، يفحص “ما إذا كان الموقع يستخدم حل تخزين صفحة كاملة وما إذا كان زمن الاستجابة مقبولاً”، مع عتبة افتراضية قدرها 600 مللي ثانية. فإن كان موقعك فوق ذلك مع تخزين صفحات مفترض أنه مفعّل، فالتخزين لا يعمل، ولن يخفي ذلك معالج إضافي.

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

الحركة المسجّلة الدخول وWooCommerce تكسران النموذج

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

يوثّق WooCommerce ذلك مباشرة. إرشاداته حول التخزين المؤقت توجّهك إلى استثناء صفحات السلة وحسابي والدفع من تخزين الصفحات لأن تلك الصفحات “يجب أن تبقى ديناميكية بما أنها تعرض معلومات خاصة بالعميل الحالي وسلته”. كما تسرد ملفات تعريف الارتباط التي يجب أن تتجاوز التخزين، ومنها woocommerce_cart_hash وwoocommerce_items_in_cart وwp_woocommerce_session_، وتنصح باستثناء _wc_session_ من تخزين قاعدة البيانات.

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

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

ما الذي تتضمنه استضافة WordPress المُدارة فعلاً

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

التحديثات

الخطط المُدارة تطبّق عادة تحديثات النواة تلقائياً، وأحياناً تحديثات الإضافات أيضاً، وأحياناً مع فحص بصري للانحدار قبلها وبعدها. والمفيد معرفته هو حجم ما يفعله WordPress مجاناً بالفعل.

فWordPress يحدّث تلقائياً منذ سنوات الإصدارات الفرعية للنواة وملفات الترجمة افتراضياً، ومنذ الإصدار 5.6 صارت التثبيتات الجديدة تعمل بالتحديثات التلقائية للإصدارات الفرعية والرئيسية للنواة معاً، ما لم يُكتشف مستودع لإدارة الإصدارات، بينما تحتفظ التثبيتات القائمة بالسلوك الأقدم. أي أن الجزء المدفوع ليس تحديثات النواة الفرعية. بل تحديثات الإضافات، والتراجع حين تنكسر إحداها، ووجود من يلاحظ أنها انكسرت.

بيئة التجربة والنسخ الاحتياطي

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

جدار الحماية وفحص البرمجيات الخبيثة

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

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

ما الذي تسحبه الاستضافة المُدارة

القيود هي النصف الذي لا يقرأه أحد، وهي عادةً أثقل وزناً من المزايا. توجد لأسباب يمكن الدفاع عنها، لكنها أسباب المزوّد لا أسبابك.

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

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

والوصول إلى صدفة الأوامر هو الغياب الشائع الآخر. فكثير من الخطط المُدارة لا تقدّم SSH إطلاقاً، أو تقدّم صدفة مقيدة بلا WP-CLI، وهو ما يحوّل عملاً روتينياً مثل بحث واستبدال جماعي بعد تغيير النطاق إلى تذكرة دعم. وأمران آخران يفاجئان الناس: العمليات الطويلة كثيراً ما تكون محدودة، فاستيراد 50,000 منتج يجب تقطيعه، والبريد الصادر كثيراً ما يكون محجوباً أو محدود المعدل، على افتراض أن الموقع المخترق سيُستخدم للرسائل المزعجة.

ادعاءات الأداء التي لا تصمد أمام الاختبار

يقوم تسويق الاستضافة على مجموعة صغيرة من الادعاءات التي تتهاوى لحظة أن تسأل عمّا جرى قياسه.

“أسرع عشرين مرة” لا تسمّي مرجعاً تقريباً أبداً. أسرع من ماذا، وعلى أي صفحة، وبأي إضافات، وتحت أي تزامن؟ بدون هذه الأربعة يكون الرقم نسبة بين كميتين مجهولتين.

“نطاق ترددي غير محدود” يجلس بجوار حد شهري للزيارات في الجدول نفسه. والنطاق الترددي نادراً ما يكون القيد على موقع WordPress أصلاً. القيد هو تنفيذ PHP المتزامن، وهو ما لا تذكره الخطة عادةً على الإطلاق.

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

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

كيف تختبر مستضيفاً كما ينبغي

اختبار الاستضافة ليس صعباً، لكنه يجب أن يجري على المسار الذي يجهد الخادم فعلاً. خمس خطوات، بالترتيب.

أولاً، اختبر مساراً غير مخزّن. أضف سلسلة استعلام فريدة لتجاوز تخزين الصفحة، أو اطلب صفحة لا تُخزَّن أبداً مثل سلة أو صفحة حساب. فإن لم تستطع إرسال طلب يشغّل PHP، فأنت تختبر خادم ملفات.

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

ثالثاً، اختبر من حيث يوجد زوارك. فالاستجابة المقيسة من مركز بيانات مجاور للخادم ليست الاستجابة التي يتلقاها عملاؤك في Leeds.

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

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

أي مؤشرات Core Web Vitals تحرّكها الاستضافة فعلاً

عند Core Web Vitals تختلط ادعاءات الاستضافة بترتيب البحث، ولذلك يستحق الأمر دقة في تحديد المقياس الذي يستطيع الخادم التأثير فيه.

هي ثلاثة، تُقيَّم عند المئين الخامس والسبعين لتحميلات الصفحة وتُفصل بين الجوال وسطح المكتب. يقيس Largest Contentful Paint التحميل، وهو جيد عند 2.5 ثانية أو أقل، ويحتاج تحسيناً بين 2.5 و4.0 ثانية، وضعيف بعد 4.0. ويقيس Interaction to Next Paint الاستجابية، وهو جيد عند 200 مللي ثانية أو أقل، ويحتاج تحسيناً حتى 500 مللي ثانية، وضعيف فوق ذلك. ويقيس Cumulative Layout Shift الاستقرار البصري، وهو جيد عند 0.1 أو أقل، ويحتاج تحسيناً حتى 0.25، وضعيف فوقها. أما First Input Delay فقد سُحب واستُبدل به INP الذي صار مؤشراً أساسياً مستقراً في 2024.

تحرّك الاستضافة واحداً من هذه مباشرة لا غير. زمن استجابة الخادم جزء من LCP، فالمستضيف الذي يقتطع منه 400 مللي ثانية يقتطع 400 مللي ثانية من LCP لكل زائر. وعلى مستضيف بطيء قد يكون ذلك الفرق بين النجاح والرسوب.

ولا تفعل الاستضافة شيئاً يُذكر لـCLS الذي ينشأ من صور بلا أبعاد ومن خطوط تتحمّل متأخرة، وتفعل القليل جداً لـINP الذي يهيمن عليه JavaScript على الخيط الرئيسي. والقاعدة أنه إذا كان LCP ضعيفاً وكانت استجابة خادمك غير المخزّنة فوق حد 600 مللي ثانية الذي يشير إليه WordPress، فالاستضافة جزء من المشكلة. وإن كانت الاستجابة مريحة وظل LCP ضعيفاً، فالخلل في الصفحة، ودليلنا عن اجتياز Core Web Vitals في 2026 هو المكان الأفضل لإنفاق الميزانية.

النسخ الاحتياطي والجزء الذي لا يتحقق منه أحد

كل خطة فوق الأرخص تعلن عن نسخ احتياطي. ولا يكاد أحد ممن يشترونها يطرح الأسئلة التي تقرر إن كانت النسخة تساوي شيئاً.

هل استعادها أحد يوماً

يقولها المركز الوطني للأمن السيبراني بوضوح في دليله للمؤسسات الصغيرة: بعد أن تصنع نسخة احتياطية، “من المهم أن تعرف كيف تستعيدها وأن تتحقق من أنها تحوي كل بياناتك المهمة”. النسخة غير المختبَرة اعتقاد لا ضابط.

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

مدة الاحتفاظ والتكرار

نسخ يومية باحتفاظ سبعة أيام تبدو سخية حتى تنظر في كيفية فشل موقع WordPress فعلاً. الموقع المشوَّه يُلاحظ خلال ساعات. أما الاختراق الذي يحقن بهدوء روابط مزعجة في مقالات قديمة فيُلاحظ خلال أسابيع، وعندها تكون كل نسخة محفوظة تحوي الحقن.

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

أين تعيش النسخة وبأي صيغة

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

والصيغة هي النسخة الأدق من المشكلة نفسها. فإن كانت الطريقة الوحيدة لقراءة نسخة احتياطية هي زر الاستعادة الخاص بالمزوّد، فلديك ميزة راحة لا نسخة قابلة للنقل. والاختبار هو هل تستطيع اليوم تنزيل ملف SQL بسيط وأرشيف ملفات يمكن لمطوّر كفء أن يقيمهما في مكان آخر. وإن لم تستطع، يتوقف الترحيل عن كونه قراراً تقنياً ويصير مفاوضة.

أين تقع البيانات ولماذا يهم ذلك المشترين البريطانيين

قرارات الاستضافة قرارات حماية بيانات، وبالنسبة لشركة بريطانية فالسؤال ليس أين سُجّلت الشركة بل أين تستقر البيانات الشخصية ومن يستطيع الوصول إليها.

يضع دليل ICO حول عمليات النقل الدولية اختباراً من ثلاث خطوات. فإذا كانت اللائحة البريطانية لحماية البيانات تنطبق على معالجتك، وكنت أنت من يبدأ النقل، وكانت الجهة المستقبِلة كياناً قانونياً منفصلاً، فأنت تجري نقلاً مقيداً. ويوضح ICO أن القواعد “تنطبق على كل عمليات النقل المقيدة، حتى الصغيرة وغير المتكررة” وتشمل كل مؤسسة تتعامل مع بيانات شخصية، “بما في ذلك التجار الأفراد والعاملين لحسابهم”.

لاحظ ما الذي يُعد نقلاً. يدرج ICO إرسال البيانات الشخصية و"إتاحة الوصول إليها" معاً لمؤسسة خارج المملكة المتحدة. ففريق دعم في الخارج لديه وصول إلى لوحة إدارتك، أو نسخة احتياطية خارجية مكرّرة إلى منطقة أخرى، قد يستوفي كلٌّ منهما ذلك التعريف.

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

ماذا ينبغي أن يقول عقد المعالجة

مستضيفك معالج وأنت المتحكم، فالعقد المكتوب ليس اختيارياً. ويسرد ICO ما يجب أن يتضمنه ذلك العقد، وأربعة من بنوده تُقرأ مباشرة بوصفها أسئلة استضافة.

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

الأمن ثانياً. تشترط المادة 28(3)(c) تدابير تفي بالمادة 32، ويوضح ICO ما تشمله: التشفير وإخفاء الهوية، ومرونة أنظمة المعالجة، و"القدرة على استعادة الوصول إلى البيانات الشخصية عند وقوع حادث"، و"عمليات لاختبار فعالية التدابير وتقييمها بانتظام". وهذا اختبار للاستعادة مكتوب في القانون لا في مقالة عن أفضل الممارسات.

الثالث هو الخروج. بموجب المادة 28(3)(g) على المعالج، وفق اختيارك، أن يحذف أو يعيد كل البيانات الشخصية عند نهاية العقد وأن يحذف النسخ الموجودة. والمزوّد الذي لا تستطيع نسخه الاحتياطية مغادرة منصته لديه مشكلة تعاقدية إلى جانب المشكلة العملية. والرابع هو التدقيق، الذي يمنحك بموجب المادة 28(3)(h) حق الحصول على المعلومات اللازمة لإثبات الامتثال وعلى شهاداته وتقاريره.

المستويات وكم تكلف في المملكة المتحدة

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

الاستضافة المشتركة، £3 إلى £15 شهرياً

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

WordPress المُدارة، £20 إلى £400 شهرياً

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

VPS أو سحابة بحزمتك الخاصة، £15 إلى £120 زائد الإدارة

تكلف نسخة سحابية متواضعة £15 إلى £120 شهرياً، لكن الجهاز هو الجزء الرخيص. فلا بد لأحد أن يرقّع نظام التشغيل، ويضبط الوكيل العكسي، ويشغّل تخزين الكائنات، ويتولى النسخ الاحتياطي، وشراء ذلك يكلف £150 إلى £600 إضافية شهرياً. وهو يستحق حين يكون الحمل غير القابل للتخزين حقيقياً، أو حين تفرض حزمتك متطلبات تمنعها المنصة المُدارة.

البنية التحتية المفصّلة، £400 شهرياً فما فوق

نشر عبر مناطق متعددة، وفعاليات عالية التزامن، وإقامة صارمة للبيانات، أو بنية يكون فيها WordPress مكوّناً بين مكوّنات. هنا تتوقف الاستضافة عن كونها قرار منتج وتصير جزءاً من البناء، وهكذا نتعامل معها داخل مشروع تطوير موقع إلكتروني.

التحجيم بالطلبات غير القابلة للتخزين لا بمشاهدات الصفحة

تُباع خطط الاستضافة بالزيارات الشهرية لأن هذا رقم يعرفه المشترون. وهو شبه عديم النفع لتخطيط السعة، لأن 100,000 مشاهدة مجهولة مخزنة لا تكلف شيئاً يُذكر، بينما 10,000 مشاهدة لمسجّلي الدخول قد تُشبع خادماً صغيراً.

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

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

ثم قدّر جانبك أنت بأمانة. احسب نسبة الجلسات المسجّلة الدخول، وحركة الدفع والحسابات في ساعتك الأكثر ازدحاماً لا في ساعتك المتوسطة، وأي حركة admin-ajax أو REST تولّدها إضافاتك في الخلفية، وهي غير مرئية في التحليلات ومرئية جداً في سجل الخادم.

عدد الإضافات وحجم التحرير قراران في الاستضافة

شيئان داخل الموقع يحددان كم استضافة يحتاج، وكلاهما يُعامل عادةً كقرار محتوى يتخذه من لا يرى الفاتورة أبداً.

الأول هو حزمة الإضافات. فكل إضافة نشطة تضيف خيارات تُحمَّل تلقائياً مع كل طلب، وأحداثاً مجدولة تنطلق على طلبات الزوار لأن cron في WordPress ليس cron حقيقياً، واستعلامات مع كل بناء صفحة. ثلاثون إضافة على موقع تعريفي مخزّن أمر يُحتمل. أما ثلاثون إضافة على متجر لا يُخزَّن فيه شيء فتعني ثلاثين إضافة تُنفَّذ عند كل خطوة من خطوات الدفع. ولنواة WordPress تصور تقريبي لموعد بدء الألم: يقترح فحص صحة الموقع الخاص بتخزين الكائنات الدائم تفعيلَ التخزين بمجرد تجاوز الموقع عتبات مثل 2,000 مقالة أو 2,000 مستخدم أو 600 خيار مُحمَّل تلقائياً.

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

الاختيار بالترتيب

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

تنفّذ Mecanik هذا كعمل بسعر ثابت قبل أي ترحيل، عادةً إلى جانب مشروع تطوير موقع إلكتروني، وتتولاه دعماً مستمراً عبر خدمة مطوّر WordPress للتوظيف لدينا. وإن كنت توازن إلى أين تتجه المنصة نفسها، فمقالنا عن WordPress 7.0 وعميل الذكاء الاصطناعي في النواة رفيق معقول لهذا المقال.

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

كم ينبغي أن تكلف استضافة WordPress في المملكة المتحدة؟ يعتمد ذلك كلياً تقريباً على حجم الحركة القابلة للتخزين المؤقت لديك. الموقع التعريفي بزوار مجهولين يخدمه جيداً نطاق £3 إلى £15 شهرياً على استضافة مشتركة. وموقع المحتوى أو المتجر الصغير ينتمي عادةً إلى استضافة WordPress المُدارة بـ£20 إلى £100 شهرياً، وترتفع إلى £100 إلى £400 للخطط المزدحمة أو متعددة المواقع. أما المتجر أو موقع العضويات ذو الحركة المسجّلة الدخول الكثيفة فيحتاج عادةً إلى VPS أو حزمة سحابية بـ£15 إلى £120 للجهاز زائد £150 إلى £600 شهرياً إن أدارها شخص آخر.

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

ما إصدار PHP الذي يحتاجه WordPress في 2026؟ يوصي WordPress بـPHP 8.3 أو أحدث. وهو لا يزال يعمل على PHP 7.4 وما فوق، لكن تلك الفروع انتهى عمرها ولا تتلقى إصلاحات أمنية. انتهى PHP 8.1 في 31 ديسمبر 2025، وPHP 8.0 في 26 نوفمبر 2023، وPHP 7.4 في 28 نوفمبر 2022، بينما يبقى PHP 8.2 في وضع الأمن فقط حتى 31 ديسمبر 2026. ونحو 38.8 في المئة من تثبيتات WordPress ما زالت تُبلّغ عن فرع منتهي العمر تماماً.

هل تحسّن الاستضافة الأفضل مؤشرات Core Web Vitals؟ واحد فقط من الثلاثة، وبشكل غير مباشر. زمن استجابة الخادم جزء من Largest Contentful Paint، فالمستضيف الأسرع يخفض LCP لكل زائر. ولا يفعل شيئاً يُذكر لـCumulative Layout Shift الذي ينشأ من صور بلا أبعاد ومن خطوط تتحمّل متأخرة، ويفعل القليل جداً لـInteraction to Next Paint الذي يهيمن عليه JavaScript على الخيط الرئيسي. وإن كانت استجابة خادمك مريحة أصلاً، فالمشكلة الباقية داخل الصفحة.

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