مؤشرات أداء الويب الأساسية: LCP وINP وCLS وكيف تحسّنها

في تقرير Web Almanac لسنة 2025، الذي يحلّل ملايين المواقع من بيانات متصفّح كروم، اجتاز 48% من المواقع على الجوال مؤشّرات أداء الويب الأساسية الثلاثة، و56% على الحاسوب.^[1] والرقمان تحسّنا كثيرًا منذ 2021، حين كانت النسبة على الجوال 32%. لكنّ معناهما أنّ نصف المواقع تقريبًا ما زالت تُبطئ على زوّارها، أو تتأخّر في الاستجابة، أو تتقافز عناصرها تحت أصابعهم.

في مقال خريطة الموقع دللتَ المحرّك على صفحاتك. وهنا السؤال التالي: حين يفتحها زائر، كيف يجدها؟ سأشرح المؤشّرات الثلاثة وعتباتها، ومكانها الحقيقيّ في الترتيب، والفرق بين بيانات الميدان والمختبر. ثمّ أمرّ على أسباب ضعف كلّ مؤشّرٍ وعلاجه، وكيف تقرأ تقاريرها وتدقّق موقعك كلّه.

ما هي، وأين مكانها في الترتيب؟

مؤشّرات أداء الويب الأساسية (Core Web Vitals) ثلاثة مقاييس تصف تجربة الزائر الحقيقيّ: متى يظهر المحتوى الرئيسيّ، وكم تتأخّر الصفحة في الاستجابة حين يتفاعل معها، وهل يثبت تخطيطها أم يتحرّك. وتقول جوجل صراحةً إنّ أنظمة الترتيب تستعمل هذه المؤشّرات،^[2] وتوصي أصحاب المواقع بأن يحقّقوا فيها نتائج جيّدة للنجاح في البحث ولتجربةٍ جيّدة عمومًا.^[3]

لكنّ الوثيقة نفسها تضع المؤشّرات في حجمها: تقول جوجل إنّه لا توجد «إشارة تجربة صفحة» واحدة، وإنّ أنظمتها تنظر في إشاراتٍ متعدّدة مجتمعة. وتقول إنّ البحث يسعى دائمًا إلى عرض المحتوى الأكثر صلة، حتى لو كانت تجربة الصفحة دون المستوى.^[2] فالأداء يرجّح بين صفحاتٍ متقاربة في جودة المحتوى وصلته، ولا يرفع صفحةً ضعيفة فوق صفحةٍ تجيب الباحث أفضل منها. وتقيّم جوجل التجربة لكلّ صفحةٍ على حدة غالبًا، لا للموقع كلّه دفعةً واحدة.

والمؤشّرات الثلاثة جزءٌ واحد من «تجربة الصفحة» كما تصفها جوجل. في الوثيقة نفسها أسئلةٌ تقترح أن تسألها عن صفحاتك، والمؤشّرات أوّلها فقط، ثمّ تقديم الصفحة عبر HTTPS وعرضها جيّدًا على الجوال. وتسأل كذلك عن خلوّها من إعلاناتٍ كثيرة تشتّت عن المحتوى الرئيسيّ، ومن النوافذ المنبثقة التي تحجبه، وعن سهولة تمييز المحتوى الرئيسيّ عن غيره في نظر الزائر.^[2] فصفحةٌ تجتاز المؤشّرات الثلاثة وتفتح على نافذة اشتراكٍ تغطّي الشاشة كلّها لم تحقّق ما تقصده جوجل بالتجربة الجيّدة.

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

لماذا هذه المقاييس الثلاثة بالذات؟

كانت سرعة المواقع تُقاس قديمًا بلحظةٍ تقنية واحدة: متى أعلن المتصفّح أنّ الصفحة اكتمل تحميلها. وهذه اللحظة كانت تخدع في الاتّجاهين، فصفحةٌ تُظهر محتواها كاملًا في ثانية، ثمّ تحمّل في الخلفية إعلاناتٍ وأدوات تحليل عشر ثوانٍ، تبدو «بطيئة» بهذا المقياس. وصفحةٌ تكتمل تقنيًّا بسرعة، ثمّ تتجمّد أمام أوّل نقرة، تبدو «سريعة».

