فشل تقييم Core Web Vitals في WordPress؟ ماذا يعني وما الذي تصلحه أولًا

عبارة “Core Web Vitals Assessment: Failed” تعني أنه بالنسبة لزوار Chrome الحقيقيين خلال آخر 28 يومًا، كان مقياس واحد على الأقل من المقاييس الثلاثة (LCP أو INP أو CLS) خارج النطاق “الجيد” عند الشريحة المئوية 75. وهذا التقييم مصدره البيانات الميدانية، لا درجة Lighthouse التي تظهر أسفله، ولهذا قد تحصل صفحة على 90 وتفشل مع ذلك.

إليك كيف تقرأ التقرير، وتحدد المقياس والصفحات التي فشلت، وتصلح موقع WordPress بالترتيب الذي يوصلك إلى “Passed” بأسرع وقت.

ماذا تعني عبارة “Core Web Vitals Assessment: Failed” فعلًا

مؤشرات Core Web Vitals هي ثلاثة قياسات تستخدمها Google لوصف تجربة الصفحة في الواقع:

• Largest Contentful Paint (LCP): الوقت الذي يستغرقه المحتوى الرئيسي (غالبًا صورة الواجهة أو العنوان الرئيسي) ليظهر.
• Interaction to Next Paint (INP): مدى سرعة استجابة الصفحة بصريًا عندما ينقر الزائر أو يلمس أو يكتب. وقد حل INP محل First Input Delay في 12 مارس 2024.
• Cumulative Layout Shift (CLS): مقدار قفز عناصر التصميم من مكانها أثناء تحميل الصفحة.

تأخذ PageSpeed Insights هذه البيانات من تقرير تجربة مستخدمي Chrome (CrUX)، وهو بيانات مجهولة الهوية من مستخدمي Chrome الحقيقيين تغطي آخر 28 يومًا. ووفقًا لـ توثيق Google لـ PageSpeed Insights، لا تنجح الصفحة أو النطاق إلا إذا كانت الشريحة المئوية 75 لـ المقاييس الثلاثة جميعها “جيدة”. وإذا لم تتوفر بيانات كافية عن INP، تنجح الصفحة عندما يكون LCP و CLS جيدين معًا. والحدود هي:

الشريحة المئوية 75 تعني أن ثلاث زيارات من كل أربع يجب أن تكون بهذه الجودة على الأقل. اتصالك السريع في المكتب لا يُحتسب كثيرًا؛ ما يُحتسب هو هاتف متوسط الفئة على بيانات الجوال.

لماذا قد تحصل على 90+ وتفشل مع ذلك

الدرجة الملونة الكبيرة في PageSpeed Insights تأتي من Lighthouse، وهو اختبار معملي: جهاز محاكى واحد، وملف شبكة واحد، وتحميل واحد للصفحة. أما التقييم الذي فوقها فهو بيانات ميدانية من زوارك الحقيقيين. ويشرح مقال Google عن سبب اختلاف البيانات المعملية عن الميدانية ذلك بالتفصيل. وهذه الأسباب الشائعة في مواقع WordPress:

• لا يستطيع Lighthouse قياس INP. لا أحد ينقر على أي شيء في الاختبار المعملي. يستخدم Lighthouse مقياس Total Blocking Time (TBT) بديلًا، كما يوضح web.dev. وقد يكون TBT للصفحة منخفضًا، ومع ذلك تستجيب ببطء عندما يفتح أشخاص حقيقيون القوائم أو يقبلون شريط ملفات تعريف الارتباط أو يرسلون النماذج.
• الزوار الحقيقيون ليسوا جهاز الاختبار. الهواتف الأقدم والشبكات البطيئة والزوار البعيدون عن خادمك كلهم يسحبون الشريحة المئوية 75 إلى الأسفل.
• الزيارات دون تسجيل دخول، ودون ذاكرة مؤقتة، والجلسات الطويلة. الاختبارات المعملية تحمّل صفحة واحدة مرة واحدة. أما المستخدمون الحقيقيون فيصلون إلى صفحات غير مخزنة مؤقتًا، ويمررون، ويفتحون النوافذ المنبثقة، ويشغّلون سكربتات تُحمَّل لاحقًا.
• قد تكون تنظر إلى بيانات النطاق (origin). إذا لم تكن للصفحة زيارات كافية، تعود PageSpeed Insights إلى بيانات النطاق بأكمله. وقد تظهر صفحة هبوط سريعة على أنها “Failed” لأن صفحات مدونتك أو متجرك بطيئة.
• الجوال وسطح المكتب منفصلان. يُقيَّم كل منهما على حدة، والجوال هو الذي يفشل عادة.

