خدمة WordPress · الأداء والنمو

تحسين سرعة موقع ووردبريس بعد تشخيص أسباب البطء

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

اطلب تشخيص سرعة موقعك شاهد أعمالي في ووردبريس
لقطة من عيادات سيفيل على WordPress

ما وراء درجة PageSpeed

الدرجة من 100 ليست الهدف، والمائة الكاملة ليست وعدًا أقطعه

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

ما يهم فعلًا هو ما يعيشه زوارك: هل تظهر الصفحة بسرعة على موبايل متوسط بشبكة 4G في القاهرة أو الرياض؟ هل يستجيب الزر عند النقر؟ هل يقفز المحتوى أثناء التحميل؟ هذه هي مقاييس Core Web Vitals التي تعتمدها Google من بيانات المستخدمين الحقيقيين (CrUX)، وهي ما أعمل عليه.

ما لا أضمنه: درجة 100/100، أو أن تحسين السرعة وحده سيرفع ترتيبك في البحث. السرعة عامل من عوامل كثيرة، وأي وعد بغير ذلك تسويق لا هندسة.

المقارنةاختبار السرعةتجربة الزوار الفعلية
مصدر البياناتاختبار محاكاة عبر Lighthouse أو PageSpeed Insights، بجهاز وشبكة محددين.بيانات زوار حقيقيين في CrUX وSearch Console، مجمّعة خلال آخر 28 يومًا.
ماذا يوضّح؟يساعد على تحديد الصور والملفات والسكربتات التي تؤخّر التحميل.يوضّح جودة تجربة الاستخدام لدى الزوار على أجهزتهم وشبكاتهم المختلفة.
ما حدوده؟قد تتغير النتيجة بين الاختبارات، ولا تمثّل وحدها تجربة كل زائر.يحتاج زيارات كافية، ويظهر أثر التعديلات تدريجيًا مع تجدد البيانات.
كيف أستفيد منه؟تشخيص أسباب البطء، وترتيب الإصلاحات، واختبار أثرها قبل وبعد.متابعة أثر التحسينات على تجربة الزوار وتقييم النتيجة بمرور الوقت.

مواقع تقودها الصور والوسائط

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

  • لقطة من الصفحة الرئيسية لـ عيادات سيفيل على WordPress

    عيادات سيفيل

    • WordPress
    • صحة وجمال

    عيادات سيفيل، موقع ووردبريس في مجال العيادات الطبية؛ تقديم العيادات، مجالات الخدمة، طلب الموعد.

  • لقطة من الصفحة الرئيسية لـ أوركيد كلينك على WordPress

    أوركيد كلينك

    • WordPress
    • صحة وجمال

    أوركيد كلينك، موقع ووردبريس في مجال عيادات التجميل؛ تقديم العيادة، بيانات الاتصال، الخدمات.

  • لقطة من الصفحة الرئيسية لـ مستشفى تعافي على WordPress

    مستشفى تعافي

    • WordPress
    • صحة وجمال

    مستشفى تعافي، موقع ووردبريس في مجال المراكز الطبية؛ التعريف بالمركز، صور المكان، أقسام الخدمات.

  • لقطة من الصفحة الرئيسية لـ د. أحمد عادل على WordPress

    د. أحمد عادل

    • WordPress
    • صحة وجمال

    د. أحمد عادل، موقع ووردبريس في مجال المواقع الطبية؛ الفريق، التواصل، الخدمات.

  • لقطة من الصفحة الرئيسية لـ ويلنس على WordPress

    ويلنس

    • WordPress
    • صحة وجمال

    ويلنس، موقع ووردبريس في مجال التغذية؛ الهوية الغذائية، التواصل، مجالات الخدمة.

  • لقطة من الصفحة الرئيسية لـ مراكز رايدنت للأسنان على WordPress

    مراكز رايدنت للأسنان

    • WordPress
    • صحة وجمال

    مراكز رايدنت للأسنان، موقع ووردبريس في مجال عيادات الأسنان؛ صورة الطبيب، التعريف، الخدمات.

  • لقطة من الصفحة الرئيسية لـ The Elite Works على WordPress

    The Elite Works

    • WordPress
    • عقارات وإنشاءات

    The Elite Works، موقع ووردبريس في مجال الإنشاءات والمقاولات؛ صور الإنشاءات، تعريف الشركة، الخدمات.

اطلب تشخيص سرعة موقعك كل مواقع ووردبريس في معرض الأعمال

LCP وINP وCLS

ثلاثة مقاييس تقيس ثلاث تجارب مختلفة، ولكل منها أسبابه في ووردبريس

العتبات أدناه هي حدود «الجيد» التي تنشرها Google عند النسبة المئوية 75 من الزيارات، وأعمل عليها كأهداف لا كضمانات، لأن جزءًا منها يعتمد على أجهزة زوارك وشبكاتهم.

