قياس سرعة ووردبريس على الموبايل بأرقام لا تكذب

فتحت PageSpeed Insights وطلعلك 34، رجعت بعد دقيقة لقيتها 47؟ ده مش سحر ولا الموقع اتصلح لوحده. والعميل اللي دفع “تحسين سرعة” السنة اللي فاتت مش هيعرف يفرّق بين الحالتين غير لو عندك طريقة قياس ثابتة، وده بالظبط اللي هنعمله النهارده.

الطريقة هنا تصلح لأي موقع ووردبريس (WordPress)، وتنتهي بجدول “قبل وبعد” يقدر العميل يعيد إنتاجه بنفسه على pagespeed.web.dev.

لماذا يتغير الرقم بين كل اختبار وآخر؟

تحسب أداة الصفحة على هاتف متوسط وشبكة 4G، وتمنحها درجة أداء من 100 مع قائمة فرص التحسين وتقدير الوقت الذي يوفره…">Lighthouse درجة الموبايل بمحاكاة هاتف متوسط على شبكة 4G. المحاكاة نفسها شبه ثابتة، لكن السكربتات الخارجية في صفحتك ليست كذلك: وسوم الإعلانات، وأدوات التتبع، وطلبات الخطوط.

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

الخطوة 1: شغّل Lighthouse ثلاث مرات وخذ الوسيط

ثبّت Lighthouse عبر npm install -g lighthouse على جهازك، ثم شغّل اختبار الموبايل بهذا الأمر (الإصدار 11 مع Chromium بدون واجهة):

lighthouse "https://example.com/" 
  --only-categories=performance 
  --form-factor=mobile --screenEmulation.mobile 
  --throttling-method=simulate 
  --output=json --output-path=mobile-1.json --quiet 
  --chrome-flags="--headless=new --no-sandbox --disable-gpu"

كرر الأمر مع mobile-2.json وmobile-3.json. لاختبار سطح المكتب استبدل خيارات المحاكاة بـ --screenEmulation.disabled --preset=desktop، ويكفيك تشغيل واحد لأن سطح المكتب نادراً ما يكون المشكلة.

بعدها اختر التشغيل صاحب الدرجة الوسطى، واحتفظ بملفات JSON الثلاثة كدليل:

for f in mobile-*.json; do
  jq -r '"(.categories.performance.score*100|floor) (input_filename)"' "$f"
done | sort -n | sed -n 2p

الخطوة 2: استخرج الأرقام الثمانية التي تهمك

الدرجة النهائية مجرد ملخص. ما يخبرك بما يجب إصلاحه موجود داخل .audits في ملف JSON:

ثم اسحب فرص التحسين مرتبة حسب الوقت الذي توفره، مع تجاهل أي فرصة توفر أقل من 100 مللي ثانية:

jq -r '.audits | to_entries[]
  | select(.value.details.type=="opportunity" and .value.details.overallSavingsMs>100)
  | "(.value.details.overallSavingsMs|floor) ms  ((.value.details.overallSavingsBytes//0)/1024|floor) KB  (.value.title)"' 
  mobile-2.json | sort -rn

الخطوة 3: ثلاث فحوصات للسيرفر لا يظهرها Lighthouse بوضوح

يقيس Lighthouse تحميلاً واحداً مُبطّأً صناعياً، فتضيع داخله تفاصيل السيرفر. ثلاثة طلبات مباشرة بـ curl تكشفها:

for i in 1 2 3; do
  curl -so /dev/null -w '%{time_starttransfer} %{size_download}n' 
    -H 'Accept-Encoding: gzip, br' "https://example.com/"
done
curl -sI -H 'Accept-Encoding: gzip, br' "https://example.com/" 
  | grep -iE '^(content-encoding|cache-control|x-cache|cf-cache-status|x-litespeed-cache|age):'

اقرأ النتيجة هكذا:

• قاعدة البيانات مع كل زيارة، والحل يبدأ بالكاش…">زمن وصول أول بايت (TTFB): خذ وسيط القراءات الثلاث. فوق 600 مللي ثانية يعني أن كل زيارة تبني الصفحة من قاعدة البيانات. وفوق 1,500 مللي ثانية فالاستضافة نفسها هي السقف، وقل ذلك للعميل بدل بيع ضبط إضافي.
• غياب content-encoding: الصفحة تُرسل بلا ضغط نصوص (Text Compression)، فتصل أكبر بثلاث إلى خمس مرات. الإصلاح إعداد واحد في السيرفر أو في إضافة الكاش.
• لا يوجد أي هيدر كاش: لا x-cache ولا cf-cache-status ولا x-litespeed-cache ولا age، ولا أثر لإضافة كاش في مسارات الملفات (wp-rocket، litespeed-cache، w3-total-cache…). هنا يبدأ الإصلاح، قبل أي حديث عن الصور.

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