استخدم الدرجة المعملية لاختبار الإصلاحات بسرعة، واستخدم التقييم الميداني للحكم على نجاحها.

حدّد المقياس الفاشل والصفحات التي فشلت

في PageSpeed Insights، يعرض القسم الميداني قيمة الشريحة المئوية 75 لكل مقياس مع علامة حمراء أو برتقالية أو خضراء. سجّل أي مقياس ليس أخضر، وهل تقول البيانات “this URL” أم “origin”.

ثم افتح تقرير Core Web Vitals في Google Search Console. يجمع التقرير عناوين URL المتشابهة (مثل كل المقالات، أو كل صفحات المنتجات) ويعطي كل مجموعة حالة أسوأ مقياس فيها. وهذا يخبرك هل المشكلة في قالب واحد أم في الموقع كله، وهو أمر مهم في WordPress: إصلاح قالب المقال الواحد يصلح كل المقالات دفعة واحدة.

ترتيب الإصلاحات في WordPress

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

1. LCP: ابدأ من الخادم

يقسم دليل Google عن LCP هذا المقياس إلى أربعة أجزاء: الوقت حتى أول بايت (TTFB)، والتأخير قبل بدء تنزيل صورة LCP، والتنزيل نفسه، ووقت عرضها. وفي WordPress يكون الجزء الأول غالبًا هو الأكبر. فلغة PHP تبني كل صفحة عند الطلب ما لم تكن مخزنة مؤقتًا، وقد يستهلك خادم مشترك بطيء جزءًا كبيرًا من ميزانية الثواني الـ 2.5 قبل أن يستلم المتصفح أي HTML.

1. قلّل زمن استجابة الخادم: فعّل التخزين المؤقت للصفحات كاملة (عند الاستضافة أو عبر إضافة تخزين مؤقت)، واستخدم إصدار PHP حديثًا، وضع شبكة CDN أمام الموقع. وإذا ظل TTFB بطيئًا في الصفحات المخزنة مؤقتًا، فالاستضافة هي عنق الزجاجة.
2. أصلح عنصر LCP: ستجده في تشخيصات PageSpeed. إذا كان صورة، فاضغطها وغيّر حجمها، وتأكد من أنها غير مؤجلة التحميل، ودعها تُحمَّل بأولوية عالية (fetchpriority="high"). وإذا كان شريط تمرير (slider)، فاستبدله بصورة واحدة.
3. قلّل الموارد التي تعيق العرض: ملفات CSS أقل في الترويسة، وملفات خطوط أقل، ولا أوراق أنماط غير مستخدمة من إضافات تُحمَّل في كل صفحة.

وإذا كان موقعك مبنيًا بمنشئ صفحات، فبنية القالب مهمة أيضًا. وقد تناولت الأسباب الخاصة بـ Elementor في مقال منفصل.

هذا جوهر عملي في الاستضافة و Core Web Vitals: أصلح استجابة الخادم أولًا، ثم الواجهة الأمامية. ومن النتائج التي حققتها خفض زمن التحميل بنسبة 25%.

2. INP: أبعد السكربتات عن الخيط الرئيسي

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

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

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

3. CLS: احجز مساحة لكل شيء

يحدث انزياح التخطيط عندما يظهر عنصر ما فيدفع المحتوى إلى الأسفل. ويسرد دليل Google عن CLS الأسباب المعتادة: صور وإعلانات وعناصر مضمّنة وإطارات iframe بلا أبعاد، ومحتوى يُحقن بعد التحميل، وخطوط الويب.

• أعطِ كل صورة وفيديو سمتي width و height (يضيفهما WordPress للصور المدرجة عبر مكتبة الوسائط؛ أما HTML المخصص وبعض القوالب فلا).
• احجز مساحة للعناصر المضمّنة والخرائط وأماكن الإعلانات بحاوية ذات ارتفاع ثابت.
• اعرض أشرطة ملفات تعريف الارتباط والعروض الترويجية كطبقات فوق المحتوى بدلًا من إدراجها أعلاه.
• استخدم خطًا احتياطيًا بأبعاد مشابهة حتى لا يكاد التبديل إلى خط الويب يحرّك النص.

