كيفية تسريع WordPress في 2026: قائمة تحقق لتحسين الأداء

مرِّر موقعك عبر PageSpeed Insights (pagespeed.web.dev) ودوّن أربعة أرقام: LCP (Largest Contentful Paint، الزمن حتى ظهور المحتوى الرئيسي)، وINP (Interaction to Next Paint، مدى الاستجابة)، وCLS (Cumulative Layout Shift، الاستقرار البصري)، والوزن الإجمالي للصفحة. حدود Core Web Vitals من Google: LCP دون 2,5 ثانية، وINP دون 200 مللي ثانية، وCLS دون 0,1. تؤثر مباشرةً على ترتيبك منذ 2021. ما دون هذه الحدود هو «جيد»؛ وبين الحدود و4 ث/500 مللي ث/0,25 هو «يحتاج إلى تحسين»؛ والأسوأ هو «ضعيف». الغرض كله من تحسين سرعة WordPress هو نقل هذه الأرقام الثلاثة إلى المنطقة الخضراء. لا تثق بدرجات GTmetrix أو غيرها من التقييمات المُجمَّعة: فهي لا تتطابق مع إشارات Google الحقيقية.

تحقّق من TTFB (Time To First Byte) من جغرافيا جمهورك باستخدام WebPageTest. إذا تجاوز TTFB ثانية واحدة، فإن استضافتك هي عنق الزجاجة: لن يُصلح ذلك أي تحسين للواجهة الأمامية. المسبّبات الشائعة: استضافة مشتركة رخيصة بخوادم محمَّلة فوق طاقتها، استضافة في قارة مختلفة عن جمهورك، غياب opcache لـ PHP (أي إصدار PHP 7+ ينبغي أن يكون مفعَّلًا فيه افتراضيًا). أرخص حل هو التبديل إلى استضافة أسرع في نفس مستوى الخطة. لأقل من 50.000 زيارة/شهر، تنتج Hostinger Business مع LiteSpeed Cache زمن TTFB دون 400 مللي ثانية. لحركة زيارات أكبر، تنتج Kinsta أو WP Engine على مستوى Google Cloud المتميز زمن TTFB دون 300 مللي ثانية باستمرار. تغيير الاستضافة يتطلب جهدًا أكبر من تثبيت إضافة، لكن التحسّن غالبًا ما يكون كبيرًا.

افتراضيًا، يولّد WordPress كل صفحة من PHP + MySQL عند كل طلب. التخزين المؤقت للصفحات يخزّن HTML المولَّد ويقدّمه مباشرةً للزوار اللاحقين: عادةً أسرع 10-20 مرة. على الاستضافات المبنية على LiteSpeed (Hostinger، معظم Bluehost، A2 Turbo، NameHero)، ثبّت LiteSpeed Cache (مجاني): يتكامل مع التخزين المؤقت على مستوى الخادم. على استضافات Apache/Nginx، ثبّت WP Rocket (59 $/سنة): إنه أعلى إضافات التخزين المؤقت جودةً ويستحق ثمنه. البدائل المجانية (W3 Total Cache، WP Super Cache) تعمل لكنها تتطلب إعدادًا أكثر. بعد تفعيل التخزين المؤقت للصفحات، أعد الاختبار في PageSpeed Insights: يُفترض أن ترى TTFB ينخفض بشكل كبير.

تشكّل الصور عادةً 60-80% من وزن صفحة WordPress. مكسبان لتحقيقهما: (1) الضغط: كل صورة يجب ضغطها قبل الرفع. استخدم أداة ضغط الصور لدينا أو ثبّت ShortPixel/Smush للضغط تلقائيًا عند الرفع. الهدف: صور الترويسة دون 200 كيلوبايت، وصور المحتوى دون 100 كيلوبايت. (2) الصيغ الحديثة: قدّم WebP (أو AVIF) بدل JPG/PNG. WebP أصغر بنسبة 25-35% بنفس الجودة. تحوّل ShortPixel وSmush Pro تلقائيًا؛ وكبديل، يعيد تحسين صور Cloudflare كتابة الصور أثناء التشغيل. (3) التحميل المؤجَّل: الصور أسفل الطية ينبغي ألا تُحمَّل إلا عند التمرير إليها. WordPress 5.5+ يضيف loading='lazy' تلقائيًا؛ تحقّق من أنه يعمل بعرض الكود المصدري. (4) سمات العرض: اضبط دائمًا width/height صريحًا على الصور لتجنّب CLS.

