كيف تجعل موقع ووردبريس أسرع: دليل عملي

نادرًا ما يكون بطء موقع ووردبريس ناتجًا عن إعداد واحد. فقد يستغرق الخادم وقتًا طويلًا في بناء الصفحة، وقد تؤخّر صورة كبيرة الحجم المحتوى الرئيسي، وقد تجعل مجموعة من السكربتات القائمةَ بطيئة الاستجابة بعد أن يبدو أن كل شيء قد تحمّل. ولكل مشكلة حلّ مختلف.

هذا الدليل موجّه لأصحاب الأعمال الذين يريدون تسلسلًا واضحًا يتّبعونه مع المطوّر. والهدف موقع يبدو سريعًا خلال الزيارات الفعلية، بحيث يستطيع العملاء القراءة والتصفّح والاستفسار والشراء دون انتظار غير ضروري. والأمثلة هنا توضيحية، وليست نتائج مشروع عميل مزعوم.

ما الذي يعنيه فعلًا أن يكون موقع ووردبريس سريعًا؟

فكّر في ثلاث لحظات: تبدأ الصفحة بالاستجابة، ثم يصبح محتواها المفيد مرئيًا، ثم تستجيب عناصر التحكّم فيها للزائر. وعبارة «تحمّلت بالكامل» لا تصف هذه اللحظات الثلاث. فقد تواصل الصفحة جلب التحليلات في الخلفية وهي قابلة للاستخدام بالفعل، أو قد تنتهي من التنزيل ثم تتجمّد عندما يفتح أحدهم عامل تصفية.

الحدود «الجيدة» لمؤشرات Core Web Vitals من Google هي: LCP لا يتجاوز 2.5 ثانية، وINP لا يتجاوز 200 ميلي ثانية، وCLS لا يتجاوز 0.1، وتُقاس عند المئين الخامس والسبعين. هذه أهداف للتجربة، وليست وعدًا بمركز في البحث. راجع إرشادات Google حول مؤشرات Core Web Vitals لفهم الفرق.

1. حدّد خط أساس قبل تثبيت أي شيء

اختر مجموعة صغيرة من عناوين URL التمثيلية: الصفحة الرئيسية، وصفحة خدمة، ومقالة طويلة، ومسار التحويل الرئيسي لديك. وينبغي للمتجر أن يضيف تصنيفًا ومنتجًا وسلة التسوّق وإتمام الشراء. اختبر الزوّار المجهولين بشكل منفصل عن المستخدمين المسجّلين، لأن سلوك التخزين المؤقت ومحتوى الصفحة قد يختلفان لديهم.

استخدم PageSpeed Insights للفصل بين البيانات الميدانية المتاحة واختبار Lighthouse المحاكي. فالبيانات الميدانية تصف زيارات حقيقية مؤهّلة، والاختبار المعملي يساعد على إعادة إنتاج المشكلات في ظروف مضبوطة. وإذا لم تتوفّر لصفحة ما بيانات ميدانية كافية، فاذكر ذلك في التدقيق. فالملخّص على مستوى النطاق الأصلي لا يثبت أن كل عنوان URL يتصرّف بالطريقة نفسها.

احفظ التاريخ وعنوان URL وملف الجهاز وإعدادات الاتصال وحالة التخزين المؤقت ونتيجة الاختبار. وكرّر تشغيلات قابلة للمقارنة بدل اختيار أسرع نتيجة. وأضف تسجيلًا قصيرًا للتفاعل الذي يشتكي منه العملاء؛ فقد يكشف مشكلة لا تُظهرها النتيجة وحدها.

قبل إجراء أي تغييرات، أنشئ نسخة احتياطية قابلة للاستعادة ونسخة في بيئة اختبار. ودوّن الوظائف التي يجب أن تستمر في العمل. فالصفحة الأسرع مع نموذج استفسار معطّل لم تحقّق متطلبات العمل.

2. أصلح مسار الاستجابة: الاستضافة والتخزين المؤقت وعمل الخادم الأصلي

ابدأ بطلب المستند في لوحة الشبكة في المتصفح. إذا كانت الاستجابة بطيئة، فاسأل: هل يحدث الانتظار في كل زيارة، أم في الغالب عند إخفاق التخزين المؤقت؟ ثم افحص موارد الخادم وتنفيذ PHP ونشاط قاعدة البيانات وأي خدمة خارجية تُستدعى أثناء بناء الصفحة.

