إذا كانت الصفحة بطيئة في الظهور، أو تتأخر في الاستجابة، أو يتحرك التصميم فجأة أثناء القراءة، فلن يقول الزائر "هذه مشكلة أداء". هو ببساطة يغادر.
لهذا السبب لا ينبغي التعامل مع Core Web Vitals على أنها أرقام تقنية تخص المطورين فقط. هذه المؤشرات تمس تجربة المستخدم، والسيو، ومعدل التحويل في وقت واحد.
ما الذي تقيسه Core Web Vitals فعلياً؟
هناك ثلاثة مؤشرات رئيسية، وكل واحد منها يراقب جانباً مختلفاً من تجربة الصفحة.
1. LCP (Largest Contentful Paint)
يقيس هذا المؤشر الوقت الذي يستغرقه ظهور أكبر عنصر مهم داخل الجزء المرئي من الصفحة. غالباً يكون صورة الهيرو، أو بانر رئيسي، أو غلاف فيديو، أو أول كتلة نصية كبيرة.
الهدف الجيد هنا هو 2.5 ثانية أو أقل.
2. INP (Interaction to Next Paint)
يقيس INP مدى سرعة ظهور استجابة مرئية بعد تفاعل حقيقي من المستخدم، مثل الضغط على زر أو فتح قائمة أو الكتابة داخل نموذج.
القيمة الجيدة هي 200 مللي ثانية أو أقل.
3. CLS (Cumulative Layout Shift)
يقيس CLS مقدار تحرك عناصر الصفحة بشكل غير متوقع أثناء التحميل.
يفضل أن يبقى عند 0.1 أو أقل.
كيف تقيس المشكلة قبل أن تبدأ بالإصلاح
التحسين الحقيقي يبدأ من التشخيص. من دون قياس واضح، ستدخل في دوامة تعديلات كثيرة وتأثير قليل.
1. Google Search Console وPageSpeed Insights
ابدأ بتقرير Core Web Vitals داخل Search Console لأنه يعرض لك مجموعات الصفحات التي تعاني فعلاً لدى المستخدمين الحقيقيين. بعدها استخدم PageSpeed Insights لتحليل عنوان URL محدد.
2. Lighthouse داخل Chrome
Lighthouse مفيد جداً لبناء فرضية تقنية سريعة. راقب خصوصاً:
- ما العنصر الذي تم التقاطه كمرشح LCP
- ما السكربتات التي تشغل الـ main thread لفترة طويلة
- ما الموارد التي تمنع الرسم الأولي
- أين تحدث قفزات التخطيط
3. بيانات الاستخدام الفعلي (RUM)
بيانات المختبر لا تكفي وحدها. الأجهزة الضعيفة، والاتصال البطيء، والسكريبتات الخارجية، وفروق الأسواق تظهر بشكل أوضح في بيانات المستخدم الحقيقي.
وإذا أردت ترتيب الصفحات من منظور SEO قبل الغوص في التفاصيل التقنية، فيمكنك ربط هذه المراجعة مع SEO Analyzer لتحديد الأولويات بسرعة أكبر.
كيف تحسن LCP بطريقة عملية
في أغلب الحالات، سبب LCP المرتفع ليس غامضاً: صورة رئيسية ثقيلة، أو استجابة خادم بطيئة، أو موارد كثيرة تعطل أول رسم.
1. ابدأ بالصورة الأهم
- استخدم WebP أو AVIF قدر الإمكان.
- قدم أحجاماً مختلفة عبر
srcsetأو<picture>. - اضغط الصورة قبل النشر.
- لا تضع
loading="lazy"على صورة الهيرو أو العنصر المرشح كـ LCP. - أضف
widthوheightحتى يحجز المتصفح المساحة مبكراً.
1<picture> 2 <source 3 srcset="hero-1200.webp 1200w, hero-800.webp 800w, hero-400.webp 400w" 4 type="image/webp" 5 sizes="(max-width: 600px) 400px, (max-width: 1200px) 800px, 1200px" 6 > 7 <source 8 srcset="hero-1200.jpg 1200w, hero-800.jpg 800w, hero-400.jpg 400w" 9 type="image/jpeg" 10 sizes="(max-width: 600px) 400px, (max-width: 1200px) 800px, 1200px" 11 > 12 <img src="hero-800.jpg" alt="Homepage hero image" width="1200" height="800" loading="eager"> 13</picture>
2. قلل وقت استجابة الخادم
إذا كان TTFB مرتفعاً، فالمتصفح ينتظر قبل أن يبدأ أي شيء.
- فعّل التخزين المؤقت عندما يكون ذلك مناسباً
- استخدم CDN للملفات الثابتة
- راقب الاستعلامات البطيئة
- أبعد المنطق الخادمي الثقيل عن المسار الحرج
3. أزل الموارد التي تعطل الرسم
الكثير من الصفحات تبدو بطيئة لأن CSS والخطوط وJavaScript تسبق كل شيء آخر.
- حمّل CSS الحرج أولاً
- استخدم
deferللسكريبتات غير الأساسية - استخدم
asyncللسكريبتات المستقلة - احذف المكتبات غير الضرورية في التحميل الأول
1<head> 2 <link rel="preload" href="/fonts/inter-var.woff2" as="font" type="font/woff2" crossorigin> 3 <script src="/js/main.js" defer></script> 4 <script src="https://analytics.example.com/script.js" async></script> 5</head>
4. استخدم preload بحذر
هو ممتاز لصورة LCP أو الخط الأساسي، لكنه ليس حلاً لكل شيء. المبالغة فيه قد تخلق ازدحاماً جديداً في الشبكة.
كيف تحسن INP وتجعل الصفحة أسرع استجابة
إذا كان INP سيئاً، فالمشكلة غالباً في أن الـ main thread مزدحم أكثر من اللازم.
1. خفف JavaScript
- قسم الحزم الكبيرة
- حمّل الميزات الثانوية عند الحاجة
- تخلص من الكود غير المستخدم
- لا تقم بتهيئة مكونات غير ضرورية في التحميل الأول
1document.querySelector('.open-chart').addEventListener('click', async () => { 2 const { renderChart } = await import('./chart-module.js'); 3 renderChart(); 4});
2. راجع السكربتات الخارجية بصرامة
أدوات الدردشة، وأكواد التحليل، والإعلانات، والخرائط، وتجارب A/B كلها قد تؤثر على التفاعل أكثر مما تتوقع.
اسأل نفسك:
- هل هذا السكربت يضيف قيمة تجارية حقيقية؟
- هل يمكن تحميله بعد أول تفاعل أو بعد التمرير؟
- هل يمكن الاستغناء عنه بالكامل؟
3. قسم المهام الطويلة
عندما تستمر مهمة JavaScript لفترة طويلة، تتجمد استجابة الصفحة مؤقتاً.
- قسم العمليات الثقيلة إلى أجزاء أصغر
- استخدم
requestIdleCallbackللمهام الثانوية - انقل الحسابات الثقيلة إلى Web Workers
كيف تخفض CLS وتمنع الصفحة من "القفز"
CLS المرتفع غالباً نتيجة مجموعة من التفاصيل الصغيرة التي لم يتم ضبطها.
1. احجز مساحة للوسائط والعناصر المضمنة
الصور، والفيديوهات، وiframe تحتاج إلى مساحة محددة قبل أن تظهر.
- أضف
widthوheight - استخدم
aspect-ratioللعناصر المتجاوبة - ضع العناصر المضمنة داخل حاويات مستقرة الارتفاع
2. تجنب إدخال عناصر مفاجئة
شريط ترويجي، أو تنبيه، أو وحدات توصية، أو إعلان يظهر في أعلى الصفحة قد يدمر الاستقرار البصري.
- احجز المساحة مسبقاً
- استخدم overlay إذا كنت لا تريد دفع المحتوى للأسفل
- حدد ارتفاعاً أدنى لمواضع الإعلانات
3. راقب تحميل الخطوط
الخطوط المخصصة قد تسبب أيضاً تحركات غير مرغوبة.
- قم بعمل preload للخط الأساسي
- استخدم
font-display: swap - اختر خطاً احتياطياً قريباً في المقاسات
مثال عملي على الأثر
كان لدى أحد متاجر التجارة الإلكترونية، مع اعتماد كبير على الزيارات من الجوال، المؤشرات التالية:
- LCP: 4.8 ثانية
- INP: 180 مللي ثانية
- CLS: 0.25
- معدل التحويل: 1.2%
- معدل الارتداد: 65%
الإجراءات التي تم تنفيذها:
- تحويل الصور الرئيسية إلى WebP
- تثبيت أبعاد الصور ومناطق الإعلانات
- تأخير تحميل التحليلات والسكريبتات الإعلانية
- عمل preload لصور الهيرو المهمة
- تقليل CSS الحرج
- استخدام CDN للملفات الثابتة
- تحسين تحميل الخطوط عبر
font-display: swap
النتائج بعد ذلك:
- LCP: 1.9 ثانية
- INP: 65 مللي ثانية
- CLS: 0.08
- معدل التحويل: 2.8%
- معدل الارتداد: 42%
لم تكن هناك معجزة. فقط ترتيب صحيح للأولويات.
لماذا المتابعة أهم من الإصلاح لمرة واحدة
Core Web Vitals يمكن أن تتراجع بسهولة مع كل إضافة جديدة: سكربت، ويدجت، قسم ترويجي، أو صورة ضخمة.
1. أنشئ نظام متابعة مستمر
راقب Search Console وبيانات RUM وأنواع الصفحات الأساسية بشكل دائم.
2. ضع ميزانية أداء
من المفيد تحديد حدود واضحة لـ:
- إجمالي حجم JavaScript
- أقصى حجم للصور
- عدد الخطوط المحملة
- عدد السكربتات الخارجية
3. أدخل الأداء في سير النشر
أي صفحة جديدة أو إعادة تصميم أو ميزة كبيرة يجب أن تمر على فحص سريع لـ LCP وINP وCLS قبل الإطلاق.
4. اجعل الفهم مشتركاً داخل الفريق
هذه ليست مسؤولية التطوير وحده. التصميم والمحتوى والتسويق يؤثرون عليها أيضاً.
الخلاصة السريعة
- LCP يتحسن عندما تعالج المورد الرئيسي، واستجابة الخادم، ومسار الرسم الحرج.
- INP يتحسن عندما تخفف الحمل عن الـ main thread.
- CLS ينخفض عندما تحجز المساحات مسبقاً وتمنع الإدخال المفاجئ للعناصر.
- بيانات المستخدم الحقيقي أهم من درجات المختبر وحدها.
- الهدف ليس تقريراً جميلاً، بل صفحة أسرع وأكثر قدرة على التحويل.
إذا كنت تريد أولاً معرفة الصفحات التي تخسر أكثر بسبب الأداء، ابدأ بمراجعة عبر SEO Analyzer، ثم انتقل إلى Lighthouse وبيانات الاستخدام الفعلي للتفاصيل الدقيقة.
