الأداء والسرعةوقت القراءة: 5 دقيقة

تحسين سرعة ووردبريس: قائمة تحقّق من 47 بندًا

قائمة تحقّق مرتّبة حسب الأولوية تغطي القياس والتخزين المؤقت وعمل قاعدة البيانات والصور والسكربتات والتحقّق من الإصدارات.

تدقيق أداء متعدد الطبقات من الخادم إلى المتصفح

الإجابة المختصرة

قِس أولًا، ثم أصلح أكبر عنق زجاجة، وأعد اختبار المسارات المهمة. تضم هذه القائمة 47 فحصًا محددًا دون أن تفرض قواعد تخزين مؤقت غير آمنة أو تعد بزمن تحميل واحد يناسب الجميع.

استخدم هذه القائمة وفق ترتيب الأدلة

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

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

حدّد خط الأساس

  1. اختر عناوين URL تمثيلية للصفحة الرئيسية والمقالة والأرشيف والمنتج وإتمام الشراء، وأدرج جلسات مسجّلة الدخول وأخرى مجهولة.
  2. سجّل منطقة الاستضافة والجهاز وظروف الشبكة والمتصفح وإصدار النشر، حتى تكون الاختبارات اللاحقة قابلة للمقارنة.
  3. شغّل اختبارات معملية قابلة للتكرار أكثر من مرة، واحتفظ بنطاق النتائج لا بأسرعها فقط.
  4. راجع LCP وINP وCLS للمستخدمين الحقيقيين حيثما توفّرت بيانات ميدانية، وميّز بين بيانات عنوان URL وبيانات النطاق الأصلي.
  5. افحص طلب المستند، وافصل بين تأخير DNS والاتصال واستجابة الخادم.
  6. التقط تتبّعًا للخيط الرئيسي أثناء إعادة إنتاج التفاعل البطيء، وليس فقط أثناء التحميل الأولي.
  7. حدّد عنصر LCP الفعلي وسلسلة الطلبات اللازمة لعرضه.
  8. احفظ نسخة احتياطية قابلة للاستعادة، وحدّد مسارات المستخدم الرئيسية التي يجب أن تظل تعمل بعد التغييرات.

قلّل العمل على الخادم الأصلي

  1. استخدم إصدار PHP مدعومًا ومتوافقًا مع الموقع، وتحقّق من الترقيات في بيئة الاختبار قبل الإنتاج.
  2. افحص حالة OPcache وسعتها. لا تعطّل التحقّق من الطوابع الزمنية ما لم تكن عملية النشر تُبطل التخزين المؤقت صراحةً.
  3. حلّل مسارات PHP البطيئة واستعلامات قاعدة البيانات المتكرّرة قبل تغيير إعدادات الخادم.
  4. راجع طلبات الواجهات البرمجية البعيدة أثناء عرض الصفحة، واستخدم تخزينًا مؤقتًا مناسبًا ومهلات محدودة.
  5. تحقّق مع مزوّد الاستضافة من التخزين المؤقت الدائم للكائنات، وتأكّد من الإبطال عند تغيّر المحتوى.
  6. خزّن HTML العام مؤقتًا فقط حيث يكون ذلك آمنًا، واستثنِ الاستجابات الموثّقة وسلال التسوّق وإتمام الشراء والاستجابات المخصّصة.
  7. تأكّد من أن مستخدمَين مختلفين لا يمكنهما تلقّي البيانات المخزّنة الخاصة بأحدهما الآخر.
  8. افحص تشبّع المعالج والذاكرة والعمّال تحت حِمل تمثيلي قبل زيادة التزامن.
  9. تحقّق من تنفيذ المهام المجدولة. وإذا نقلت WP-Cron إلى مُجدوِل النظام، فراقب المهام الفائتة والفاشلة.
  10. افحص خطط الاستعلام قبل إضافة الفهارس، وقيّم عبء الكتابة، واختبر على نسخة تمثيلية من البيانات.
  11. راجع الخيارات المحمّلة تلقائيًا كبيرة الحجم مع الإضافة المالكة لها، وخذ نسخة احتياطية قبل أي تنظيف موجّه.
  12. قسّم الاستعلامات الكبيرة إلى صفحات، وتجنّب تحميل مجموعة غير محدودة في الذاكرة.

