لماذا موقعي بطيء؟ كيف تعثر على السبب وتعالجه

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

قِس قبل أن تغيّر أي شيء

لبيانات السرعة نوعان، وكلٌّ منهما يجيب عن سؤال مختلف:

• البيانات الميدانية تأتي من زوّار حقيقيين على أجهزتهم واتصالاتهم. يجمعها تقرير Chrome UX Report من Google للمواقع التي لديها زيارات كافية، ويمكنك الاطّلاع عليها في PageSpeed Insights وفي تقرير «مؤشرات أداء الويب الأساسية» في Google Search Console. وهي تخبرك بما يعيشه الناس فعلًا.
• البيانات المختبرية تأتي من تحميل الصفحة مرة واحدة في ظروف مضبوطة، كما يفعل Lighthouse. وهي أقل تمثيلًا للواقع، لكنها قابلة للتكرار وتفسّر سبب بطء الصفحة.

تصف مؤشرات أداء الويب الأساسية (Core Web Vitals) من Google التجربة الجيدة بأنها Largest Contentful Paint (LCP) بمقدار 2.5 ثانية أو أقل، وInteraction to Next Paint (INP) بمقدار 200 مللي ثانية أو أقل، وCumulative Layout Shift (CLS) بمقدار 0.1 أو أقل، مَقيسةً عند المئين 75 من الزيارات الحقيقية.

للتشخيص، أجرِ اختبارًا مختبريًا. يحمّل فاحص سرعة الموقع المجاني من Rudra صفحتك عبر Lighthouse ويعرض First Contentful Paint و LCP و Total Blocking Time و CLS و Speed Index و Time to Interactive، إضافةً إلى فحوص Lighthouse التي لم تنجح، بدءًا بالأسوأ. ولا تنسَ حدوده: فهو تحميل واحد من خادمنا في ظروف المحاكاة التي يعتمدها Lighthouse، ولذلك لن تطابق الأرقام بياناتك الميدانية تمامًا، وهو لا يستطيع قياس INP لأنه يحتاج إلى تفاعلات حقيقية. و Total Blocking Time هو الإشارة المختبرية الأوثق صلةً بسرعة الاستجابة.

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

أكثر الأسباب شيوعًا وكيف تعالجها

1. استجابة بطيئة من الخادم

لا شيء آخر يمكن أن يبدأ قبل أن يرسل الخادم شيفرة HTML. فإذا كان Time to First Byte مرتفعًا، فالسبب في العادة استضافة رخيصة أو مثقلة بالأحمال، أو صفحات تُبنى من الصفر عند كل طلب، أو استعلامات بطيئة لقاعدة البيانات، أو زوّار بعيدون عن الخادم. الحلول: فعّل التخزين المؤقت للصفحات (في معظم أنظمة إدارة المحتوى إضافة أو إعداد لذلك)، وضع شبكة CDN أمام الموقع، وأزل الإضافات التي لا تحتاج إليها، ورقِّ الاستضافة إن كان الخادم ضعيفًا ببساطة. وتعدّ إرشادات Google قيمة TTFB البالغة 0.8 ثانية أو أقل جيدة. وفي عمليات الزحف إلى الموقع كاملًا، ينبّه Rudra إلى الصفحات التي تأخر خادمها أكثر من 1.5 ثانية في الاستجابة، ويعدّ ما زاد على 3 ثوانٍ حرجًا.

2. صور أكبر من اللازم

الصورة المصدَّرة مباشرةً من كاميرا أو هاتف قد يبلغ حجمها عدة ميغابايتات وعرضها آلاف البكسلات، ثم تُعرض بعرض 800 بكسل. غيّر مقاسها، واضغطها، واستخدم الصيغ الحديثة. ودليلنا عن كيف تقلّل حجم الصور يشرح ذلك خطوة بخطوة.

3. JavaScript أكثر من اللازم

الحزم الكبيرة ووسوم الأطراف الخارجية (التحليلات، وأدوات المحادثة، واختبارات A/B، وسكربتات الإعلانات) تتزاحم على الخيط الرئيسي في المتصفح. وما دام سكربت طويل يعمل، لا تستطيع الصفحة الاستجابة للّمسات، فيظهر ذلك على هيئة Total Blocking Time مرتفع في المختبر و INP ضعيف في الميدان. راجع كل وسم خارجي وأزل ما لا يستخدمه أحد، وحمّل الأدوات غير الأساسية بعد أن تصبح الصفحة تفاعلية أو حين يطلبها الزائر، وقسّم الحزم الكبيرة لتحمّل كل صفحة ما تحتاج إليه فقط.

4. ملفات CSS وسكربتات تعيق العرض

السكربتات الموضوعة في <head> بلا async أو defer، وكل ورقة أنماط، يجب أن تُحمَّل قبل أن يتمكن المتصفح من رسم أي شيء. أضف defer إلى السكربتات التي لا يلزم تشغيلها فورًا، مثل <script src="/app.js" defer></script>، وادمج أوراق الأنماط غير الضرورية أو أزلها، وفكّر في تضمين القدر القليل من CSS اللازم لأعلى الصفحة داخل الصفحة نفسها.

