Core Web Vitals: اجتياز اختبار السرعة من Google

في عام 2021، أعلنت Google أن Core Web Vitals عوامل ترتيب. ثلاثة مقاييس محددة تؤثر الآن بشكل مباشر على ترتيب موقعك في نتائج البحث: Largest Contentful Paint (LCP)، وCumulative Layout Shift (CLS)، وInteraction to Next Paint (INP). المواقع ذات المقاييس الضعيفة أقل احتمالاً للترتيب الجيد. المواقع ذات المقاييس الممتازة تكتسب ميزة في الترتيب. في السيو الحديث، اجتياز Core Web Vitals أمر غير قابل للتفاوض.

الآثار المترتبة عميقة. لم يعد بإمكانك تجاهل الأداء. لا يمكنك بناء موقع بطيء والأمل في ترتيب جيد. أوضحت Google أن تجربة المستخدم مهمة، وأن Core Web Vitals تقيس هذه التجربة كمياً. تحسين Core Web Vitals لم يعد اختيارياً؛ بل أصبح إلزامياً للظهور التنافسي في نتائج البحث.

ما هي Core Web Vitals ولماذا تهم

تقيس Core Web Vitals ثلاثة أبعاد من تجربة المستخدم: سرعة التحميل (LCP)، والثبات البصري (CLS)، والاستجابة (INP). تشرح صفحة Web Vitals من Google كل مقياس بالتفصيل. تمثل هذه المقاييس الثلاثة أهم جوانب تجربة المستخدمين لموقعك.

جمعت Google تريليونات نقاط البيانات من مستخدمين حقيقيين لتحديد المقاييس الأكثر أهمية. والنتيجة هي Core Web Vitals. هذه ليست حدوداً عشوائية؛ بل هي قياسات مبنية على أدلة لما يجعل الموقع يبدو سريعاً ومستجيباً بالنسبة للمستخدمين الحقيقيين.

يشرح الإعلان الرسمي من Google كيف تؤثر Core Web Vitals على ترتيب نتائج البحث. تعتبر Google أن Core Web Vitals أحد عوامل الترتيب المتعددة. لا تزال جودة المحتوى وملاءمته أكثر أهمية، لكن موقعين بمستوى ملاءمة متقارب سيُرتَّبان وفقاً لأداء Core Web Vitals الخاص بكل منهما.

Largest Contentful Paint (LCP): قياس سرعة التحميل

يقيس Largest Contentful Paint (LCP) المدة التي يستغرقها أكبر عنصر محتوى في الصفحة ليصبح مرئياً للمستخدم. قد يكون هذا العنصر صورة أو فيديو أو عنواناً أو كتلة نص. يقيس LCP اللحظة التي يتمكن فيها المستخدم من رؤية المحتوى الرئيسي وإدراك أن الصفحة قد تم تحميلها.

توصية Google: يجب أن يكون LCP أقل من 2.5 ثانية. تُعتبر الصفحات التي يقل فيها LCP عن 2.5 ثانية "جيدة". الصفحات التي يتراوح فيها LCP بين 2.5 و4 ثوانٍ "بحاجة إلى تحسين". الصفحات التي يتجاوز فيها LCP 4 ثوانٍ "ضعيفة". المستخدمون الذين يواجهون LCP يتجاوز 3 ثوانٍ يشعرون بأن الصفحة بطيئة. المستخدمون الذين يواجهون LCP يتجاوز 4 ثوانٍ غالباً ما يغادرون الصفحة.

الأسباب الشائعة لبطء LCP: بطء زمن استجابة الخادم، وكود CSS وJavaScript الذي يعطل العرض، والصور غير المُحسَّنة، والخطوط الكبيرة التي تستغرق وقتاً للتحميل. أصلح LCP من خلال: تحسين سرعة الخادم (تقليل Time to First Byte / TTFB)، وإزالة الموارد التي تعطل العرض، وتأجيل JavaScript، وتحسين الصور وضغطها، واستخدام صيغ صور حديثة (WebP)، والتحميل المسبق (preload) للموارد الحرجة.