فبنت جوجل المؤشّرات الحالية حول ما يلاحظه الإنسان، لا حول ما يعلنه المتصفّح. وكلّ مؤشّرٍ يجيب عن سؤالٍ يطرحه الزائر بلا كلمات. هل ظهر ما جئتُ من أجله؟ هذا LCP. وحين نقرتُ، هل استجابت الصفحة؟ هذا INP. وهل بقي النصّ في مكانه وأنا أقرأ؟ هذا CLS. ولهذا تصلح المؤشّرات الثلاثة لكلّ نوعٍ من المواقع، مدوّنةً كان أو متجرًا أو لوحة تحكّم.

المؤشّرات الثلاثة وعتباتها

لكلّ مؤشّرٍ عتبتان تقسمان النتائج إلى ثلاث فئات: جيّد، ويحتاج تحسينًا، وسيّئ. ولا تُقاس هذه العتبات بالمتوسّط. تقيسها جوجل عند المئين الخامس والسبعين من زيارات الصفحة، مفصولةً بين الجوال والحاسوب، أي أنّ ثلاثة أرباع الزيارات على الأقلّ يجب أن تحقّق العتبة الجيّدة. وتجتاز الصفحة التقييم إن حقّقت المؤشّرات الثلاثة معًا عند هذا المئين.^[4]

شكل 1

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

وأصعب المؤشّرات اجتيازًا على الجوال أوّلها. في تقرير Web Almanac لسنة 2025 نفسه، حقّق 62% من المواقع على الجوال نتيجةً جيّدة في LCP، مقابل 77% في INP و81% في CLS.^[1] فإن كان عليك أن تبدأ بمؤشّرٍ واحد دون أن تعرف شيئًا عن موقعك، فالاحتمال الأكبر أنّ مشكلتك في سرعة ظهور المحتوى الرئيسيّ.

مؤشّر LCP: متى يظهر المحتوى الرئيسيّ

مؤشّر زمن عرض أكبر محتوى (Largest Contentful Paint) يقيس متى يُرسم أكبر عنصرٍ مرئيّ في الشاشة الأولى، وهو غالبًا صورة الغلاف أو العنوان الكبير. والعتبة الجيّدة 2.5 ثانية أو أقلّ.^[5] وهذه اللحظة هي التي يشعر فيها الزائر أنّ الصفحة ظهرت فعلًا، مهما سبقها من عناصر صغيرة.

وتقسم وثيقة التحسين من جوجل زمن هذا المؤشّر على أربعة أجزاءٍ متتالية.^[6] الأوّل زمن أوّل بايت (TTFB)، من طلب الصفحة حتى يصل أوّل بايتٍ من الخادم. والثاني تأخّر بدء التحميل، بين وصول الصفحة وبدء جلب الصورة أو العنصر الكبير. والثالث مدّة تحميل هذا العنصر نفسه. والرابع تأخّر العرض، من انتهاء التحميل حتى يُرسم العنصر فعلًا على الشاشة.

شكل 2

وهذا التقسيم يحدّد من أين يبدأ العلاج: إن كان زمن أوّل بايت طويلًا، فالمشكلة في الخادم أو الاستضافة أو غياب التخزين المؤقّت، وأيّ تحسينٍ للصورة لن يعوّضها. وإن كان تأخّر بدء التحميل طويلًا، فالمتصفّح يكتشف الصورة متأخّرًا، لأنّها تُحقن بجافاسكربت أو تُحمَّل تحميلًا كسولًا أو تُعلن في ملفّ CSS. وإن كانت مدّة التحميل طويلة، فالصورة ثقيلة أو بصيغةٍ قديمة. وإن طال تأخّر العرض، فملفّات CSS وجافاسكربت تحجب الرسم بعد وصول الصورة.

