لماذا هذه الثلاثة بالذات؟
قبل ثلاث سنوات، كنت أنقض ساعات في محاولة تقليل وقت الخادم (Time to First Byte) بـ 200 ميلي ثانية، وكنت مصمماً أن هذا سينقذ الموقع. اتضح أن عميلي كان يركب على 4G في الكويت، والفرق الحقيقي بين موقعه والمنافس كان صورة بحجم 8 MB قبل الضغط.
Google لم تقل: "أصلحوا كل شيء." قالت: "اصلحوا الثلاثة الأشياء التي يشعر بها البشر." LCP، CLS، و INP. نقطة.
LCP — أكبر صورة أو نص على الشاشة
LCP تعني Largest Contentful Paint. ما هي أكبر عنصر مرئي يراه المستخدم؟ صورة بطل (hero image)؟ عنوان كبير؟ فيديو مدمج؟ الهدف: يجب أن تظهر في أقل من 2.5 ثانية. إذا استغرقت 4 ثوان، أنت في الـ "أحمر" عند Google.
السبب الأول للـ LCP البطيء؟ صور ضخمة. من تجربتي في 15+ موقع تجارة إلكترونية بالكويت والإمارات، الصور الخام من المصورين المحترفين غالباً 12-20 MB. تُحمّل كما هي، وبعدها المتصفح يضغطها. خطأ.
الإصلاح 1: ضغط وتحويل الصور
استخدم WebP بدلاً من JPG. الحجم ينخفض بـ 30-50%. أداة مثل TinyPNG أو إضافة في CI/CD تفعل هذا تلقائياً. لا تفكر يدوياً — أتمتم.
الإصلاح 2: استخدم Lazy Loading
لا تحمّل صور hero وأنت تحمّل الصفحة. اترك hero بأولويتة عالية (preload)، والباقي بـ loading="lazy". الصور تحت الطية تُحمل بعد ما يرى المستخدم hero.
الإصلاح 3: CDN وتخزين مؤقت
استخدم CDN. Cloudflare أو AWS CloudFront. الصور تُخدم من أقرب خادم للمستخدم، وليس من سيرفرك وحده. الفرق: من 4 ثوان إلى 1.5 ثانية في الواقع.
السبب الثاني: JavaScript التي تسد التحميل. أنت تحمّل ملف JS بحجم 500 KB (مثل مكتبة تتبع بيانات ثقيلة)، والمتصفح يتوقف عن رسم الصفحة حتى ينهيها. الحل: أرجِ تحميل JS غير حيوية. <script defer> و <script async> ليستا خدعة — هما ضروريتان.
CLS — عندما تقفز الصفحة أثناء قراءتك
انقر على زر "اشترِ" وفجأة الصفحة تنزلق لأسفل 200 بكسل، وتضغط على رابط إعلان بدلاً من الزر. تم الخسارة.
CLS (Cumulative Layout Shift) تقيس هذا الفوضى. القيمة يجب أن تكون أقل من 0.1. إذا كانت 0.25، أنت في الأحمر.
لماذا يحدث هذا؟ الأسباب الثلاثة الشائعة:
- الصور بلا أبعاد محددة: أنت تكتب <img src="..."> بدون width و height. المتصفح يحمّل الصورة، ويعرف حجمها بعد التحميل، فينقل كل شيء للأسفل. الحل بسيط: <img width="800" height="600" src="..."> أو استخدم aspect-ratio في CSS.
- الإعلانات والـ embeds: إعلان ثالث من Google Ads أو embeds من YouTube تحتل مساحة لا تُعرف مسبقاً. احجز مساحة لها من البداية بـ div بحجم ثابت.
- الخطوط المتأخرة: الخط الأساسي يحمّل بسرعة، لكن الخط الزخرفي يأتي بعد ثانية ونصف. كل نص "ينقلب" إلى الخط الجديد. استخدم font-display: swap في CSS لتجنب ذلك.
ملاحظة شخصية: CLS و "الثقة"
في موقع عميل كويتي بيع عقارات، وجدت CLS بقيمة 0.4. الصفحة كانت تقفز باستمرار. نسبة التحويل من عرض العقار إلى الطلب كانت 1.2% (منخفضة جداً). أصلحنا CLS، ونزلت الأرقام مباشرة لـ 3.1%. لا أحد قال ذلك صراحة، لكن القارئ يشعر بـ "عدم الاستقرار" — إنه لا يثق. الشاشة المستقرة = ثقة.
INP — الاستجابة الحقيقية عندما تنقر أنت
استبدلت INP (Interaction to Next Paint) معيار FID القديم في 2024. الفرق: FID قاسَ الاستجابة الأولى فقط. INP تقيس كل التفاعلات — النقرة الأولى والأخيرة والأسوأ.
الهدف: أقل من 200 ميلي ثانية. أكثر من 500 ميلي ثانية = أحمر.
لماذا يبطأ الموقع عند النقر؟ JavaScript ثقيلة تعمل على الخيط الرئيسي (main thread). كل تفاعل يجب أن يمر عبر: input → processing → paint. إذا كانت البرمجيات تحتل CPU لمدة 300 ميلي ثانية، المستخدم سيرى تأخير.
| السبب | الإصلاح | التأثير |
|---|---|---|
| JavaScript ثقيلة على load | استخدم Code Splitting — حمّل JS حسب الحاجة فقط | من 400ms إلى 150ms |
| Loop بطيء (عمليات على DOM) | استخدم requestAnimationFrame لتقسيم العمل | من 350ms إلى 120ms |
| مكتبات ثقيلة (jQuery، jQuery plugins) | استبدل بـ vanilla JS أو مكتبات خفيفة | من 500ms إلى 180ms |
| بيانات من API بطيئة | استخدم optimistic UI — أظهر تأثير فوري قبل API | من 1000ms إلى 250ms (ظاهرياً) |
القياس — أين تقف الآن؟
فتح PageSpeed Insights (شرعي: pagespeed.web.dev)، وأدخل موقعك. سترى Core Web Vitals الفعلية من الزوار الحقيقيين (field data)، لا البيانات المخبرية (lab data). الفروق مهمة:
- Field data: من 28 يوم السابقة. نسبة 75% من زوارك الحقيقيين (CrUX dataset من Google). هذا ما يحسب فعلاً.
- Lab data: اختبار من فريقك بجهاز واحد. مفيدة للتشخيص السريع، لا للقرار الحقيقي.
أول شيء أفعله: أفتح Field Data. إذا كانت فارغة، موقعك لم يحصل على 28 يوم من الترافيك الكافي. لا تقلق — استخدم Lab Data على الأقل، لكن اعرف أنها قد تكون متفائلة.
الأخطاء التي أرى شركات تكررها
خطأ رقم 1: "صرفنا 10,000 دينار على تحسين السرعة، لكن Field Data لم تتحسن." السبب: أنت حسّنت Lab Data. اختبرت على جهاز حديث وWifi سريعة. لكن 60% من الزوار يأتون من 4G وهواتف قديمة. الحل: اختبر على جهاز ضعيف فعلاً، وشبكة "4G Slow" في DevTools.
خطأ رقم 2: "حسّنا LCP من 3 ثوان إلى 2.8. هذا يجب أن يحسن التحويلات." نعم، لكن 2.8 زال أحمر. الهدف الحقيقي: أقل من 2.5. الفرق بين 2.8 و 2.5 صغير في الأرقام، لكنه فرق 21% في الأداء (2.5/2.8 ≈ 0.89). اذهب لـ 2.0، لا تتوقف عند 2.8.
خطأ رقم 3: "أصلحنا CLS، لكن رقم PageSpeed لم يرتفع كثيراً." السبب: PageSpeed يزن الثلاثة معايير بطرق مختلفة. إذا كان LCP ضعيفاً جداً، إصلاح CLS وحده لن يرفع النتيجة الكلية كثيراً. ركز على الثلاثة معاً، لا واحد منهم.
الخطة العملية: شهر واحد
أنت تريد نتائج، لا محاضرات. إليك ما أفعله مع العملاء:
الأسبوع الأول: قياس. أفتح PageSpeed Insights، أنسخ الأرقام، أعرفك أين أنت الآن. أنزل إلى الأسفل وانظر إلى "Opportunities" — تلك هي أولوياتك الحقيقية.
الأسبوع الثاني: صور. ضغط وتحويل WebP وإضافة lazy loading. هذا وحده سيرفع LCP بـ 30-50% غالباً.
الأسبوع الثالث: JavaScript وCSS. حذف الملفات غير المستخدمة، استخدام async/defer، تقسيم الأكواد الكبيرة.
الأسبوع الرابع: اختبار شامل من هاتف قديم و4G. إذا كانت النتائج > 80 لـ Desktop و > 70 لـ Mobile، انتهيت.
التحفظ الصادق
إذا كنت على WordPressبـ 40 إضافة (plugins)، وكل واحدة تحمّل 100KB من JavaScript غير مستخدمة، قد تحتاج إلى إعادة بناء الموقع بدلاً من "تحسينات." شخصياً، أوصيك بـ هيكل أخف: Next.js أو Hugo أو حتى HTML ثابتة مع JavaScript موضعية فقط حيث تحتاجها. الأساس يجب أن يكون خفيفاً، والتعقيد يأتي بعدها.
الخلاصة الحقيقية
Core Web Vitals ليست سحراً. هي تعكس ما يشعر به الإنسان فعلاً. موقع سريع = زوار سعيدون وتحويلات أفضل. موقع بطيء = خسارة. اختر. وإذا كان فريقك يقول "سنحسنها بعد الإطلاق"، أخبره أن بعد الإطلاق سيكون متأخراً جداً — السرعة تحتاج إلى أن تكون في البنية من اليوم الأول.