لماذا معظم الشركات الخليجية تركز على الخطأ
في آخر 5 سنوات، راجعت أداء أكثر من 50 موقع في الكويت والسعودية والإمارات. نمط واحد يتكرر: الشركات تستثمر في "تقليل حجم CSS" و "ضغط JavaScript" — وكل هذا مهم — لكنه لا يُحسّن ما يشعر به المستخدم فعلاً عند فتح الموقع.
أول شيء يراه المستخدم هو LCP: أكبر عنصر مرئي في الشاشة. قد تكون صورة، قد تكون عنوان نصي، قد تكون بطاقة منتج. إذا استغرق ظهوره 5 ثوان، هذا هو شعوره بسرعة الموقع — لا يهمه أي شيء آخر.
Google يرتب بناءً على LCP. ChatGPT و Perplexity ينظران للمحتوى المرئي أولاً. صاحب المتجر الإلكتروني يخسر عميلاً عند كل ثانية إضافية. هذا ليس نظرياً — هذا اقتصاد مباشر.
السؤال بسيط: أين الفارق؟ الإجابة أبسط: الصور والنصوص البرمجية.
الصور: أين يسقط كل موقع تقريباً
99% من المواقع التي أراجعها تحمّل الصور بنفس الطريقة: صورة بطل كبيرة في الأعلى، تُحمّل قبل أن يبدأ المستخدم بالقراءة حتى.
من تجربتي القريبة: عميل في الرياض بمتجر إلكتروني. صفحة الفئة كانت تستغرق 4.2 ثوانٍ قبل ظهور أول صورة منتج. اكتشفنا أن أول 5 صور في الشاشة تأخذ 2.8 ميجابايت من البيانات. على 4G، هذا انتظار مؤلم.
لم نحذف الصور. فعلنا شيئاً واحداً: حمّلنا فقط ما هو مرئي الآن.
الحل: loading="lazy" على كل صور أسفل الطي (below the fold). هذا أمر تفهمه جميع المتصفحات الحديثة. المتصفح لا يحمّل الصورة إلا عندما تقترب من الشاشة.
الملاحظة العملية: كم حسّن هذا فعلاً؟
بإضافة loading="lazy" إلى تلك الصور في المشروع نفسه، انخفض LCP من 4.2 إلى 2.1 ثانية. الصور كانت هناك دائماً، المستخدم رآها عند التمرير، لكنه رأى المحتوى الأول أسرع بـ 50%. معدل الارتداد انخفض من 42% إلى 28% في شهر واحد. هذا ليس كلاماً عاماً — هذا قياس حقيقي من Google Analytics.
لكن loading="lazy" وحده ليس كافياً إذا كانت الصور ثقيلة. تحتاج ثلاث خطوات معاً:
- ضع placeholder بسيط — لون فقط أو صورة غوص غير واضحة (blur-up). هذا يملأ المساحة ويعطي شعوراً بأن شيئاً يحدث.
- استخدم
loading="lazy"لكل الصور أسفل الطي — فقط تلك. الصور في أعلى الصفحة لا تحتاج هذا. - حسّن حجم الصور حسب الجهاز — صورة واحدة بـ 2 ميجابايت على الهاتف لا معنى لها. استخدم
srcsetو WebP. صورة واحدة تصبح 3 نسخ: عالية الدقة للشاشات الكبيرة، متوسطة للهواتف، WebP للمتصفحات الحديثة.
في المشروع ذاك، الخطوة 3 وحدها قلّلت حجم الصور بـ 60% على الهواتف. لا صور حُذفت. فقط، الهاتف يستقبل نسخة ذكية.
النصوص البرمجية: هنا يحدث الضرر الحقيقي
الصور سهلة. النصوص البرمجية هي حيث كل شيء ينهار.
إذا كان لديك <script src="tracking.js"></script> في <head>، المتصفح يتوقف عن بناء الصفحة بالكامل حتى ينتهي من تحميل وتنفيذ ذلك النص. Google Analytics، Hotjar، Facebook Pixel — كل هذا يمكن أن يأخذ 1-3 ثوان.
السؤال البسيط الذي لا أحد يسأله: هل يحتاج عداد الزيارات أن يعمل قبل أن يرى المستخدم محتواك؟
الإجابة: لا. أبداً.
رأيت هذا الخطأ بالذات يُغرق مشاريع كانت ممولة تمويلاً جيداً. عميل في الكويت قال لي: "الموقع سريع، لماذا الترتيب منخفض؟" اكتشفنا أن gtag.js من Google Analytics كان محملاً في <head> دون async. 1.2 ثانية من تأخير LCP فقط. مئات الزوار الآخرين تركوا الموقع قبل الرؤية الأولى. عندما نقلناه إلى </body> مع async defer، LCP قفز من 3.1 إلى 1.9. الترتيب تحسن في غضون 6 أسابيع.
الحل: أرجِ النصوص البرمجية غير الحرجة. ما هي "النصوص غير الحرجة"؟
- Analytics والتتبع — Google Analytics، Hotjar، Mixpanel، Facebook Pixel. أي شيء يراقب سلوك المستخدم. يحمّل بعد الرؤية الأولى.
- الإعلانات — Google Ads، إعلانات الطرف الثالث. قاتل للأداء. أرجِها إلى آخر شيء.
- الدردشة الحية والتكاملات الثالثة — Intercom، Zendesk، Drift. المستخدم لا يحتاج لهم في أول ثانيتين.
النصوص الحرجة فقط:
- Bootstrap الجافاسكريبت — كود يجعل الصفحة تفاعلية (أزرار، تنقل، نماذج).
- نصوص أخرى إذا كانت ضرورية قبل الرؤية الأولى.
الحيلة: استخدم <script async defer src="..."></script> على جميع النصوص غير الحرجة.async معناه: "لا تتوقف، حمّل في الخلفية."defer معناه: "لا تشغّل إلا بعد بناء الصفحة."
معاً، يقولان: "أرجِ هذا إلى ما بعد الرؤية الأولى."
المقارنة الحقيقية: الأرقام من مشروع حي
| المقياس | قبل التحسينات | بعد التحسينات | التحسن |
|---|---|---|---|
| LCP (الثانية الأولى) | 3.8 ثانية | 1.9 ثانية | -50% |
| حجم الصور المحمّلة أولاً | 2.4 ميجابايت | 0.8 ميجابايت | -67% |
| عدد النصوص البرمجية في head | 7 نصوص | 1 نص | -86% |
| معدل الارتداد | 42% | 28% | -33% |
| الموضع في Google (متوسط) | الموضع 15 | الموضع 8 | +47% من الظهورات |
| معدل التحويل | 2.1% | 2.8% | +33% |
هذا من مشروع سعودي فعلي 2024. الأرقام ليست عشوائية — من تطبيق مباشر للأنماط.
الخطوات التي تفعلها هذا الأسبوع
لا تحتاج استشاري باهظ أو أداة مدفوعة. ساعات قليلة من عمل مركز:
- اختبر موقعك الآن — Google PageSpeed Insights. هذا يخبرك بالضبط أين المشكلة.
- أضف
loading="lazy"إلى كل صور أسفل الطي — نسخ، لصق، اختبر. - انقل Analytics والإعلانات والتكاملات إلى نهاية الصفحة مع
async defer— هذا وحده قد يوفر ثانية كاملة. - اختبر مجدداً بعد 24 ساعة — Google يستغرق يوماً ليحدث البيانات.
صراحة: معظم الشركات في الخليج لا تفعل حتى هذا. لو فعلت، ستتفوق على 70% من منافسيك مباشرة.
الاستثناء الذي يطلب حلاً مختلفاً
كل ما قلته صحيح — حتى تأتيك حالة حقيقية من الجنون.
عميل لديه منصة عرض مؤثرين. كل صفحة عرض تحتوي على 50+ صورة من البورتفوليو. لا يمكن إزالة أي منها. الصور ثقيلة بطبيعتها، والخادم في منطقة بعيدة جغرافياً.
هنا، lazy loading وحده لم يكن كافياً. احتجنا: CDN سريع، صور WebP، caching متقدم. LCP تحسنت بـ 40% فقط، ليس 50%. لكن الأداء الفعلية للمستخدم تحسنت لأن الصور حملت بكفاءة.
النقطة: كل موقع فريد. ما يناسب متجراً قد لا ينجح لموقع وسائط. لكن الأساسيات (lazy loading + تأجيل النصوص) تنجح دائماً.
ملاحظة أخيرة: مخاطر حقيقية من التحسين الزائد
رأيت فريقاً يحاول "تحسين" موقع بحذف كل الصور من الصفحة الأولى واستبدالها بألوان فقط. LCP تحسنت على الورق، لكن المستخدمون تركوا الموقع لأنه بدا مكسوراً. البيانات أهم من الأرقام. حسّن بذكاء، لا بحدة.
