Core Web Vitals، أو مؤشرات أداء الويب الأساسية، ثلاثة مقاييس تقيّم جوانب محددة من تجربة استخدام الصفحة: سرعة ظهور المحتوى الرئيسي، والاستجابة للتفاعلات، وثبات العناصر بصريًا. وتشمل LCP وINP وCLS، وفق التعريف الرسمي لمبادرة Web Vitals. وهي ليست درجة واحدة لسرعة الموقع، ولا تغطي بمفردها جميع جوانب تجربة المستخدم.
لتحسين هذه المؤشرات، ابدأ بتحديد المقياس المتأثر والبيانات التي تقرؤها، ثم ابحث عن سبب يمكن إثباته. ضغط الصور قد يساعد في مشكلة تحميل، لكنه لا يفسر تلقائيًا تأخر استجابة زر أو تحرك النص أثناء القراءة. لذلك يختلف مسار الإصلاح بحسب المشكلة، وليس بحسب قائمة إعدادات موحدة لجميع المواقع.
تاريخ النشر: 30 سبتمبر 2026.
انتقل مباشرة إلى: المقاييس والقيم الجيدة · طريقة الفحص · تحسين LCP · تحسين INP · تحسين CLS · التحقق من الإصلاح.
ما مقاييس Core Web Vitals، وما القيم الجيدة؟
تُصنَّف نتائج المؤشرات إلى «جيد» و«يحتاج إلى تحسين» و«ضعيف». ويوضح الجدول حدود كل فئة وفق منهجية تحديد حدود مؤشرات أداء الويب الأساسية وتصنيفات PageSpeed Insights:
| المقياس | جيد | يحتاج إلى تحسين | ضعيف |
|---|---|---|---|
| LCP | 2.5 ثانية أو أقل | أكثر من 2.5 وحتى 4 ثوانٍ | أكثر من 4 ثوانٍ |
| INP | 200 مللي ثانية أو أقل | أكثر من 200 وحتى 500 مللي ثانية | أكثر من 500 مللي ثانية |
| CLS | 0.1 أو أقل | أكثر من 0.1 وحتى 0.25 | أكثر من 0.25 |
LCP: متى يظهر أكبر محتوى مرئي؟
يقيس Largest Contentful Paint الوقت حتى عرض أكبر عنصر محتوى مؤهل داخل المساحة المرئية من الصفحة. قد يكون صورة رئيسية أو كتلة نصية، وليس بالضرورة الصورة الأولى في الكود. وهو لا يقيس اكتمال تحميل جميع ملفات الصفحة، كما يختلف عن FCP الذي يتعلق بظهور أول محتوى. يشرح دليل LCP العناصر التي تدخل في القياس وكيفية تحديدها.
INP: هل تستجيب الصفحة بسرعة عندما تستخدمها؟
يقيس Interaction to Next Paint التأخر من بدء تفاعل مؤهل، مثل النقر أو الضغط على مفتاح، حتى عرض الإطار التالي. ويراقب التفاعلات خلال الزيارة، ثم يعكس أبطأها مع معالجة بعض القيم الشاذة؛ فهو ليس متوسط زمن التفاعلات ولا تأخر أول نقرة فقط. والتمرير أو مرور المؤشر وحدهما ليسا من التفاعلات المقاسة، وفق تعريف INP.
حلّ INP محل FID ضمن المؤشرات الأساسية في 12 مارس 2024، بحسب إعلان Google. لذلك لا تعتمد على دليل ما زال يعرض FID باعتباره مقياس الاستجابة المستخدم في المجموعة الحالية.
CLS: هل تتحرك العناصر بصورة غير متوقعة؟
يقيس Cumulative Layout Shift عدم الاستقرار البصري، مثل انتقال فقرة أو زر عندما يظهر إعلان فوقه. قيمته بلا وحدة؛ فـ0.1 ليست ثانية ولا نسبة مئوية. ويعتمد الحساب على أكبر مجموعة من الإزاحات غير المتوقعة المتقاربة زمنيًا، وليس جمعًا مفتوحًا لكل حركة طوال الزيارة. يوضح دليل CLS قواعد القياس والاستثناءات.
متى تجتاز الصفحة التقييم؟ وما معنى المئين 75؟
لا يُحكم على تجربة الزوار من اختبار واحد. تُقارن الحدود بالقيمة عند المئين الخامس والسبعين، أو p75: القيمة التي تقع عندها أو دونها نحو 75% من القياسات المرتبة. ويُحسب ذلك لكل مقياس على حدة، مع فصل الجوال عن سطح المكتب، كما توضح إرشادات تقييم Web Vitals. ولا يعني المصطلح أن 75% من صفحات موقعك سريعة.
عندما تتوافر بيانات كافية للمؤشرات الثلاثة، يتطلب اجتياز تقييم PageSpeed Insights أن تكون قيم p75 جميعها جيدة. مثال افتراضي: إذا كان LCP يساوي 2.2 ثانية، وINP يساوي 320 مللي ثانية، وCLS يساوي 0.06، فلن يجتاز التقييم؛ لأن INP يحتاج إلى تحسين رغم جودة المقياسين الآخرين.
هناك استثناء مهم في قواعد تقييم PageSpeed: عند عدم كفاية بيانات INP، يمكن الاجتياز إذا كان LCP وCLS جيدين. أما عدم كفاية بيانات أحد هذين المقياسين فيمنع إجراء التقييم. لذلك غياب قيمة INP لا يعني الفشل تلقائيًا.
هل تؤثر Core Web Vitals في ترتيب Google؟
نعم؛ تؤكد Google أن أنظمة الترتيب تستخدم Core Web Vitals. لكنها توضح أيضًا أن النتائج الجيدة لا تضمن تصدر البحث، وأن تجربة الصفحة أوسع من هذه الأرقام. كما أن محاولة الوصول إلى درجة مثالية لأسباب تتعلق بالسيو وحده قد لا تكون أفضل استخدام للوقت، وفق إرشادات تجربة الصفحة في بحث Google.
تعامل معها باعتبارها جزءًا من تحسين موقع مفيد وسهل الاستخدام، لا بديلًا عن محتوى يجيب عن طلب الباحث. والهدف العملي هو إزالة التأخيرات والإزاحات التي يواجهها الناس، لا حذف وظائف مهمة للحصول على تقرير أخضر.
لماذا تختلف نتيجة Core Web Vitals عن درجة PageSpeed؟
تعرض PageSpeed Insights نوعين مختلفين من البيانات. البيانات الميدانية تصف تجارب فعلية جُمعت من زيارات المستخدمين، بينما البيانات المختبرية تنتج من اختبار في ظروف محددة. الأولى تساعدك على معرفة ما واجهه الزوار، والثانية تساعدك على إعادة إنتاج المشكلة وتشخيصها. ويوضح شرح اختلاف بيانات المختبر والميدان لماذا يمكن أن تختلف النتيجتان دون أن تكون إحداهما خاطئة.
تأتي البيانات الميدانية في PageSpeed من تقرير تجربة مستخدم Chrome، أو CrUX. وهي ليست قياسًا لكل زائر على كل متصفح؛ إذ تخضع لشروط أهلية تخص المستخدمين والصفحات والمنصات، بحسب منهجية CrUX.
أما درجة Performance من 100 فتنتج من تجميع مقاييس اختبار Lighthouse بأوزان محددة، وفق طريقة احتساب الدرجة. لذلك قد تبدو الدرجة جيدة بينما تكشف التجارب الفعلية مشكلة في الاستجابة أو تحرك المحتوى بعد التحميل.
إذا اختلفت النتائج، قارن الجهاز وفترة القياس وطريقة الاستخدام. قد يزور المستخدم الصفحة من هاتف أضعف، أو يتفاعل مع قائمة لم يفتحها الاختبار، أو يشاهد محتوى مختلفًا. لا تستخدم إعادة تشغيل الاختبار حتى تظهر نتيجة جميلة دليلًا على إصلاح المشكلة؛ ابحث عن تفسير يمكن إعادة اختباره.
طريقة فحص Core Web Vitals خطوة بخطوة
اختر صفحات تمثل القوالب المهمة: مقالًا، وصفحة خدمة، وصفحة منتج أو تصنيف عند وجود متجر. لا تكتفِ بالرئيسية؛ فالهدف تحديد أين تقع المشكلة وما إذا كان سببها مشتركًا. ويتوافق هذا المسار مع منهج استخدام أدوات Google لقياس المؤشرات وتحسينها.
ابدأ بعنوان صفحة في PageSpeed Insights
- افتح PageSpeed Insights، وأدخل عنوان الصفحة، ثم اضغط «تحليل» أو Analyze.
- اختر الجوال أو سطح المكتب، وسجّل اختيارك حتى تقارن النتائج على الجهاز نفسه.
- اقرأ قسم تجربة المستخدمين الفعليين، وتحقق هل البيانات تخص عنوان الصفحة أم الأصل Origin.
- سجّل المقياس المتأثر وقيمته وفترة البيانات المعروضة، بدل الاكتفاء بعبارة «لم يجتز التقييم».
- انتقل إلى نتائج المختبر، وافتح التحليلات المرتبطة بالمشكلة، مثل LCP breakdown أو Layout shift culprits عند ظهورها. يشرح دليل تحليلات الأداء وظيفة هذه النتائج.
عندما لا تكفي بيانات الصفحة، قد يعرض PageSpeed بيانات على مستوى الأصل بدلًا منها. لا تنسب هذه الأرقام إلى الصفحة وحدها. والأصل يتحدد بالبروتوكول واسم المضيف والمنفذ؛ لذلك https://example.com وhttps://shop.example.com ليسا أصلًا واحدًا، وفق تعريف Origin.
استخدم Search Console لمعرفة نطاق المشكلة
افتح تقرير «مؤشرات أداء الويب الأساسية»، ثم تقرير الجوال أو سطح المكتب، واختر المشكلة وافتح أمثلة عناوين URL. تجمع Search Console الصفحات المتشابهة في مجموعات؛ لذلك قد تختلف قيمة المجموعة عن نتيجة صفحة منفردة في PageSpeed. والتقرير ليس جردًا شاملًا لكل صفحة مفهرسة، كما توضح مساعدة تقرير Core Web Vitals.
اختبر أكثر من مثال داخل المجموعة قبل تعديل قالب كامل. إذا تكرر السبب نفسه، مثل مكوّن إعلان أو قائمة مشتركة، فاجعل الإصلاح على مستوى ذلك المكوّن، ثم راجع صفحات أخرى تستخدمه. أما اختلاف الأسباب فيحتاج إلى فصل المهام بدل افتراض حل واحد للمجموعة كلها.
ماذا تفعل عندما لا تتوافر بيانات؟
عدم توافر البيانات ليس نجاحًا أو فشلًا. قد تكون الصفحة حديثة أو لا تجمع عينة مؤهلة كافية. ولا تنشر Google رقمًا دقيقًا لحد الزوار اللازم للإدراج في CrUX، وفق شروط كفاية العينة. ابدأ بالاختبارات المحلية، لكن لا تعرض نتائجها باعتبارها بيانات فعلية لكل جمهورك.
وللتشخيص المتقدم، يمكن جمع بيانات مراقبة المستخدمين الفعليين RUM باستخدام حل تحليلي أو مكتبة web-vitals. تحتاج المكتبة إلى إرسال القياسات وتجميعها في نظام تقارير؛ فهي لا تنشئ لوحة تحليلات بمجرد إضافتها. كذلك يختلف توافر بعض القياسات بحسب دعم المتصفح للواجهات المطلوبة.
تحسين LCP: حدد أين يتأخر ظهور المحتوى
ابدأ بتحديد عنصر LCP الفعلي. افتح أدوات المطور في Chrome، ثم Performance، وسجّل إعادة تحميل الصفحة. راجع تحليل LCP breakdown لتعرف المرحلة التي تستغرق الوقت، بدل افتراض أن المشكلة حجم الصورة. يوضح توثيق تقسيم LCP أربع مراحل رئيسية:
| المرحلة | ماذا تعني؟ | ما الذي تفحصه؟ |
|---|---|---|
| TTFB | الوقت حتى وصول أول بايت من مستند HTML. | التحويلات، والاستجابة، والشبكة، والاستفادة من التخزين المؤقت. |
| تأخر بدء تحميل المورد | الفاصل قبل بدء طلب مورد LCP. | هل يُكتشف المورد متأخرًا أو ينتظر JavaScript؟ |
| مدة تحميل المورد | الوقت اللازم لتنزيل المورد نفسه. | حجم الملف، والصورة المناسبة للشاشة، وظروف النقل. |
| تأخر عرض العنصر | الانتظار بعد اكتمال المورد حتى ظهوره. | حجب العرض أو انشغال المتصفح أو إبقاء العنصر مخفيًا. |
إذا كان عنصر LCP نصًا لا يحتاج إلى مورد منفصل لعرضه، فقد تكون مرحلتا تحميل المورد صفريتين. أما ارتفاع TTFB فلا يثبت وحده أن شركة الاستضافة سيئة؛ فقد تشارك التحويلات أو بُعد الخادم أو ظروف الشبكة في التأخير. اربط التعديل بالسبب الذي تظهره الأدلة، كما يشرح دليل تحسين LCP.
عندما تكون صورة الشاشة الأولى هي عنصر LCP
تأكد من إمكانية اكتشاف الصورة مبكرًا، ولا تطبق عليها loading="lazy" إذا كانت مطلوبة فور فتح الصفحة. افحص الحاجة إلى fetchpriority="high" أو التحميل المسبق عندما يتأخر اكتشافها، وفق إرشادات اكتشاف مورد LCP. لا توزع الأولوية العالية على كل الصور أو تحمّل كل الموارد مسبقًا؛ حدد المورد المهم أولًا.
إذا كانت المشكلة مدة التنزيل، استخدم أبعادًا مناسبة للعرض وصورًا متجاوبة عبر srcset وsizes عند الحاجة، وراجع الضغط وصيغًا مثل WebP أو AVIF. هذه إجراءات لتحسين نقل الصورة، كما يوضح دليل تحسين تسليم الصور؛ لكنها لا تعالج بمفردها تأخر الخادم أو انتظار اكتشاف الصورة.
كيف تعرف أن تعديل LCP نجح؟
أعد الاختبار في الظروف نفسها، وقارن المرحلة التي استهدفتها. إذا كان الإصلاح متعلقًا بالاكتشاف، فابحث عن بدء طلب الصورة أبكر؛ وإذا كان متعلقًا بحجمها، فقارن مدة نقلها. ثم راقب LCP نفسه وتأكد من سلامة التصميم. تحسن جزئية دون تحسن النتيجة قد يعني أن مرحلة أخرى أصبحت موضع التأخير.
تحسين INP: شخّص التفاعل البطيء، لا تحميل الصفحة فقط
اختبار تحميل لا ينفذ تفاعلات المستخدم لا يكشف تجربة INP كاملة. افتح لوحة Performance في Chrome، ثم جرّب النقر على القائمة أو الكتابة في البحث أو تغيير فلتر. تعرض اللوحة القياسات المحلية والتفاعلات المسجلة، وفق دليل لوحة Performance. ولتحليل أعمق، سجّل التفاعل ثم افحص تفاصيله.
يساعد تحليل INP breakdown على التمييز بين ثلاثة مواضع للتأخير. وهذا مهم لأن الزر الذي ضغطت عليه قد يكون ضحية عمل آخر يشغل المتصفح، وليس صاحب الكود المسبب للمشكلة.
| موضع التأخير | الدليل المحتمل | اتجاه الإصلاح |
|---|---|---|
| قبل بدء المعالجة | المتصفح مشغول بمهام أخرى عند حدوث التفاعل. | تقليل العمل المنافس، وفحص السكربتات التي تعمل في ذلك الوقت. |
| أثناء معالجة التفاعل | الكود المستجيب للنقرة أو الكتابة يستغرق وقتًا طويلًا. | تقليل العمل داخل معالج الحدث وتقسيم ما يمكن تقسيمه. |
| قبل عرض الإطار التالي | انتهت المعالجة لكن تحديث الواجهة ما زال متأخرًا. | تقليل تكلفة التخطيط والرسم وحجم التحديث المرئي. |
قلّل العمل الذي يمنع ظهور الاستجابة
عندما يثبت التسجيل وجود مهمة طويلة، اطلب تقليل العمل غير الضروري وتقسيم التنفيذ إلى مهام تسمح للمتصفح بمعالجة التفاعل وعرض النتيجة. ويمكن تأجيل الأعمال التي لا يحتاجها الإطار التالي، دون تعطيل الوظيفة الأساسية. يشرح دليل تحسين المهام الطويلة هذا المبدأ، بينما يربطه دليل تحسين INP بمعالجات الأحداث وتحديث الواجهة.
مثال تشخيصي: عند فتح فلتر منتجات، افحص هل التأخير يحدث قبل تشغيل كود الفلتر، أم أثناء معالجة النتائج، أم عند إعادة عرض قائمة كبيرة. تختلف المعالجة في كل حالة؛ لذلك لا تبدأ بضغط الصور أو شراء استضافة أعلى قبل تحديد الجزء البطيء.
كذلك لا تؤجل جميع ملفات JavaScript عشوائيًا. اختبر خصوصًا أول تفاعل بعد تفعيل أي إعداد لتأخير السكربتات؛ فقد تصبح النقرة نفسها نقطة بدء تحميل أو تنفيذ عمل ثقيل. احتفظ بالاعتماديات اللازمة، وقيّم سكربتات الأطراف الثالثة بحسب أثرها المثبت، لا بحسب مصدرها وحده.
ما دور TBT؟ وكيف تتحقق من الإصلاح؟
مقياس Total Blocking Time، أو TBT، يساعد في تشخيص انشغال المتصفح أثناء التحميل، وقد يرتبط تحسنه بتحسن الاستجابة. لكنه ليس INP ولا بديلًا مطابقًا له، وفق توثيق TBT. لا تعتبر انخفاضه إثباتًا كافيًا على أن جميع التفاعلات أصبحت سريعة.
أعد التفاعل نفسه بعد الإصلاح، ثم جرّب تفاعلات أخرى وأوقاتًا مختلفة أثناء التحميل وبعده. قارن الجزء الذي استهدفته، وتأكد من أن النقر والكتابة وإرسال النماذج ما زالت تعمل. وإذا كان الإجراء ينتظر طلب شبكة، فاختبر وضوح استجابة الواجهة أيضًا؛ INP لا يقيس مدة اكتمال العملية البعيدة كلها.
تحسين CLS: امنع السبب الذي يدفع المحتوى إلى التحرك
لا تكتفِ بإعادة تحميل الصفحة ثم التوقف. سجّل استخدامها في لوحة Performance، وراقب مسار Layout shifts أثناء ظهور الصور والإعلانات والتضمينات. افتح الإزاحة لرؤية العناصر المتحركة وتوقيتها؛ يشرح دليل تشخيص إزاحات التخطيط كيف تتتبع المشكلة، بما فيها الإزاحات التي تحدث بعد التحميل الأول.
العنصر المتحرك ليس بالضرورة سبب المشكلة. قد يحدد التقرير فقرة انتقلت إلى أسفل، بينما السبب صورة أو إعلان أُضيف فوقها. وتقدم نتيجة Layout shift culprits أسبابًا محتملة تحتاج إلى فحص، لا حكمًا نهائيًا يغني عن مشاهدة ما حدث.
احجز المساحة قبل وصول المحتوى
للصور والفيديو والتضمينات، حدّد الأبعاد أو نسبة الأبعاد المناسبة حتى يعرف المتصفح المساحة المطلوبة قبل اكتمال التحميل. أما الإعلانات والمكوّنات الديناميكية، فاحجز لها مساحة تتوافق مع تصميم الشاشة والأحجام المتوقعة، وفق إرشادات تحسين CLS.
لا تفرض ارتفاعًا واحدًا على كل المواضع والأجهزة. اختبر حالة ظهور إعلان صغير أو كبير، وحالة عدم وصول إعلان، وتجنب انهيار المساحة المحجوزة بما يدفع المحتوى للتحرك مرة أخرى. وإذا كانت هناك لافتة تُدرج فوق النص بعد ظهوره، فراجع طريقة إدراجها بدل محاولة تثبيت كل فقرة تأثرت بها.
راجع تبديل الخطوط وحالات ما بعد التحميل
قد تتغير أبعاد النص عند الانتقال من الخط البديل إلى خط الموقع. ولا يضمن font-display: swap وحده منع الإزاحة. راجع ملاءمة الخط البديل وأبعاده، ويمكن للمطور استخدام خصائص مثل size-adjust عندما تناسب التنفيذ، كما يشرح دليل تحسين الخطوط البديلة.
بعد الإصلاح، كرر السيناريو الذي أحدث الحركة، ثم مرّر الصفحة وانتظر تحميل المكوّنات المتأخرة. انخفاض CLS في اختبار التحميل وحده لا ينفي مشكلة تظهر لاحقًا؛ فالبيانات الفعلية قد تشمل هذه المراحل، بحسب شرح الفرق بين قياس CLS في المختبر والميدان.
تحسين Core Web Vitals في ووردبريس دون إعدادات عشوائية
في ووردبريس، طبّق التشخيص نفسه قبل اختيار إضافة تسريع. يشمل دليل تحسين أداء ووردبريس القوالب والإضافات والتخزين المؤقت وبيئة الاستضافة؛ لذلك لا تختزل المشكلة في عامل واحد، ولا تعتبر عدد الإضافات وحده تشخيصًا.
- حدّد مصدر المورد: اربط الصورة أو السكربت أو المكوّن المتأخر بالقالب أو الإضافة التي تنتجه، قبل تعطيل أي شيء.
- راجع التداخل: تحقق من الميزات التي تنفذها الاستضافة والقالب والإضافات بالفعل، حتى لا تغيّر التحميل الكسول أو تأخير السكربتات من أكثر من مكان دون فهم النتيجة.
- اختبر تغييرًا محددًا: استخدم نسخة احتياطية وبيئة اختبار للتعديلات الحساسة، وقارن القياس قبل التغيير وبعده.
بعد التعديل، اختبر القوائم والبحث والنماذج، والسلة والدفع إذا كان الموقع متجرًا. لا توقف الحماية أو الموافقة على التتبع أو ميزات إمكانية الوصول لمجرد رفع الدرجة. والإضافة التي تنفذ التحسينات لا تُغني عن قياس أثرها على الصفحات والتفاعلات الفعلية.
أي مشكلة تصلح أولًا، وكيف تتحقق من النتيجة؟
لا توجد أولوية ثابتة تقول إن LCP يسبق INP أو CLS في كل موقع. رتّب العمل بحسب شدة المشكلة وتكرارها، وعدد القوالب المتأثرة، وأهمية الإجراء للمستخدم، وتكلفة التعديل ومخاطره. قد يكون إصلاح قائمة تعوق التنقل أهم من تحسين صغير في صورة بصفحة قليلة الاستخدام.
أنشئ لكل مهمة سجلًا مختصرًا يتضمن عنوان الصفحة أو القالب، والجهاز، والمقياس، والدليل على السبب، والتغيير المقترح، وطريقة التحقق. هذا يمنع الانتقال من إعداد إلى آخر دون معرفة ما الذي أحدث الفرق.
قارن قبل الإصلاح وبعده في ظروف قابلة للمقارنة
احتفظ بنتيجة أساسية، ثم أعد الاختبار باستخدام الصفحة والجهاز والسيناريو نفسيهما. سجّل أيضًا حالة التخزين المؤقت وأي اختلاف مؤثر في المحتوى المعروض. توضح وثائق Lighthouse عن تذبذب النتائج أن تغير الأجهزة والإعلانات وظروف التشغيل قد يغير الدرجة دون أن يكون السبب تعديلًا في الكود.
لا تكتفِ بتحسن المقياس المستهدف: افحص المؤشرين الآخرين ووظائف الصفحة. فقد يتطلب تعديل التحميل مراجعة أثره على الاستجابة أو ثبات التصميم. وبعد نجاح الاختبار المحلي، تابع التجارب الميدانية للتأكد من أن التحسن يصل إلى الزوار، لا إلى بيئة الاختبار وحدها.
متى تظهر التحسينات في PageSpeed وSearch Console؟
تعرض بيانات المستخدمين في PageSpeed Insights فترة جمع سابقة مدتها 28 يومًا، وتتحدث يوميًا، وفق توثيق الخدمة. لذلك قد يظهر أثر التعديل في الاختبار المحلي قبل أن يتغير التقييم الميداني بوضوح. والنافذة المتحركة لا تعني غياب أي تحسن قبل مرور 28 يومًا، ولا تضمن الاجتياز في يوم محدد.
أما في Search Console، فبعد معالجة المشكلة في العناوين المتأثرة، افتح تفاصيلها واضغط «بدء التتبّع». تبدأ جلسة متابعة لمدة 28 يومًا للتحقق من استمرار المشكلة، بحسب تعليمات التحقق من الإصلاح. هذه متابعة لنتائج التعديل، وليست إجراءً يُصلح الموقع أو طلبًا لإعادة فهرسته.
اعتبر الإصلاح مكتملًا عندما تستطيع تفسير ما تغيّر: عرفت السبب، وعدّلت الجزء المسؤول، وأعدت إنتاج الاختبار، وتأكدت من سلامة الوظائف، ثم تابعت أثر النشر على البيانات الفعلية. بهذه الطريقة تصبح Core Web Vitals أداة لتحسين تجربة المستخدم، لا مجموعة أرقام تُطاردها دون تشخيص.