كيف حسّنت سرعة موقع WordPress من أكثر من 30 ثانية إلى حوالي ثانيتين؟

أنا مش متخصص في WordPress بشكل أساسي؛ خبرتي الأساسية في Backend Development باستخدام PHP وLaravel.

لكن في فترة من الفترات اتعرض عليّ إني أمسك موقع مبني بـ WordPress، وكان أول هدف مطلوب مني واضح جدًا:

نخلي الموقع أسرع بأقصى قدر ممكن.

المشكلة إن الموقع كان أحيانًا بيحتاج أكتر من 30 ثانية علشان يكتمل تحميله، وده وقت ضخم جدًا بالنسبة لأي موقع.

ومن خلال التجربة دي، اتأكدت من حاجة مهمة:

بطء الموقع مش دايمًا بيكون سببه الـ Backend أو قاعدة البيانات.

عقلية الـ Backend Developer مش كفاية لوحدها

كمطور Laravel، إحنا متعودين لما نتكلم عن تحسين الأداء نفكر مباشرة في حاجات زي:

• حل مشكلة N+1 Query باستخدام with().
• استخدام Pagination بدل تحميل آلاف الـ records مرة واحدة.
• تجنب استخدام all() بدون داعي.
• اختيار الحقول المطلوبة فقط من قاعدة البيانات.
• تقليل عدد الـ Queries وتحسينها.
• استخدام الـ Cache في الأماكن المناسبة.

وكل دي طبعًا حاجات مهمة جدًا.

لكن أثناء شغلي على WordPress، اكتشفت إن في عوامل أبسط بكتير كان تأثيرها على تجربة المستخدم وسرعة الموقع أكبر مما توقعت.

ودي أهم الحاجات اللي فرقت معايا.

1. الصور كانت من أكبر أسباب البطء

الصور كانت من أكتر الحاجات اللي أثرت على أداء الموقع.

وجود صورة بحجم ضخم، ثم عرضها في مساحة صغيرة داخل الصفحة، معناه إن المستخدم بيحمّل بيانات أكبر بكتير من اللي هو محتاجها فعلًا.

بدأت أركز على:

• اختيار صيغة مناسبة للصور.
• ضغط الصور وتقليل حجم الملفات.
• استخدام أبعاد مناسبة لمكان عرض الصورة.
• تجنب تحميل صور بدقة ضخمة بدون داعي.
• استخدام Lazy Loading للصور الموجودة خارج الجزء الظاهر من الصفحة.

مثلًا، استخدام:

<img src="image.webp" loading="lazy" alt="..." />

ممكن يبدو كتعديل بسيط جدًا، لكنه بيكون مؤثر خصوصًا في الصفحات اللي فيها عدد كبير من الصور.

الفكرة ببساطة:

ليه أحمل صورة المستخدم لسه محتاج يعمل Scroll علشان يشوفها؟

2. إزالة شاشة الـ Preloader

دي كانت من أكتر الحاجات اللي فرقت في إحساس المستخدم بسرعة الموقع.

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

المشكلة إن الصفحة كان فيها موارد مش ضروري المستخدم يستناها علشان يبدأ يشوف المحتوى.

JavaScript، صور، iframe، وخدمات خارجية...

حتى لو كان اللي لسه بيتحمّل مجرد Google Map موجودة في الـ Footer، المستخدم كان لسه شايف شاشة التحميل!

بعد إزالة الـ Preloader، الصفحة بدأت تظهر بشكل تدريجي للمستخدم.

العنوان يظهر.

المحتوى الأساسي يظهر.

الصور والموارد الأقل أهمية تكمل تحميلها بعد كده.

وده عمل فرق كبير جدًا في Perceived Performance أو السرعة اللي المستخدم بيحس بيها، مش بس الأرقام اللي أدوات القياس بتعرضها.

3. تقليل الـ Plugins

WordPress بيسهّل جدًا إنك تضيف أي Feature تقريبًا عن طريق Plugin.

وده شيء ممتاز، لكنه ممكن يتحول لمشكلة.

أحيانًا بنثبت Plugin فيه عشرات المميزات علشان نستخدم منه وظيفة واحدة بسيطة جدًا.

وفي المقابل، الـ Plugin ممكن يضيف:

• ملفات CSS.
• ملفات JavaScript.
• Database Queries.
• Hooks وFilters إضافية.
• Requests أو عمليات إضافية أثناء تحميل الصفحة.

كل Plugin مش مجرد اسم موجود في لوحة التحكم.

لازم أسأل نفسي:

هل أنا فعلًا محتاج الـ Plugin ده؟ وهل القيمة اللي بيضيفها تستاهل التكلفة اللي بيضيفها على الموقع؟

تقليل الـ Plugins غير الضرورية كان من الحاجات اللي ساعدت بشكل واضح في تحسين الأداء.

4. ضبط الـ Caching بشكل صحيح

الـ Caching كان من أهم أسباب التحسن.

مش منطقي إن كل Request لصفحة محتواها شبه ثابت يبدأ رحلة التنفيذ من الصفر في كل مرة.

في صفحات كتير المحتوى بتاعها نادرًا ما بيتغير، وبالتالي استخدام الـ Cache بشكل صحيح بيقلل كمية الشغل اللي السيرفر محتاج يعملها لكل زيارة.

الفكرة مش مجرد:

"ركبت Cache Plugin، يبقى الموقع سريع."

لكن الأهم إنك تفهم:

• إيه الصفحات اللي ينفع تتعمل لها Cache؟
• إمتى الـ Cache يتجدد؟
• إيه المحتوى الديناميكي اللي مينفعش يتعامل بنفس الطريقة؟
• وهل الـ Cache فعلًا شغال وبيحقق نتيجة ولا مجرد Plugin متثبت؟

لما الـ Caching اتظبط بشكل مناسب، الفرق كان واضح جدًا.

النتيجة: من أكثر من 30 ثانية إلى حوالي ثانيتين

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

وده فرق ضخم.

لأن المستخدم مش مهتم الموقع معمول بـ Laravel ولا WordPress، ومش مهتم عندك كام Query أو استخدمت Design Pattern إيه.

هو ببساطة ضغط على الرابط وعاوز يشوف المحتوى.

وكل ثانية انتظار ممكن تأثر على انطباعه عن الموقع.

الدرس الأهم بالنسبة لي

التجربة دي أكدتلي مرة تانية إن تحسين الأداء مش مجرد كتابة Backend Code أفضل.

الأداء هو نتيجة تفاصيل كتير بتشتغل مع بعض:

Backend + Database + Images + Frontend Assets + Network Requests + Plugins + Caching + طريقة تحميل وعرض الصفحة للمستخدم.

وأحيانًا تعديل بسيط جدًا في مكان غير متوقع ممكن يعمل فرق أكبر من ساعات من تحسين الكود.

وأكيد في عوامل تانية كتير ممكن تفرق حسب طبيعة كل موقع، لكن الصور، والـ Preloader، والـ Plugins، والـ Caching كانوا من أكتر الحاجات اللي عملت فرق واضح في التجربة دي.

وأنت؟

هل واجهت قبل كده موقع WordPress بطيء جدًا؟

وإيه التغيير البسيط اللي عملته وحقق أكبر فرق في الأداء؟