استضافة و إضافات WordPress
جعل WordPress سريعًا وآمنًا: قائمة تحقق للأداء والمكونات الإضافية
إن سرعة WordPress وأمانه يعتمدان دائماً وبشكل كامل على البيئة التي تشغله. إليكم قائمة التحقق العملية التي نطبقها على كل موقع WordPress نستضيفه — ما يجب تخزينه مؤقتاً، وما يجب تأمينه، والإضافات التي تستحق الاستخدام مقابل تلك التي تصبح زائدة عن الحاجة بفضل المنصة.
إن كفاءة WordPress تعتمد تمامًا على ما يُشغّله
يدعم WordPress جزءًا كبيرًا من الويب بفضل مرونته، ولكن هذه المرونة هي أيضًا السبب في بطئه وانعدام أمانه: فالتثبيت الافتراضي يستعلم عن قاعدة البيانات عشرات المرات في كل صفحة، ويبث إصداره وحزمته البرمجية لأي شخص يبحث، ويدعوكم إلى تكديس الإضافات حتى يتضخم كل من ضعف الأداء ونطاق التعرض للهجمات دون أن تشعروا. لا يُعد أي من ذلك عيبًا في WordPress بقدر ما هو نتيجة لتشغيله على بنية تحتية لا تقدم أي مساعدة.
الخبر السار هو أن نفس القرارات القليلة تعالج معظم هذه المشاكل، وهي قرارات تتعلق بالبنية التقنية بدلاً من المحتوى. قم بالتخزين المؤقت بقوة في الطبقة المناسبة، وأبعد قاعدة البيانات عن المسار النشط، وشغّل فقط الإضافات القليلة التي تستحق وجودها بالفعل، وحافظ على تحديث كل شيء بانتظام، واعزل الموقع حتى تظل أي مشكلة محصورة. هذا المقال هو قائمة التحقق تلك، بالترتيب الذي نطبقه على كل موقع WordPress على المنصة.
التخزين المؤقت على الخادم، وليس فقط في المكون الإضافي
إن العامل الفردي الأكبر تأثيرًا على سرعة WordPress هو عدم تشغيل WordPress على الإطلاق لمعظم الزيارات. فالطلب القياسي يقوم بتشغيل WordPress، وتشغيل إضافاتك، والاستعلام من قاعدة البيانات قبل أن يرسل بايتًا واحدًا؛ بينما تقوم ذاكرة التخزين المؤقت للصفحة الكاملة بتقديم الصفحة الجاهزة مباشرةً من خادم الويب في الزيارة التالية، متجاوزةً عملية التشغيل بأكملها. ومكان تواجد ذاكرة التخزين المؤقت تلك له أهمية بالغة: فإضافة التخزين المؤقت تعمل داخل PHP، ولذلك يبدأ PHP بالعمل قبل أن تتمكن ذاكرة التخزين المؤقت من الاستجابة، في حين تستجيب ذاكرة التخزين المؤقت على مستوى الخادم في وقت أبكر من مسار الطلب وتحتفظ بالصفحات في صيغة تتيح للخادم تفريغها على الفور.
يعمل كل موقع WordPress نستضيفه على LiteSpeed Enterprise مع LSCache على مستوى الخادم، ويقوم ملحق التخزين المؤقت الخاص بنا بربط WordPress به بشكل صحيح وجاهز للاستخدام — مثبت مسبقًا ويتم تحديثه تلقائيًا، بحيث يكون هناك شيء أقل لتكوينه أو تحديثه. على أصل لا يعتمد على LiteSpeed، لا يصدر نفس الملحق ببساطة أي ترويسات للصفحة الكاملة ويبقى بعيدًا عن المسار بينما يستمر التخزين المؤقت للكائنات في العمل، لذلك لا يُترك الموقع المنقول أبدًا بنصف تكوين. القاعدة العملية لقائمتكم المرجعية: تخزين مؤقت واحد للصفحة الكاملة، على مستوى الخادم، ولا تضعوا ملحق تخزين مؤقت ثانٍ فوقه — فهما يتعارضان.
ذاكرة التخزين المؤقت للكائنات وقاعدة البيانات
لا يمكن لكل طلب أن يكون صفحة ثابتة. فالجلسات المسجلة، ولوحة الإدارة، والبحث، وسلال التسوق، وأي جزء مخصص يجب أن تشغّل PHP، وبالنسبة إلى هذه الحالات، يتحول الهدف من تجاوز التطبيق إلى تجاوز قاعدة البيانات. يحتفظ التخزين المؤقت للكائنات على مستوى الموقع — Redis في حالتنا — بنتائج عمليات قراءة قاعدة البيانات المتكررة في الذاكرة، بحيث لا يتم الاستعلام عن الخيارات، والعناصر المؤقتة، وعمليات البحث نفسها من قاعدة البيانات عند كل زيارة. يظهر التأثير تحديداً حيث لا يمكن للتخزين المؤقت الكامل للصفحة المساعدة: لوحة إدارة أسرع، وسلال تسوق أسرع، وحمل أقل بكثير على قاعدة البيانات في ظل حركة المرور العالية.
الكلمة الأساسية هنا هي «لكل موقع» (per-site). تعني ذاكرة التخزين المؤقت للكائنات المشتركة (shared object cache) أن موقعًا واحدًا نشطًا للغاية أو سيئ البرمجة يمكنه إخلاء البيانات المخزنة مؤقتًا للجميع وحرمان جيرانه من قاعدة البيانات؛ بينما تضمن الذاكرة المؤقتة المخصصة لكل موقع، مقترنةً بحدود قاعدة البيانات لكل موقع، إبقاء نطاق هذا التأثير محدودًا. في قائمة مهامكم، تعاملوا مع ذاكرة التخزين المؤقت الدائمة للكائنات كخيار غير تفاوضي لأي موقع يضم مستخدمين مسجلين الدخول أو متجرًا، وتوخوا الحذر من الاستضافة التي تتم فيها مشاركة هذه الذاكرة عبر المستأجرين.
الإضافات التي تستحق التشغيل — وتلك التي تحل المنصة محلها
كل إضافة تقوم بإضافتها هي رمز برمجي يعمل عند الطلبات وباب قد يدخل منه شخص ما يوماً ما، لذا فإن الهدف الصادق هو استخدام أقل عدد من الإضافات التي تنجز أكبر قدر ممكن من المهام. وتلغي الاستضافة الجيدة الحاجة إلى فئة كاملة منها: فمع التخزين المؤقت على مستوى الخادم، وذاكرة التخزين المؤقت المدارة للكائنات، والنسخ الاحتياطية للمنصة، لن تحتاجوا إلى إضافة للتخزين المؤقت، أو إضافة منفصلة لذاكرة التخزين المؤقت للكائنات، أو إضافة للنسخ الاحتياطي — حيث يتم إنجاز هذه المهام بشكل أفضل تحت WordPress، وتشغيلها في الأعلى يضيف تعارضات وعبئاً إضافياً فقط.
ما يستحق التشغيل حقاً هو تلك المجموعة الصغيرة التي تضيف إمكانات فعلية: الإضافات التي يحتاجها موقعكم بالفعل لأداء وظيفته، و—على منصتنا—الإضافتان بمستوى المستودعات الرسمية اللتان نُطورهما ونوفرهما مع كل موقع. تربط إضافة التخزين المؤقت الخاصة بنا WordPress بالتخزين المؤقت للخادم وتتولى الإفراغ الذكي بحيث يؤدي التعديل إلى مسح الصفحات المعنية فقط. وتقوم إضافة الأثر الرقمي (footprint) بتجريد العلامات الدالة التي يبثها تثبيت WordPress الافتراضي—مثل علامة الإصدار وعلامة المولد، ونقاط نهاية الاكتشاف، وXML-RPC، وتنبيهات الروابط (pingbacks)، وترويسة المشغل بواسطة (powered-by)—مع كل عملية نشر، وبذلك لا يمكن لأي تحديث لإضافة أو قالب إعادتها خلسة. كلاهما مبنيان وفق معايير دليل إضافات WordPress.org، ومجانيان، ويتم تحديثهما تلقائياً.
الحفاظ على أمان وتحديث WordPress
معظم اختراقات WordPress ليست ذكية، بل هي قديمة. يُعد وجود نواة أو قالب أو إضافة قديمة بها ثغرة أمنية معروفة ومنشورة هو الطريقة الشائعة للغاية لاختراق المواقع، مما يجعل البقاء على اطلاع دائم بأحدث التحديثات هو الإجراء الأمني الأكثر قيمة على الإطلاق — والأكثر إملالاً، ولهذا السبب يتم تجاهله. يجب أن ترفع الاستضافة المدارة هذا العبء عن كاهلكم: من خلال تصحيح حزمة البرامج التي يستند إليها WordPress، وجعل تطبيق تحديثات النواة والإضافات آمناً عبر تزويدكم بنسخة تجريبية لاختبارها ونسخة احتياطية للرجوع إليها عند الحاجة.
علاوة على التحديث المستمر، توقع فرض الحدود لحمايتكم: فحص البرمجيات الضارة قيد التشغيل افتراضيًا حتى يتم اكتشاف الإصابة قبل أن يلاحظها الزائر، وعزل المواقع لمنع أي موقع مخترق من الوصول إلى غيره، وحماية من هجمات حجب الخدمة الموزعة (DDoS) عند الحافة، وتشفير TLS في كل مكان مع تجديد الشهادات تلقائيًا. لا يغني أي من ذلك عن الممارسات الأساسية لحفظ الأمان — بيانات اعتماد قوية، وصلاحيات وصول بأدنى حد ممكن، وإزالة الإضافات التي لم تعد قيد الاستخدام — ولكنه يعني أن البنية التحتية ليست هي الحلقة الأضعف. في قائمة التحقق الخاصة بكم، يكون السؤال لأي مضيف بسيطًا: هل الأمان هو الخيار الافتراضي، أم حزمة تقومون بشرائها؟
WooCommerce والصفحات التي يجب ألا تقوم بتخزينها مؤقتًا أبدًا
المتجر هو المكان الذي يحقق فيه التخزين المؤقت القوي أكبر مكاسبه، ويلحق فيه أسوأ أضراره إذا طُبّق بسذاجة. تعد صفحات الدليل والمنتجات والفئات أكثر الصفحات التي تشهد زيارات وأكثرها قابلية للتخزين المؤقت لديكم، ويعد تقديمها من ذاكرة التخزين المؤقت الكاملة للصفحة هو أفضل شيء يمكنكم فعله لسرعة المتجر. ولكن صفحات سلة التسوق والدفع والحساب شخصية ويجب ألا تُقدَّم أبدًا من ذاكرة تخزين مؤقت مشتركة — وإذا فعلتم ذلك، فسيرى المتسوق سلة شخص آخر، وهو ما يعد متجرًا معطلاً وانتهاكًا للخصوصية في آن واحد.
الطريقة للحصول على الأمرين معًا هي تخزين الصفحة مؤقتًا وإحداث ثغرات للأجزاء المباشرة. تقوم تقنية Edge Side Includes بعرض مجتزأ سلة التسوق، وإجماليات السلة المصغرة، وحالة الحساب لكل طلب بينما يتم تقديم بقية الصفحة من التخزين المؤقت، ويتم استبعاد صفحات cart وcheckout وmy-account وأي صفحات nonce أو session افتراضيًا. تتم إدارة تحديث البيانات عبر تفريغ تلقائي ذكي يعمل عند تغيير منتج أو سعر أو طلب، وبذلك لا يبقى أي سعر قديم أبدًا. إذا كنتم تديرون WooCommerce، فهذا هو الجزء من قائمة التحقق الذي يجب ضبطه بدقة: واجهة متجر سريعة من التخزين المؤقت، وسلة تسوق مباشرة لكل مستخدم، وعدم تخزين أي بيانات شخصية مؤقتًا على الإطلاق.
الأسئلة الشائعة
هل ما زلت بحاجة إلى إضافة تخزين مؤقت مثل WP Rocket؟
لا. تتم معالجة التخزين المؤقت الكامل للصفحات على خادم الويب بواسطة LSCache الخاص بـ LiteSpeed، وتقوم إضافة التخزين المؤقت الخاصة بنا بربط WordPress به وإدارة التفريغ الذكي، كما توجد ذاكرة تخزين مؤقت للكائنات من Redis لكل موقع خلفه. إن إضافة إضافة ثانية للتخزين المؤقت الكامل للصفحات عادةً ما يتعارض مع ذاكرة التخزين المؤقت على مستوى الخادم بدلاً من المساعدة، لذلك فهو ليس مطلوباً ولا يوصى به.
ما هي المكونات الإضافية التي تجعلها المنصة غير ضرورية؟
تعد إضافات التخزين المؤقت، وإضافات تخزين الكائنات المؤقت المنفصلة، وإضافات النسخ الاحتياطي غير ضرورية هنا، لأن هذه المهام تُنفَّذ تحت مستوى WordPress — تخزين مؤقت على مستوى الخادم، وتخزين كائنات مؤقت مُدار لكل موقع، ونسخ احتياطية على مستوى المنصة. وتساعد إزالتها في تقليل التعارضات ومساحة التعرض للهجمات. ما يستحق الإبقاء عليه هو الإضافات التي يحتاجها موقعكم فعلياً لأداء وظائفه، بالإضافة إلى إضافتينا المجانيتين للتخزين المؤقت والـ footprint، واللتين تأتيان مثبتتين مسبقاً.
هل سيؤدي التخزين المؤقت إلى تعطيل سلة تسوق WooCommerce أو الصفحات التي تم تسجيل الدخول إليها؟
لا. يتم استبعاد صفحات سلة التسوق (Cart) وإتمام الطلب (checkout) وحسابي (my-account) وأي صفحات nonce أو صفحات جلسات من التخزين المؤقت افتراضيًا، وتحافظ تقنية Edge Side Includes على تحديث جزء سلة التسوق والإجماليات في الصفحات المخزنة مؤقتًا. يرى المتسوقون دائمًا سلتهم الخاصة وصفحة إتمام طلب صالحة بينما لا تزال واجهة المتجر تُحمَّل من التخزين المؤقت، ويعمل التطهير التلقائي الذكي على مسح الصفحات المتأثرة عند تغيير منتج أو سعر أو طلب.
كيف تحافظون على أمان WordPress دون أن أقوم بإدارته؟
نقوم بتحديث الحزمة البرمجية أسفل WordPress، ونجعل تطبيق تحديثات النواة والإضافات آمنًا باستخدام بيئات الاختبار والاستعادة بنقرة واحدة، ونشغل فحص البرمجيات الضارة والحماية من هجمات DDoS تلقائيًا بشكل افتراضي، ونعزل كل موقع حتى لا ينتشر أي اختراق، ونُصدر شهادات TLS ونجددها تلقائيًا. يزيل ذلك البنية التحتية كنقطة ضعف؛ وتبقى الممارسات الأساسية مثل بيانات الاعتماد القوية وإزالة الإضافات غير المستخدمة على عاتقكم.
ذات صلة
جربه مجاناً لمدة 14 يوماً
أنشئ مواقعك الأولى مجانًا لمدة 14 يومًا — دون الحاجة لبطاقة. هل تنقل موقعًا أو شبكة حالية؟ عمليات الترحيل مجانية وبلا حدود.
ابدأ مجانًا