LCP Largest Contentful Paint
متى يظهر أكبر عنصر في الشاشة الأولى

غالبًا صورة البطل أو العنوان الرئيسي. أسبابه الشائعة في ووردبريس: صورة غير مضغوطة أو بلا أولوية تحميل، خطوط ويب تحجب النص، سيرفر بطيء الاستجابة (TTFB)، وCSS كبير يحجب العرض.

الهدف ≤ 2.5 s
INP Interaction to Next Paint
كم تتأخر الصفحة في الاستجابة للنقر أو الكتابة

حل محل FID. أسبابه: سكربتات ثقيلة في الخيط الرئيسي (منزلقات، أدوات تتبع كثيرة، بانٍ صفحات)، ومعالجات أحداث طويلة، وتحميل كل JavaScript في كل صفحة.

الهدف ≤ 200 ms
CLS Cumulative Layout Shift
كم يقفز المحتوى أثناء التحميل

أسبابه: صور بلا أبعاد، إعلانات ولافتات تُحقن لاحقًا، خطوط تبدل الشكل بعد الظهور، وعناصر تُضاف فوق المحتوى بـ JavaScript.

الهدف ≤ 0.1

تشريح التحميل

نعرف أين يتأخر موقعك، ثم نبدأ بالأهم

أحلّل رحلة تحميل الصفحة: من استجابة السيرفر إلى ظهور المحتوى وتشغيل الأدوات. الرسم يوضّح المراحل التي أفحصها لتحديد سبب البطء بدل الاكتفاء بتثبيت إضافة كاش.

مراحل تحميل الصفحةرسم توضيحي
  • استجابة السيرفر (TTFB)PHP + قاعدة البيانات قبل أول بايت
  • بنية الصفحة وتنسيقهاملفات القالب والبانِي والإضافات
  • خطوط الويبتحجب النص حتى تصل إن لم تُضبط
  • صورة الهيرو (LCP)الحجم والصيغة والأولوية
  • أدوات التتبع والخدمات الخارجيةتتبع، دردشة، خرائط، فيديو
  • سكربتات القالب والإضافاتتؤثر على INP عند التفاعل
  • صور أسفل الصفحةتحميل مؤجّل عند اقترابها من الشاشة

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

ما أجمعه قبل أي تعديلتقارير PageSpeed لأهم خمس صفحات (موبايل وحاسوب)، بيانات Core Web Vitals من Search Console، شلال التحميل من أدوات المطور، عدد الاستعلامات وزمنها من Query Monitor، وقائمة الإضافات مع أثر كل منها. هذا هو تقرير الأساس الذي تستلمه.
الخطة تُرتب حسب الأثر والجهدصورة بطل بحجم ميغابايتين تُصلح في دقائق وتغير LCP كثيرًا؛ أما إعادة كتابة قالب ثقيل فعمل كبير يُقترح فقط إن كان هو السبب الفعلي.

أين الإصلاح

خمس طبقات يمكن أن يكون البطء في أي منها، والكاش آخرها لا أولها

التشخيص يحدد الطبقة. العمل على طبقة ليست هي السبب يضيع الوقت ويعطي شعورًا زائفًا بالتحسن.

  • الصور والوسائط

    ضغط وتحويل إلى WebP/AVIF، مقاسات مناسبة لكل مكان، أبعاد صريحة لتجنب CLS، أولوية عالية لصورة LCP وتحميل كسول للباقي. غالبًا أكبر مكسب بأقل جهد.

  • JavaScript وCSS

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

  • الخطوط

    تحميل الأوزان المستخدمة فقط، font-display مناسب، استضافة ذاتية عند الحاجة، وضبط بديل مقارب حتى لا يقفز النص العربي عند وصول الخط.

  • PHP وقاعدة البيانات

    استعلامات بطيئة من إضافات أو قوالب، جداول خيارات متضخمة (autoload)، مراجعات ومسودات متراكمة، وإصدار PHP قديم. تُقاس بـ Query Monitor وسجلات السيرفر.

  • الاستضافة والكاش وCDN

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

  • الإضافات والقالب

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

تحفظات WooCommerce

المتاجر أثقل بطبيعتها، وكاش خاطئ فيها أخطر من بطء

