لقد قمت بتثبيت إضافة تخزين مؤقت. وضغطت صورك. واتبعت خمسة دروس تعليمية مختلفة. ومع ذلك، لا يزال موقع WordPress الخاص بك يُحمَّل كأنه عالق في عام 2009.
هذا أكثر شيوعاً مما تتخيل. تحسين سرعة ووردبريس ليس إصلاحاً واحداً — بل هو مجموعة من الإصلاحات المتراكمة. وإذا كانت طبقة واحدة في هذه المجموعة معطوبة، فلن تستطيع الطبقات الأخرى أن تفعل الكثير. دعنا نستعرض الأسباب الحقيقية التي تجعل موقعك بطيئاً، حتى بعد أن تكون قد فعلت "كل الأشياء الصحيحة".
إضافة التخزين المؤقت تعمل، لكنها غير كافية
التخزين المؤقت للصفحات — وهو حفظ نسخة HTML ثابتة من صفحاتك — هو عادةً أول شيء يقوم الناس بإعداده. ونعم، إنه يساعد. لكن التخزين المؤقت للصفحات يغطي جزءاً فقط من المشكلة.
يُجري WordPress عشرات الاستعلامات على قاعدة البيانات في كل تحميل للصفحة. حتى لو كان HTML مخزناً مؤقتاً، فإن الاستعلامات على مستوى الكائنات (مثل: جلسات المستخدمين، وبيانات الأدوات، والخيارات المؤقتة) لا تزال تصل إلى قاعدة البيانات في كل طلب. بدون طبقة تخزين مؤقت في الذاكرة بين WordPress وقاعدة البيانات، تتراكم هذه الاستعلامات بسرعة.
يحل Redis التخزين المؤقت للكائنات هذه المشكلة. إذ يخزن نتائج استعلامات قاعدة البيانات في الذاكرة، فيأخذ WordPress البيانات من RAM بدلاً من تشغيل الاستعلامات في كل مرة. عادةً ما تتجاوز معدلات الإصابة في ذاكرة Redis المُعدَّة جيداً 80%، مما يعني أن الغالبية العظمى من استدعاءات قاعدة البيانات لا تصل إليها أبداً. وهذا فرق ملموس في وقت التحميل.
إذا لم يتولَّ مزود الاستضافة هذا الأمر نيابةً عنك، فمن المفيد إعداده بشكل منفصل. نحن نقدمه كخيار مدمج — بمجرد تفعيله، يُنشَر التخزين المؤقت تلقائياً دون أي تغييرات في الكود من جانبك.
ملفات JavaScript تُحمَّل مبكراً جداً
هذا يفاجئ كثيراً من الناس. قد تكون ملفات JavaScript لديك صغيرة الحجم ومضغوطة، لكن إذا كانت تُحمَّل بشكل متزامن في <head> من صفحتك، فإن المتصفح يتوقف عن كل شيء حتى ينتهي من تنزيل كل ملف وتنفيذه.
الحل هو تأجيل أو تأخير تحميل JS. إليك الفرق:
- Defer — يتم تنزيل السكريبت بالتوازي مع الصفحة لكنه لا يُنفَّذ إلا بعد الانتهاء من تحليل HTML. مناسب للسكريبتات التي تحتاج للتشغيل عند تحميل الصفحة دون إعاقة العرض.
- Delay — لا يُحمَّل السكريبت أبداً حتى يتفاعل المستخدم مع الصفحة (تمرير، نقر، لمس). رائع للتحليلات وأدوات الدردشة وغيرها من السكريبتات غير الأساسية.
يمكن لتأخير JavaScript غير الضروري أن يُحسِّن بشكل كبير درجة Largest Contentful Paint (LCP) الخاصة بك. المقايضة هي أن بعض السكريبتات تحتاج إلى التشغيل فوراً — كسكريبتات الدفع في صفحة متجر إلكتروني — لذا ستحتاج إلى إضافتها إلى قائمة استثناءات بدلاً من تأخير كل شيء.
ملفات CSS ضخمة وغير مستخدمة في معظمها
أدوات بناء الصفحات والقوالب المتميزة قوية، لكنها تأتي بتكلفة: ملفات CSS ضخمة تُحمَّل على مستوى جميع الصفحات، حتى عندما لا تنطبق معظم القواعد على ما هو معروض فعلياً على الشاشة.
الصفحة الرئيسية لا تحتاج إلى أنماط سلة WooCommerce. مقالة المدونة لا تحتاج إلى CSS الخاصة بمكون عرض الشرائح. لكن كثيراً من القوالب تحمل كل شيء بغض النظر.
تعمل أدوات Remove Unused CSS (RUCSS) على إصلاح هذا من خلال تحليل قواعد CSS المستخدمة فعلاً في كل نوع من الصفحات وإزالة كل ما عداها. النتيجة هي ورقة أنماط أصغر بكثير تُقدَّم لكل صفحة بدلاً من ملف واحد ضخم يُقدَّم في كل مكان. يستغرق الأمر بعض الوقت للتوليد — تعمل العملية في الخلفية — لكن تقليص حجم الملف يكون في الغالب كبيراً.
كلمة تحذير: قد تبدو الأنماط الديناميكية والأنماط المعتمدة على JavaScript "غير مستخدمة" أثناء التحليل لكنها في الواقع ضرورية عند التشغيل. اختبر دائماً بشكل شامل بعد تفعيل RUCSS وأضف أي محددات CSS متأثرة إلى قائمة حماية حتى لا تُحذف.
أنت تُعالج الأعراض وليس السبب الجذري
هذا شيء لا يتحدث عنه الناس بما يكفي: في بعض الأحيان لا يكون البطء متعلقاً بالملفات على الإطلاق. بل يتعلق ببطء تنفيذ PHP، أو كثرة الإضافات التي تقوم بعمل متكرر، أو وظيفة واحدة مكتوبة بشكل سيء تعمل في كل صفحة.
وقت تحميل مدته 4 ثوانٍ ناتج عن وقت تنفيذ PHP مدته 3.8 ثانية لن يُصلَح بضغط الصور. يحتاج إلى قياس دقيق — أي قياس ما يستغرق أطول وقت على مستوى الكود فعلياً.
يُظهر لك القياس الجيد وقت التحميل، وعدد استعلامات قاعدة البيانات، واستخدام الذاكرة، والمكونات الأبطأ تحديداً. بمجرد أن تتمكن من رؤية ذلك، ستتوقف عن التخمين. لقد شهدنا مواقع خفّض أصحابها وقت التحميل إلى النصف بمجرد تحديد إضافتين وإلغاء تفعيلهما لأنهما كانتا تُجريان استدعاءات API متكررة في كل تحميل للصفحة.
إذا لم تقم بعد بقياس أداء موقع WordPress الخاص بك، فيجب أن يكون ذلك خطوتك التالية قبل الإقدام على أي شيء آخر. تحدثنا عن هذا بمزيد من التفصيل في إصلاحات سرعة WordPress التي تستحق وقتك (وتلك التي لا تستحقه).
مزود الاستضافة هو عنق الزجاجة
لا يمكن لأي قدر من تحسين سرعة ووردبريس أن يعوّض عن سيرفر بطيء. إذا كان Time to First Byte (TTFB) لديك يتجاوز 600ms، فالسيرفر هو المشكلة — وليس قالبك ولا إضافاتك.
يقيس TTFB المدة التي يستغرقها السيرفر للرد على طلب قبل إرسال أي محتوى. TTFB الجيد هو ما دون 200ms. بيئات الاستضافة المشتركة، خاصةً المزدحمة منها، تتجاوز بانتظام 1–2 ثانية في TTFB وحدها. يمكنك امتلاك موقع WordPress محسَّن تماماً ولا يزال يشعر بالبطء فقط لأن السيرفر يستغرق وقتاً طويلاً للرد.
هذا أحد أكثر جوانب تحسين سرعة ووردبريس إغفالاً. يحظى الجانب المتعلق بالإضافات بكل الاهتمام، لكن البنية التحتية لا تقل أهمية. إذا كان مزود الاستضافة الحالي يُضعف الأداء باستمرار في TTFB، فلن تُصلح ذلك أي إضافة. اطلع على نظرة عامة على تحسين WordPress لمزيد من المعلومات حول كيفية ملاءمة طبقة السيرفر في الصورة الكاملة.
صورك تبدو محسَّنة لكنها ليست بالأبعاد الصحيحة
لقد مررت صورك عبر أداة ضغط. جيد. لكن هل يتم تقديمها بالأبعاد الصحيحة؟
خطأ شائع هو رفع صورة بعرض 2400px والسماح لـ CSS بتصغيرها إلى 600px في المتصفح. لا يزال المتصفح يُنزِّل الصورة الكاملة بحجم 2400px — فقط يعرضها بشكل أصغر. يتراكم هذا الهدر في النطاق الترددي بسرعة، خاصةً على اتصالات الهاتف المحمول.
الحل له جزآن:
- تقديم الصور بحجم العرض الصحيح باستخدام خاصية srcset في WordPress — تفعل القوالب الحديثة ذلك تلقائياً إذا قمت بتعيين أحجام الصور الصحيحة.
- استخدام صيغ الجيل التالي مثل WebP أو AVIF، والتي عادةً ما تُقلل أحجام الملفات بنسبة 30–50% مقارنةً بـ JPEG عند جودة مماثلة.
يستحق التحميل الكسول أيضاً التحقق منه. الصور الموجودة أسفل الصفحة لا ينبغي تحميلها حتى يتمرر المستخدم نحوها. تُفعِّل معظم إضافات التخزين المؤقت هذا، لكن من المفيد التأكد من أنه فعال بالفعل — وليس مجرد افتراض.
طبّقت عدداً كبيراً من التحسينات المتعارضة
هذا الأمر مؤلم لأنه يأتي من فعل الشيء الصحيح عدة مرات أكثر من اللازم.
تشغيل إضافتَي تخزين مؤقت في وقت واحد، أو استخدام كل من ميزة دمج الملفات في إضافة ما وميزة الضغط في مزود الاستضافة، يؤدي في الغالب إلى تعطل التصميم وأخطاء في وحدة التحكم ومواقع أبطأ بشكل متناقض. يمكن أن تتعارض التحسينات بطرق دقيقة — إضافة واحدة تضمّن CSS الأساسي بينما تؤجل أخرى ورقة الأنماط نفسها، مما يخلق تعارضاً في التوقيت يُعطل العرض.
النهج الأأمن هو طبقة واحدة من التحسين لكل وظيفة. إضافة تخزين مؤقت واحدة. أداة ضغط واحدة. محسِّن صور واحد. ثم اختبر بعد كل تغيير قبل إضافة الطبقة التالية.
غطينا بالضبط كيفية القيام بذلك دون إحداث فوضى في كيفية استخدام إضافات التخزين المؤقت دون تعطل موقع WordPress الخاص بك عن طريق الخطأ.
ترتيب عملي لتشخيص المشكلة
عندما تشعر أنك جربت كل شيء، يساعدك النهج المنظم. اتبع هذه الخطوات بالترتيب:
- قِس TTFB أولاً. استخدم Google PageSpeed Insights أو WebPageTest. إذا كان TTFB يتجاوز 500ms، ابدأ من مستوى السيرفر.
- قِس تنفيذ PHP. اعثر على الخطافات البطيئة والإضافات البطيئة واستعلامات قاعدة البيانات الزائدة قبل لمس أي شيء آخر.
- تحقق من التخزين المؤقت لقاعدة البيانات. تأكد من أن Redis أو Memcached نشط وأن معدل الإصابة لديك صحي.
- راجع تحميل JavaScript. أجِّل ما يمكنك، وأخِّر السكريبتات غير الأساسية، واختبر للتأكد من عدم وجود أعطال.
- تحقق من أحجام الصور وصيغها. تأكد من أن srcset يعمل وأن WebP يُقدَّم للمتصفحات الداعمة له.
- نظِّف CSS الزائد. إذا كان حجم الصفحة لا يزال كبيراً، انظر في CSS غير المستخدم وفكر في تطبيق RUCSS.
العمل على السرعة عملية تكرارية. الهدف ليس تطبيق كل التحسينات دفعة واحدة — بل إيجاد عنق الزجاجة الخاص بموقعك وإصلاحه أولاً. بمجرد أن تفعل ذلك، تتراكم التحسينات. لمزيد من المعلومات حول بناء إعداد WordPress سريع من مستوى البنية التحتية، تُعدّ وثائق تحسين WordPress مكاناً جيداً للتعمق أكثر.