حسّن العرض والتفاعل

  1. لا تُزِل السكربتات والأنماط غير المستخدمة إلا بعد التحقّق من القوائم والنماذج وإتمام الشراء ومتطلبات المحرّر.
  2. أجّل السكربتات المتوافقة مع الحفاظ على ترتيب الاعتماديات؛ فخاصية async ليست بديلًا عن التنفيذ المرتّب.
  3. افحص الأنماط التي تعيق العرض، واختبر أي أسلوب لـ CSS الحرج على جميع القوالب وأحجام الشاشات.
  4. اجعل صورة LCP قابلة للاكتشاف في HTML الأولي بدل إدراجها لاحقًا عبر JavaScript.
  5. لا تستخدم التحميل الكسول مع صورة LCP. استخدم أولوية الجلب العالية بشكل انتقائي، ثم افحص مخطط الشلال.
  6. قسّم شيفرة JavaScript الثقيلة إلى أجزاء مقيسة، وأعد التحكّم إلى المتصفح بينها عند الحاجة.
  7. اجمع قراءات التخطيط وكتاباته معًا لتجنّب إعادة حساب التخطيط القسرية المتكرّرة.
  8. أزِل الأدوات المصغّرة غير الضرورية التابعة لجهات خارجية، ولا تؤجّل الاختيارية منها إلا إذا سمح سلوكها وقواعد الموافقة بذلك.
  9. احجز أبعاد الصور والمحتوى المضمّن والإعلانات قبل وصول مواردها.
  10. افحص مقاييس الخط البديل وإزاحات التخطيط، واستخدم font-display بشكل مدروس.
  11. حافظ على قابلية استخدام عناصر التحكّم التفاعلية عبر التنقّل بلوحة المفاتيح ومع تقليل الحركة.
  12. اختبر الصفحات الطويلة والأجهزة منخفضة القدرة؛ فالصفحة الرئيسية السريعة لا تثبت أن كل القوالب سريعة.

قدّم موارد بأحجام مناسبة

  1. اختر عرض الصورة وفق المساحة التي تُعرض فيها وكثافة البكسل المتوقّعة.
  2. قارن بين AVIF وWebP والصيغ الحالية على الملف الفعلي بدل افتراض نسبة توفير ثابتة.
  3. وفّر خيارات srcset متجاوبة وقيمة sizes تعكس التخطيط.
  4. استخدم التحميل الكسول للصور خارج الشاشة، وفكّ الترميز غير المتزامن حيث يكون مناسبًا.
  5. أبقِ التسميات والشروحات الأساسية بصيغة HTML؛ فالنص الصغير داخل الصور صعب القراءة.
  6. استضف الخطوط ذاتيًا أو قلّل طلباتها بطريقة أخرى، وحمّل فقط الأوزان ومجموعات الأحرف التي يحتاجها الموقع.
  7. لا تحمّل مسبقًا إلا الموارد الحرجة فعلًا، بعد التحقّق من مخطط شلال الطلبات.
  8. تحقّق من تقديم موارد النصوص بضغط gzip أو Brotli، وتجنّب إعادة ضغط الصور المضغوطة مسبقًا.
  9. استخدم تخزينًا مؤقتًا طويل الأمد للموارد الثابتة ذات الإصدارات، وغيّر عنوان URL الخاص بها عند تغيّر محتواها.
  10. حمّل الفيديو بشكل مقصود. فإخفاء الفيديو عبر CSS وحده لا يضمن توقّف تنزيله.

تحقّق من الإصدار

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

الأسئلة الشائعة

ما الذي ينبغي إصلاحه أولًا؟

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

هل تؤدي نتيجة Lighthouse المنخفضة إلى عقوبة ثابتة في الترتيب؟

لا توجد قاعدة منشورة تفرض عقوبة ثابتة في ترتيب Google على نتيجة Lighthouse تقلّ عن رقم معيّن. استخدم النتيجة لاكتشاف الفرص التقنية، واستخدم البيانات الميدانية لفهم الزوّار الحقيقيين.

هل أحتاج إلى تطبيق الفحوصات الـ 47 كلها على كل موقع ووردبريس؟

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

ما الذي يجب اختباره بعد تغيير إعدادات التخزين المؤقت أو السكربتات؟

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

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

تابع القراءة

تعمّق في تشخيص TTFB ومؤشرات Core Web Vitals وتقديم الصور المتجاوبة.

Paul Edward

بقلم Paul Edward

مطوّر ويب متكامل أول يعمل بـ PHP وLaravel وWordPress وأنظمة ويب مدعومة بالذكاء الاصطناعي.

المزيد عن بول

Leave a Reply

Your email address will not be published. Required fields are marked *

جارٍ تحميل تحقق سريع… (يتطلب JavaScript)

تابع القراءة

نموذج المشروع الخطوة 1 من 2 · العمل

ما الذي تريد بناءه؟

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

العمل

اختر كل ما ينطبق.

المنصة

«لا أعرف» إجابة مقبولة تمامًا.

ما الذي تحاول بناءه، وما الذي يجب أن يقدّمه لمن سيستخدمونه؟ اكتبه كما لو كنت تقوله بصوت عالٍ.

0 / 1200

خطوتان. أقل من دقيقة.