والعلاج المعتاد لكلّ جزءٍ معروف، فللخادم استضافةٌ مناسبة وتخزينٌ مؤقّت وشبكة توصيل محتوى تقرّب ملفّاتك من زائرك أينما كان، في حمص أو في هامبورغ. وللاكتشاف: اجعل صورة LCP في شيفرة الصفحة الأولى نفسها، وأعطها fetchpriority="high"، ولا تضع عليها loading="lazy" أبدًا. وللتحميل: صيغةٌ حديثة مثل WebP أو AVIF، وأبعادٌ لا تزيد على ما يظهر، مع srcset لكلّ حجم شاشة.^[6]

مؤشّر INP: كم تتأخّر الصفحة في الاستجابة

مؤشّر التفاعل حتى العرض التالي (Interaction to Next Paint) يقيس الزمن من نقرة الزائر أو ضغطته حتى يرسم المتصفّح الإطار التالي الذي يُظهر أثرها. ويراقب التفاعلات طوال الزيارة، ويأخذ أبطأها تقريبًا. والعتبة الجيّدة 200 ملّي ثانية أو أقلّ، والسيّئة فوق 500.^[7]

وقد حلّ هذا المؤشّر محلّ مؤشّر تأخّر الإدخال الأوّل (FID) في 12 آذار 2024، وخرج الثاني من البرنامج نهائيًّا.^[8] والفرق بينهما جوهريّ: القديم كان يقيس تأخّر التفاعل الأوّل وحده، وجزءًا واحدًا منه. فكانت صفحاتٌ كثيرة تجتازه وهي تتجمّد عند كلّ نقرةٍ بعد الأولى. فإن رأيتَ أداةً أو مقالًا يعرض FID مؤشّرًا حاليًّا في 2026، فهي قديمة.

ويتكوّن زمن التفاعل من ثلاثة أجزاء. تأخّر الإدخال، وهو انتظار التفاعل حتى تبدأ الشيفرة المسؤولة عنه، وسببه غالبًا مهامّ طويلة تشغل الخيط الرئيسيّ. ثمّ زمن المعالجة، أي تشغيل تلك الشيفرة، ثمّ تأخّر العرض، أي رسم الإطار الجديد.^[7] والمهمّة الطويلة أيّ مهمّةٍ تشغل الخيط الرئيسيّ أكثر من 50 ملّي ثانية، وعلاجها تقسيمها إلى قطعٍ أصغر، وتأجيل الشيفرة غير الضرورية، وتقليل السكربتات الخارجية.

والسكربتات الخارجية أكثر ما يُفسد هذا المؤشّر في مواقع المحتوى: إعلاناتٌ، وأدوات تحليل، ونوافذ دردشة، وأزرار مشاركة، ولكلٍّ منها شيفرةٌ تنافس تفاعل زائرك على الخيط الرئيسيّ نفسه. راجع ما تحمّله صفحتك واسأل عن كلّ سكربت: هل يستحقّ مكانه؟ وأجّل ما يمكن تأجيله حتى يفرغ المتصفّح من عرض المحتوى.

مؤشّر CLS: هل يثبت التخطيط

مؤشّر إزاحة التخطيط التراكمية (Cumulative Layout Shift) يقيس تحرّك العناصر المرئية دون أن يطلب الزائر ذلك. والعتبة الجيّدة 0.1 أو أقلّ، والسيّئة فوق 0.25. والرقم بلا وحدة، لأنّه يجمع نسبة ما تحرّك من الشاشة مع المسافة التي تحرّكها.^[9] وتعرف أثره حين تهمّ بالنقر على رابطٍ فيقفز النصّ لأنّ إعلانًا ظهر فوقه، فتنقر على الإعلان.

