هذه قائمة تحقق خاصة بووردبريس، لا إعادة لنفس العوامل العامة الموضَّحة في ما الذي يجعل موقع شركتك سريعًا فعليًا؟ أو مؤشرات الويب الأساسية لمواقع الشركات — تلك تنطبق على أي موقع؛ هذه ما يخص تثبيت ووردبريس تحديدًا، بما في ذلك الطريقة المحدَّدة التي يمكن أن يفسد بها كل إصلاح إن طُبِّق دون اختبار.
طبقات التخزين المؤقت: صفحة مقابل كائن
تُخزِّن ذاكرة تخزين الصفحة مؤقتًا نسخة مُصيَّرة بالكامل من صفحة وتقدّمها مباشرة للطلبات المتكررة، متخطية عملية ووردبريس المعتادة في استعلام قاعدة البيانات وإعادة بناء الصفحة من الصفر — هذا التغيير الأعلى أثرًا لموقع محتوى نموذجي، لأنه يحوّل طلبًا ديناميكيًا مكلفًا إلى طلب ثابت رخيص. ذاكرة تخزين الكائنات مختلفة: تُخزِّن نتائج استعلامات قاعدة بيانات فردية في الذاكرة بحيث لا تحتاج الاستعلامات المتكررة داخل أو عبر الطلبات لمسّ قاعدة البيانات مجددًا، وهذا يهم أكثر في مواقع كثيفة قاعدة البيانات (متاجر ووكومرس، مواقع عضوية، أي شيء بنشاط تسجيل دخول متكرر) حيث لا ينطبق التخزين المؤقت الكامل للصفحة على معظم الطلبات. تحل الاثنتان مشكلتين مختلفتين وتُستخدَمان معًا عادة بدلاً من كبديلين.
أين يُفسِد التخزين المؤقت الأمور
يفترض التخزين المؤقت الكامل للصفحة أن الصفحة تبدو متطابقة لكل زائر، وهذا خاطئ لحظة دخول حالة تسجيل الدخول أو سلة التسوق أو أي محتوى شخصي إلى الصورة — تخزين لوحة تحكم مسجَّل الدخول أو صفحة السلة مؤقتًا لكل زائر يمكن أن يُظهِر لعميل محتوى سلة عميل آخر، أو يحبس مسؤولاً مسجَّل الدخول في عرض مؤقت قديم من موقعه نفسه. أي إعداد تخزين مؤقت على متجر ووكومرس أو موقع عضوية يحتاج استثناءات صريحة لصفحات السلة والدفع والحساب وتسجيل الدخول، واختبار مسار تسجيل الدخول والشراء الفعلي بعد تفعيل التخزين المؤقت — لا مجرد التحقق من تحميل الصفحة الرئيسية بسرعة — هو الخطوة التي تلتقط هذا قبل أن يلتقطه عميل.
تحسين الصور
الصور غير المُحسَّنة من أكثر الأسباب الشائعة والمحدَّدة لبطء صفحة ووردبريس — صورة مرفوعة مباشرة من هاتف أو كاميرا عادة بحجم عدة ميجابايت وبأبعاد بكسل أكبر بكثير مما ستُعرَض عليه أبدًا. ضغط الصور، وتقديمها بصيغة حديثة كـWebP، وضبط سمات العرض والارتفاع الصريحة بحيث يستطيع المتصفح حجز مساحة التخطيط قبل تحميل الصورة (تجنب انزياح التخطيط، جزء مما تقيسه مؤشرات الويب الأساسية) كلها قابلة للتحقيق عبر إضافة أو، بشكل متزايد، مدمجة في معالجة الوسائط الخاصة بووردبريس نفسه أو خط أنابيب صور مزوّد الاستضافة. تغيير الحجم للأبعاد المعروضة عليها الصورة فعليًا يهم بقدر أهمية الضغط — صورة بعرض 4000 بكسل مضغوطة جيدًا لكن معروضة بعرض 800 بكسل لا تزال تُجبِر المتصفح على تنزيل بيانات أكثر بكثير مما تحتاجه الصفحة.
تدقيق مجموعة الإضافات
عدد الإضافات وحده لا يحدد الأثر على الأداء — حفنة من الإضافات رديئة الكتابة تحمّل سكربتات وأنماطًا غير ضرورية في كل صفحة، حتى صفحات لا تُستخدَم فيها، سبب فعلي لبطء أكثر شيوعًا من مجرد وجود إضافات كثيرة. تدقيق عملي: اسرد كل إضافة نشطة، حدد ماذا تفعل فعليًا وهل لا تزال ضرورية، وتحقق (عبر تبويب الشبكة في المتصفح أو إضافة تحليل أداء خاصة بووردبريس) من أيها يُحمِّل أصولاً أو يُشغِّل استعلامات قاعدة بيانات على صفحات لا تحتاجها. تعطيل وإزالة الإضافات غير المستخدَمة فعلاً، والبحث عن بدائل أخف لأي إضافة وُجدت ثقيلة بشكل غير معتاد، يستعيد عادة أداءً أكثر من أي تغيير تخزين مؤقت فردي — لأنه يعالج مصدر العمل الزائد الفعلي بدلاً من مجرد تخزين نتيجة ذلك العمل الزائد مؤقتًا.
حداثة إصدار PHP
يعمل ووردبريس على PHP، وإصدارات PHP الأحدث أسرع قياسًا في تنفيذ نفس الكود من الأقدم، بغض النظر عن أي شيء خاص بووردبريس — هذه إحدى خطوات التحسين القليلة القريبة من مكسب خالص بأقل عيوب، شريطة التأكد من توافق قالب الموقع وإضافاته مع الإصدار الأحدث أولاً. تشغيل إصدار PHP منتهي الدعم أيضًا تعرّض أمني لا مجرد مسألة أداء، لأنه لم يعد يتلقى تصحيحات أمنية — التحقق من إصدار PHP الحالي (مرئي في معظم لوحات تحكم الاستضافة) وتحديثه، بعد التأكد من التوافق في بيئة تجريبية، مهمة لمرة واحدة تستحق القيام بها.
التصغير ودمج الملفات: أين يُفسِد الأمور
يقلل تصغير ودمج ملفات CSS وJavaScript عدد الطلبات والحجم الإجمالي، لكنه التحسين الأكثر احتمالاً لكسر موقع بشكل مرئي إن طُبِّق دون حذر — تعتمد بعض أكواد JavaScript على تحميلها بترتيب محدَّد أو على وجود ملف منفصل كطلب خاص بها، ويمكن لدمج أو إعادة ترتيب الملفات أن يكسر وظيفة بصمت (قائمة تعطَّلت، نموذج توقف عن الإرسال، عنصر تفاعلي توقف عن الاستجابة) دون أي خطأ واضح. القاعدة العملية: فعّل هذا التغيير تحديدًا لوحده، لا كجزء من حزمة تغييرات متزامنة، واختبر يدويًا عناصر الموقع التفاعلية الفعلية — القوائم والنماذج وأي ميزة معتمدة على JavaScript — مباشرة بعد ذلك، لا مجرد التأكد أن الصفحة تُحمَّل بصريًا.
أين تتناسب CDN في الصورة
تحل CDN (راجع ما هي شبكة توصيل المحتوى (CDN)؟ للآلية العامة) مشكلة مختلفة عن التحسينات أعلاه: تُقلِّل المسافة الشبكية بين الزائر والأصول الثابتة للخادم، لا مقدار العمل الذي يؤديه ووردبريس نفسه لتوليد صفحة. لموقع ووردبريس بزوار موزَّعين عبر منطقة جغرافية واسعة، اقتران تخزين الصفحة مؤقتًا بشبكة CDN تقدّم الصور وCSS وJavaScript من مواقع طرفية يعالج سؤالي "ما تكلفة توليد هذه الصفحة" و"ما المسافة التي يجب أن تقطعها الاستجابة" معًا — لا يُغني أحدهما عن الآخر، وموقع بـCDN فقط دون تخزين مؤقت للصفحة لا يزال يعيد توليد كل طلب ديناميكي من الصفر على الخادم الأصلي.
القياس قبل وبعد
ينبغي قياس كل تغيير أعلاه بشكل فردي مقابل خط أساس، لا تطبيقها جميعًا دفعة واحدة والأمل في الأفضل — تفعيل خمسة تحسينات في آن واحد ثم اكتشاف أن سلة الموقع معطوبة لا يترك طريقة لمعرفة أي تغيير تسبب فيها. منهج قياس ثابت (نفس أداة الاختبار، نفس الصفحة، ويُفضَّل نفس وقت اليوم نظرًا لتفاوت الظروف الواقعية) قبل وبعد كل تغيير فردي يُظهِر ما يساهم فعليًا مقابل ما بدا أنه سيساعد لكنه لم يُحرِّك الرقم بشكل ملموس.
مثال عملي: صفحة رئيسية بأربع ثوانٍ
تُحمَّل الصفحة الرئيسية لموقع ووردبريس في نحو أربع ثوانٍ، مقاسة باستمرار دون تخزين مؤقت. تفعيل تخزين الصفحة مؤقتًا وحده يُقلِّص زمن تحميل الزيارات المتكررة بشكل كبير، لأن استعلامات قاعدة البيانات المكلفة وتصيير القوالب تُتخطى تمامًا عند نجاح الذاكرة المؤقتة — لكن أول زيارة لأي فترة تخزين مؤقت تظل بطيئة، ويختبر زاحف محرك بحث أو زائر نادر ذلك المسار غير المخزَّن بشكل غير متناسب. إضافة تحسين الصور فوق ذلك يعالج تلك التكلفة الأولى مباشرة، لأن جزءًا كبيرًا من الثواني الأربع في حالة نموذجية يعود لصور مبالغ في حجمها لا زمن معالجة الخادم وحده. تدقيق إضافات يزيل إضافتين غير مستخدَمتين تُحمِّلان سكربتاتهما الخاصة في كل صفحة يُشذِّب طلبات أخرى لا علاقة لها بالمحتوى الفعلي المعروض. لم يكن أي من هذه التغييرات الثلاثة ليغلق الفجوة كاملة بمفرده — المزيج يعالج ثلاثة أسباب منفصلة (تكلفة الطلب المتكرر، وزن الأصول، طلبات غير ضرورية) لا يستطيع إصلاح واحد لمسها دفعة واحدة، وهذا هو النمط العام الذي يستحق توقعه: التحسن الملموس في سرعة ووردبريس نادرًا ما يكون تغييرًا واحدًا، بل عدة تغييرات أصغر يعالج كل منها جزءًا مختلفًا من الإجمالي.
ترتيب تنفيذ، لا قائمة مهام عشوائية
مرتَّبة حسب الأثر النموذجي نسبة للجهد: تخزين الصفحة مؤقتًا أولاً (أكبر مكسب لمعظم المواقع الغنية بالمحتوى)، تحسين الصور ثانيًا (غالبًا أكبر تخفيض في وزن الأصول)، تدقيق الإضافات ثالثًا (معالجة مصدر العمل الزائد الفعلي بدلاً من مجرد تخزين نتيجته مؤقتًا)، ثم حداثة إصدار PHP وذاكرة الكائنات للمواقع كثيفة قاعدة البيانات، مع ترك التصغير أخيرًا واختباره بأكبر قدر من الحذر نظرًا لطريقة فشله المحدَّدة. لا يحتاج أي من هذا أن يحدث في جلسة واحدة. تطبيق التغييرات واحدًا تلو الآخر، مع اختبار فعلي بينها — خصوصًا على متجر أو موقع عضوية حيث لسلة أو تسجيل دخول معطوب تكلفة مباشرة — أبطأ، لكنه ما يُبقي "أسرع" من أن تصبح بصمت "أسرع ومعطوب".
