كيف تحسّن سرعة موقعك (Core Web Vitals) ولماذا تهمّ ترتيبك

Core Web Vitals ثلاثة مؤشرات تقيس جوانب مختلفة من تجربة المستخدم: سرعة ظهور المحتوى، ثبات التصميم، وسرعة استجابة الصفحة لتفاعلك. لنشرح كلاً منها بمثال ملموس:

• LCP (سرعة عرض أكبر عنصر): يقيس متى يظهر أكبر عنصر مرئي على الشاشة — غالباً صورة كبيرة أو عنوان رئيسي. الهدف أن يحدث ذلك خلال 2.5 ثانية أو أقل. إن تأخر، يشعر الزائر أن الصفحة «لا تفتح».
• CLS (مقدار الإزاحة البصرية): يقيس مدى تحرّك العناصر فجأة أثناء التحميل. هل سبق أن حاولت الضغط على زر فقفز مكانه لأن إعلاناً أو صورة حُمّلت متأخرة؟ هذا ما يقيسه CLS، والهدف أن يبقى أقل من 0.1.
• INP (سرعة الاستجابة للتفاعل): حلّ محل المؤشر القديم FID، ويقيس مدى سرعة استجابة الصفحة عند ضغطك على زر أو كتابتك في حقل. الهدف أن تكون الاستجابة خلال 200 ميلي ثانية.

المهم أن جوجل تقيس هذه المؤشرات من بيانات مستخدمين حقيقيين (Field Data)، لا من اختبار معملي وحده. أي أن أداء موقعك على أجهزة زوّارك الفعلية وشبكاتهم هو ما يُحتسب، وليس أداءه على جهازك السريع المتصل بالألياف.

أغلب حالات البطء تعود لعدد محدود من الأسباب المتكررة. إذا عرفت أيّها ينطبق عليك، عرفت من أين تبدأ:

• الصور الثقيلة: السبب الأول والأكثر شيوعاً. صور بحجم عدة ميغابايت تُحمّل بدقة أكبر بكثير مما يظهر على الشاشة، دون ضغط أو تنسيق حديث.
• كثرة السكربتات الخارجية: أدوات التتبّع، الدردشة، الإعلانات، والخطوط الخارجية — كل سكربت يضيف وزناً ويؤخّر التفاعل.
• الاستضافة البطيئة أو البعيدة: خادم بطيء أو بعيد جغرافياً عن زوّارك يزيد زمن الاستجابة الأولي قبل أن يبدأ التحميل أصلاً.
• غياب التخزين المؤقت (Caching): إعادة بناء الصفحة من الصفر مع كل زيارة بدل تقديم نسخة جاهزة.
• JavaScript الزائد: تطبيقات تُحمّل كميات ضخمة من الشيفرة قبل أن تعرض أي شيء مفيد للمستخدم.

نقطة مهمة: البطء نادراً ما يكون لسبب واحد. عادةً هو تراكم عدة عوامل صغيرة. ولهذا فإن القياس قبل الإصلاح ضروري — لتعرف أين يضيع الوقت فعلاً بدل أن تخمّن.

لا تبدأ بالإصلاح العشوائي. ابدأ بالقياس باستخدام أدوات مجانية موثوقة تعطيك صورة واضحة عن وضعك الحالي:

• PageSpeed Insights من جوجل: يعطيك تقييماً لكل مؤشر من Core Web Vitals، ويجمع بين بيانات المعمل والبيانات الميدانية الحقيقية، مع اقتراحات عملية مرتّبة حسب الأثر.
• تقرير Core Web Vitals في Search Console: يُظهر أداء صفحاتك على نطاق الموقع كله بمرور الوقت، ويصنّفها إلى جيدة وتحتاج تحسيناً وضعيفة.
• Lighthouse داخل متصفح كروم: مفيد للتشخيص أثناء التطوير، لكن تذكّر أنه اختبار معملي قد يختلف عن تجربة المستخدم الحقيقية.

القاعدة: ابدأ بالصفحات الأهم — الصفحة الرئيسية، صفحة المنتج، صفحة الدفع — لأنها التي تؤثر مباشرة على إيراداتك. تحسين صفحة لا يزورها أحد لن يغيّر شيئاً في النتيجة.

بعد القياس، هذه الإصلاحات هي الأكثر تأثيراً مقابل الجهد، مرتّبة من الأسهل إلى الأعمق:

• اضغط الصور وحوّلها لصيغ حديثة مثل WebP أو AVIF، وقدّم لكل جهاز الحجم المناسب له (responsive images) بدل صورة واحدة عملاقة.
• أجّل تحميل الصور خارج الشاشة (lazy loading) حتى يقترب منها المستخدم.
• احجز مساحة الصور والإعلانات مسبقاً بتحديد أبعادها، فيختفي التحرّك المفاجئ ويتحسّن CLS فوراً.
• قلّل السكربتات الخارجية واحذف ما لا تستخدمه فعلاً، وأجّل تحميل غير الضروري منها.
• فعّل التخزين المؤقت وشبكة توزيع المحتوى (CDN) لتقريب موقعك جغرافياً من زوّارك.
• حمّل الخطوط محلياً واستخدم font-display لتجنّب اختفاء النص أثناء تحميل الخط.

هذه ليست قائمة يجب تنفيذها كاملة دفعة واحدة. نفّذ أكثرها أثراً على صفحاتك الأهم، أعد القياس، ثم انتقل للتالي. التحسين المتدرّج المبني على القياس أنجح من حملة إصلاح كبيرة تُنفّذ مرة وتُنسى.

السؤال المنطقي: هل يستحق كل هذا الجهد؟ الإجابة نعم، لسببين متكاملين.

الأول هو الترتيب في البحث. Core Web Vitals عامل ضمن إشارات تجربة الصفحة لدى جوجل. هي ليست العامل الأهم — المحتوى وملاءمته للبحث يبقيان الأساس — لكنها مرجّحة عند تقارب الصفحات في الجودة. بين موقعين متقاربين في المحتوى، الأسرع غالباً يتقدّم.

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

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