واسمه يوحي بأنّه يجمع كلّ الإزاحات في الزيارة، وأكثر الشروح العربية تقوله كذلك. والتعريف الحاليّ في وثيقة جوجل غير ذلك: المؤشّر يأخذ أكبر دفعةٍ من الإزاحات. والدفعة إزاحاتٌ متتالية لا يفصل بينها أكثر من ثانية، ولا تتجاوز مدّتها كلّها خمس ثوانٍ.^[9] فصفحةٌ طويلة يقرؤها زائرٌ عشرين دقيقة لا تُعاقَب لأنّ إزاحاتٍ صغيرة متفرّقة تراكمت عبر الزيارة كلّها، وتُعاقَب على أسوأ لحظة اهتزازٍ فيها.

وأسبابه معروفة، وعلاجها أسهل ما في المؤشّرات الثلاثة: صورٌ وإطاراتٌ بلا أبعاد، فيحجز لها المتصفّح مكانًا بعد وصولها: حدّد width وheight أو aspect-ratio لكلّ وسيط. وإعلاناتٌ ونوافذ تُحقن فوق المحتوى: احجز مكانها قبل أن تصل. وخطوطٌ تصل متأخّرة فيتبدّل النصّ عند وصولها: حمّل خطّك الأساسيّ مبكّرًا، واختر خطًّا احتياطيًّا قريب القياس منه.^[9]

مثالٌ من صفحةٍ واحدة

لنجمع الثلاثة في صفحة مقالٍ عاديّة: صورة غلافٍ كبيرة في الأعلى، وقائمةٌ منسدلة للتنقّل، وإعلانٌ يظهر بين الفقرة الأولى والثانية. الموقع على استضافةٍ مشتركة مزدحمة، والصورة بصيغة PNG وعرضها 4000 بكسل، والقالب يضع عليها تحميلًا كسولًا لكلّ الصور بلا استثناء.

زمن أوّل بايت يطول لأنّ الخادم مزدحم، ثمّ يتأخّر بدء جلب الصورة لأنّ التحميل الكسول يؤجّلها، ثمّ يطول تحميلها لأنّها أثقل بعشرات المرّات ممّا تحتاجه الشاشة. فيسوء LCP من ثلاثة أجزاءٍ من أجزائه الأربعة. والقائمة المنسدلة تشغّل مكتبة جافاسكربت ثقيلة عند كلّ نقرة، والخيط الرئيسيّ مشغولٌ أصلًا بسكربت الإعلان، فيسوء INP. والإعلان يُحقن بلا مساحةٍ محجوزة، فيدفع الفقرة الثانية إلى الأسفل والزائر في منتصفها، فيسوء CLS.

ثلاث مشكلاتٍ في صفحةٍ واحدة، ولكلٍّ منها طبقتها: الاستضافة والصورة لمؤشّر LCP، وجافاسكربت لمؤشّر INP، والتخطيط لمؤشّر CLS. ولن يصلحها كلّها إجراءٌ واحد مثل «إضافة تسريع»، فكلّ طبقةٍ تحتاج علاجها.

الميدان والمختبر: أيّ الرقمين يحسب؟

كلّ أداةٍ تعرض لك هذه المؤشّرات تأخذ أرقامها من أحد مصدرين. بيانات الميدان تأتي من زوّارٍ حقيقيّين يستعملون كروم، يجمعها تقرير تجربة مستخدمي كروم (CrUX) على مدى 28 يومًا، وهي ما تقيس به جوجل تجربة صفحتك. وبيانات المختبر تأتي من تحميلٍ واحد في بيئةٍ محاكاة، كما يفعل Lighthouse، وهي مفيدةٌ لتشخيص السبب، والرقم الذي يحسب يأتي من الميدان.^[4]

شكل 3

والفرق بينهما كبيرٌ في مؤشّر التفاعل خاصّة، لأنّ المختبر لا يعرف كيف سينقر زوّارك، فيقيس بدلًا منه زمن الحجب الكلّيّ (TBT). وتقول جوجل إنّ انخفاض هذا المؤشّر يقترن غالبًا بانخفاض INP، وتوصي مع ذلك بقياس INP في الميدان.^[10] فلا تفرح بنتيجة 100 في المختبر إن كانت بيانات الميدان سيّئة، ولا تقلق من نتيجةٍ مختبرية متوسّطة إن كان الميدان جيّدًا، فالميدان هو الحكم في النهاية.