تعرض PageSpeed Insights نتيجة LCP الخاصة بك وتقدم توصيات محددة. شغِّل الاختبار على صفحاتك الرئيسية، ورتِّب التوصيات حسب الأثر، ونفِّذ التحسينات الأعلى أثراً أولاً.

Cumulative Layout Shift (CLS): قياس الثبات البصري

يقيس Cumulative Layout Shift (CLS) الحركة غير المتوقعة لعناصر الصفحة أثناء تحميلها. عندما تقرأ مقالاً ويقفز النص فجأة للأسفل لأن إعلاناً تم تحميله فوقه، فهذا هو تحوُّل التخطيط (layout shift). يقيس CLS مقدار تحوُّل تخطيط الصفحة كمياً أثناء التحميل.

توصية Google: يجب أن يكون CLS أقل من 0.1. تُعتبر نتيجة CLS أقل من 0.1 "جيدة". النتائج بين 0.1 و0.25 بحاجة إلى تحسين. النتائج فوق 0.25 "ضعيفة". حتى التحولات الصغيرة تتراكم. يعني CLS بقيمة 0.15 أن عناصر الصفحة تحركت بمجموع يعادل 15% من ارتفاع منطقة العرض أثناء التحميل. يجد المستخدمون هذا الأمر مزعجاً ويشعرون بالإحباط.

الأسباب الشائعة لارتفاع CLS: الإعلانات التي تُحمَّل بشكل غير متزامن، والصور بدون خصائص width وheight محددة، والعناصر المضمَّنة (embeds) (مثل فيديوهات YouTube وأدوات وسائل التواصل الاجتماعي) التي تُحمَّل بشكل غير متزامن، والخطوط التي تتبدل فجأة. أصلح CLS من خلال: تحديد أبعاد الصور في HTML (خصائص width وheight)، وحجز مساحة للإعلانات قبل تحميلها، واستخدام font-display: swap ضمن كود @font-face في CSS لمنع اهتزاز الخط، وتحميل الفيديوهات والعناصر المضمَّنة بشكل متزامن أو مع حجز مساحة لها.

يجب أن تحتوي كل صورة في موقعك على خصائص width وheight صريحة. هذا يخبر المتصفح بحجز المساحة قبل تحميل الصورة. بدون الأبعاد، لا يعرف المتصفح مقدار المساحة الواجب حجزها، مما يتسبب في تحوُّل التخطيط عند وصول الصورة.

Interaction to Next Paint (INP): قياس الاستجابة

يقيس Interaction to Next Paint (INP) مدى استجابة صفحتك لتفاعلات المستخدم (النقرات، اللمسات، إدخال لوحة المفاتيح). INP هو الزمن الفاصل بين لحظة تفاعل المستخدم مع الصفحة ولحظة استجابة الصفحة بصرياً. الصفحة المستجيبة تستجيب خلال أجزاء من الألف من الثانية. الصفحة غير المستجيبة تستغرق ثوانٍ.

توصية Google: يجب أن يكون INP أقل من 200 جزء من الألف من الثانية. النتائج أقل من 200 جزء من الألف من الثانية "جيدة". النتائج بين 200 و500 جزء من الألف من الثانية بحاجة إلى تحسين. النتائج فوق 500 جزء من الألف من الثانية "ضعيفة". يتوقع المستخدمون استجابة فورية. INP بقيمة 500 جزء من الألف من الثانية يبدو بطيئاً. INP بقيمة ثانية واحدة يبدو معطلاً.

الأسباب الشائعة لضعف INP: JavaScript الثقيل الذي يعطِّل الخيط الرئيسي (main thread)، والسكريبتات الكبيرة من أطراف ثالثة، ومعالجات الأحداث (event handlers) غير الفعّالة، وغياب استخدام request idle callback. أصلح INP من خلال: تقسيم مهام JavaScript الطويلة إلى أجزاء أصغر، وتأجيل JavaScript غير الحرج، وإزالة السكريبتات غير المستخدمة، وتحسين مستمعي الأحداث (event listeners)، واستخدام web workers للمهام كثيفة الحساب.

