تحسين سرعة ووردبريس

ما تقيسه مؤشرات Core Web Vitals فعلًا

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

أين يذهب الوقت في ووردبريس

1. الخادم لم يستجب بعد. إن كان TTFB ٨٠٠ مللي ثانية، فلن ينجيك أي عمل على الواجهة: ثلث ميزانية LCP استُهلك قبل وصول أول بايت. الأسباب: غياب التخزين الكائني، استضافة بطيئة، إصدار PHP قديم، أو إضافة تستدعي واجهة خارجية أثناء توليد الصفحة.
2. قاعدة البيانات تعمل أكثر من اللازم بكثير. جدول wp_options متضخّم ببيانات تُحمَّل تلقائيًا، واستعلامات بيانات وصفية بلا فهرسة، ومؤقتات منتهية لا يُنظّفها أحد. لا تراها أي أداة واجهة، وهي كثيرًا أكبر مصدر للتحسين.
3. كل إضافة تُحمّل ملفاتها في كل صفحة. إضافة نماذج تُحمّل CSS في الصفحة الرئيسية، ومكتبة شرائح في صفحات بلا شرائح. الإلغاء الشرطي يزيل عادةً ثلث الحجم دون أي تغيير مرئي.
4. الصور أضخم عنصر ولم يُصغّرها أحد. صورة بعرض ٣٠٠٠ بكسل تُعرض بـ ٨٠٠، بلا WebP أو AVIF، وبلا سمتَي width وheight (وهذا يُفسد CLS أيضًا)، وتحميل مؤجّل مطبّق على الصورة الرئيسية — وهو ما يُسيء إلى LCP.
5. الخطوط تعطّل العرض ثم تُزحزح التصميم. أربعة أوزان من عائلتين، بلا font-display: swap، أو مُحمَّلة من نطاق خارجي يحتاج استعلام DNS ومصافحة TLS خاصة به.
6. سكربتات خارجية نسيتها. مدير وسوم، نافذة محادثة، أداتا تحليلات، خريطة حرارية، لافتة كوكيز. غالبًا تستهلك معظم INP، ولا يعوّض ذلك أي تحسين في شيفرتك أنت.

المنهج

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

لماذا لا أسعى إلى نتيجة ١٠٠

نتيجة Lighthouse كاملة ممكنة في أي موقع تقريبًا إن قبلت تعطيل أشياء: تأجيل كل الجافاسكربت، وحذف أدوات التتبع التي يحتاجها التسويق، ودمج كل شيء. رأيت مواقع بنتيجة ١٠٠ وصفحة دفع لا تعمل على Safari.

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

ووكومرس مشكلة مختلفة

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

أسئلة شائعة

كم ستزيد سرعة موقعي؟

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

هل تكتفي بإضافة تخزين مؤقت؟

لا. التخزين المؤقت يخفي البطء ولا يزيله. العمل هو إيجاد ما هو بطيء فعلًا وإصلاحه، ثم يأتي التخزين المؤقت.

هل يعطّل التحسين موقعي؟

لا عند العمل على نسخة تجريبية أولًا. كل تغيير يُختبر — بما يشمل الدفع والنماذج — قبل الإنتاج.

هل تؤثر السرعة في السيو والمبيعات؟

عامل ترتيب مؤكّد لكنه متواضع. الأثر التجاري أكبر: الصفحات البطيئة تفقد الزائر قبل أن يرى العرض.

كيف أتأكد أن العمل نجح؟

أرقام قبل وبعد من نفس الاختبارات على نفس الصفحات، مخبريًا وميدانيًا. الميدانية هي ما تستخدمه جوجل.

الاستضافة تقول إن الموقع سليم. من المُحق؟

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