هل تريد رأيًا ثانيًا قبل أن تبدأ؟ يمكنك فحص Core Web Vitals لموقعك مجانًا ضمن تدقيق MarTech الذي أقدمه. سأخبرك بالمقياس الذي تصلحه أولًا ولماذا.

المواقع العربية ومواقع RTL: الخطوط و LCP و CLS

للمواقع العربية وثنائية اللغة، المنتشرة في السعودية والخليج، بعض الفخاخ الإضافية، وكلها تقريبًا مرتبطة بالخطوط:

• مجموعتان من الخطوط. الموقع الذي يحمّل عائلة خطوط لاتينية وأخرى عربية، كل منهما بعدة أوزان، ينزّل ملفات خطوط كثيرة. حمّل فقط الأوزان التي تستخدمها كل لغة فعلًا.
• النص كعنصر LCP. في أقسام الواجهة العربية الغنية بالنصوص، يكون العنوان الرئيسي غالبًا هو عنصر LCP، فيؤخر خط الويب المتأخر LCP مباشرة. قدّم الخطوط من نطاقك أنت، وحمّل مسبقًا فقط الخط المستخدم في الجزء الظاهر أولًا من الصفحة.
• انزياحات تبديل الخطوط. قد تختلف أبعاد الخطوط العربية الاحتياطية كثيرًا عن خط الويب، فيتحرك النص عند التبديل. اختر خطًا احتياطيًا بمقاييس مشابهة، أو استخدم font-display: optional الذي تقترحه Google لتجنب إعادة التخطيط.
• اختبر كل لغة على حدة. يرصد CrUX البيانات حسب عنوان URL، لذا قد تفشل صفحات /ar/ بينما تنجح الصفحات الإنجليزية. افحص الاثنتين في Search Console.

متى ستظهر عبارة “Passed”؟

تغطي البيانات الميدانية نافذة متحركة مدتها 28 يومًا، لذا تندمج إصلاحاتك فيها تدريجيًا. تحدّث PageSpeed Insights بياناتها الميدانية يوميًا، لكن التقييم لا يتغير إلا بعد أن يعكس عدد كافٍ من تلك الأيام الـ 28 الموقع الأسرع. توقّع أن يستغرق ذلك حتى أربعة أسابيع تقريبًا بعد نشر الإصلاح، وأطول من ذلك للصفحات قليلة الزيارات.

في تقرير Core Web Vitals في Search Console، افتح المشكلة بعد إصلاحها في كل عناوين URL المتأثرة وابدأ التحقق (تسمي صفحة المساعدة من Google هذا الزر “Start Tracking”). ستراقب Google تلك العناوين لمدة 28 يومًا. وفي الأثناء، استخدم الدرجة المعملية و Chrome DevTools للتأكد من أن كل تغيير يساعد.

الأسئلة الشائعة

لماذا تقول PageSpeed “Failed” بينما درجتي خضراء؟

الدرجة اختبار معملي لمرة واحدة. أما التقييم فهو بيانات مستخدمين حقيقيين على مدى 28 يومًا عند الشريحة المئوية 75، ويشمل INP الذي لا يستطيع الاختبار المعملي قياسه. إنهما يجيبان عن سؤالين مختلفين.

ماذا تعني كلمة “origin” في قسم Core Web Vitals؟

لم تتوفر للصفحة بيانات كافية من مستخدمين حقيقيين، فتعرض PageSpeed Insights بيانات نطاقك بالكامل. إصلاح صفحة واحدة لن يغير ذلك كثيرًا؛ ابحث عن القوالب البطيئة في Search Console.

هل تصلح إضافة التخزين المؤقت Core Web Vitals؟

غالبًا ما تصلح الجزء الخاص بالخادم من LCP، وهي خطوة كبيرة. لكنها لن تصلح صورة واجهة كبيرة جدًا، أو سكربتات الأطراف الثالثة الثقيلة (INP)، أو انزياحات التخطيط (CLS).

أصلحت كل شيء. لماذا ما زالت تقول Failed؟

نافذة الـ 28 يومًا ما زالت تتضمن زيارات من قبل الإصلاح. أمهلها حتى أربعة أسابيع، وتأكد من أن الإصلاح يشمل الجوال وكل القوالب، لا الصفحة التي اختبرتها فقط.