اختر الاستضافة بناءً على احتياجات التطبيق وجودة الدعم، لا على حصة نقل بيانات موعودة فقط. ومن الأسئلة المفيدة: هل يوفّر المزوّد بيئة اختبار ونسخًا احتياطية مجرّبة؟ ما إصدارات PHP المدعومة؟ هل يمكنك رؤية الطلبات البطيئة وتشبّع الموارد؟ من يساعدك عندما تعطّل قاعدة تخزين مؤقت عملية إتمام الشراء؟ ويكون تغيير المنصّة مبرّرًا عندما تُظهر القياسات أن المنصّة الحالية هي القيد.

افهم أنواع التخزين المؤقت الثلاثة قبل إعدادها

• التخزين المؤقت في المتصفح يتيح للزائر العائد إعادة استخدام الملفات الثابتة التي لم تتغيّر. أضف أرقام إصدارات لملفات CSS والسكربتات والصور حتى تصل التحديثات بشكل موثوق.
• التخزين المؤقت للصفحات يحفظ استجابة مولّدة حتى لا تُعاد بناء الصفحة العامة مع كل طلب. ويمكن أن يكون على الخادم، أو في طبقة إضافة متوافقة، أو في شبكة CDN.
• التخزين المؤقت للكائنات يعيد استخدام بيانات التطبيق ونتائج الاستعلامات. ويمكن للتخزين المؤقت الدائم للكائنات أن يساعد أعباء العمل المناسبة عبر الطلبات، لكنه لا يغني عن تخزين مؤقت كامل لصفحات HTML.

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

لا تطبّق أبدًا قاعدة شاملة من نوع «خزّن كل شيء مؤقتًا» على موقع شركة. فصفحات الحسابات والاستجابات المخصّصة وسلال التسوّق وإتمام الشراء واستدعاءات الدفع تحتاج إلى معاملة مدروسة. تحقّق مع المطوّر أو مزوّد الاستضافة من ملفات تعريف الارتباط وطرق الطلب ومعاملات الاستعلام وقواعد الاستثناء. واختبر بجلستين مستقلتين للتأكّد من أن عميلًا لا يمكنه تلقّي معلومات عميل آخر.

حسّن المسار غير المخزّن مؤقتًا أيضًا

تنتهي صلاحية التخزين المؤقت، ويُمسح، ويُخفق أحيانًا. حلّل الاستعلامات البطيئة وخطافات الإضافات المكلفة بدل إخفاء كل التأخيرات خلف تخزين مؤقت دافئ. وانقل العمل المناسب مع الواجهات البرمجية الخارجية خارج عرض الصفحة، وأضف مهلات محدودة، ولا تحتفظ ببيانات احتياطية مخزّنة إلا عندما يتحمّل العمل ذلك. واستخدم إصدار PHP مدعومًا، وتحقّق من التوافق قبل الترقية.

لا تنسخ إلى بيئة الإنتاج فهارس قاعدة بيانات أو إعدادات ذاكرة للخادم دون أساس. حقّق في عبء العمل المحدد، واختبر التغيير، واحتفظ بإمكانية التراجع. ويُعدّ دليل تحسين أداء ووردبريس مرجعًا مفيدًا للبداية.

3. اجعل المحتوى الرئيسي يظهر أسرع

حدّد عنصر LCP الفعلي في التتبّع. فقد يكون في صفحة ما صورة فوتوغرافية، وفي أخرى عنوانًا. وهذا مهم لأن الحل الصحيح قد يتعلّق بحجم صورة، أو طلب مورد متأخّر، أو ورقة أنماط، أو خط.

بالنسبة إلى الصورة البارزة، جهّز عدة عروض مفيدة وقارن WebP أو AVIF بالصيغة الأصلية. افحص الجودة بالحجم المعروض؛ فتفاصيل المنتج والنصوص والوجوه والتدرّجات قد تحتاج إلى إعدادات ضغط مختلفة. واحتفظ بالأصل في سير عمل الوسائط حتى لا تبدأ عمليات القصّ والأحجام المستقبلية من نسخة متدهورة الجودة.