وإن كان موقعك صغيرًا أو جديدًا، فقد لا تجد بيانات ميدانٍ أصلًا. تقرير CrUX لا ينشر أرقامًا إلّا لصفحاتٍ بلغت حدًّا أدنى من الزيارات، فترى في Search Console شاشة No data available.^[11] والحلّ عندها أن تعمل بالمختبر وحده، وتكرّر الفحص على جوالٍ متوسّط، حتى يكبر موقعك ويظهر ميدانه.

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

قِس ميدانك بنفسك

بيانات CrUX تأتي من زوّار كروم وحدهم، وتصلك مجمّعة، فلا تعرف منها أيّ بلدٍ أو أيّ جهازٍ يجرّ رقمك إلى الأسفل، ولا ترى فيها زوّار سفاري وفايرفوكس أصلًا. ولمن يريد أن يرى ذلك، تنشر جوجل مكتبة web-vitals، وهي مكتبة جافاسكربت صغيرة تقيس المؤشّرات الثلاثة في متصفّح كلّ زائر. وتقيسها بالطريقة نفسها التي تقيس بها أدوات جوجل، ثمّ ترسلها إلى أداة التحليل التي تستعملها.^[4]

ومع بياناتك أنت تستطيع أن تقسم النتائج كما يهمّك. زوّار سوريا وحدهم، وزوّار الخليج وحدهم، وأصحاب الجوالات الرخيصة وحدهم. فإن وجدتَ أنّ LCP جيّدٌ في دبي وسيّئٌ في دمشق، فالمشكلة غالبًا في المسافة إلى الخادم وحجم الصور، وعلاجها شبكة توصيلٍ وصورٌ أخفّ، لا إعادة كتابة القالب. وهذه الخطوة للمواقع التي يكفيها جمهورها لتكون الأرقام ذات معنى. أمّا الموقع الصغير فيكفيه المختبر وتقرير Search Console.

الرجوع الفوريّ إلى الصفحة

ولتحسينٍ واحد أثرٌ كبير يغفله أكثر الناس: ذاكرة الرجوع والتقدّم في المتصفّح (bfcache). حين يضغط الزائر زرّ الرجوع، يستطيع المتصفّح أن يعيد الصفحة السابقة من الذاكرة كما تركها، دون أن يطلب أيّ شيءٍ من الشبكة، فتظهر في لحظة.^[12] وزياراتٌ كثيرة في موقع محتوى هي بالضبط هذا: قارئٌ يفتح مقالًا من صفحة التصنيف، ثمّ يرجع إليها، ثمّ يفتح غيره.

لكنّ صفحاتٍ كثيرة تُحرم هذه الذاكرة دون أن يعرف أصحابها. وأهمّ سببٍ تذكره جوجل حدث unload في جافاسكربت، وتقول بعبارةٍ حاسمة: لا تستعمله أبدًا، واستعمل حدث pagehide بدلًا منه.^[12] وتضيفه أحيانًا سكربتاتٌ خارجية قديمة، لا شيفرتك أنت. وتقرير Lighthouse يخبرك إن كانت الصفحة تمنع هذه الذاكرة ولماذا.

كيف تقرأ التقارير

ابدأ بتقرير Core Web Vitals في Search Console، فهو يعرض عناوين موقعك مجمّعةً في مجموعات صفحاتٍ متشابهة، ولكلّ مجموعةٍ حالةٌ من ثلاث: Good وNeed improvement وPoor. وحالة المجموعة هي حالة أسوأ مؤشّراتها.^[11] فمجموعةٌ جيّدة في LCP وسيّئة في CLS تظهر سيّئة، وهذا يريك أين تعمل. وكان في Search Console تقريرٌ اسمه «تجربة الصفحة»، أعلنت جوجل في 19 نيسان 2023 تحويله إلى صفحة إرشادٍ تحيل إلى تقريرَي المؤشّرات وHTTPS، فلا تبحث عنه.^[13]

