دليل عملي لقياس سرعة موقعك بأدوات مجانية، وفهم أرقام LCP وINP وCLS، ومعرفة أي الأسباب الخمسة الشائعة يخنق موقعك بالتحديد.
"الموقع بطيء" شكوى لا يمكن تنفيذها. الجملة القابلة للتنفيذ تشبه: "أكبر عنصر في الصفحة الأولى يستغرق 4.8 ثانية للظهور على شبكة 4G، والسبب صورة بحجم 1.9 ميجابايت". هذا المقال ينقلك من الشكوى إلى الجملة الثانية، بأدوات مجانية ودون خبرة برمجية.
لماذا يهم هذا مالياً؟
البطء لا يزعج الزائر فقط، بل يخصم من نتيجتين معاً: نسبة من الزوار تغادر قبل أن ترى شيئاً، وجوجل يستخدم مؤشرات تجربة الصفحة ضمن إشارات الترتيب. أنت تدفع في الإعلانات ثمن زيارة ثم تخسرها في الثانية الثالثة.
والأثر أشد لدى الجمهور العربي لسببين: نسبة استخدام الهاتف مرتفعة جداً، وجودة الشبكة تتفاوت بشدة بين المدن. الموقع الذي يبدو سريعاً على واي فاي مكتبك قد يكون كارثة على شبكة بيانات في مكان آخر.
الخطوة الأولى: اقرأ الأرقام الثلاثة
جوجل تلخّص التجربة في ثلاثة مؤشرات:
LCP — سرعة ظهور أكبر عنصر. متى يرى الزائر الشيء الرئيسي (صورة الهيرو أو العنوان)؟ المستهدف أقل من 2.5 ثانية. فوق 4 ثوانٍ يعني مشكلة حقيقية.
INP — استجابة التفاعل. حين يضغط الزائر زراً، متى يستجيب الموقع فعلاً؟ المستهدف أقل من 200 ملي ثانية. الأرقام السيئة هنا سببها غالباً جافاسكربت ثقيلة تعمل في الخلفية.
CLS — استقرار التخطيط. هل يقفز المحتوى وأنت تقرأ فيجعلك تضغط الشيء الخطأ؟ المستهدف أقل من 0.1، والسبب الأشهر صور بلا أبعاد محددة وخطوط تُحمَّل متأخرة.
الخطوة الثانية: القياس بثلاث أدوات مجانية
PageSpeed Insights. ادخل رابط موقعك. المهم ليس الرقم الملون بل قسمان: بيانات المستخدمين الحقيقيين في الأعلى إن توفرت (هذه هي الحقيقة)، وقائمة الفرص في الأسفل مرتبة بأثرها. ابدأ دائماً من تبويب الموبايل لا سطح المكتب.
WebPageTest. يتيح اختيار موقع جغرافي وسرعة اتصال. اختر أقرب موقع لجمهورك وشبكة 4G. أهم ما فيه المخطط الشلالي: صف من الأشرطة يمثل كل ملف يُحمَّل. الشريط الطويل جداً هو مشكلتك، والصفوف المتراصة بلا فراغ تعني عدداً هائلاً من الطلبات.
أدوات المتصفح. افتح تبويب Network، فعّل التحكم بالسرعة (Fast 4G)، امسح الكاش وأعد التحميل. انظر إلى إجمالي حجم الصفحة أسفل النافذة. أي رقم فوق 2 ميجابايت لصفحة تعريفية يعني أنك وجدت المشكلة.
الخطوة الثالثة: الأسباب الخمسة الشائعة
1. الصور. السبب الأول بفارق كبير. صورة كاميرا بحجم 4 ميجابايت تُرفع كما هي وتُصغَّر بالعرض فقط، فيحمّل زائر الموبايل الأربعة ميجابايت كاملة. الحل: تصدير بصيغة WebP أو AVIF، تحديد أبعاد، تحميل كسول لما هو أسفل الشاشة، ونسخ بأحجام مختلفة للشاشات المختلفة. وحدها هذه الخطوة تقلب نتيجة أغلب المواقع.
2. عدد الإضافات. كل إضافة في ووردبريس تضيف ملفات CSS وجافاسكربت على كل صفحة، حتى حيث لا تُستخدم. إضافة سلايدر تُحمَّل في صفحة "من نحن" التي لا سلايدر فيها. افتح قائمة إضافاتك واسأل عن كل واحدة: متى استُخدمت آخر مرة؟
3. الخطوط. ثلاث عائلات خطوط بستة أوزان تعني ملفات كثيرة تحجب الرسم. اكتفِ بعائلة واحدة
وثلاثة أوزان، واستخدم font-display: swap، واستضف الخط محلياً إن أمكن.
4. الاستضافة. إن كان زمن الاستجابة الأول (TTFB) فوق 600 ملي ثانية، فالمشكلة قبل أي تحسين في الصفحة. الاستضافة المشتركة بمئة موقع على الخادم نفسه سبب متكرر جداً.
5. سكربتات الطرف الثالث. بكسل ميتا، وجوجل تاج مانجر، وشات بوت، وأداة استطلاع، وخريطة مدمجة. كل واحدة تبدو صغيرة، ومجموعها يخنق الصفحة. القاعدة: كل سكربت خارجي يجب أن يبرّر وجوده بعائد مقاس.
الخطوة الرابعة: ماذا تصلح أولاً
رتّب على أساس (الأثر ÷ الجهد):
- اضغط الصور وحوّلها إلى WebP — أثر عالٍ، جهد منخفض.
- احذف الإضافات غير المستخدمة — أثر عالٍ، جهد منخفض.
- فعّل الكاش على مستوى الصفحة وشبكة توزيع محتوى — أثر عالٍ، جهد متوسط.
- قلّل الخطوط والسكربتات الخارجية — أثر متوسط، جهد منخفض.
- انتقل إلى استضافة أفضل — أثر عالٍ، جهد متوسط، تكلفة شهرية.
- أعد بناء الواجهة — أثر أعلى، جهد أكبر، وهو الخيار حين تفشل الخطوات السابقة في إيصالك للهدف.
متى يكون الإصلاح غير مجدٍ؟
حين يكون الموقع مبنياً على قالب ضخم مع بانٍ صفحات يولّد كوداً منتفخاً، تصل بعد كل التحسينات إلى تحسن محدود ثم تتوقف. عندها تصير إعادة البناء أرخص من الترقيع المتكرر، والقرار بين المسارين شرحناه في ووردبريس أم تطوير مخصص.
كيف تحافظ على السرعة بعد إصلاحها؟
السرعة ليست مشروعاً ينتهي. ضع ثلاث عادات: قياس شهري بأداة واحدة ثابتة، وقاعدة أن أي إضافة جديدة تُقاس قبل وبعد، وسقف متفق عليه لحجم الصفحة (مثلاً 1 ميجابايت للصفحة التعريفية). الفريق الذي لا يقيس يعود للبطء خلال ستة أشهر.
الخلاصة
قِس قبل أن تصلح، وابدأ من الموبايل، وأصلح الصور أولاً. إن وصلت إلى سقف التحسينات ولم يتحرك الرقم، فالمشكلة معمارية لا تجميلية. نحن نبني المواقع بحيث تكون السرعة قراراً في البنية لا مرحلة تنظيف في النهاية — التفاصيل في خدمة تطوير المواقع، وحين تصير السرعة مقبولة يصبح السيو التقني هو الخطوة التالية المنطقية.
حالة عملية: من 6.2 ثانية إلى 1.8
موقع شركة خدمات على ووردبريس، جاءنا برقم LCP يبلغ 6.2 ثانية على الموبايل. ما وجدناه بالترتيب:
صورة هيرو بحجم 3.4 ميجابايت بصيغة PNG. اثنتان وعشرون إضافة، تسع منها لم تُستخدم منذ عامين. أربع عائلات خطوط بأربعة عشر وزناً. سكربتان لأداتي محادثة (واحدة منسية من تجربة سابقة). استضافة مشتركة بزمن استجابة أول يبلغ 900 ملي ثانية.
ما فعلناه: تحويل الصور إلى WebP بأحجام متعددة، وحذف تسع إضافات، وتقليص الخطوط إلى عائلة واحدة بثلاثة أوزان، وحذف أداة المحادثة المنسية وتأجيل تحميل الثانية، والانتقال إلى استضافة سحابية مع شبكة توزيع.
النتيجة: 1.8 ثانية. لم يُعد بناء الموقع، ولم يتغير التصميم. أغلب المكسب جاء من الصور والإضافات وحدهما — وهما أرخص بندين في القائمة.
ما لا يجب أن تفعله؟
لا تركّب خمس إضافات تسريع معاً. ستتصارع على الوظائف نفسها وتنتج نتيجة أسوأ من غيابها جميعاً. إضافة كاش واحدة مضبوطة تكفي.
لا تطارد الرقم 100. الفرق بين 92 و100 غالباً لا يشعر به أحد، وتكلفته تصاعدية. المستخدم يشعر بالفرق بين 45 و90، لا بين 92 و99.
لا تعتمد على نتيجة سطح المكتب. أغلب زوارك على الموبايل، والقياس يجب أن يعكس ذلك.
لا تحذف مزايا يحتاجها العمل بحجة السرعة. الهدف موازنة لا تقشف.
أسئلة شائعة
كم مرة أقيس؟ مرة شهرياً بأداة ثابتة، وقبل وبعد أي تغيير كبير.
هل شبكة التوزيع (CDN) ضرورية؟ إن كان جمهورك موزعاً جغرافياً أو خادمك بعيد عنهم، نعم وأثرها واضح. لجمهور محلي على خادم قريب، أثرها أقل لكنها لا تضر.
هل الاستضافة الأغلى دائماً أسرع؟ لا. المهم مواصفاتها الفعلية وزمن استجابتها لا سعرها. اطلب رقم TTFB كمعيار قبول.
موقعي سريع عندي وبطيء عند العملاء، لماذا؟ لأن متصفحك يخزّن الملفات مؤقتاً. اختبر دائماً بنافذة خاصة ومع محاكاة شبكة بطيئة.
هل الصور هي المشكلة دائماً؟ ليست دائماً، لكنها الأكثر شيوعاً والأرخص إصلاحاً. ابدأ منها ثم قِس مجدداً قبل الانتقال لغيرها.