دع المتصفح يختار المصدر المناسب باستخدام srcset وسمة sizes دقيقة. ويمكن لدوال الصور في مكتبة وسائط ووردبريس توليد ترميز متجاوب عندما تتوفّر النسخ والبيانات الوصفية. وتحقّق من HTML المعروض، لأن القوالب المخصّصة قد تتجاوز هذه المزايا.

<!-- Example for an image displayed up to 720px wide. -->
<img src="/media/service-960.webp"
  srcset="/media/service-480.webp 480w,
          /media/service-960.webp 960w,
          /media/service-1440.webp 1440w"
  sizes="(max-width: 760px) calc(100vw - 40px), 720px"
  width="1440" height="900"
  loading="eager" fetchpriority="high"
  decoding="async"
  alt="Technician inspecting a commercial ventilation unit">

تحجز الأبعاد نسبة العرض إلى الارتفاع، ويمكن لـ CSS مع ذلك أن يجعل الصورة مرنة. وهذا المثال يناسب صورة يُرجّح أن تكون عنصر LCP، لا كل صورة في الصفحة. استخدم التحميل الكسول للصور الداعمة أسفل منطقة العرض الأولية، وتجنّب منح جميع الصور أولوية عالية. وتأكّد من أن عنوان الصورة الأساسية قابل للاكتشاف في HTML الأولي.

تحتاج الصور الغنية بالنصوص إلى عناية خاصة. فلقطة شاشة صغيرة لجدول بيانات قد تكون خفيفة لكنها غير مقروءة. استخدم جداول HTML للمعلومات الأساسية وSVG للرسوم التوضيحية المناسبة. ويشرح دليل الصور المتجاوبة التقديم وفحوصات الجودة بمزيد من التفصيل.

4. قلّل عمل القالب والإضافات دون تعطيل الموقع

قد تحمّل صفحة تبدو بسيطة عدة عروض شرائح وخطوط أيقونات ومكتبات حركة وأنماط أدوات مصغّرة. دقّق فيما يُطلب ويُنفَّذ فعليًا في كل قالب. وأزِل الميزات المكرّرة قبل محاولة تصغير كل ما تحمّله.

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

حمّل الموارد حيث تُحتاج فقط. فسكربت نموذج التواصل قد لا يلزم إلا في صفحة التواصل، ومكتبة معرض المنتجات قد لا تلزم إلا في صفحات المنتجات. وحافظ على ترتيب الاعتماديات عند استخدام السكربتات المؤجّلة. ولا تؤجّل بشكل أعمى شيفرة المصادقة أو الدفع أو الموافقة أو التنقّل الأساسي.

5. اجعل التفاعلات سريعة الاستجابة، لا التحميل فقط

أعد إنتاج إجراء بطيء: فتح قائمة الجوّال، أو توسيع عوامل التصفية، أو اختيار نوع من المنتج، أو إرسال نموذج. ويمكن لتتبّع الخيط الرئيسي أن يُظهر ما إذا كان التأخير ناتجًا عن تنفيذ JavaScript، أو عن إعادة حساب التخطيط مرارًا، أو عن تحديث عرض كبير.

قلّل كمية العمل أولًا. أعد عرض ما تغيّر فقط، وأزِل مستمعي الأحداث غير الضروريين، وتجنّب قراءة قياسات التخطيط مرارًا مباشرة بعد تغيير الأنماط. وإذا ظلّت عملية حسابية ما كبيرة، فقسّمها إلى أجزاء محدودة تسمح للمتصفح بالاستجابة بينها. ويمكن للعامل (Worker) أن يساعد في الحسابات المناسبة، لكنه لا يستطيع إجراء تحديثات DOM العادية مباشرة.

تستحق أدوات الدردشة والتتبّع والخرائط ومقاطع الفيديو المضمّنة من جهات خارجية المراجعة نفسها. حمّل الميزات الاختيارية عند الحاجة حيثما كان ذلك مناسبًا، مع الحفاظ على الوظائف ومتطلبات الموافقة. فاستبدال خريطة مضمّنة تُحمَّل فورًا بزر واضح «تحميل الخريطة» قد يفيد أكثر من ضغط أيقونة زخرفية صغيرة.