غالباً ما يكون INP أصعب مقاييس Core Web Vitals تحسيناً لأنه يتطلب خبرة في JavaScript. إذا كان فريقك يفتقر إلى مهارات تحسين JavaScript، فكِّر في الاستعانة باستشاري أداء أو استخدام خدمة تحسين أداء من طرف ثالث.

كيف تُقاس Core Web Vitals

تُقاس Core Web Vitals بطريقتين: بيانات المختبر وبيانات الميدان. تأتي بيانات المختبر من أدوات مثل PageSpeed Insights وLighthouse التي تعمل في بيئة مضبوطة. تأتي بيانات الميدان من مستخدمين حقيقيين يزورون موقعك. تُعطي Google الأولوية لبيانات الميدان لأنها تمثل تجربة المستخدم الفعلية.

يشرح مسار التعلم الخاص بالأداء من Google الفرق بين مقاييس المختبر ومقاييس الميدان. تساعدك بيانات المختبر على تحديد المشكلات واختبار الإصلاحات. تُظهر بيانات الميدان الأداء في العالم الحقيقي. قد تحصل على نتائج مختبر ممتازة لكن نتائج ميدان ضعيفة إذا كان مستخدموك الحقيقيون يستخدمون شبكات بطيئة أو أجهزة قديمة.

يُبلِّغ Google Search Console عن بيانات ميدان Core Web Vitals. يعرض التقرير قياسات مستخدمين حقيقيين مجمَّعة من تقرير Chrome User Experience Report (CrUX). إذا لم تكن لدى موقعك بيانات مستخدمين حقيقيين كافية، توفر Google بدلاً من ذلك بيانات مختبر من Lighthouse.

المعايير المرجعية ونتائج الاجتياز

تُعرِّف Google Core Web Vitals "الجيدة" بأنها تلك التي تحقق المئين الخامس والسبعين (75th percentile) من تجربة المستخدم. هذا يعني أن 75% من المستخدمين الحقيقيين يختبرون موقعك عند الحد الأدنى أو أفضل منه. الحدود هي:

LCP: 2.5 ثانية أو أقل. CLS: 0.1 أو أقل. INP: 200 جزء من الألف من الثانية أو أقل. تم التحقق من هذه الحدود علمياً من خلال تحليل تريليونات من تفاعلات المستخدمين الحقيقيين. الصفحات التي تصل إلى هذه الحدود أو تتجاوزها توفر تجربة مستخدم جيدة.

مع ذلك، لا تشترط Google أن تجتاز 100% من صفحاتك Core Web Vitals. إذا اجتازت 75% من صفحاتك، يُعتبر موقعك ذا Core Web Vitals "جيدة" إجمالاً. هذا يعني أنه يمكن أن يكون لديك بعض الصفحات الأبطأ وتظل مجتازاً إذا كانت معظم صفحات حركة المرور لديك سريعة.

تحسين كل مقياس: خطوات عملية

لتحسين LCP: أولاً، قس TTFB (Time to First Byte) الخاص بك باستخدام PageSpeed Insights. إذا كان TTFB بطيئاً (فوق 600 جزء من الألف من الثانية)، فإن الخادم لديك هو نقطة الاختناق. طوِّر الاستضافة (hosting)، أو حسِّن كود الواجهة الخلفية (backend)، أو استخدم شبكة توصيل محتوى (Content Delivery Network / CDN). إذا كان TTFB جيداً لكن LCP بطيء، فإن CSS أو JavaScript لديك يعطِّل العرض. أجِّل JavaScript غير الحرج وضمِّن CSS الحرج داخل الصفحة (inline) للمحتوى الظاهر أعلى الطية (above the fold).

