كل موقع بطيء يتلقّى التشخيص نفسه من صاحبه: «لا بدّ أن الاستضافة سيئة». وهذا صحيح أحياناً. لكن الاستضافة في الغالب سليمة، والموقع يحمل أربعمئة كيلوبايت من جافاسكربت لا يُستعمل، وصورةَ صفحة رئيسية مُصدَّرة من الكاميرا كما هي، وأحد عشر سكربت تسويق ينتظر كلٌّ منها انتهاء الآخر.
والسرعة تهمّ تجارياً — الزوّار يغادرون المواقع البطيئة، وجوجل يستعمل تجربة الصفحة مدخلاً في الترتيب — لكن النصائح على الإنترنت خليط من مقاييس غير مشروحة وترشيحات إضافات. وهذا الدليل هو النسخة العملية: كيف تعرف ما هو البطيء في موقعك فعلاً، وبأي ترتيب تصلحه، وكيف تميّز هل الاستضافة هي المشكلة حقاً أم أنها التفسير المريح.
الخلاصة السريعة
أغلب مواقع الأعمال بطيئة لأربعة أسباب، بهذا الترتيب من حيث التكرار: صور ضخمة، وسكربتات طرف ثالث كثيرة، وقالب متضخّم أو إضافات كثيرة، واستجابة خادم بطيئة. والأخير وحده هو الاستضافة. قِس أولاً بأداة حقيقية، وأصلح الصور والسكربتات قبل أن تمسّ أي شيء آخر، وعامل «اشترِ خادماً أكبر» بوصفه الخطوة الأخيرة لا الأولى. وأهمّ قياس هو Largest Contentful Paint — كم يستغرق ظهور المحتوى الرئيسي — والهدف دون 2.5 ثانية.
قِس قبل أن تغيّر أي شيء
«يبدو بطيئاً» ليس تشخيصاً، وانطباعك الشخصي أضعف الأدلّة المتاحة: متصفّحك يخزّن الموقع مؤقّتاً، وأنت على الأرجح قريب من الخادم.
استعمل PageSpeed Insights (أداة جوجل المجانية) على أهمّ صفحاتك — الرئيسية، وصفحة خدمتك الأساسية، ومقال من المدوّنة. تعطيك أمرين، والفرق بينهما مهمّ:
بيانات المختبر تحميل محاكى على اتصال مقيَّد. مفيدة في التشخيص لأنها تعدّد مشكلات محدَّدة.
بيانات الميدان ما اختبره الزوّار الحقيقيون خلال الشهر الماضي. وهذه هي التي يستعملها جوجل. وإن كانت زيارات الموقع قليلة جداً فسيكون هذا القسم فارغاً — وهذا طبيعي لا خطأ.
وثلاثة أرقام تستحقّ المعرفة:
Largest Contentful Paint (LCP) — متى يصير المحتوى الرئيسي مرئياً. والجيّد دون 2.5 ثانية. وهذا ما تركّز عليه.
Interaction to Next Paint (INP) — كم تستجيب الصفحة بسرعة حين ينقر أحدهم أو يلمس. والجيّد دون 200 مللي ثانية. والسيّئ منه يعني دائماً تقريباً جافاسكربت أكثر من اللازم.
Cumulative Layout Shift (CLS) — كم تقفز الصفحة أثناء التحميل. والجيّد دون 0.1. وسببه عادةً صور بلا أبعاد محدَّدة، أو إعلانات ولافتات تُدرَج بعد التحميل.
واختبر على الجوّال لا سطح المكتب. فأغلب زوّارك على الهواتف، وتقييم جوجل يرجّح الجوّال.
الأسباب الأربعة الحقيقية
١. الصور — أكبر سبب منفرد، وأسهلها إصلاحاً
أشيع ما نجده على موقع أعمال لافتةُ صفحة رئيسية عرضها 4000 بكسل وحجمها ثلاثة ميغابايت، تُعرَض في حيّز عرضه 1200 بكسل. فيُنزّل المتصفّح الميغابايتات الثلاثة كاملةً ثم يرمي أغلبها.
ما تفعله: غيّر أبعاد الصور إلى الحجم الذي تُعرَض به فعلاً، واحفظها بصيغة WebP بدل JPEG أو PNG، وفعّل التحميل الكسول لتُحمَّل الصور أسفل الشاشة عند التمرير إليها فقط. وووردبريس الحديث يفعّل التحميل الكسول افتراضياً؛ أما تغيير الأبعاد وتحويل الصيغة فهو ما يتخطّاه الناس.
والهدف الواقعي للافتة بعرض الشاشة دون 200 كيلوبايت. وأغلب المواقع التي نفحصها فيها عدّة صور تتجاوز الميغابايت، وإصلاح ذلك وحده كثيراً ما ينصّف زمن التحميل.
٢. سكربتات الطرف الثالث — السبب الذي لا يحبّ أحد سماعه
تحليلات، وودجات محادثة، وخرائط حرارية، وبكسلات إعلانية، وودجات تقييمات، ومحمّلات خطوط، وتضمينات حجز. كلٌّ منها طلبٌ إلى خادم شخص آخر، وصفحتك تنتظر خوادم لا سيطرة لك عليها.
والنمط الذي نراه مراراً: أداة تسويق جُرِّبت قبل سنتين، ولم تُزَل قطّ، وما زالت تُحمَّل في كل عرض صفحة لكل زائر. افتح مصدر صفحتك أو لوحة الشبكة واسرد كل نطاق خارجي تتصل به. ثم برّر كلّاً منها. وما لا تستطيع تبريره احذفه.
ومشكلة متّصلة يُستهان بها: الخطوط. فثلاث عائلات خطوط مخصّصة بستّة أوزان كلفة أداء حقيقية. ووزنان من عائلة واحدة يكفيان دائماً تقريباً.
٣. تضخّم القالب والإضافات
القوالب متعدّدة الأغراض تشحن شيفرة كل تخطيط تستطيع إنتاجه، ومنشئات الصفحات تضيف شيفرتها. وكل إضافة مفعَّلة قد تضيف CSS وجافاسكربت إلى كل صفحة، بما فيها الصفحات التي لا تستعملها — كإضافة نموذج تواصل تحمّل ملفاتها في مدوّنتك مثلاً.
ما تفعله: عطّل واحذف الإضافات التي لا تستعملها — والحذف مهمّ، لأن المعطَّلة تبقى على القرص وتبقى انكشافاً أمنياً. أما ما تُبقيه فإضافة أداء جيّدة تستطيع حصر ملفات كل إضافة في الصفحات التي تحتاجها فعلاً. وهذا التغيير وحده كثيراً ما يفوق أي إعداد تخزين مؤقّت قيمةً.
وكن صريحاً بشأن القالب: إن كان قالباً متعدّد الأغراض عمره عشر سنوات ومعه عشرون عارض شرائح، فلن يجعله أي تحسين سريعاً، واستبداله هو الإصلاح الحقيقي.
٤. استجابة الخادم — حيث تهمّ الاستضافة فعلاً
هذا هو الجزء الذي يخصّ الاستضافة حقاً، وله قياس محدَّد: Time To First Byte — كم يستغرق الخادم ليبدأ الاستجابة. ودون 200 مللي ثانية جيّد، وفوق 600 مللي ثانية مشكلة.
ولارتفاعه أسباب شائعة: استضافة مشتركة مُباعة بإفراط فيقف موقعك في طابور خلف مواقع أخرى على الجهاز نفسه؛ ونسخة PHP قديمة، إذ كان كل إصدار رئيسي أسرع من سابقه بفارق معتبر؛ وقاعدة بيانات لم تُصَن قطّ؛ وغياب التخزين المؤقّت على الخادم فيُعاد بناء الصفحة كاملةً لكل زائر؛ وخادم في قارّة غير قارّة جمهورك.
والأخير مباشر ويُغفَل كثيراً: إن كان عملاؤك في الإمارات وخادمك في الولايات المتحدة، فكل طلب يعبر محيطاً مرّتين. وخادم في المنطقة — أو شبكة توصيل محتوى أمامه — يزيل تأخيراً لا يبلغه أي تحسين في الشيفرة.
التخزين المؤقّت: أعلى عائد بأقلّ جهد
بلا تخزين مؤقّت، يدفع كل زائر خادمَك إلى تشغيل PHP والاستعلام من قاعدة البيانات وتجميع الصفحة من الصفر — لصفحة لم تتغيّر منذ شهر.
التخزين المؤقّت للصفحات يحفظ الصفحة الجاهزة ويقدّمها مباشرةً. وعلى موقع أعمال ووردبريس نموذجي هذا أكبر تحسين متاح منفرداً، وهو غالباً مسألة تفعيل لا بناء.
التخزين المؤقّت للكائنات يحفظ نتائج استعلامات قاعدة البيانات، ويهمّ أكثر في المواقع الديناميكية: المتاجر والعضويات وكل ما يتطلّب تسجيل دخول.
التخزين المؤقّت في المتصفّح يخبر الزوّار العائدين بإعادة استعمال الملفات التي نزّلوها سلفاً.
شبكة توصيل المحتوى تقدّم ملفاتك الثابتة من موقع قريب من كل زائر.
وتحذيران عمليّان: لا تثبّت أكثر من إضافة تخزين مؤقّت واحدة، فهي تتعارض وأعراضها غريبة. وتذكّر أن الكاش سيُريك بكل سرور صفحةً قديمة بعد إصلاحك لشيء ما — فأفرغه قبل أن تستنتج أن إصلاحك لم ينجح. هذا الالتباس تحديداً كلّفنا ساعات، وسيكلّفك بعضها.
ترتيب الإصلاح
العمل بهذا الترتيب يعطي أكبر تحسّن بأقلّ مخاطرة:
١. قِس بـPageSpeed Insights على الجوّال، وسجّل قيمة LCP الحالية.
٢. أصلح الصور. غيّر الأبعاد، وحوّل إلى WebP، وتأكّد من تفعيل التحميل الكسول.
٣. احذف ما لا تستعمله. إضافات غير مستعمَلة تُحذَف، وسكربتات طرف ثالث غير مستعمَلة تُزال، وخطوط غير مستعمَلة تُسقَط.
٤. فعّل التخزين المؤقّت — حلٌّ واحد، وتخزين للصفحات وللمتصفّح على الأقل.
٥. افحص نسخة PHP. فما دون 8.1 هدرٌ لسرعة مجانية، وما دون 8.0 مشكلة أمنية إلى جانب كونه مشكلة أداء.
٦. قِس ثانيةً. وقارن بالخطوة الأولى.
٧. الآن فقط انظر في الخادم. فإن بقي TTFB مرتفعاً بعد كل ما سبق، فالاستضافة قيدُك فعلاً.
وأغلب المواقع تصير أسرع بوضوح عند الخطوة الرابعة، ولهذا فإن البدء من السابعة إنفاقٌ في غير موضعه.
كم من السرعة يكفي؟
النتائج الكاملة مشروع تباهٍ. وموقع أعمال يُظهر محتواه الرئيسي في أقلّ من 2.5 ثانية على اتصال جوّال يبلي حسناً، والفارق بين 2.5 ثانية و1.5 ثانية أقلّ أهمية بكثير من الفارق بين 6 ثوانٍ و3.
وأمران يستحقّان انتباهاً أكثر من الدرجة: الثبات — فموقع سريع في الثالثة فجراً وبطيء في الحادية عشرة صباحاً لديه مشكلة سعة لا يكشفها اختبار واحد — والصفحات التي تهمّ فعلاً. فتحسين الصفحة الرئيسية بينما تبقى صفحة خدمتك الأساسية بطيئة تحسينٌ للشيء الخطأ، لأن القرار لا يُتَّخذ هناك.
أين موقعنا
تستضيف «بيغ بانغ لحلول تقنية المعلومات» مواقع الأعمال وتصونها في أنحاء الإمارات، على بنية تحتية في المنطقة، مع PHP حديثة وتخزين مؤقّت على مستوى الخادم ومراقبة — مشمولةً لا مُباعةً ترقيةً. وحين يكون موقع عميل بطيئاً، فخطوتنا الأولى تحديد هل السبب الشيفرة أم الخادم — لأن قول «اشترِ باقة أكبر» لصاحب لافتة رئيسية حجمها ثلاثة ميغابايت ليس نصيحة، بل بيعاً.
فإن كان موقعك يبدو بطيئاً وأردت أن تعرف أيّاً من الأسباب الأربعة هو سببه فعلاً، أرسل لنا الرابط ونقيسه ونخبرك بصراحة.
