لماذا موقعي بطيء؟ الأسباب والحلول

قِس المشكلة الحقيقية أولًا

لا يمكنك إصلاح ما لم تقِسه، و"يبدو بطيئًا" ليس تشخيصًا. افتح PageSpeed Insights (pagespeed.web.dev)، وأدخِل رابطك، واقرأ أمرين: مقاييس Core Web Vitals ومقاييس المختبر. ركّز على تبويب الجوال، لأن معظم الزوّار على الهواتف. ثم قِس TTFB (زمن أول بايت) — كم يستغرق خادمك لإرسال أول بايت — لأنه يفصل مشكلة الخادم عن مشكلة التوصيل.

الأهداف السليمة هي LCP أقلّ من 2.5 ثانية، وINP أقلّ من 200 مللي ثانية، وCLS أقلّ من 0.1، وTTFB أقلّ من نحو 200 مللي ثانية. فإن كان TTFB مرتفعًا، فالاختناق في جهة الخادم: الاستضافة أو PHP أو قاعدة البيانات. وإن كان TTFB جيدًا بينما LCP مرتفع، فالاختناق في الصفحة نفسها — غالبًا الصور الكبيرة ومدى بُعد المسافة التي تقطعها إلى الزائر. هذا القياس الواحد يخبرك بأيّ الحلول أدناه تبدأ.

الأسباب الحقيقية لبطء الموقع

تتشارك معظم المواقع البطيئة حفنة من الأسباب. فالخادم البطيء أو الاستضافة المشتركة المزدحمة يرفعان TTFB قبل تحميل صورة واحدة. ثم تأتي الصفحات الثقيلة — الصور المفرطة الحجم (عادةً أكبر شيء في الصفحة)، والقوالب المتضخّمة، ومنشئو الصفحات الذين يشحنون عشرات من أوراق الأنماط والنصوص البرمجية. وكثرة النصوص البرمجية من أطراف ثالثة (أدوات الدردشة، وخرائط الحرارة، وأدوات التتبّع، والخطوط الإضافية) تضيف كلٌّ منها طلبًا وتعرقل العرض.

ويؤخّر CSS وJavaScript المعرقِلان للعرض أوّلَ رسم حتى لو كان الخادم سريعًا. والمسافة مهمّة: فخادم واحد بعيد عن كثير من زوّارك يضيف زمن استجابة لكل شيء، وقد تُغرِقه موجة ذروة. وكل موقع بطيء تقريبًا مزيج من هذه — عمل الخادم المتكرّر، والأصول الثقيلة، والنصوص المعرقِلة، والبُعد المادي.

فهم Core Web Vitals

يعتمد Google في الترتيب جزئيًا على Core Web Vitals، فمن المفيد معرفة ما يقيسه كلٌّ منها. فـ LCP (أكبر عنصر محتوى مرئي) هو المدة التي يستغرقها ظهور المحتوى الرئيسي — غالبًا الصورة الرئيسية؛ وتضرّه أكثر ما تضرّه الخوادم البطيئة والصور الثقيلة البعيدة. وINP (زمن الاستجابة للتفاعل التالي) هو مدى سرعة استجابة الصفحة حين ينقر الزائر أو يضغط؛ ويضرّه JavaScript الثقيل الذي يعرقل الخيط الرئيسي.

وCLS (الإزاحة التراكمية للتخطيط) هو مقدار تنقّل التخطيط أثناء التحميل؛ وتضرّه الصور والإعلانات بلا مساحة محجوزة، والخطوط التي تُحمّل متأخّرة. وإصلاح الأسباب أعلاه — توصيل أسرع، وصور أخفّ، وJavaScript أقلّ، ومساحة محجوزة للوسائط — هو بالضبط ما يحسّن هذه الأرقام الثلاثة.

الحلول التي تحرّك الأرقام

اعمل بترتيب الأثر. التخزين المؤقت: قدّم صفحة جاهزة بدلًا من إعادة بنائها في كل زيارة — وهو المكسب الأوحد الأكبر لـ TTFB وحمل الخادم. الصور: عدّل أحجامها إلى الحجم الذي تُعرض به وقدّم صيغًا حديثة (WebP/AVIF)، فهي عادةً تهيمن على وزن الصفحة. النصوص البرمجية: احذف نصوص الأطراف الثالثة التي لا تحتاجها وأجّل الباقي لتتوقّف عن عرقلة أوّل رسم.

احجز مساحة للصور والإعلانات حتى لا يقفز التخطيط (CLS أفضل)، وحمّل الخطوط دون عرقلة العرض. ثم قصّر المسافة التي يقطعها محتواك بشبكة CDN. يستهدف كل حلٍّ سببًا محدّدًا، وهي معًا تحرّك LCP وINP وCLS دفعةً واحدة.

تحلّ شبكة CDN مشكلة المسافة والذروة

حتى بعد ضبط خادمك وصفحاتك، لا يمكن للخادم الواحد أن يكون إلا في مكان واحد. تنسخ شبكة CDN ملفاتك الثابتة إلى خوادم حافة حول العالم، فيُخدَم كل زائر من أقربها — زمن استجابة أقلّ وLCP أدنى لمن هم بعيدون عن أصلك، إضافةً إلى مرونة عند موجات الذروة لأن الحافة تمتصّ الحمل. ويأتي معها التوصيل الحديث (ضغط Brotli وHTTP/2) وSSL تلقائي وWAF وحماية DDoS.

يفعل cdn.com.tr ذلك دون إعادة بناء: وجّه نطاقك عبر الـ CDN فتبدأ الحافة بتخزين أصولك وتوصيلها من موقع قريب من كل زائر. وتظلّ الصفحات الديناميكية تعمل بشكل طبيعي، وتجدّد الشهادات نفسها، وتختفي المسافة التي كانت تضرّ LCP لديك.

أين تهمّ السرعة أكثر