يقدّم دليل Google لتحسين INP الإطار التقني. ويبقى اختبار القبول العملي بسيطًا: يجب أن يبدو الإجراء سريع الاستجابة على هاتف متوسط الإمكانات، لا على جهاز المطوّر فقط.

6. أوقف إزاحات التخطيط وعمليات النقل غير الضرورية

احجز أبعاد الصور والإعلانات والمحتوى المضمّن. وتجنّب إدراج شريط إعلاني فوق المحتوى بعد أن يبدأ القارئ التفاعل. وتحقّق مما إذا كان خط يتحمّل متأخرًا يغيّر فواصل الأسطر بما يكفي لتحريك عناصر التحكّم. فالخط البديل واستراتيجية تحميل الخطوط المدروسة يمكنهما إبقاء النص مقروءًا مع الحدّ من الحركة.

احتفظ فقط بعائلات الخطوط وأوزانها ومجموعات الأحرف التي يحتاجها الموقع فعلًا. ولا تحمّل موردًا مسبقًا إلا بعد أن يُظهر مخطط الشلال أن اكتشافه المبكر سيفيد؛ فطلبات التحميل المسبق العشوائية تنافس الموارد التي أردت منحها الأولوية.

بالنسبة إلى خلفيات الوسائط، فإن إخفاء الفيديو عبر CSS ليس طريقة موثوقة لمنع تنزيله. فضّل صورة غلاف خفيفة وتشغيلًا صريحًا عندما يكون المحتوى المتحرّك اختياريًا. واختبر التصميم النهائي مع تفعيل تقليل الحركة ومع التنقّل بلوحة المفاتيح.

7. تحقّق من إتمام الشراء والنشر والنماذج قبل الإصدار

جهّز قائمة تحقّق قصيرة للإصدار بنتائج نجاح أو إخفاق. اختبر التنقّل في القائمة، والبحث في الموقع، والتحقّق من صحة النماذج، والإرسال الناجح، ورسائل البريد الإلكتروني. وفي WooCommerce، اختبر أنواع المنتجات والقسائم والضرائب وتحديثات السلة وإتمام الشراء وتأكيدات الدفع في بيئة الاختبار المناسبة. وتحقّق من التكاملات المعتمدة على الموافقة في حالتَي القبول والرفض.

بعد ذلك، عدّل مقالة واستبدل صورة. وتأكّد من إبطال التخزين المؤقت، ومن أن الزائر الجديد والزائر العائد يريان النسخة الصحيحة. واختبر جلسة موثّقة بشكل منفصل. فسلوك التخزين المؤقت جزء من المنتج، وليس إعدادًا يمكن افتراض صحّته.

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

خطة واقعية للأسبوع الأول

1. اليوم الأول: القياس. اختر عناوين URL المهمة، واحصل على النتائج المعملية، وأعد إنتاج شكاوى العملاء. وتأكّد من النسخ الاحتياطية وبيئة الاختبار.
2. اليوم الثاني: فحص الخادم الأصلي. حلّل الطلبات البطيئة غير المخزّنة مؤقتًا، واتفق مع مزوّد الاستضافة على حدود آمنة للتخزين المؤقت.
3. اليوم الثالث: إصلاح المحتوى الرئيسي. صحّح أحجام الصور وطريقة اكتشافها، وأزِل تأخيرات العرض التي يمكن تجنّبها في القوالب الأكثر زيارة.
4. اليوم الرابع: اختبار التفاعلات. عالج السكربتات المكلفة وميزات الجهات الخارجية التي تعيق الإجراءات المفيدة.
5. اليوم الخامس: التحقّق والإصدار. شغّل الفحوصات الوظيفية، وانشر مع إتاحة التراجع، وسجّل خط الأساس الجديد.

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

المصادر وقراءات إضافية

• ووردبريس: تحسين الأداء
• Google: تحسين Largest Contentful Paint
• Google: تحسين Interaction to Next Paint
• Google: مؤشرات Core Web Vitals وبحث Google
• قائمة تسريع ووردبريس المكوّنة من 47 بندًا

إذا كنت بحاجة إلى مساعدة في تحديد نقطة البداية، فتعرّف على تدقيق أداء ووردبريس وتحسينه. أحضر معك عناوين URL البطيئة وإجراءات العملاء الأهم؛ فهي نقطة انطلاق أفضل من النتيجة وحدها.