ثمّ خذ صفحةً من مجموعةٍ سيّئة إلى PageSpeed Insights. في أعلى تقريره بيانات الميدان من CrUX إن توفّرت، للصفحة أو للموقع كلّه، وهي الجزء الذي يهمّك أوّلًا. وتحتها تشخيص Lighthouse المختبريّ، الذي يسمّي لك عنصر LCP في الصفحة، والموارد التي تحجب العرض، والمهامّ الطويلة. وفي أدوات مطوّري كروم، تعرض لوحة الأداء زمن LCP مقسومًا على أجزائه الأربعة، بجوار رقم الميدان من CrUX.^[6]

الصور والخطوط: أكثر ما يُثقل مواقع المحتوى

في مواقع المقالات، الصور أثقل ما في الصفحة عادةً، وأسهل ما يُصلح. اخدمها بصيغة WebP أو AVIF، فهي أخفّ بكثير من JPEG وPNG بالجودة نفسها. ولا ترفع صورةً عرضها 4000 بكسل لتعرضها في 800. وأعطِ كلّ صورةٍ أبعادها، وضع التحميل الكسول على الصور التي تقع تحت الشاشة الأولى وحدها، فهو يوفّر على الزائر تحميل ما قد لا يصل إليه أبدًا.

والخطوط العربية لها وزنٌ خاصّ، لأنّ ملفّ الخطّ العربيّ الكامل أكبر من اللاتينيّ بكثير، وقد يحمل حروفًا وأشكالًا لا يستعملها موقعك، فيدفع الزائر ثمن تحميلها بلا فائدة. حمّل الأوزان التي تستعملها فعلًا، واحدًا أو اثنين، لا العائلة كلّها. وقدّم ملفّ الخطّ الأساسيّ مبكّرًا بـpreload، واستعمل font-display ليظهر النصّ بخطٍّ احتياطيّ فور تحميل الصفحة بدل أن يبقى مخفيًّا. واختر خطًّا احتياطيًّا قريب القياس من خطّك، حتى لا يتحرّك النصّ حين يصل الخطّ الأصليّ.

كيف تدقّق موقعًا كاملًا

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

بنيتُ زاحفي Crawlix ليقيس في كلّ صفحةٍ يزحفها مؤشّرات المختبر، ومنها LCP وCLS وزمن أوّل بايت وزمن الحجب الكلّيّ، مع فحوصٍ للصور تخصّ هذا المقال مباشرة. يرصد الصور التي لا تحمل width وheight، وهي أشيع أسباب CLS، والتحميل الكسول، وحجم كلّ صورة، وهل هي بصيغة WebP أو AVIF. ويعمل على جهازك في ويندوز ولينكس بواجهةٍ عربية، ولا يرفع بيانات موقعك إلى أيّ خادم.

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

بأيّها تبدأ؟

ابدأ من بيانات الميدان، وبالمؤشّر الذي يضع أكثر صفحاتك خارج «جيّد». فإن كان LCP، فابدأ بزمن أوّل بايت، لأنّ كلّ ما بعده ينتظره. والاستضافة الجيّدة مع التخزين المؤقّت وشبكة التوصيل تحلّ جزءًا كبيرًا منه في موقع محتوى عاديّ. وإن كان CLS، فأبعاد الصور ومساحات الإعلانات، وهو غالبًا أسرع إصلاح. وإن كان INP، فهو أصعبها، ويبدأ بجرد السكربتات الخارجية قبل أيّ تحسينٍ في شيفرتك.

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

أفكارٌ قديمة ما زالت تتكرّر

