الصفحات البطيئة تخسر زوارها. فالناس يتركون الصفحات التي يطول تحميلها، والسرعة تؤثر في التحويلات والتفاعل ومؤشرات أداء الويب الأساسية. والخبر السار: يمكن لمعظم المواقع أن تصبح أسرع بكثير ببضعة تغييرات.
هذه القائمة مرتبة تقريبًا حسب الأثر في موقع نموذجي. قِس قبل كل تغيير وبعده لتعرف ما الذي نجح.
نتيجة أداء Lighthouse ومقاييس المختبر وCore Web Vitals لمستخدمين حقيقيين لأي صفحة.
1. استخدم استضافة جيدة
كل شيء يبدأ من الخادم. فإذا كان زمن وصول البايت الأول يتجاوز باستمرار نحو 800 مللي ثانية، فلن يعوّض أي ضبط للواجهة ذلك بالكامل. والاستضافة المشتركة الرخيصة المزدحمة عنق زجاجة شائع. ابحث عن مستضيفين بعتاد حديث (تخزين NVMe)، وإصدارات حديثة من PHP أو Node، وHTTP/2 أو HTTP/3، ومراكز بيانات قريبة من جمهورك.
قِس زمن DNS والاتصال وTLS وزمن أول بايت عبر ثلاثة طلبات.
2. فعّل التخزين المؤقت للصفحات
توليد الصفحة من الصفر – بتشغيل الشيفرة واستعلامات قاعدة البيانات – في كل زيارة عملية بطيئة. أما التخزين المؤقت للصفحات فيحفظ HTML الجاهز ويقدمه فورًا.
- WordPress: استخدم إضافة تخزين مؤقت (WP Rocket، أو LiteSpeed Cache على خوادم LiteSpeed، أو W3 Total Cache، أو WP Super Cache) أو تخزينًا مؤقتًا على مستوى الاستضافة
- cPanel: يقدم كثير من المستضيفين LiteSpeed Cache أو خيارات مدمجة مشابهة
- التطبيقات المخصصة: خزّن الصفحات المعروضة أو الاستعلامات المكلفة مؤقتًا في الذاكرة
3. ضع شبكة CDN أمام الموقع
تقدم شبكة توصيل المحتوى الملفات من خوادم قريبة من كل زائر وتمتص ذروات الزيارات. والخطة المجانية من Cloudflare بداية سريعة؛ ويمكن لمعظم شبكات CDN أيضًا تخزين صفحات HTML كاملة مؤقتًا، ما قد يخفض أزمنة الاستجابة بشكل كبير للجماهير العالمية.
4. حسّن الصور
الصور عادةً أثقل جزء في الصفحة.
- غيّر حجمها إلى حجم العرض
- حوّلها إلى WebP أو AVIF
- اضغطها (جودة بين 75–85% تقريبًا)
- استخدم
srcsetلتحصل الهواتف على ملفات أصغر - حدد
widthوheightلمنع إزاحة التخطيط
اعرف الحجم الكلي للصفحة وأثقل الصور والسكربتات والأنماط فيها.
5. حمّل الوسائط أسفل الصفحة تحميلًا كسولًا
أضف loading="lazy" إلى الصور وiframe غير الظاهرة عند التحميل الأول – لكن ليس للصورة الرئيسية التي يجب أن تُحمّل في أبكر وقت ممكن.
6. فعّل الضغط
تتقلص الملفات النصية (HTML وCSS وJavaScript وSVG وJSON) بنسبة 70–80% مع Gzip، وأكثر قليلًا مع Brotli. وكثيرًا ما يكون ذلك إعدادًا واحدًا في الخادم – في cPanel، ابحث عن «Optimize Website».
تحقق مما إذا كانت الصفحة تُرسَل بضغط Gzip أو Brotli وكم توفر.
7. حدد مدد تخزين مؤقت طويلة في المتصفح للملفات الثابتة
يجب ألا يعيد الزوار العائدون تنزيل شعارك وملفات CSS وJavaScript في كل صفحة. اضبط Cache-Control: max-age=31536000, immutable للملفات الثابتة ذات الإصدارات (التي يتضمن اسمها إصدارًا أو بصمة)، حتى يحصل الإصدار الجديد على عنوان جديد.
8. أزل JavaScript غير المستخدم
JavaScript أغلى الموارد بايتًا ببايت: إذ يجب تنزيله وتحليله وترجمته وتنفيذه، وغالبًا على معالجات هواتف بطيئة. راجع ما يفعله كل سكربت. فوسوم التحليلات القديمة وشرائح العرض غير المستخدمة واختبارات A/B المهجورة والمكتبات المحمّلة في كل صفحة من أجل ميزة واحدة تتراكم بسرعة.
9. أجّل السكربتات غير الحرجة
السكربتات في <head> بدون async أو defer تمنع عرض الصفحة حتى تُنزّل وتُنفّذ. أضف defer إلى السكربتات غير اللازمة للعرض الأول، أو انقلها إلى نهاية body.
<script src="/js/app.js" defer></script>
10. كن صارمًا مع سكربتات الطرف الثالث
أدوات الدردشة، والعناصر الاجتماعية المضمّنة، وخرائط الحرارة، ومديرو الوسوم المليئة ببكسلات التسويق، وسكربتات الإعلانات قد تشكل بسهولة معظم JavaScript في الصفحة. اسأل عن كل منها ما إذا كانت تستحق تكلفتها. وحمّل الأدوات غير الأساسية بعد تفاعل المستخدم فقط (مثلًا، حمّل أداة الدردشة عندما ينقر أحدهم زر الدردشة).
11. حسّن خطوط الويب
- استخدم عددًا أقل من عائلات الخطوط وأوزانها
- قدّم ملفات WOFF2، ويُفضّل أن تستضيفها بنفسك
- حمّل مسبقًا ملف الخط أو الملفين الأهم
- استخدم
font-display: swapليظهر النص فورًا - فكّر في مجموعة خطوط النظام لنص المتن
12. صغّر ملفات CSS وJavaScript
يزيل التصغير المسافات والتعليقات. ويمكن لأدوات البناء وإضافات التخزين المؤقت وشبكات CDN فعل ذلك تلقائيًا.
صغّر CSS لتقليل حجم الملف بإزالة المسافات والتعليقات.
13. ضمّن CSS الحرج في الصفحة
يمكن وضع CSS اللازم لعرض الشاشة الأولى مباشرة في <head>، وتحميل البقية دون حظر العرض. وتستطيع إضافات تخزين مؤقت كثيرة توليد CSS الحرج لك.
14. قلّل عمليات إعادة التوجيه
كل إعادة توجيه تضيف رحلة ذهاب وإياب كاملة قبل أن يبدأ تحميل الصفحة أصلًا. اربط مباشرة بالعناوين النهائية، وتأكد من الوصول إلى نسختك المفضلة (https، مع www أو بدونها) بقفزة واحدة.
تتبّع كل خطوة في سلسلة إعادة التوجيه مع رموز الحالة والتوقيتات.
15. أبقِ قاعدة البيانات والمنصة خفيفتين
في WordPress، عطّل واحذف الإضافات التي لا تحتاجها، ونظّف مراجعات المقالات والبيانات المؤقتة المنتهية، وحدّث PHP وWordPress والإضافات باستمرار. فكل إضافة تضيف شيفرة قد تعمل مع كل طلب.
من أين تبدأ
إن كنت ستفعل ثلاثة أشياء فقط، فافعل هذه:
- أصلح استجابة الخادم بالتخزين المؤقت أو CDN أو استضافة أفضل
- حسّن الصور وقدّم الصيغ الحديثة
- قلّل JavaScript وأجّله، خاصة سكربتات الطرف الثالث
هذه الثلاثة تمثل عادةً معظم التحسن في أغلب المواقع.
قِس الأشياء الصحيحة
استخدم أدوات المختبر (Lighthouse وPageSpeed Insights) لتشخيص التغييرات واختبارها، والبيانات الميدانية (تقرير مؤشرات أداء الويب الأساسية في Search Console وتقرير تجربة مستخدم Chrome) لترى ما يختبره الزوار الحقيقيون. واختبر على الجوال – فهناك تظهر معظم مشكلات الأداء.
تسريع موقع على استضافة cPanel المشتركة
تعمل مواقع كثيرة على استضافة cPanel المشتركة. وغالبًا ما تكون الخيارات المفيدة متاحة بالفعل:
- إصدار PHP (MultiPHP Manager أو Select PHP Version): شغّل إصدار PHP حديثًا ومدعومًا – فالإصدارات الأحدث أسرع بكثير
- Optimize Website: فعّل الضغط للملفات النصية
- LiteSpeed Cache: إذا كان مستضيفك يستخدم LiteSpeed، فإضافة التخزين المؤقت الخاصة به لـWordPress فعالة جدًا
- Cloudflare: يقدم كثير من مستضيفي cPanel تكاملًا مع Cloudflare بنقرة واحدة
- استهلاك الموارد: إذا كان حسابك يصل باستمرار إلى حدود المعالج أو الذاكرة، فسيتباطأ الخادم تحت الضغط – فكّر في خطة أكبر أو خادم VPS
تدقيق سرعة في 30 دقيقة
إن كان لديك نصف ساعة، فهذا الروتين يكشف معظم المشكلات الكبيرة:
- شغّل اختبار سرعة على الجوال لصفحتك الرئيسية وأكثر صفحات الهبوط زيارة
- دوّن زمن وصول البايت الأول. هل يتجاوز 800 مللي ثانية؟ ابدأ بالتخزين المؤقت والاستضافة.
- حدد عنصر LCP. هل هو صورة؟ افحص حجمها وصيغتها وما إذا كانت تُحمّل تحميلًا كسولًا.
- انظر إلى قائمة سكربتات الطرف الثالث. أزل كل ما لا تستخدمه فعليًا.
- افحص الوزن الإجمالي للصفحة وأكبر خمسة ملفات.
- اختبر الصفحة نفسها مجددًا بعد كل إصلاح.
قِس زمن DNS والاتصال وTLS وزمن أول بايت عبر ثلاثة طلبات.
ميزانيات الأداء
بعد أن يصبح موقعك سريعًا، حافظ على سرعته بوضع ميزانية أداء – حدود يتفق فريقك على عدم تجاوزها، مثل:
- وزن إجمالي للصفحة أقل من 1.5 ميغابايت في القوالب الرئيسية
- JavaScript أقل من 300 كيلوبايت مضغوطًا
- LCP أقل من 2.5 ثانية على هاتف متوسط الفئة
- خمسة سكربتات طرف ثالث كحد أقصى
راجع الميزات الجديدة ووسوم التسويق مقابل الميزانية قبل إطلاقها. فالحفاظ على سرعة الموقع أسهل بكثير من إعادة تسريع موقع بطيء.
متى تستعين بمطوّر
تحتاج بعض المشكلات إلى تغييرات في الشيفرة: سكربتات تحظر العرض في القالب، وحزم JavaScript ضخمة جدًا، وإزاحات تخطيط بسبب المحتوى الديناميكي، واستعلامات قاعدة بيانات بطيئة. وإذا كنت تعمل مع مطوّر، فشارك المقاييس المحددة والقوالب المتأثرة وتفاصيل التشخيص من اختبار السرعة – فذلك يوفر وقتًا كبيرًا.
أهم النقاط
- أصلح زمن استجابة الخادم أولًا باستضافة جيدة وتخزين مؤقت للصفحات وشبكة CDN.
- الصور المحسّنة – بحجم مناسب ومضغوطة وبصيغ حديثة – هي عادةً أكبر مكسب في الواجهة.
- أزل JavaScript وأجّله، وراجع كل سكربت طرف ثالث.
- فعّل الضغط ومدد التخزين المؤقت الطويلة في المتصفح للملفات الثابتة.
- اختبر على الجوال، وقِس قبل كل تغيير وبعده، وضع ميزانية أداء.
- في cPanel، افحص إصدار PHP وإعدادات الضغط وخيارات التخزين المؤقت أولًا.
الأسئلة الشائعة
ما زمن تحميل الصفحة الجيد؟
استهدف ظهور المحتوى الرئيسي خلال 2.5 ثانية (LCP جيد) لمعظم الزوار الحقيقيين، واستجابة الصفحة للمسات خلال 200 مللي ثانية.
هل سيتصدر الموقع الأسرع النتائج؟
السرعة إحدى إشارات الترتيب الكثيرة ونادرًا ما تكون الحاسمة، لكنها قد تساعد بين صفحات متشابهة – وهي تحسّن تجربة المستخدم والتحويلات بشكل موثوق.
هل أحتاج إلى مطوّر لتسريع موقعي؟
يمكن تنفيذ كثير من التحسينات – التخزين المؤقت وCDN وتحسين الصور وإزالة الإضافات – دون شيفرة. أما تغييرات JavaScript والقوالب فقد تحتاج إلى مطوّر.
هل لا يزال AMP ضروريًا؟
لا. لم تعد Google تشترط AMP لأهم الأخبار، والصفحة العادية المحسّنة جيدًا تقدم الفوائد نفسها.
افحص موقعك
أجرِ فحصًا مجانيًا يضم أكثر من 55 فحصًا واحصل على حل لكل مشكلة.