سرعة الموقع هي أول ما يختبره الزائر قبل أن يرى أي محتوى؛ فإذا تأخر ظهور الصفحة أو اهتزت عناصرها أثناء التحميل، يغادر كثيرون قبل قراءة سطر واحد. في هذا الدليل نتعرف على أسباب بطء المواقع، والأدوات والمعايير التي تقيس بها السرعة بدقة، والترتيب الصحيح لمعالجة المشكلات حتى لا يذهب وقتك وميزانيتك في أعمال قليلة الأثر.
لماذا تهم سرعة الموقع؟ ما هو أبعد من الترتيب في جوجل
السرعة ليست مجرد رقم في التقارير التقنية:
- تجربة المستخدم: كثير من الزيارات يأتي من الهواتف، عبر إنترنت الجوال الذي لا تكون جودته ثابتة دائماً. والصفحة السريعة على شبكة Wi-Fi في المكتب قد تكون بطيئة على هاتف العميل.
- المبيعات والعملاء المحتملون: نموذج تواصل يتأخر تحميله، أو زر شراء يتحرك تحت إصبع المستخدم، يؤدي مباشرة إلى خسارة العميل.
- تحسين محركات البحث (SEO): تأخذ جوجل تجربة الصفحة، ومنها مؤشرات Core Web Vitals، في الاعتبار إلى جانب عوامل أخرى. لكن السرعة وحدها لا تصنع الترتيب، فصلة المحتوى بالبحث وجودته لهما وزن أكبر؛ غير أنه حين تتقارب صفحتان في المحتوى، قد تصنع التجربة الأفضل الفارق. وإن كنت تعمل على SEO لموقعك، فالسرعة من أسس خدمات SEO والتحسين التقني للموقع.
- تكلفة الإعلانات: في الإعلانات بالدفع لكل نقرة، تؤثر جودة صفحة الهبوط في تقييم الإعلان. والمبلغ الذي تدفعه مقابل النقرة يضيع فعلياً إذا غادر المستخدم قبل تحميل الصفحة. وإن كنت تبني صفحة مستقلة لكل حملة، فاطلع أيضاً على نصائح تصميم صفحة الهبوط.
لماذا موقعي بطيء؟ ستة أسباب رئيسية
قبل أي خطوة، عليك أن تعرف مصدر المشكلة. فكل المواقع البطيئة تقريباً تعاني من بند واحد أو أكثر من هذه القائمة.
1. استضافة ضعيفة أو غير مناسبة
إذا استغرق الخادم وقتاً طويلاً في بناء الصفحة، فلن يعوّض ذلك أي تحسين آخر. يظهر هذا الوقت في مؤشر TTFB (زمن وصول أول بايت). من الأسباب الشائعة: استضافة مشتركة مزدحمة، وإصدار PHP قديم، وموارد غير كافية للمواقع الثقيلة مثل المتاجر، وبُعد الخادم جغرافياً عن الجمهور. وإن كان جمهورك يتركز في منطقة واحدة، كدول الخليج مثلاً، فإن موقع الخادم وجودة اتصاله بتلك المنطقة لهما أهمية كبيرة.
2. صور ثقيلة غير محسّنة
هذا هو السبب الأكثر شيوعاً: صورة جاءت مباشرة من الكاميرا أو من المصمم بأبعاد تبلغ آلاف البكسلات، وتُعرض في إطار صغير. والصورة الكبيرة أعلى الصفحة الرئيسية (عادةً البانر أو السلايدر) كثيراً ما تكون هي العنصر الذي يُفسد مؤشر LCP.
3. كثرة الإضافات والسكربتات
كل إضافة أو مكتبة تضيفها قد تحمّل ملفات CSS وJavaScript الخاصة بها في جميع الصفحات، حتى تلك التي لا تحتاج إليها. والمشكلة ليست في عدد الإضافات وحده؛ فإضافة واحدة رديئة البرمجة قد تكون أبطأ من عشر إضافات خفيفة.
4. غياب التخزين المؤقت (Cache)
من دون تخزين مؤقت، يبني الخادم الصفحة من الصفر مع كل زيارة: استعلامات لقاعدة البيانات، وتنفيذ الكود، وتوليد HTML. أما التخزين المؤقت للصفحات فيحفظ النتيجة ويقدمها للزائر التالي. ويضمن التخزين المؤقت في المتصفح عدم إعادة تنزيل الملفات الثابتة، مثل الشعار والخطوط وملفات CSS، في الزيارة التالية.
5. خطوط ثقيلة أو سيئة التحميل
تستخدم مواقع كثيرة، ولا سيما المواقع العربية، خطاً مخصصاً واحداً أو أكثر. وتحميل جميع أوزان الخط (رفيع، عادي، متوسط، عريض، أسود) بينما لا يُستخدم منها سوى وزنين، أو تحميل الخط من خدمة خارجية، يزيد زمن التحميل وقد يتسبب في قفز النص عند استبدال الخط.
6. سكربتات الطرف الثالث
أدوات الدردشة المباشرة، وأكواد الإحصاءات والتتبع، وبكسلات الإعلانات، والخرائط المضمّنة، وفيديوهات يوتيوب، وأدوات الشبكات الاجتماعية، كلها تُحمَّل من خوادم أخرى لا تتحكم في سرعتها. وإذا كانت إحدى هذه الخدمات بطيئة أو غير مستقرة لدى زوارك، فقد تؤخر تحميل بقية الصفحة أيضاً.
كيف تقيس سرعة موقعك؟
عبارة «الموقع بطيء» مجرد إحساس؛ ولحل المشكلة تحتاج إلى أرقام.
PageSpeed Insights: بيانات المستخدمين الحقيقيين مقابل بيانات المختبر
تعرض أداة PageSpeed Insights المجانية من جوجل نوعين من البيانات يجب ألا يختلطا:
- البيانات الميدانية (Field Data): التجربة الفعلية لمستخدمي متصفح Chrome خلال الأسابيع القليلة الماضية. لا تظهر إلا إذا كانت الزيارات كافية، وهي المعيار الذي تعتمده جوجل في التقييم.
- بيانات المختبر (Lab Data): نتيجة اختبار محاكاة يُجرى بأداة Lighthouse في اللحظة نفسها. والدرجة من 0 إلى 100 تخص هذا الجزء، وهي مفيدة في العثور على سبب المشكلة، لكنها تتفاوت قليلاً من تشغيل إلى آخر.
إذا كانت بياناتك الميدانية جيدة، فلا داعي لقلق جدي من درجة مختبر متوسطة.
مؤشرات Core Web Vitals بلغة بسيطة
حددت جوجل ثلاثة مؤشرات باسم «مؤشرات أداء الويب الأساسية». ويُقاس كل مؤشر عند المئين الخامس والسبعين من الزيارات؛ أي أن ثلاثة أرباع الزيارات على الأقل يجب أن تقع ضمن نطاق «جيد».
| المؤشر | ماذا يقيس؟ | جيد | يحتاج إلى تحسين | ضعيف |
|---|---|---|---|---|
| LCP | زمن عرض أكبر جزء من المحتوى المرئي (عادةً الصورة الرئيسية أو العنوان) | حتى 2.5 ثانية | من 2.5 إلى 4 ثوانٍ | أكثر من 4 ثوانٍ |
| INP | سرعة استجابة الصفحة لنقرات المستخدم ولمساته وكتابته | حتى 200 ملّي ثانية | من 200 إلى 500 ملّي ثانية | أكثر من 500 ملّي ثانية |
| CLS | مقدار التحرك غير المتوقع لعناصر الصفحة أثناء التحميل | حتى 0.1 | من 0.1 إلى 0.25 | أكثر من 0.25 |
ببساطة: يسأل LCP «متى رأيت المحتوى الرئيسي؟»، ويسأل INP «حين ضغطت الزر، هل استجابت الصفحة بسرعة؟»، ويسأل CLS «بينما كنت أقرأ أو أنقر، هل تحرك شيء تحت يدي؟».
نصائح للقياس الصحيح
- اعتمد نتيجة الجوال. تعتمد جوجل نسخة الجوال أساساً للتقييم، والمشكلات تكون عادةً أشد هناك.
- لا تختبر الصفحة الرئيسية وحدها. قِس أيضاً صفحة منتج وصفحة تصنيف ومقالاً؛ فلكل نوع من الصفحات قالب مختلف.
- كرر كل اختبار عدة مرات وخذ المتوسط، خاصةً لدرجة المختبر.
- راجع تقرير Core Web Vitals في Google Search Console؛ فهو يجمع الصفحات المتشابهة في مجموعات ويُظهر في أي مجموعة تكمن المشكلة.
- سجّل الأرقام قبل كل تغيير وبعده لتعرف أي إجراء أحدث أثراً فعلياً.
تسريع موقعك: قائمة الإصلاحات حسب الأولوية
منطق ترتيب الأولويات بسيط: أولاً الأعمال عالية الأثر قليلة المخاطر، ثم الأعمال الأكثر تعقيداً. الجدول التالي نقطة انطلاق عامة؛ أما الترتيب الدقيق لكل موقع فيتوقف على نتائج القياس.
| الإجراء | على أي مؤشر يؤثر عادةً؟ | الصعوبة والمخاطر |
|---|---|---|
| تحسين الصور | LCP | منخفضة |
| تفعيل التخزين المؤقت للصفحات والمتصفح | LCP وTTFB | منخفضة إلى متوسطة |
| ترقية الاستضافة أو إصدار PHP | TTFB وLCP | متوسطة |
| حذف الإضافات والسكربتات الزائدة | INP وLCP | متوسطة |
| حجز مساحة للصور والبانرات | CLS | منخفضة |
| تحسين الخطوط | LCP وCLS | منخفضة إلى متوسطة |
| تأجيل JavaScript غير الضروري | INP وLCP | متوسطة إلى عالية |
| استخدام شبكة CDN | LCP | متوسطة |
1. أصلح الصور
- حوّل الصور إلى صيغ أخف مثل WebP (أو AVIF إذا كان قالبك ومتصفحات جمهورك يدعمانها).
- اجعل أبعاد الصورة متناسبة مع إطار العرض، وقدّم نسخة أصغر للجوال (الخاصية srcset).
- فعّل التحميل الكسول (lazy loading) للصور أسفل الصفحة، لكن لا تستخدم التحميل الكسول أبداً للصورة الرئيسية أعلى الصفحة؛ فذلك يُسوء LCP. ولهذه الصورة تحديداً يمكنك رفع أولوية التحميل (fetchpriority).
- استبدل السلايدر متعدد الصور أعلى الصفحة بصورة ثابتة واحدة.
2. فعّل التخزين المؤقت
فعّل التخزين المؤقت للصفحات، والتخزين المؤقت في المتصفح للملفات الثابتة، والضغط (Gzip أو Brotli) على الخادم. وفي المواقع الديناميكية مثل المتاجر، يجب ألا تُخزَّن صفحات سلة التسوق والحساب مؤقتاً؛ فتأكد من مراجعة هذا الإعداد.
3. افحص الخادم
إذا كان TTFB مرتفعاً، فالمشكلة في الخادم أو الكود، لا في المتصفح. انتقل إلى إصدار PHP أحدث مدعوم، وقارن موارد الاستضافة باحتياجات الموقع، وإن لم تعد الاستضافة المشتركة كافية، فانتقل إلى خادم افتراضي خاص (VPS) أو باقة أعلى.
4. احذف كل ما لا تحتاج إليه
اكتب قائمة بالإضافات وأكواد الطرف الثالث، واسأل عن كل منها: «لو حذفته غداً، ما الذي سيتعطل؟». أكواد التتبع القديمة من حملات انتهت، والأدوات التي لا ينظر أحد في تقاريرها، هي أول المرشحين للحذف.
5. أوقف قفز الصفحة
حدّد العرض والارتفاع لجميع الصور والفيديوهات وعناصر iframe حتى يحجز المتصفح مساحتها مسبقاً. والبانرات والنوافذ المنبثقة التي تُضاف فوق المحتوى بعد التحميل من أكثر أسباب ارتفاع CLS شيوعاً.
6. خفّف الخطوط
لا تحمّل من الخط إلا الأوزان المستخدمة فعلاً، واستضف الخطوط على خادمك، واستخدم صيغة WOFF2، واضبط font-display لتتأكد من أن النص لا يبقى غير مرئي حتى يصل الخط.
7. أدِر JavaScript وCSS
شغّل السكربتات غير اللازمة للعرض الأولي باستخدام defer أو التحميل المؤجل، وقلّل CSS غير المستخدم، واضغط الملفات (minify). هذه المرحلة هي الأكثر عرضة لإحداث خلل في المظهر أو الوظائف؛ لذا بعد كل تغيير، اختبر يدوياً النماذج وقائمة الجوال ومسار الشراء.
نصائح خاصة بمواقع ووردبريس (WordPress)
يتمتع ووردبريس بمرونة كبيرة، وهذه المرونة نفسها تفتح الباب أمام البطء. هذه أكثر الحالات تكراراً في مواقع ووردبريس:
- ثبّت إضافة تخزين مؤقت واحدة فقط. إضافات مثل LiteSpeed Cache (إذا كان خادم الويب لدى الاستضافة LiteSpeed) أو WP Rocket أو W3 Total Cache تعمل كل منها وحدها؛ وتثبيت إضافتي تخزين مؤقت أو إضافتي تحسين في الوقت نفسه يسبب عادةً تعارضاً وأخطاء.
- استخدم أدوات بناء الصفحات بحذر. أدوات البناء بالسحب والإفلات تولّد الكثير من الأكواد والملفات الزائدة. وإذا كان قالب الموقع مبنياً من الأساس على أداة بناء صفحات، فإن سقف التحسين يكون أكثر محدودية. وفي هذه الحالة يكون تغيير القالب أحياناً الحل الأكثر استدامة؛ وقد ذكرنا علاماته في دليل إعادة تصميم الموقع.
- حافظ على نظافة قاعدة البيانات. النسخ القديمة من المقالات (revisions)، والتعليقات المزعجة، والبيانات المؤقتة منتهية الصلاحية (transients)، والإعدادات المتبقية من إضافات محذوفة، كلها تثقل قاعدة البيانات. وحدّد أيضاً عدد النسخ المحفوظة.
- في WooCommerce، انتبه للطلبات الخلفية. تحديث سلة التسوق، وأدوات «منتجات ذات صلة»، والفلاتر المتقدمة قد ترسل طلبات ثقيلة إلى الخادم. وفي المتاجر الكبيرة، يساعد التخزين المؤقت للكائنات (مثل Redis) على الخادم مساعدة ملحوظة.
- حافظ على تحديث القالب والإضافات، وقبل أي تغيير كبير، خذ نسخة احتياطية أو اختبر على نسخة تجريبية.
كثير من هذه الأعمال جزء من الصيانة المنتظمة للموقع، وليست مشروعاً منفصلاً؛ وستجد قائمة أشمل في قائمة صيانة مواقع ووردبريس.
هل يكفي تحسين لمرة واحدة أم تحتاج إلى مراقبة مستمرة؟
سرعة الموقع لا تبقى ثابتة. فبانر جديد كبير الحجم، أو إضافة ثُبّتت من أجل حملة، أو كود تتبع جديد، أو تحديث للقالب، قد يمحو نتيجة أسابيع من التحسين في يوم واحد. ولتجنب ذلك:
- راجع تقرير Core Web Vitals في Google Search Console مرة واحدة شهرياً على الأقل.
- قبل نشر تغييرات كبيرة، اختبر الصفحات الرئيسية بأداة PageSpeed Insights.
- ضع قواعد لفريق المحتوى عند رفع الصور: الحد الأقصى للأبعاد، والصيغة، والحجم.
- راقب توفر الموقع (Uptime) وزمن استجابة الخادم بأداة مراقبة.
إن لم يكن لديك الوقت أو الفريق التقني لهذه المراقبة، يمكنك إسنادها إلى فريق دعم؛ فمراقبة السرعة والتحديثات والنسخ الاحتياطي المنتظم جزء من خدمات صيانة المواقع ورعايتها لدى MyTarh.
متى تصلح الأمر بنفسك ومتى تحتاج إلى متخصص
قبل البدء، حدّد هدفاً واقعياً: ليس المطلوب أن يفتح الموقع في «عدد معين من الثواني». الهدف المعقول أن تصل الصفحات المهمة في البيانات الميدانية إلى عتبات «جيد» في Core Web Vitals؛ أي LCP حتى 2.5 ثانية، وINP حتى 200 ملّي ثانية، وCLS حتى 0.1. ولا يَعِد أي متخصص صادق بالوصول إلى رقم محدد قبل فحص الموقع، لأن جزءاً من النتيجة يتوقف على الاستضافة والقالب والسكربتات الخارجية.
| المهمة | بنفسك | متخصص |
|---|---|---|
| ضغط الصور وتحويلها وتحديد أبعادها | نعم | — |
| حذف الإضافات وأكواد التتبع غير المستخدمة (مع نسخة احتياطية) | نعم | — |
| تثبيت إضافة تخزين مؤقت واحدة وضبطها الأساسي | نعم عادةً | في المتاجر، ضبط استثناءات السلة والحساب |
| ارتفاع TTFB أو ترقية PHP أو نقل الاستضافة | — | نعم |
| ضعف INP بسبب JavaScript القالب أو أداة بناء الصفحات | — | نعم |
| التخزين المؤقت للكائنات والاستعلامات الثقيلة وقاعدة البيانات | — | نعم |
قاعدة بسيطة: إذا لم تستطع التراجع عن الإجراء بنقرة واحدة، أو كان يؤثر في النماذج أو سلة التسوق أو الدفع، فلا تجربه بنفسك على الموقع الفعلي.
هذه العلامات تخبرك بأن الوقت قد حان لطلب المساعدة:
- أنجزت الأعمال قليلة المخاطر، لكن تقرير Core Web Vitals لم يتغير بعد عدة أسابيع.
- كل تحسين يعطّل شيئاً ولا تعرف السبب.
- أصبح الموقع بطيئاً فجأة دون أي تغيير ملحوظ من جانبك. خذ هذا على محمل الجد: الاستهلاك المفاجئ لموارد الخادم، أو ملفات مجهولة، أو عمليات إعادة توجيه غريبة قد تكون علامة على برمجية خبيثة لا مشكلة سرعة. وفي هذه الحالة، وقبل أي تحسين، راجع علامات اختراق الموقع وخطوات استعادته.
- لا تملك وقتاً للمراقبة الشهرية، وتتراجع السرعة مجدداً كل بضعة أشهر. هنا يكون إسناد العمل إلى صيانة المواقع ورعايتها أكثر منطقية من تحسينات متتالية لمرة واحدة.
أخطاء تُفسد التحسين
- السعي وراء درجة 100: الهدف تجربة جيدة للمستخدم الحقيقي والبقاء ضمن نطاق «جيد» في Core Web Vitals. وقضاء أسابيع لكسب بضع درجات إضافية في المختبر لا يستحق العناء غالباً.
- تثبيت عدة إضافات تحسين في وقت واحد: بدلاً من أن تتراكم الآثار، ينتج عادةً تعارض وأعطال.
- ضغط JavaScript ودمجه بشكل مفرط دون اختبار: قد تكون النتيجة نموذجاً لا يُرسَل أو قائمة لا تفتح على الجوال.
- الاختبار على سطح المكتب وعلى الصفحة الرئيسية فقط: المشكلة الحقيقية تكون غالباً في صفحات المنتجات والمقالات على الجوال.
الأسئلة الشائعة
ما مدى تأثير سرعة الموقع على الترتيب في جوجل؟
تأخذ جوجل تجربة الصفحة في الاعتبار إلى جانب عشرات العوامل الأخرى، لكن جودة المحتوى وصلته بالبحث لهما أثر أكبر. انظر إلى السرعة أساساً على أنها جزء من تجربة المستخدم ومعدل التحويل، لا رافعة مباشرة للترتيب.
درجتي في PageSpeed منخفضة لكن الموقع يفتح لديّ بسرعة؛ أيهما الصحيح؟
على الأرجح كلاهما. فأنت تختبر بالإنترنت والجهاز الخاصين بك، وغالباً مع ملفات مخزنة مؤقتاً، بينما يحاكي اختبار PageSpeed هاتفاً متوسطاً على إنترنت أبطأ. والمعيار النهائي هو البيانات الميدانية للمستخدمين الحقيقيين؛ وإن لم تتوفر بعد، فخذ نتيجة المختبر للجوال على محمل الجد.
هل استخدام شبكة CDN مفيد لموقعي؟
يتوقف ذلك على جمهورك. إذا كان معظم زوارك في دولة واحدة وكان خادمك قريباً منهم أصلاً، فقد لا تفيد شبكة CDN، بل إن شبكة لا تملك نقاط وجود قريبة قد تطيل المسار. أما إذا كان جمهورك موزعاً على عدة دول أو كان لديك الكثير من الملفات الثقيلة، فقد تفيد شبكة CDN لها نقاط وجود قريبة من زوارك. قِس الأداء قبل التفعيل وبعده.
هل أستطيع تحسين سرعة موقع ووردبريس بنفسي؟
يمكنك عادةً تنفيذ أجزاء مثل ضغط الصور وحذف الإضافات غير المستخدمة وتثبيت إضافة تخزين مؤقت بنفسك. أما مهام مثل ضبط الخادم وإدارة JavaScript وتحسين قاعدة البيانات فتنطوي على خطر تعطيل الموقع، ومن الأفضل أن ينفذها متخصص مع وجود نسخة احتياطية.
بعد التحسين، متى تظهر النتيجة في Google Search Console؟
البيانات الميدانية لدى جوجل هي متوسط الأسابيع القليلة الماضية، لذا يظهر التحسن في التقارير تدريجياً. يمكنك رؤية بيانات المختبر في PageSpeed فوراً، لكن لتأكيد الإصلاحات في تقرير Core Web Vitals عليك الانتظار بضعة أسابيع.
سرعة الموقع لا تُصلَح بإضافة واحدة أو حيلة واحدة: حدّد المشكلة أولاً بدقة باستخدام PageSpeed Insights وGoogle Search Console، ثم ابدأ بالأعمال عالية الأثر قليلة المخاطر مثل الصور والتخزين المؤقت، وأخيراً امنع الموقع من التباطؤ مجدداً بالمراقبة المنتظمة. وإن أردت فحص الوضع الحالي لموقعك والحصول على قائمة إصلاحات مرتبة حسب الأولوية، فتواصل مع MyTarh للحصول على استشارة مجانية عبر صفحة دعم المواقع وتحسينها.