ما تكلفه مؤشرات Core Web Vitals في أرباحك فعلياً

غالباً ما يجري الحديث عن مؤشرات أداء الويب الأساسية Core Web Vitals كموضوع يخص السيو (SEO) فقط. وهذا التأطير يقلل من قيمتها الحقيقية، لأنها كإشارة ترتيب تعد ثانوية إلى حد كبير — وقد صرحت Google بذلك بوضوح؛ فالصفحة البطيئة التي تقدم أفضل إجابة لا تزال تتصدر على الصفحة السريعة التي تقدم محتوى أدنى جودة.

الدافع الحقيقي للاهتمام بها هو معدل التحويل والمبيعات. فالزائر الذي يغادر موقعك قبل أن يكتمل تصيير الصفحة يحقق معدل تحويل صفري، ولن يعوض ذلك أي تصدر في نتائج البحث.

إليك ما تقيسه المؤشرات الثلاثة بدقة، وما يسبب تراجع درجاتها واقعياً، وما يجب البدء بإصلاحه أولاً.

المؤشرات الثلاثة الأساسية

سرعة تحميل أكبر جزء من المحتوى (LCP - Largest Contentful Paint)

يقيس توقيت اكتمال تصيير أكبر عنصر مرئي على الشاشة. وهو عادة الصورة البارزة (Hero Image)، أو وسم العنوان الرئيسي H1، أو كتلة نصية عريضة.

• جيد: أقل من 2.5 ثانية
• يحتاج إلى تحسين: بين 2.5 إلى 4.0 ثوانٍ
• ضعيف: أكثر من 4.0 ثوانٍ

يعد مؤشر LCP أقرب مقياس عملي للإجابة عن سؤال: \"متى أصبحت هذه الصفحة مفيدة وقابلة للقراءة للزائر؟\". وهو العنصر الأول الذي يجب البدء بإصلاحه.

ثبات التصميم التراكمي (CLS - Cumulative Layout Shift)

يقيس مدى تحرك العناصر واهتزازها بشكل مفاجئ أثناء التحميل. لقد مررت بهذه التجربة بالتأكيد: تهم بالنقر على رابط، فيتحمل إعلان فوقه فجأة، فتهتز الصفحة، وتنقر على شيء آخر غير مقصود.

• جيد: أقل من 0.1
• ضعيف: أكثر من 0.25

يعد مؤشر CLS عادة الأسهل والأقل كلفة في الإصلاح بين الثلاثة، لأن أسبابه واضحة ومحددة ومحصورة في حالات معدودة.

مدى استجابة الصفحة للتفاعل (INP - Interaction to Next Paint)

يقيس الوقت المستغرق لتستجيب الصفحة بصرياً بعد تفاعل المستخدم معها. لقد حل هذا المؤشر محل مؤشر تأخير الإدخال الأول (FID) في مارس 2024، وهو أكثر صرامة بكثير: إذ يقيس كل تفاعل يجريه الزائر طوال فترة وجوده في الصفحة، وليس التفاعل الأول فقط.

• جيد: أقل من 200 مللي ثانية
• ضعيف: أكثر من 500 مللي ثانية

يرتبط ضعف مؤشر INP دائماً تقريباً بمشاكل JavaScript — حيث يكون الخيط الرئيسي للمعالجة (Main Thread) مزدحماً ويعجز عن إعادة رسم الشاشة في الوقت المناسب.

البيانات المعملية مقابل البيانات الميدانية

يسبب هذا التمييز ارتباكاً واسعاً، لذا يجدر توضيحه بدقة شديدة:

البيانات المعملية (Lab Data) هي محاكاة للتحميل في بيئة اختبارية مضبوطة — وهو ما تمنحه لك أداة Lighthouse في أدوات المطورين بمتصفح Chrome. وهي ممتازة لتكرار الاختبارات وتصحيح الأخطاء، لكنها ليست ما تعتمده Google لترتيب المواقع.

البيانات الميدانية (Field Data) تأتي من تقرير تجربة مستخدمي Chrome (CrUX): وهي قياسات حقيقية مأخوذة من مستخدمين فعليين للمتصفح عبر نافذة متجددة مدتها 28 يوماً. هذه هي البيانات التي تعتمدها Google بالفعل في خوارزمياتها، وهي ما تشاهده في لوحة Search Console.

وكثيراً ما يتعارض المصدران؛ وحين يتعارضان، فالبيانات الميدانية هي الحقيقة المطلقة. فقد يحقق الموقع درجة 95 في Lighthouse على حاسوب المطور السريع، ومع ذلك يفشل في البيانات الميدانية لأن أغلب زوارك الحقيقيين يتصفحون عبر هواتف أندرويد متوسطة وعلى شبكات اتصالات جوالة مزدحمة.