مثال حقيقي: موقع حصل على 20 من 100

هذه أرقام موقع ووردبريس لشركة أمنية في كاليفورنيا قاسها كاتب المقال الأصلي، دون ذكر اسمها:

الموقع يعمل بـ Elementor وWPBakery معاً، مع إضافة سلايدر، و31 ملف سكربت و45 ملف CSS، بلا إضافة كاش ولا ضغط نصوص ولا CDN، وصورة هيرو حجمها 981 كيلوبايت. أكبر فرصة كانت تفعيل ضغط النصوص وحده: توفير نحو 11 ثانية و2.1 ميجابايت.

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

الخطوة 4: حوّل النتائج إلى قائمة إصلاحات مرتبة

القاعدة هنا: لا تضع إصلاحاً في القائمة إلا إذا ظهر دليله في القياس. هكذا تخرج بتوصية خاصة بهذا الموقع بدل قائمة عامة منسوخة.

بخصوص الخطوط العربية: إذا كان موقعك يستخدم Cairo أو Tajawal من Google Fonts فارفع ملفات woff2 إلى موقعك واستدعها محلياً. ستتخلص من طلب خارجي كامل، وتمنع قفز النص عند تبديل الخط.

ما لا تصلحه أي إضافة سرعة

قل هذه الأشياء للعميل من البداية حتى لا تَعِد برقم لن يتحقق:

• استضافة بطيئة: إذا بقي TTFB فوق 1.5 ثانية على صفحة مخزنة في الكاش، فلن تحرك تحسينات الواجهة الدرجة كثيراً.
• منشئ الصفحات نفسه: Elementor وWPBakery وDivi تحمّل قدراً كبيراً من CSS وJavaScript بطبيعتها. أنت تحسّن حولها، وإعادة بناء القالب مشروع إعادة تصميم وليست مهمة سرعة.
• سلة WooCommerce وصفحة الدفع: لا تُخزّن في الكاش عمداً، فقِس ووعد على الصفحات العامة فقط.
• فرق أقل من 10 نقاط: يقع داخل هامش التذبذب الطبيعي على المواقع الثقيلة، فلا تعتبره إنجازاً.

في Elementor: فعّل من Settings ثم Features خيارات مثل Optimized DOM Output (تقليل عناصر الصفحة) وImproved Asset Loading (تحميل ملفات الودجت المستخدمة فقط)، واستخدم Flexbox Container بدل الأقسام والأعمدة القديمة. هذه وحدها تخفض عدد عناصر DOM بشكل ملحوظ قبل أن تلمس أي إضافة.

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

س: لماذا تختلف درجة PageSpeed Insights في كل مرة أختبر فيها موقعي؟
ج: لأن السكربتات الخارجية مثل الإعلانات والتتبع والخطوط لا تُحمّل بنفس السرعة كل مرة. شغّل الاختبار ثلاث مرات واعتمد الوسيط.

س: ما الدرجة المقبولة لموقع ووردبريس على الموبايل؟
ج: هدف Google هو 90 فأكثر، لكن الأهم أن يكون LCP أقل من 2.5 ثانية وCLS أقل من 0.1، لأن هذه هي مقاييس Core Web Vitals الفعلية.

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

س: كيف أعرف أن الاستضافة هي سبب بطء موقعي؟
ج: قِس TTFB بـ curl ثلاث مرات على صفحة مخزنة في الكاش. إذا بقي فوق 1.5 ثانية فالمشكلة في الاستضافة أو في بُعد مركز البيانات عن زوارك.

الخلاصة

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

جرّب الطريقة دي على موقعك النهارده، وابعتلنا أرقام “قبل وبعد” في التعليقات، وافتكر: ابن موقعك قطعة قطعة، وأول قطعة هي القياس الصح.

مرجع المقال (بالإنجليزية): Why your WordPress site scores 20/100 on a phone, and how to measure it so the number holds up
المقال ده مش ترجمة حرفية: متكيّف للقارئ العربي ومضاف عليه سياق ووردبريس وElementor وJetEngine.