• «FID مؤشّرٌ أساسيّ»: خرج من البرنامج في 12 آذار 2024، وحلّ محلّه INP.
• «تحتاج 100 في PageSpeed»: الهدف اجتياز العتبات في الميدان، ونتيجة المختبر أداة تشخيص.
• «CLS يجمع كلّ إزاحات الزيارة»: يأخذ أكبر دفعةٍ منها، في نافذةٍ لا تتجاوز خمس ثوانٍ.
• «العتبات متوسّطات»: تُقاس عند المئين الخامس والسبعين، ولكلّ جهازٍ وحده.
• «الأداء يتفوّق على المحتوى»: جوجل تعرض المحتوى الأكثر صلة ولو كانت تجربته دون المستوى.
• «التحميل الكسول لكلّ الصور يسرّع الصفحة»: على صورة LCP يؤخّرها، فاستثنها منه.

خلاصة عملية

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

وحين تصبح صفحتك سريعةً ثابتة، يبقى أن يفهم المحرّك ما فيها: منتجٌ بسعرٍ وتقييم، أم وصفةٌ بمكوّنات، أم مقالٌ بكاتبٍ وتاريخ. ذلك موضوع المقال التالي، «البيانات المنظّمة (Schema)».

المصادر

1. موقع HTTP Archive، «Web Almanac 2025: Performance»: نسبة المواقع التي تجتاز المؤشّرات الثلاثة، 48% على الجوال و56% على الحاسوب سنة 2025، و32% و41% سنة 2021.
2. جوجل، مركز البحث للمطوّرين، «Understanding page experience in Google Search results»: لا إشارة واحدة لتجربة الصفحة، وأنظمة الترتيب تستعمل المؤشّرات، والمحتوى الأكثر صلة أوّلًا ولو كانت التجربة دون المستوى، والتقييم لكلّ صفحة.
3. جوجل، مركز البحث للمطوّرين، «Understanding Core Web Vitals and Google search results» (آخر تحديث 10 كانون الأوّل 2025): مقاييس لتجربة المستخدم الحقيقية، والتوصية بنتائج جيّدة.
4. موقع web.dev، «Web Vitals»: القياس عند المئين الخامس والسبعين لكلّ جهاز، واجتياز المؤشّرات الثلاثة معًا، والفرق بين أدوات الميدان والمختبر.
5. موقع web.dev، «Largest Contentful Paint (LCP)»: التعريف والعتبة الجيّدة 2.5 ثانية.
6. موقع web.dev، «Optimize Largest Contentful Paint»: الأجزاء الأربعة (TTFB، وتأخّر بدء التحميل، ومدّة التحميل، وتأخّر العرض)، وعلاج كلٍّ منها، وعرضها في أدوات مطوّري كروم.
7. موقع web.dev، «Interaction to Next Paint (INP)»: التعريف والعتبتان 200 و500 ملّي ثانية، وأجزاء التفاعل الثلاثة.
8. موقع web.dev، «Interaction to Next Paint becomes a Core Web Vital on March 12» (2024): حلول INP محلّ FID.
9. موقع web.dev، «Cumulative Layout Shift (CLS)»: أكبر دفعةٍ من الإزاحات (نافذة جلسة: أقلّ من ثانية بين الإزاحات، وخمس ثوانٍ حدًّا أقصى)، والعتبتان 0.1 و0.25، والأسباب.
10. موقع web.dev، «Total Blocking Time (TBT)»: زمن الحجب الكلّيّ مؤشّرٌ مختبريّ يقترن انخفاضه غالبًا بانخفاض INP، والتوصية بقياس INP في الميدان.
11. مساعدة Search Console، «Core Web Vitals report»: الحالات Poor وNeed improvement وGood، وتجميع الصفحات المتشابهة، وحالة المجموعة بحسب أسوأ مؤشّر، وشاشة No data available.
12. موقع web.dev، «Back/forward cache» (آخر تحديث 2 تموز 2026): الرجوع الفوريّ من الذاكرة، ولا تستعمل حدث unload أبدًا واستعمل pagehide.
13. مدوّنة مركز البحث من جوجل، «More guidance on page experience» (19 نيسان 2023): تحويل تقرير تجربة الصفحة إلى صفحة إرشادٍ تحيل إلى تقريرَي المؤشّرات وHTTPS.