النتيجة العملية: حسن موقعك استناداً للبيانات الميدانية، واستعن بالبيانات المعملية لتصحيح الأكواد. وتذكر أن البيانات الميدانية تتطلب وقتاً — فالإصلاح يحتاج إلى 28 يوماً ليظهر أثره الكامل في التقارير.

تعرض أداة تدقيق السيو المجانية كلا المقياسين، مستخرجة مباشرة من واجهة Google PageSpeed Insights API الرسمية، لتكتشف مواضع التباين لنطاقك.

ما الذي يسبب تراجع مؤشر LCP واقعياً؟

مرتبة حسب الأسباب الأكثر شيوعاً:

الصور

يمثل عنصر LCP صورة في أغلب صفحات الويب، وغالباً ما تكون أضخم بكثير مما ينبغي.

ونمط الخطأ يتكرر دائماً: صورة JPEG بحجم 700 كيلوبايت وأبعاد 3000 بكسل، تُعرض على شاشة بعرض 640 بكسل فقط، ودون إشارة لأولوية التحميل وبصيغة قديمة غير مضغوطة.

والحل النموذجي:

<picture>
  <source srcset="/hero-640.avif 640w, /hero-1280.avif 1280w" type="image/avif" />
  <source srcset="/hero-640.webp 640w, /hero-1280.webp 1280w" type="image/webp" />
  <img src="/hero-640.jpg" alt="…"
       width="640" height="480"
       fetchpriority="high" decoding="async" />
</picture>

يحقق هذا الكود أربعة إنجازات معاً: تقلص صيغتا AVIF و WebP حجم الملف بنسبة 50 إلى 80% مقارنة بـ JPEG بنفس الجودة. وترسل سمة srcset للهواتف ملفات تناسب أبعاد شاشاتها. وتضمن سمتا width و height حجز المساحة مسبقاً، مما يعالج مؤشر CLS تلقائياً. وتخبر سمة fetchpriority="high" المتصفح بأن هذه الصورة أهم من أي عنصر آخر يقوم باستجلابه.

هذه السمة الأخيرة تحديداً هي التعديل المنفرد الأعلى عائداً في الصفحة، ولا تكلف أي جهد إضافي.

إياك وإضافة خاصية loading="lazy" لصورة LCP الأساسية. فالتحميل الكسول يؤجل استجلاب الصورة، وهو خطأ فادح للعنصر الرئيسي الذي تخضع للتقييم على سرعته. طبق التحميل الكسول على الصور الموجودة أسفل الصفحة فقط؛ وحمل الصورة البارزة الرئيسية فوراً.

الموارد التي تحجب التصيير (Render-Blocking)

كل ملف تنسيق CSS في ترويسة الصفحة يحجب تصيير المحتوى حتى يكتمل تحميله وتحليله برمجياً. وينطبق ذلك على كل سكربت تزامني.

والخطأ الكلاسيكي هو سلاسل الطلبات المتتالية:

/* في ملف styles.css — ينشئ سلسلة معطلة */
@import url('https://fonts.googleapis.com/css2?family=…');

يضطر المتصفح هنا لتحميل styles.css، وتحليله، ثم اكتشاف تعليمة الاستيراد، ثم تحميل ملف الخطوط، وتحليله، ثم استجلاب ملفات الخطوط نفسها. أربع رحلات اتصال متتالية قبل أن يظهر حرف واحد على الشاشة.

ضع رابط الخطوط في ترويسة HTML مباشرة، مع إضافة تعليمة preconnect مسبقاً:

<link rel="preconnect" href="https://fonts.googleapis.com" />
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin />
<link rel="stylesheet" href="https://fonts.googleapis.com/css2?family=…&display=swap" />

خاصية display=swap بالغة الأهمية: فهي تعرض النص فوراً بخط بديل من النظام بدلاً من ترك مساحة فارغة بيضاء أثناء انتظار تحميل خط الويب.

زمن استجابة الخادم (TTFB)

إذا تجاوز وقت وصول أول بايت (Time To First Byte) حاجز 600 مللي ثانية، فيستحيل أن تكون بقية مراحل التحميل سريعة. والأسباب معروفة وقابلة للإصلاح: غياب طبقة التخزين المؤقت (Caching)، استضافة ضعيفة الموارد، استعلامات قواعد بيانات بطيئة عند كل تحميل، أو شبكة CDN غير مضبوطة أمام الخادم الأصلي.

بالنسبة للمواقع التسويقية، فإن الحل يكمن في التوليد الثابت (Static Generation). فإذا كانت الصفحة لا تتغير لكل زائر، فيجب أن تكون ملفاً جاهزاً على القرص، وليست صفحة تُبنى من الصفر عند كل طلب.

التضخم البرمجي لأكواد JavaScript

أطر العمل التي تُحمّل 400 كيلوبايت من ملفات JavaScript لمجرد عرض صفحة نصية بسيطة تدفع ثمناً باهظاً بلا مبرر. فعلى هاتف أندرويد متوسط، قد يستغرق تحليل وتنفيذ هذا الحجم من الأكواد أكثر من ثانية كاملة قبل أن يظهر أي محتوى.