5. غياب الضغط

الملفات النصية (HTML و CSS و JavaScript و JSON و SVG) يتقلص حجمها كثيرًا بضغط gzip أو Brotli. ابحث في ترويسات استجابة صفحتك، في تبويب Network بالمتصفح، عن content-encoding: br أو gzip. فإن لم تجدها ففعّل الضغط على الخادم (في nginx: gzip on; مع قائمة gzip_types) أو في شبكة CDN لديك.

6. ملفات ثابتة غير مخزَّنة مؤقتًا

لا ينبغي للزوّار العائدين أن ينزّلوا شعارك وورقة أنماطك من جديد. للملفات التي يتغيّر اسمها بتغيّر محتواها (معظم أدوات البناء تضيف بصمة hash، مثل app.3f9a2c.js)، أرسل Cache-Control: public, max-age=31536000, immutable. وأبقِ HTML على تخزين مؤقت قصير أو على إعادة التحقق لتظهر التحديثات سريعًا.

7. خطوط ويب ثقيلة

عدة عائلات من الخطوط، كلٌّ منها بأوزان كثيرة، يتراكم حجمها سريعًا، وقد يبقى النص غير مرئي ريثما تُنزَّل الخطوط. استخدم أوزانًا أقل، وقدّم الخطوط بصيغة WOFF2، واقتصر فيها على المحارف التي تحتاج إليها، وأضف font-display: swap ليظهر النص فورًا بخط احتياطي، وحمّل مسبقًا الخط الوحيد المستخدم في الجزء الظاهر من الصفحة دون غيره. أما مجموعة خطوط النظام فتغنيك عن التنزيل كليًّا.

8. إزاحة التخطيط

الصفحات التي تتقافز عناصرها سببها في العادة صور ومحتويات مضمَّنة لم تُحجز لها مساحة، أو إعلانات تُحقن وسط المحتوى، أو شرائط تظهر فوق النص بعد التحميل. أعطِ كل صورة خاصيتَي width و height (أو aspect-ratio في CSS)، واحجز مساحة للإعلانات والمحتويات المضمَّنة عبر min-height، واعرض شرائط ملفات تعريف الارتباط والعروض الترويجية طبقةً فوق الصفحة بدلًا من أن تدفع المحتوى إلى الأسفل.

9. صفحات متضخمة وطلبات كثيرة

مستندات HTML الكبيرة جدًا (بسبب بيانات مضمَّنة أو شبكات منتجات لا تنتهي في الغالب)، وعشرات السكربتات، والسكربت نفسه مضمَّنًا مرتين: كلها تبطّئ الصفحة. قسّم القوائم الطويلة إلى صفحات، وانقل البيانات المضمَّنة الكبيرة إلى ملفات مستقلة مخزَّنة مؤقتًا، وأزل الوسوم المكرَّرة. وينبّه زحف Rudra إلى مستندات HTML التي تتجاوز 1 ميغابايت، والصفحات التي تستدعي أكثر من 100 مورد، والسكربتات المحمَّلة أكثر من مرة.

10. عمليات إعادة توجيه قبل أن تبدأ الصفحة أصلًا

الزائر الذي يكتب example.com فيُعاد توجيهه إلى https://example.com، ثم إلى https://www.example.com، ثم إلى /home، ينتظر عند كل قفزة. أعِد التوجيه إلى عنوان URL النهائي مباشرةً في خطوة واحدة، واستخدم العناوين النهائية في روابطك كلها.

ما الذي تصلحه أولًا

1. إذا كانت استجابة الخادم بطيئة فابدأ منها. فكل المقاييس الأخرى تنتظرها.
2. إذا كان LCP ضعيفًا فاعثر على عنصر LCP. يسمّيه لك Lighthouse. وهو في العادة صورة رئيسية (اضغطها، ولا تؤجّل تحميلها، وفكّر في fetchpriority="high") أو عنوان تؤخّره الخطوط أو ملفات CSS المعيقة للعرض.
3. إذا كان Total Blocking Time أو INP ضعيفًا فانظر في JavaScript، وخصوصًا وسوم الأطراف الخارجية.
4. إذا كان CLS ضعيفًا فاحجز مساحة للصور والمحتويات المضمَّنة والإعلانات والشرائط.
5. أعد الاختبار بعد كل تغيير، لتعرف ما الذي أفاد فعلًا.

ما الذي لا يخبرك به اختبار السرعة

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

أخطاء شائعة

• ملاحقة درجة مثالية في Lighthouse بدلًا من المقاييس التي يشعر بها زوّارك.
• الاختبار على سطح المكتب فقط وعبر شبكة Wi-Fi سريعة في المكتب.
• تأجيل تحميل الصورة الرئيسية (lazy loading)، وهو ما يؤخّر LCP.
• تثبيت عدة إضافات «للسرعة» أو للتخزين المؤقت يتعارض بعضها مع بعض.
• الحكم على تغيير من تشغيل واحد للاختبار؛ فالنتائج تتفاوت من تشغيل إلى آخر.