لماذا موقعك بطيء؟ وكيف رفعنا سرعة موقعنا من 47 إلى 99

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

في هذا المقال ستعرف الأسباب الأكثر شيوعًا لبطء المواقع، وكيف تقرأ تقرير PageSpeed Insights دون أن تضيع في المصطلحات. ثم نعرض تجربتنا الفعلية: كيف رفعنا درجة موقع Apex على الموبايل من 47 إلى 99، بالخطوات نفسها التي يمكنك أن تطلب تطبيقها على موقعك.

لماذا موقعك بطيء؟ الأسباب الأكثر شيوعًا

معظم المواقع البطيئة لا تعاني من مشكلة واحدة كبيرة، بل من عوائق صغيرة تتراكم قبل أن يظهر المحتوى. وفي كثير من الحالات لا يكون الخادم هو المتهم، بل ما يُرسَل إلى المتصفح وترتيب تحميله.

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

• سكربتات خارجية تُحمَّل مبكرًا: أدوات التحليلات، وبكسلات الإعلانات، ونوافذ الدردشة، وكلها تتنافس على معالج الهاتف قبل أن يرى الزائر أي شيء.
• صور أكبر من مكانها: صورة بعرض آلاف البكسلات تُعرض في مساحة صغيرة على شاشة الهاتف.
• ملفات CSS وخطوط تعطّل العرض: ينتظر المتصفح تحميلها كاملة قبل أن يرسم الصفحة.
• أطر تصميم تُبنى داخل المتصفح: مثل استخدام نسخة CDN من Tailwind تولّد الأنماط أثناء التشغيل بدل ملف جاهز.
• تحويلات (Redirects) غير ضرورية: كل تحويل رحلة إضافية بين الهاتف والخادم قبل وصول المحتوى.
• طبقات حماية مبالغ فيها: صفحات «جارٍ فحص متصفحك» التي تؤخر كل زائر، وقد تعترض زاحف محرك البحث نفسه.
• تأثيرات بصرية ثقيلة: مثل الضبابية (blur) التي تبدو جميلة على الحاسوب وترهق معالجات الهواتف المتوسطة.
• إضافات كثيرة: في مواقع WordPress خاصة، قد تضيف كل إضافة ملفات CSS وJavaScript إلى كل الصفحات حتى التي لا تحتاجها.

كيف تقرأ تقرير PageSpeed Insights؟

يعطيك تقرير PageSpeed Insights درجة أداء من 100، ويقسّمها إلى مؤشرات محددة. الدرجة ليست الهدف في ذاتها؛ الهدف أن تعرف أي مؤشر يسحبها إلى أسفل ولماذا.

افتح الأداة من رابطها الرسمي PageSpeed Insights، وابدأ بتبويب الموبايل. أهم المؤشرات التي ستراها:

إذا كان لموقعك عدد كافٍ من الزوار، يعرض التقرير أيضًا بيانات المستخدمين الحقيقيين لمؤشرات Core Web Vitals، وهي LCP وINP وCLS. هذه البيانات تعكس تجربة عملائك الفعلية، أما الاختبار المعملي فهو أسرع طريق لاكتشاف الأخطاء وقياس أثر كل تعديل. للتعريفات والحدود الرسمية راجع صفحة Web Vitals على web.dev.

قصتنا: موقع Apex كان يحصل على 47 فقط

موقعنا نفسه كان مثالًا على معظم ما سبق. درجة الموبايل كانت 47، مع أن التصميم بسيط والمحتوى قليل. عندما فككنا التقرير وجدنا أن المشكلة ليست شيئًا واحدًا، بل سبعة عوائق متراكمة.

المفاجأة أن أكبر عائق لم يكن في الكود أصلًا، بل في إعداد على الـ CDN. الـ CDN شبكة خوادم وسيطة تقدّم ملفات موقعك من نقطة قريبة من الزائر وتحميه من بعض الهجمات. كان مفعّلًا لدينا تحدٍّ يعرض صفحة «جارٍ فحص متصفحك» قبل فتح الموقع، وكان يضيف نحو 5 ثوانٍ لكل زائر، والأسوأ أنه كان يعترض زاحف Google.

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

الخطوات السبع التي رفعت السرعة من 47 إلى 99

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