هذا ليس اعتراضاً على أطر العمل ذاتها — بل اعتراض على استخدام أطر عمل تُصير المحتوى في متصفح العميل (Client-Rendered) لصفحات كان يمكن تصييرها ككود HTML ثابت وخفيف.

ما الذي يسبب تراجع مؤشر CLS واقعياً؟

تغطي ثلاثة أسباب جميع الحالات تقريباً:

الصور دون أبعاد محددة. بدون تحديد width و height، يعجز المتصفح عن حجز المساحة مسبقاً، فيهتز كل المحتوى للأسفل عند وصول الصورة. حدد كليهما دائماً — مع استخدام height: auto في CSS لضمان التجاوب.

تبديل خطوط الويب. يُعرض الخط البديل، ثم يكتمل تحميل خط الويب بمقاييس وأبعاد مختلفة، فيهتز النص ويتغير موضعه. عالج ذلك باستخدام font-display: swap مع سمة size-adjust لضبط مقاييس الخط البديل.

المحتوى المحقون فوق المحتوى الحالي. لافتات الكوكيز، أشرطة العروض، الإعلانات، والعناصر المضمنة متأخرة التحميل. فأي عنصر يُدرج في أعلى المستند يدفع المحتوى للأسفل. احجز المساحة مسبقاً، أو اجعلها كطبقة عائمة (Overlay) بدلاً من إقحامها في مسار الصفحة.

ما الذي يسبب تراجع مؤشر INP واقعياً؟

ينشأ ضعف INP عن ازدحام الخيط الرئيسي للمعالجة. وأبرز مصادره:

• المهام الطويلة (Long Tasks) — أي مهمة JavaScript مفردة تتجاوز 50 مللي ثانية تحجب الاستجابة.
• معالجات الأحداث الثقيلة — تنفيذ عمليات معقدة ومكلفة داخل كود النقر أو الإدخال مباشرة.
• وسوم السكربتات الخارجية — التحليلات، ونوافذ المحادثة، والخرائط الحرارية، وسكربتات A/B تتنافس جميعاً على الخيط الرئيسي.
• إعادة التصيير المفرطة — قيام إطار العمل بإعادة رسم شجرة عناصر ضخمة عند كل ضغطة زر.

خطوات الإصلاح، مرتبة حسب الأثر:

1. تدقيق وحذف السكربتات الخارجية. معظم المواقع تحمل وسوماً لا يتذكر أحد سبب إضافتها. احذف ما لا يستحق تكلفته، وحمل الباقي عبر سمة defer أو بعد تفاعل المستخدم.
2. تفكيك المهام البرمجية الطويلة. امنح الأولوية للخيط الرئيسي باستخدام scheduler.yield() حيثما أمكن، أو عبر setTimeout(…, 0).
3. تقنين معالجات الأحداث المتكررة (Debounce). لا سيما في أحداث input و scroll.
4. نقل العمليات الحسابية المعقدة إلى Web Worker.

ما يجب عليك إصلاحه أولاً

إذا كان وقتك محدوداً، فالتزم بهذا التسلسل:

1. اضغط وصغّر حجم صورة LCP، وأضف سمة fetchpriority="high". هذا هو التحسن الأكبر، وغالباً ما يستغرق ساعة واحدة فقط.
2. أضف سمات width و height لكل صورة. يعالج معظم مشاكل اهتزاز التصميم CLS في دقائق.
3. احذف سلاسل استيراد @import المعطلة للتصيير. انقل الخطوط للترويسة مع preconnect.
4. راجع السكربتات الخارجية واحذف غير المستخدم منها. يفيد مؤشري INP و LCP معاً وبشكل ملحوظ.
5. فعل التحميل الكسول للصور السفلية. دون المساس بالصورة البارزة الرئيسية.
6. عالج زمن استجابة الخادم TTFB إذا كان يتجاوز 600 مللي ثانية. يتطلب جهداً أكبر، لكن لا شيء يعمل بكفاءة بدونه.

كلمة صادقة بشأن الدرجات الرقمية

السعي المحموم للحصول على درجة 100 كاملة في Lighthouse هو مضيعة للوقت والجهد غالباً. فالفارق بين درجة 85 و 100 نادراً ما يغير سلوك المستخدم؛ بينما الفارق بين 35 و 75 يغير سلوكه ومعدل تحويله جذرياً.

احرص على الدخول في النطاق \"الجيد\" في البيانات الميدانية للمؤشرات الثلاثة، ثم توقف وركز جهودك على تحسين مسار التحويل والمبيعات. فالسرعة وسيلة لزيادة الأرباح وليست غاية مجردة — والصفحة السريعة ذات العرض التجاري السيئ لن تبيع شيئاً في النهاية.