لتحسين CLS: افحص موقعك بحثاً عن العناصر التي تتحرك أثناء التحميل. استخدم DevTools الخاصة بالمتصفح لتحديد العناصر المتحركة. أضف خصائص width وheight إلى كل صورة. استخدم font-display: swap في CSS. احجز مساحة للإعلانات والعناصر المضمَّنة والمحتوى الديناميكي.

لتحسين INP: استخدم تبويب Performance في Chrome DevTools لتحديد مهام JavaScript الطويلة (المهام التي تستغرق أكثر من 50 جزءاً من الألف من الثانية). قسِّم المهام الطويلة. أجِّل JavaScript غير الحرج. استخدم requestIdleCallback للمهام منخفضة الأولوية. اختبر على أجهزة حقيقية، لا على أجهزة الحاسوب المكتبي فقط.

مراقبة Core Web Vitals مع مرور الوقت

استخدم Google Search Console لمراقبة أداء Core Web Vitals. يعرض تقرير Core Web Vitals مقاييس المستخدمين الحقيقيين لموقعك وكيف تقارن بحدود Google. تُصنَّف الصفحات بأنها جيدة، أو بحاجة إلى تحسين، أو ضعيفة.

أعدِّ تنبيهات مراقبة. إذا تراجعت Core Web Vitals لديك، فعليك التحقيق في الأمر فوراً. قد تشمل الأسباب: عمليات نشر كود جديدة أدخلت عدم كفاءة، أو سكريبتات جديدة من طرف ثالث، أو تغييرات في الصور أو الوسائط، أو مشكلات في الاستضافة (hosting).

راقب الجوَّال مقابل سطح المكتب بشكل منفصل. عادة ما تكون معالجات الأجهزة الجوَّالة وشبكاتها أبطأ، لذلك غالباً ما تكون Core Web Vitals أسوأ على الجوَّال منها على سطح المكتب. أعطِ الأولوية لتحسين تجربة الجوَّال للمواقع ذات حركة مرور جوَّالة مهمة.

Core Web Vitals واستراتيجية السيو

أصبحت Core Web Vitals الآن عامل ترتيب أساسياً، تضاهي أهميته أهمية الروابط الخلفية وجودة المحتوى. من غير المرجَّح أن تُرتَّب المواقع ذات Core Web Vitals الضعيفة ترتيباً جيداً، بغض النظر عن جودة محتواها. هذا يعني أن تحسين الأداء يجب أن يكون جزءاً من استراتيجية السيو لديك، لا فكرة لاحقة.

إذا كنت تتنافس على الترتيب وكان منافسوك يتمتعون بـ Core Web Vitals أفضل، فإن لديهم ميزة في الترتيب. لا يمكنك الفوز بالمحتوى وحده إذا كان موقعك بطيئاً وغير مستجيب. عليك مضاهاة أداء المنافسين أو تجاوزه للتنافس على قدم المساواة.

الخلاصة

أصبحت Core Web Vitals الآن أساسية لنجاح السيو. تحسين LCP وCLS وINP يحسِّن مباشرة ترتيب موقعك في نتائج البحث وتجربة المستخدم. المواقع ذات Core Web Vitals الممتازة تتفوق في الترتيب على مواقع بمستوى ملاءمة مماثل لكنها ذات مقاييس ضعيفة. لا مفر من ذلك: إذا أردت ترتيباً متقدماً، عليك اجتياز Core Web Vitals.

ابدأ بتشغيل PageSpeed Insights على صفحاتك الرئيسية. حدِّد أكبر نقاط الاختناق لديك وأصلحها أولاً. أعطِ الأولوية لتحسين تجربة الجوَّال. راقب الأداء بانتظام في Google Search Console. استخدم تدقيق GEO SEO الخاص بنا لتحديد مشكلات Core Web Vitals في موقعك بأكمله وتتبُّع التحسينات مع مرور الوقت.