تتضمن معظم إضافات التخزين المؤقت (WP Rocket، LiteSpeed Cache) تصغير CSS/JS: فعِّله. أكبر مكسب هو تأجيل أو إزالة السكربتات غير المستخدمة. شغّل Chrome DevTools ← علامة تبويب Coverage على صفحتك الرئيسية؛ تُظهر أي بايتات من CSS وJS تُستخدم فعلًا. النتائج النموذجية: 50-80% من CSS غير مستخدم، و30-60% من JS غير مستخدم. الحلول: (أ) استخدم قالبًا أخف (GeneratePress أو Kadence يرسلان أقل من 30 كيلوبايت من CSS)، (ب) عطِّل الإضافات غير المستخدمة (غالبًا مصدر السكربتات غير المستخدمة)، (ج) استخدم إضافة مثل Asset CleanUp لتعطيل السكربتات في الصفحات التي لا تحتاج إليها (مثلًا، Contact Form 7 يُحمَّل في كل مكان افتراضيًا حتى لو لم تستخدمه إلا في /contact).

كل إضافة WordPress نشطة تعمل عند كل تحميل صفحة، مضيفةً احتمالًا استعلامات وJavaScript وCSS. معظم المواقع البطيئة لديها أكثر من 30-50 إضافة نشطة، نصفها لم يعد يُستخدم. استخدم Query Monitor (مجاني) لرؤية أي الإضافات تجري أكثر استعلامات قاعدة البيانات. استخدم المستوى المجاني من New Relic أو APM من Kinsta لرؤية أي دوال الإضافات تستغرق أطول وقت. أبرز المخالفين تاريخيًا: Jetpack (يفعل أشياء كثيرة، كلها عند كل طلب)، وإضافات النسخ الاحتياطي المتضخمة التي تعمل أثناء ذروات الزيارات، وإضافات المشاركة الاجتماعية التي تحمّل CSS/JS الخاص بها حتى في صفحات بلا أزرار مشاركة، وإضافات الأمان التي تفحص الملفات في الوقت الفعلي. عطِّل إضافة، أعد اختبار الأداء، وقرِّر إن كانت الميزة تستحق التكلفة.

يراكم WordPress نفايات في قاعدة البيانات مع مرور الوقت: مراجعات المقالات، وtransients المنتهية، وتعليقات السبام، والبيانات الوصفية اليتيمة. ثبّت WP-Optimize (مجاني) وشغّل تنظيفًا لقاعدة البيانات مرة واحدة. صيانة شهرية معقولة: احذف المراجعات الأقدم من 60 يومًا (احتفظ بالحديثة للأمان)، وtransients المنتهية، وقائمة السبام. للمواقع عالية الزيارات، أكبر مكسب لقاعدة البيانات هو التخزين المؤقت للكائنات: يخزّن Redis أو Memcached في الذاكرة نتائج استعلامات MySQL المكلفة، متجنّبًا العمل المتكرر. تتضمن معظم استضافات WordPress المُدارة Redis في مستوياتها الأعلى؛ وفي الاستضافة المشتركة الأساسية، هذا غير متاح.

شبكة CDN (شبكة توزيع المحتوى) تخزّن مؤقتًا مواردك الثابتة (الصور، CSS، JS) في مواقع طرفية (edge) قرب زوارك. لجمهور أمريكي فقط مُستضاف في الولايات المتحدة، تقدّم CDN تحسينًا متواضعًا. لجمهور عالمي، CDN ضرورية: تخفض زمن وصول الموارد من 200-500 مللي ثانية إلى 20-50 مللي ثانية. المستوى المجاني من Cloudflare يغطي معظم الاحتياجات؛ وBunnyCDN بـ 0,01-0,05 $/جيجابايت ترقية مدفوعة بأداء ممتاز. للصور تحديدًا، يمكن لـ Cloudflare Images أو Bunny Image Optimizer إعادة التحجيم وتحويل الصيغ أثناء التشغيل.

بعد كل تغيير مهم، أعد تشغيل PageSpeed Insights. الهدف هو التقدّم التدريجي: معظم المواقع لا تنتقل من «ضعيف» إلى «جيد» بتغيير واحد. بعد جولة تحسين كاملة، النتائج النموذجية: متجر WooCommerce على استضافة مشتركة ينتقل من LCP بـ 4-6 ث إلى LCP بـ 1,5-2,5 ث. مدوّنة محتوى على استضافة مُدارة تنتقل من LCP بـ 2-3 ث إلى LCP بـ 0,8-1,5 ث. إذا بقيت فوق 3 ث من LCP بعد كل ما سبق، فالأرجح أن عنق الزجاجة هو قالبك: بدِّل إلى قالب أخف (GeneratePress أو Kadence أو Astra) قبل مواصلة التحسين.