في المتجر تختلف القواعد: صفحات السلة والدفع وحسابي والطلبات لا تُكاش أبدًا، وإلا رأى عميل سلة عميل آخر. أجزاء السلة الديناميكية (fragments) تُضبط لتعمل فقط حيث تلزم، والمستخدمون المسجلون يُستثنون من كاش الصفحات.

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

  • استثناء السلة والدفع وحسابي من كاش الصفحات والـ CDN، واختبارها بحسابين
  • تحميل سكربتات WooCommerce والدفع في صفحات المتجر فقط
  • فهرسة أو استبدال استعلامات الفلاتر والبحث الثقيلة
  • صور المنتجات بمقاسات مسجلة وضغط وتحميل كسول في الشبكة
  • كاش الكائنات (Object cache) حين تتوفر Redis أو ما يماثلها لدى الاستضافة
  • مراجعة المهام المجدولة (Action Scheduler) المتراكمة التي تثقل كل طلب
  • اختبار كامل للشراء بعد كل تغيير في الكاش أو السكربتات

كيف أوثّق قبل وبعد

لا أعرض هنا أرقام عملاء؛ أعرض المنهجية التي تجعل أرقامك أنت قابلة للتصديق

مقارنة بلا شروط موحدة لا تثبت شيئًا. هذا ما أفعله لتكون المقارنة في تقريرك صادقة.

  1. تثبيت الشروط

    الصفحات نفسها (الرئيسية وأهم صفحة خدمة أو منتج)، الجهاز المحاكى نفسه، الشبكة نفسها، والوقت نفسه من اليوم قدر الإمكان.

    المخرج: بروتوكول قياس مكتوب
  2. قياس الأساس

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

    المخرج: تقرير أساس بلقطات محفوظة
  3. التنفيذ على نسخة تجريبية ثم الحي

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

    المخرج: سجل تدخلات وأثر كل منها
  4. القياس بعد التنفيذ

    البروتوكول نفسه تمامًا، ثم انتظار بيانات الميدان لأسابيع لتأكيد الأثر على الزوار الحقيقيين.

    المخرج: مقارنة قبل/بعد موثقة
  5. خطة المتابعة

    ما الذي قد يعيد البطء (إضافة جديدة، صور بلا ضغط، سكربت تتبع جديد) وكيف تراقبه، أو ضمه إلى الصيانة.

    المخرج: قائمة حماية الأداء

أسئلة شائعة

أسئلة عن السرعة والدرجات

هل تضمن درجة 100 في PageSpeed؟
لا، ولا أرشح أن تجعلها هدفًا. الدرجة نتيجة اختبار معملي يتغير من تشغيل لآخر ويتأثر بسكربتات ضرورية لعملك (تتبع، دردشة). الهدف الذي أعمل عليه هو Core Web Vitals في بيانات الميدان ضمن حدود «الجيد»، وأوثق التحسن بنفس الشروط قبل وبعد.
هل يتحسن ترتيب موقعي في البحث مباشرة؟
السرعة عامل واحد من عوامل ترتيب كثيرة، وأثرها غير مباشر غالبًا: تجربة أفضل، تخلٍّ أقل، زحف أسهل. تحسين السرعة لا يعوض محتوى ضعيفًا أو مشاكل فهرسة، وتلك تُعالج في SEO التقني. لا أعد بترتيب.
هل الكاش يسبب مشاكل في السلة أو الدفع؟
نعم إن ضُبط خطأ، وهذا شائع: كاش صفحات يشمل السلة أو الدفع، أو CDN يخزن صفحة حسابي. أستثني هذه الصفحات والمستخدمين المسجلين، وأختبر الشراء بحسابين مختلفين بعد كل تغيير في الكاش.
هل السيرفر هو السبب؟
أحيانًا، ويظهر ذلك في زمن الاستجابة الأول (TTFB) المرتفع حتى مع كاش فعال. أقيسه أولًا؛ إن كان السيرفر غير مناسب أقول ذلك بوضوح مع البدائل بدل محاولة تعويضه بإضافات. وكثيرًا ما يكون السبب إضافة أو استعلامًا لا الاستضافة نفسها.
هل كل الإضافات تبطئ الموقع؟
لا. ما يبطئ هو الإضافات التي تحمّل CSS وJavaScript في كل صفحة، أو تشغّل استعلامات ثقيلة عند كل طلب، أو تتراكم مهامها المجدولة. أقيس أثر كل إضافة على حدة وأقترح الإزالة أو الاستبدال أو تقييد التحميل، لا الحذف العشوائي.
كم تستغرق النتيجة؟
الإصلاحات المعملية تظهر فورًا في القياس بعد التنفيذ. أما بيانات الميدان في Search Console فتعكس التغيير بعد أسابيع لأنها تجمع 28 يومًا من الزيارات. التقرير النهائي يضم الاثنين، والمدة الكلية تُذكر في النطاق حسب حجم الموقع.

أرسل رابط موقعك وأهم صفحة فيه، وسأرد بقراءة أولية لمصدر البطء المحتمل

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

اطلب تشخيص سرعة موقعك كل خدمات ووردبريس