لاحظ أن أيًّا من هذه الخطوات لم يتطلب تغيير الاستضافة أو إعادة تصميم الموقع. كلها قرارات تقنية في طريقة تقديم الصفحة.

لماذا كان تأجيل وسوم Google مؤثرًا إلى هذا الحد؟

لأن وسوم التحليلات والإعلانات ملفات JavaScript تعمل على المسار الرئيسي للمتصفح، وهو المسار نفسه الذي يرسم الصفحة ويستجيب للمس. عندما تعمل أثناء التحميل، يتجمد الموقع لحظات على الهواتف المتوسطة.

في اختبار لاحق على موقعنا، رفع تأجيل وسوم Google وحده الدرجة من 71 إلى 91، وخفّض وقت الحظر الكلي من 160 مللي ثانية إلى صفر. أي أن تعديلًا واحدًا في طريقة تحميل سكربت خارجي صنع فرقًا يقارب 20 نقطة.

كيف يعمل التأجيل حتى أول تفاعل؟

• تُحمَّل الصفحة دون أي سكربت تتبع.
• يستمع الكود لأول حدث من الزائر، مثل التمرير أو اللمس أو تحريك الفأرة أو الضغط على لوحة المفاتيح.
• عند أول حدث يُضاف وسم Google إلى الصفحة مرة واحدة فقط، ثم يعمل بشكل طبيعي.
• يمكن إضافة مهلة زمنية احتياطية يُحمَّل بعدها الوسم إذا لم يتفاعل الزائر.

ينطبق المبدأ نفسه على بكسلات الإعلانات الأخرى ونوافذ الدردشة: كل ما لا يحتاجه الزائر في الثانية الأولى يمكن أن ينتظر.

خطوات تسريع الموقع التي يمكنك تطبيقها اليوم

لا تحتاج إلى فهم الكود لتبدأ. هذه قائمة مراجعة يمكنك أن تمر عليها بنفسك أو تسلّمها لمطوّرك:

• اختبر الصفحة الرئيسية وأهم صفحة خدمة أو منتج على الموبايل، وسجّل الدرجة والمؤشرات قبل أي تعديل.
• افتح موقعك من متصفح خاص (Incognito): هل تظهر صفحة فحص أو انتظار قبل المحتوى؟
• تأكد أن رابط موقعك لا يمر بتحويلات متتالية، مثل الانتقال من http إلى https ثم إلى مسار آخر.
• راجع قائمة السكربتات الخارجية واحذف ما لم تعد تستخدمه من بكسلات وأدوات قديمة.
• أجّل التحليلات والإعلانات والدردشة حتى أول تفاعل.
• حوّل الصور إلى WebP وحدد لكل صورة أبعادها في الكود.
• قلّل عدد الخطوط وأوزانها، فالخطوط العربية تحديدًا قد تكون ملفات كبيرة.
• في WordPress، احذف الإضافات غير الضرورية وفعّل التخزين المؤقت (Cache).
• أعد الاختبار بعد كل تعديل، حتى تعرف ما الذي أحدث الفرق.

السرعة أيضًا جزء من أساسيات الظهور في البحث، وقد شرحنا بقية هذه الأساسيات في دليل SEO للمواقع العربية.

متى لا تكفي التعديلات وتحتاج إلى إعادة بناء؟

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

علامات تدل على أنك وصلت إلى هذا السقف:

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

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

الخلاصة

• معظم بطء المواقع يأتي من عوائق متراكمة: سكربتات خارجية، وصور كبيرة، وCSS وخطوط تعطّل العرض، وتحويلات وطبقات حماية زائدة.
• اقرأ مؤشرات التقرير وليس الدرجة فقط؛ TBT يكشف مشكلات JavaScript، وLCP يكشف مشكلات الصور والعرض.
• رفعنا موقع Apex من 47 إلى 99 بسبع خطوات دون تغيير الاستضافة، وكان أكبر عائق تحدي «فحص المتصفح» في الـ CDN.
• تأجيل وسوم Google حتى أول تفاعل وحده رفع اختبارًا من 71 إلى 91 وخفّض وقت الحظر من 160 مللي ثانية إلى صفر.
• تسريع الموقع عملية مستمرة: أعد الاختبار بعد كل إضافة أو تعديل.