Core Web Vitals هي ثلاثة مقاييس محددة يستخدمها جوجل لقياس كيفية تجربة المستخدمين الحقيقيين لموقعك. تتتبع سرعة التحميل (LCP)، والاستجابة للتفاعل (INP)، والثبات البصري (CLS). جعلها جوجل إشارة ترتيب في 2021، وظلت جزءاً من الخوارزمية منذ ذلك الحين. لن تقرر وحدها موقع ترتيبك، لكن عندما تتقارب صفحتان في كل شيء آخر، تحصل الصفحة ذات المؤشرات الأفضل على الأفضلية.
معظم الأدلة في هذا الموضوع مكتوبة للمطورين. هذا الدليل ليس كذلك. إذا كنت صاحب عمل أو مدير تسويق يحتاج إلى فهم معنى هذه المقاييس، وهل يجتازها موقعك، وأي الإصلاحات تستحق الأولوية، فأنت في المكان الصحيح. سنُبقي التفاصيل التقنية عند حد ما هو مفيد فعلاً لاتخاذ القرارات لا لتنفيذ الشيفرة.
ما هي Core Web Vitals؟
Core Web Vitals مجموعة فرعية من إشارات تجربة الصفحة الأوسع لدى جوجل. قدمها جوجل في 2020 وأدرجها في خوارزمية الترتيب ضمن تحديث تجربة الصفحة منتصف 2021. الفكرة مباشرة: يريد جوجل مكافأة المواقع الممتعة فعلاً في الاستخدام، لا المحسّنة للكلمات المفتاحية فحسب.
هناك ثلاثة مقاييس، يقيس كل منها بعداً مختلفاً من تجربة المستخدم:
Largest Contentful Paint (LCP) – سرعة تحميل المحتوى الرئيسي
Interaction to Next Paint (INP) – سرعة استجابة الصفحة عند تفاعل شخص معها
Cumulative Layout Shift (CLS) – مدى ثبات التخطيط أثناء تحميل الصفحة
هذا كل شيء. ثلاثة أرقام. لكل منها حد يجب بلوغه، ويقيّم جوجل أداءك بناءً على بيانات مستخدمين حقيقيين من تقرير Chrome User Experience Report (CrUX)، لا على محاكاة مخبرية.
من المفيد معرفة أمر منذ البداية: يقيّم جوجل هذه المقاييس عند المئين الخامس والسبعين (p75) من جميع زيارات الصفحة. أي أن 75% من زوارك يجب أن يحصلوا على تجربة “جيدة” كي تجتاز الصفحة. لا يكفي أن تُحمَّل الصفحة سريعاً على حاسوبك عبر إنترنت فائق السرعة. يجب أن تعمل جيداً لغالبية جمهورك الفعلي، بمن فيهم أصحاب الهواتف القديمة واتصالات 4G المتقطعة.
المقاييس الثلاثة في لمحة
| المقياس | ما يقيسه | الحد الجيد | الحد الضعيف |
|---|---|---|---|
| LCP (Largest Contentful Paint) | أداء التحميل – الوقت حتى اكتمال عرض أكبر عنصر مرئي | ≤ 2.5 ثانية | > 4.0 ثوانٍ |
| INP (Interaction to Next Paint) | الاستجابة – التأخير بين تفاعل المستخدم والاستجابة البصرية | ≤ 200 ملي ثانية | > 500 ملي ثانية |
| CLS (Cumulative Layout Shift) | الثبات البصري – مقدار الإزاحة غير المتوقعة للتخطيط أثناء التحميل | ≤ 0.1 | > 0.25 |
كل ما يقع بين “جيد” و”ضعيف” يصنف “يحتاج إلى تحسين”. نظام الإشارات الضوئية لدى جوجل بسيط: الأخضر جيد، والكهرماني يحتاج إلى تحسين، والأحمر ضعيف.
Largest Contentful Paint (LCP)
يقيس LCP الوقت الذي يستغرقه أكبر عنصر مرئي في الصفحة حتى يكتمل عرضه. عادة ما يكون صورة رئيسية أو كتلة نص كبيرة أو إطار غلاف فيديو، أي ما يشغل أكبر مساحة من الشاشة فوق خط الطي عند أول تحميل للصفحة.
الحد هو 2.5 ثانية منذ انتقال المستخدم إلى الصفحة. أقل من 2.5 ثانية جيد. وأكثر من 4 ثوانٍ ضعيف.
لماذا يهم LCP
LCP هو المقياس الذي يشعر به زوارك بشكل مباشر أكثر من غيره. إنه الفرق بين صفحة تظهر أمامك فوراً وأخرى يحدّق فيها الزائر في شاشة فارغة متسائلاً هل يضغط زر الرجوع. تُظهر بيانات جوجل باستمرار أن المستخدمين يهجرون الصفحات التي تتأخر في عرض محتوى ذي معنى. وهذه زيارات مفقودة وعملاء محتملون مفقودون وإيرادات مفقودة، بغض النظر عن ترتيبك.
ما الذي يسبب ضعف LCP
أربعة أمور مسؤولة عن معظم مشاكل LCP:
بطء استجابة الخادم (TTFB). إذا استغرق خادمك وقتاً طويلاً للرد على الطلب الأول، يتأخر كل شيء بعده. زمن أول بايت (TTFB) هو خط البداية لـ LCP. الاستضافة البطيئة أو الخادم المثقل أو غياب شبكة توصيل المحتوى (CDN) كلها قد تطيله.
الموارد المعيقة للعرض. ملفات CSS وJavaScript التي يجب على المتصفح تنزيلها ومعالجتها قبل عرض أي شيء على الشاشة. إذا كان موقعك يحمّل عشرات أوراق الأنماط والسكربتات قبل رسم أول بكسل، فسيتضرر LCP.
الصور غير المحسّنة. أكثر مشاكل LCP شيوعاً على الإطلاق. صورة رئيسية بحجم 3MB لم تُضغط أو تُقدَّم بصيغة حديثة (WebP أو AVIF) ستستهلك ميزانية LCP وحدها. وتقديم الصورة الضخمة نفسها للجوال وسطح المكتب يفاقم المشكلة.
العرض من جهة العميل. المواقع المبنية بأطر JavaScript التي تعرض المحتوى في المتصفح بدلاً من الخادم غالباً ما يكون LCP لديها أسوأ. فالمتصفح يجب أن ينزّل JavaScript وينفذها ثم يعرض المحتوى، بخطوات إضافية قبل ظهور أي شيء مرئي.
يرتبط LCP ارتباطاً وثيقاً بمقياسين آخرين ستراهما في تقارير Lighthouse: First Contentful Paint (FCP) الذي يقيس لحظة ظهور أول جزء من المحتوى، وTime to First Byte (TTFB) الذي يتتبع زمن استجابة الخادم الأولى. ليس أي منهما من Core Web Vitals، لكن كليهما يغذي LCP. إذا كان TTFB لديك بطيئاً، فسيكون LCP كذلك.
مكاسب سريعة لـ LCP
اضغط الصور وغيّر أحجامها، وقدمها بصيغة WebP أو AVIF
طبّق التحميل الكسول على الصور أسفل خط الطي (لكن لا تطبّقه أبداً على عنصر LCP نفسه)
استخدم CDN لتقليل أزمنة استجابة الخادم
حمّل عنصر LCP مسبقاً (أخبر المتصفح بإعطائه الأولوية)
أجّل JavaScript وCSS غير الحرجة
فكّر في العرض من جهة الخادم إذا كنت تستخدم إطاراً ثقيل الاعتماد على JavaScript
سنغطي تحسين سرعة الموقع بعمق أكبر في مقال مخصص. أما الآن، فهذه الإصلاحات الخاصة بمؤشرات الويب الأساسية هي التي تحرك نتائج LCP.
Interaction to Next Paint (INP)
يقيس INP مدى استجابة صفحتك عندما يفعل شخص شيئاً فعلاً: ينقر زراً، أو يلمس قائمة، أو يكتب في حقل نموذج. وتحديداً، يتتبع التأخير بين تفاعل المستخدم والمرة التالية التي يرسم فيها المتصفح تحديثاً بصرياً على الشاشة.
الحد هو 200 ملي ثانية. أقل من 200 ملي ثانية جيد. وأكثر من 500 ملي ثانية ضعيف.
حل INP محل FID في مارس 2024
إذا صادفت مقالات قديمة تشير إلى First Input Delay (FID)، فقد أُحيل ذلك المقياس إلى التقاعد. استبدل جوجل FID بـ INP في 12 مارس 2024.
السبب واضح: كان FID يقيس التأخير في أول تفاعل فقط. إذا نقر شخص زراً لحظة تحميل الصفحة وحدث تأخير، التقطه FID. لكن إذا كان كل تفاعل لاحق متثاقلاً، لم يكن FID يكترث. كان مقياساً لحدث واحد يحاول تمثيل تجربة المستخدم الكاملة، ولم يكن على قدر المهمة.
يصلح INP ذلك بقياس جميع التفاعلات طوال زيارة الصفحة بأكملها والإبلاغ عن الأسوأ (مع بعض التنعيم الإحصائي للصفحات كثيرة التفاعلات). إنه صورة أصدق بكثير عن مدى استجابة موقعك فعلياً في الاستخدام.
هذا التغيير فاجأ مواقع كثيرة. كان لدى كثير منها نتائج FID مريحة لكنها فشلت في INP لأن صفحاتها كانت متثاقلة بعد التحميل الأولي. وبعد عامين، يبقى INP أكثر مؤشرات الويب الأساسية فشلاً، مع نسبة كبيرة من المواقع لا تزال دون حد 200 ملي ثانية.
ما الذي يسبب ضعف INP
مشاكل INP تسببها JavaScript في الغالب الأعم. ثلاثة مكونات تشكل زمن استجابة كل تفاعل:
تأخير الإدخال. الوقت بين فعل المستخدم وبدء المتصفح في معالجته. إذا كان الخيط الرئيسي مشغولاً بتنفيذ JavaScript أخرى، ينتظر التفاعل في الطابور.
زمن المعالجة. المدة التي يستغرقها معالج الحدث في التنفيذ. الحسابات المعقدة أو التلاعب بـ DOM أو استدعاءات API المتزامنة أثناء معالجة الحدث كلها تطيله.
تأخير العرض. الوقت بين انتهاء معالج الحدث ورسم المتصفح للتحديث البصري. إعادة حسابات التخطيط وأعمال العرض بعد تشغيل معالج الحدث تضيف إليه.
ما الذي تنظر فيه لأجل INP
حدد مهام JavaScript طويلة التشغيل وفكّكها (أي مهمة تتجاوز 50 ملي ثانية تحجب الخيط الرئيسي)
قلل كمية JavaScript المحمّلة على الصفحة إجمالاً
أجّل سكربتات الأطراف الثالثة (التحليلات، ودجات الدردشة، سكربتات الإعلانات) التي تتنافس على وقت الخيط الرئيسي
استخدم web workers لنقل المعالجة الثقيلة خارج الخيط الرئيسي
دقق معالجات الأحداث بحثاً عن تعقيد غير ضروري
مؤشر بديل مفيد: يقيس Total Blocking Time (TBT) في Lighthouse إجمالي وقت حجب الخيط الرئيسي أثناء تحميل الصفحة. هو مقياس مخبري وليس من Core Web Vitals، لكنه يرتبط جيداً بـ INP. إذا كان TBT لديك مرتفعاً، فالأرجح أن INP كذلك.
INP هو المقياس الذي يتطلب غالباً مشاركة مطور لإصلاحه. إذا كان موقعك يعمل على WordPress بعشرات الإضافات، كل منها يضيف JavaScript الخاصة به، فالأرجح أن INP هو حيث ستعاني أكثر.
Cumulative Layout Shift (CLS)
يقيس CLS حركة التخطيط غير المتوقعة، تلك اللحظات التي توشك فيها على لمس رابط فتقفز الصفحة لأن إعلاناً حُمّل فوقه، أو ينزاح النص لأسفل لأن خطاً ويبياً اكتمل تنزيله. وهو درجة بلا وحدة تُحسب من مقدار المساحة المنزاحة من نافذة العرض ومسافة انزياحها.
الحد هو 0.1. أقل من 0.1 جيد. وأكثر من 0.25 ضعيف.
لماذا يثير CLS إحباط المستخدمين
الإزاحات التخطيطية هي المقياس الذي يلاحظه المستخدمون دون معرفة اسمه التقني. الجميع مر بتجربة مد يده نحو زر لينقر إعلاناً بالخطأ لأن الصفحة تحركت في اللحظة الأخيرة. أو قراءة مقال وفقدان الموضع لأن لافتة حُمّلت ودفعت النص لأسفل.
وهو ليس مجرد إزعاج. فعلى الجوال، حيث مساحة الشاشة ضيقة وأهداف اللمس صغيرة، تسبب الإزاحات نقرات خاطئة ترسل الناس إلى الصفحة الخطأ. وذلك يقوّض الثقة بسرعة.
الأسباب الشائعة لـ CLS
صور وفيديوهات بلا أبعاد. إذا لم تحدد خاصيتي العرض والارتفاع (أو تستخدم aspect-ratio في CSS)، فلن يعرف المتصفح كم يحجز من مساحة. وعندما يُحمَّل الوسيط، ينزاح كل ما تحته لأسفل.
الإعلانات والتضمينات المحمّلة ديناميكياً. خانات إعلانات الأطراف الثالثة معروفة بمشاكل CLS. فهي تحقن محتوى في الصفحة بعد العرض الأولي، دافعة كل شيء آخر من مكانه.
خطوط الويب المسببة لـ FOUT/FOIT. عندما يُحمَّل خط مخصص ويحل محل الخط الاحتياطي، قد يعاد تدفق النص إذا اختلف حجما الخطين. ومضة النص غير المنسق (FOUT) أو ومضة النص غير المرئي (FOIT) كلتاهما تسهمان في الإزاحة.
محتوى يُحقن فوق محتوى قائم. اللافتات أو إشعارات الكوكيز أو أشرطة التنبيه التي تدفع المحتوى لأسفل بعد اكتمال عرض الصفحة.
إصلاح CLS
حدد دائماً العرض والارتفاع صراحة للصور والفيديوهات
احجز مساحة لخانات الإعلانات والتضمينات الديناميكية عبر CSS
استخدم `font-display: swap` مع خطوط احتياطية متطابقة الحجم
تجنب إدراج محتوى فوق محتوى قائم بعد العرض الأولي
استخدم خصائص `contain` في CSS لعزل إعادة حسابات التخطيط
CLS غالباً أسهل المقاييس الثلاثة إصلاحاً لأن أسبابه بصرية وحلوله موثقة جيداً. ومعظم تحسينات CLS لا تحتاج حتى إلى مطور؛ فمحرر محتوى كفء يعرف إضافة أبعاد الصور يمكنه إحداث فرق قابل للقياس.
البيانات الميدانية مقابل المخبرية: لماذا يهم التمييز
هذا أمر تتخطاه معظم الأدلة أو تشرحه بطريقة لا تُفهم إلا لمن يفهمه سلفاً. لكنه مهم حقاً لكيفية تفسير نتائج مؤشراتك.
البيانات المخبرية تأتي من أدوات تحاكي تحميل الصفحة في بيئة محكومة. Lighthouse (المدمج في Chrome DevTools) وقسم المختبر في PageSpeed Insights كلاهما يولّدان بيانات مخبرية. تستخدم ملف جهاز ثابتاً واتصال شبكة مخنوقاً ومتصفحاً نظيفاً بلا إضافات. البيانات المخبرية متسقة وقابلة للتكرار، مما يجعلها مفيدة لتصحيح مشاكل محددة.
البيانات الميدانية تأتي من مستخدمين حقيقيين يزورون موقعك في العالم الحقيقي. يجمعها جوجل عبر تقرير Chrome User Experience Report (CrUX) الذي يجمّع بيانات أداء مجهولة الهوية من مستخدمي Chrome الموافقين على إحصاءات الاستخدام. تظهر البيانات الميدانية في Google Search Console وقسم الميدان في PageSpeed Insights ولوحة CrUX.
وهنا سبب أهمية التمييز: يستخدم جوجل البيانات الميدانية للترتيب، لا المخبرية.
قد تكون نتيجة Lighthouse لديك 95، لكن إذا كان مستخدموك الحقيقيون، أصحاب هواتف Android الأقدم، ومَن لديهم ثلاث تبويبات مفتوحة وإشارة جوال متقطعة، يحصلون على أزمنة تحميل بطيئة، فذلك ما يراه جوجل. البيانات المخبرية أداة التصحيح لديك. والبيانات الميدانية هي شهادة تقييمك.
هذا يفاجئ الناس باستمرار. يشغّل مطور Lighthouse فيرى نتيجة فوق 90 ويعلن أن الموقع بخير. وفي الوقت نفسه يعلّم Google Search Console عشرات الصفحات بضعف LCP لأن الجمهور الحقيقي يستخدم أجهزة واتصالات أبطأ من جهاز المطور. مصدرا البيانات لا يتناقضان؛ إنهما يقيسان شيئين مختلفين.
هذا يعني أيضاً أنك تحتاج زيارات كافية كي تتوفر لدى جوجل بيانات ميدانية عن صفحاتك. الصفحات الأحدث أو الأقل زيارات قد لا تملك بيانات CrUX أصلاً، وحينها يرجع جوجل إلى بيانات مستوى الأصل (أداء موقعك الإجمالي عبر كل الصفحات). وإذا كان موقعك جديداً كلياً أو يستقبل زيارات Chrome قليلة جداً، فقد لا يملك جوجل بيانات كافية لتقييم مؤشراتك إطلاقاً. وليست تلك مشكلة بالضرورة؛ إنما تعني أن المؤشرات لن تكون عاملاً في ترتيبك حتى تتوفر البيانات.
أي أداة تعرض ماذا
| الأداة | نوع البيانات | الأفضل لـ |
|---|---|---|
| Google Search Console | ميدانية (CrUX) | مراقبة حالة المؤشرات على مستوى الموقع؛ معرفة الصفحات الناجحة والفاشلة |
| PageSpeed Insights | كلاهما (ميدانية + مخبرية) | تشخيص صفحات محددة؛ الميدانية للأداء الحقيقي والمخبرية لتوصيات قابلة للتنفيذ |
| Lighthouse (Chrome DevTools) | مخبرية فقط | تصحيح مشاكل محددة في بيئة محكومة |
| لوحة Performance في Chrome DevTools | مخبرية (محلية) | تصحيح معمق للتفاعلات الفردية والإزاحات التخطيطية |
| لوحة CrUX (عبر BigQuery أو Data Studio) | ميدانية | تحليل الاتجاهات؛ تتبع الأداء بمرور الوقت |
| إضافة Web Vitals لمتصفح Chrome | لحظية (جهازك) | فحوص سريعة أثناء تصفح موقعك |
لمعظم أصحاب الأعمال ومديري التسويق، Google Search Console وPageSpeed Insights هما الأداتان المهمتان. الأولى تخبرك أي الصفحات تجتاز وأيها تفشل. والثانية تخبرك لماذا.
كم تؤثر Core Web Vitals على الترتيب؟
هذا هو السؤال الذي يريد الجميع إجابته، والإجابة الصادقة: أقل مما قيل لك على الأرجح، وأكثر مما ينبغي تجاهله.
أكد جوجل أن Core Web Vitals إشارة ترتيب. لكنه أوضح أيضاً أن صلة المحتوى وجودته وسلطته لا تزال أثقل وزناً بكثير. وقد دأب فريق Search Relations لدى جوجل على تأطير تجربة الصفحة كعامل ترجيح لا كعامل مهيمن؛ شيء يهم عندما تتقارب الإشارات الأخرى، لا شيء يتجاوزها.
فكّر فيها هكذا. إذا كان محتواك هزيلاً وملف روابطك الخلفية ضعيفاً واستهدافك للكلمات المفتاحية خاطئاً، فلن تنقذك مؤشرات مثالية. لكن إذا كنت في صفحة نتائج تنافسية تقدم فيها صفحات متعددة جودة محتوى وسلطة متقاربة، فالصفحة ذات مقاييس تجربة المستخدم الأفضل تملك أفضلية.
المعنى العملي: لا تُصب بالذعر بشأن Core Web Vitals إذا كانت لديك مشاكل سيو أكبر تحتاج حلاً أولاً. أصلح محتواك. ابنِ سلطتك. رتّب أسس السيو التقني لديك. ثم حسّن المؤشرات. لكن لا تتجاهلها أيضاً، خصوصاً إذا كنت منافساً بالفعل وتبحث عن كل أفضلية ممكنة.
الجوال مقابل سطح المكتب: تقييمان منفصلان
يقيّم جوجل Core Web Vitals بشكل منفصل للجوال وسطح المكتب. قد يجتاز موقعك المقاييس الثلاثة على سطح المكتب ويفشل على الجوال، أو العكس. وبما أن جوجل يعتمد الفهرسة بأولوية الجوال، فأداء الجوال هو الأهم للبحث.
هنا تتعثر مواقع كثيرة. الصفحات التي تبدو سريعة على MacBook Pro لدى المطور قد تكون بطيئة بشكل مؤلم على هاتف Android متوسط باتصال 4G. فجوة قدرة المعالجة كبيرة؛ إذ يستطيع هاتف رائد معالجة JavaScript أسرع بعدة مرات من جهاز Android اقتصادي. ومستخدمو Android الاقتصادي غالباً هم غالبية جمهورك على الجوال.
الاختبار على سطح المكتب وحده يعطي صورة مضللة. افحص دائماً بياناتك الميدانية للجوال في Search Console؛ فتلك النسخة التي يهتم بها جوجل. وإذا أردت محاكاة تجربة أكثر واقعية في المختبر، يساعد الخنق الافتراضي في Lighthouse، لكنه حتى هو متساهل مقارنة بما يعيشه كثير من المستخدمين الحقيقيين.
أي مقياس تصلح أولاً؟
إذا فشل موقعك في أكثر من مؤشر، فأنت بحاجة إلى إطار أولويات. إصلاح كل شيء دفعة واحدة غير واقعي، وبعض التحسينات تحقق أثراً أكبر من غيرها.
ابدأ بالمقياس الذي تفشل فيه أكثر الصفحات
افتح Google Search Console، وانتقل إلى تقرير Core Web Vitals، وانظر إلى تبويب الجوال. أي مقياس لديه أكبر عدد من الروابط في “ضعيف” أو “يحتاج إلى تحسين”؟ تلك نقطة انطلاقك، ليس لأنه الأهم بمعزل عن غيره، بل لأن إصلاح المشكلة الأوسع انتشاراً يرفع أكبر عدد من الصفحات.
ثم رتّب حسب الجهد مقابل الأثر
CLS عادة المكسب الأسرع. إضافة أبعاد الصور وحجز مساحة الإعلانات وإصلاح تحميل الخطوط تغييرات مباشرة نسبياً. إذا كان CLS مشكلتك، فكثيراً ما يمكنك إصلاحه في أيام لا أسابيع.
تحسينات LCP تميل إلى إحداث الأثر الملموس الأكبر. الصفحة الأسرع تحميلاً يلاحظها الجميع: مستخدموك وفريقك ومعدل تحويلك. تحسين الصور وترقية الخوادم وتطبيق CDN حلول مفهومة جيداً بنتائج متوقعة.
INP عادة الأصعب إصلاحاً. يتطلب تحسين JavaScript، أي وقت مطور وربما تغييرات معمارية. إذا كان INP مشكلتك الرئيسية، فتوقع وقتاً أطول وخطط للميزانية وفق ذلك.
مصفوفة الأولويات
| السيناريو | أصلح أولاً | لماذا |
|---|---|---|
| CLS يفشل والبقية سليمة | CLS | إصلاح سريع بأثر مستخدم غير متناسب |
| LCP يفشل والبقية سليمة | LCP | أكبر تحسن ملموس مع حلول مفهومة جيداً |
| INP يفشل والبقية سليمة | INP | الخيار الوحيد، لكن خطط لاستثمار في التطوير |
| عدة مقاييس تفشل | CLS ← LCP ← INP | المكاسب الأسهل أولاً لبناء الزخم ثم التعقيد أخيراً |
| الكل يجتاز بالكاد | LCP | الأرجح انزلاقاً إلى “يحتاج إلى تحسين” في الظروف الحقيقية |
هذه ليست قاعدة صارمة. إذا كان LCP لديك 2.6 ثانية (يفشل بالكاد) بينما INP لديك 800 ملي ثانية (في عمق المنطقة الحمراء)، فاقلب الترتيب. السياق هو الفيصل.
كيف تراقب Core Web Vitals
فحص نتائجك مرة والانصراف لا يكفي. تتغير Core Web Vitals بمرور الوقت مع إضافة المحتوى وتحديث الإضافات وتشغيل حملات إعلانية جديدة ودفع تغييرات الشيفرة. المراقبة المستمرة تلتقط التراجعات قبل أن تمس الترتيب.
Google Search Console (لوحتك الأساسية)
يجمّع تقرير Core Web Vitals في Search Console روابطك في جيد ويحتاج إلى تحسين وضعيف، للجوال وسطح المكتب. ويتحدث مع جمع جوجل بيانات ميدانية جديدة، أي أن تغييرات اليوم لن تظهر فوراً؛ توقع نافذة متحركة من 28 يوماً قبل انعكاس التحسينات.
وعندما تصلح مشكلة، استخدم زر “التحقق من الإصلاح” في Search Console. سيعيد جوجل تقييم الروابط المتأثرة ويؤكد نجاح الإصلاح.
مراقبة المستخدم الحقيقي (RUM)
للمواقع الأكبر، توفر أدوات مراقبة المستخدم الحقيقي بيانات أدق من CrUX وحده. تعمل سكربتات RUM على صفحاتك الحية وتجمع بيانات أداء من كل زائر، مانحة إياك تغذية راجعة أسرع وتفصيلاً أدق حسب نوع الصفحة والجهاز والجغرافيا ومصدر الزيارات. أدوات مثل SpeedCurve وDebugBear وVercel Analytics تقدم لوحات RUM مصممة خصيصاً حول Core Web Vitals.
أعد تنبيهات
إذا كان نظام إدارة المحتوى أو مزود الاستضافة لديك يوفر مراقبة أداء، فاضبط حدوداً تطلق تنبيهات قبل عبورك من “جيد” إلى “يحتاج إلى تحسين”. التقاط تراجع عند LCP يساوي 2.3 ثانية أفضل من اكتشافه عند 3.5 ثانية في مراجعتك الشهرية التالية.
راقب التراجعات بعد التغييرات
أكثر أوقات تدهور Core Web Vitals شيوعاً هي بعد تغيير في الموقع: تحديث نظام إدارة المحتوى، أو إضافة جديدة، أو تجديد تصميم، أو سكربت طرف ثالث أضافه أحد أفراد فريق التسويق. كل من هذه قد يُدخل موارد جديدة معيقة للعرض أو JavaScript أثقل أو عناصر مزيحة للتخطيط دون أن يدرك أحد.
أدرج فحوص المؤشرات في عملية النشر لديك. حتى اختبار سريع على PageSpeed Insights قبل تغيير كبير وبعده يمكن أن يلتقط المشاكل قبل بلوغها بياناتك الميدانية. فبحلول ظهور التراجع في Search Console، يكون قد أثّر على مستخدميك لأسابيع بالفعل.
Core Web Vitals والصورة الأشمل للسيو
لا توجد Core Web Vitals بمعزل عن غيرها. فهي جزء من مجموعة أوسع من إشارات تجربة الصفحة التي يراعيها جوجل، إلى جانب أمان HTTPS وملاءمة الجوال وغياب النوافذ البينية المتطفلة (تلك النوافذ المنبثقة بملء الشاشة التي تحجب المحتوى). أدرج جوجل كل هذه في تحديث تجربة الصفحة عام 2021، وإن كانت Core Web Vitals هي إشارات تجربة الصفحة الوحيدة التي تغذي الترتيب مباشرة.
لكن حتى بالنظر من مسافة أبعد، تجربة الصفحة نفسها مجرد عامل من عوامل ترتيب كثيرة. جودة المحتوى وسلطة الروابط الخلفية والصلة الموضوعية وإشارات E-E-A-T ومئات العوامل الأخرى تلعب كلها دوراً. المواقع التي تتصدر هي التي تصيب في معظم هذه الأمور، لا التي تهووس بمقياس واحد وتهمل كل شيء آخر.
ومع ذلك، لمؤشرات الويب الأساسية أثر غير مباشر يتجاوز وزنها الترتيبي المباشر. فالموقع الأسرع والأكثر استجابة وثباتاً يُبقي المستخدمين على الصفحة أطول ويقلل معدلات الارتداد ويحسّن معدلات التحويل. قد لا تكون إشارات سلوك المستخدم هذه عوامل ترتيب مباشرة، لكنها تؤثر على نتائج الأعمال التي يسعى السيو في النهاية إلى تحقيقها. إصلاح مؤشراتك نادراً ما يكون جهداً مهدوراً، حتى لو كانت دفعة الترتيب متواضعة.
إذا كنت تفكر في استراتيجية السيو لديك بشكل شمولي، فإن Core Web Vitals تقع في خانة “الأسس التقنية”. إنها من الأشياء التي ينبغي أن تكون صحيحة، مثل امتلاك شهادة أمان أو تخطيط ملائم للجوال، لا الشيء الذي تبني حوله استراتيجيتك بأكملها.
ضبط مؤشراتك بشكل صحيح
لمعظم الأعمال، تقع Core Web Vitals في إحدى فئتين: إما أن موقعك يجتازها وتحتاج فقط إلى مراقبتها، أو لا يجتازها وتحتاج من يشخّص المشاكل ويصلحها.
إذا كنت في الفئة الثانية ولست متأكداً من أين تبدأ، فهذه بالضبط نوعية المشاكل التي صُمم تدقيق السيو التقني لحلها. في Gorilla Marketing، ندرج تشخيص Core Web Vitals في كل تدقيق تقني: ليس النتائج فحسب، بل قائمة أولويات بما يجب إصلاحه ولماذا يهم وما الأثر المتوقع. يعمل استراتيجيون كبار مباشرة على كل حساب، مترجمين بيانات الأداء إلى توصيات بلغة واضحة يستطيع فريق التطوير لديك تنفيذها. إذا أردت تقييماً صريحاً لوضع موقعك، تواصل معنا.
