في المقال السابق قدّمتَ للمحرّك خريطةً تدلّه على صفحاتك. لكنّ الوصول إلى الصفحة شيء، وتجربتها شيءٌ آخر. حين يفتح زائرٌ صفحتك، لا يهمّه أنّها مفهرسة، بل يهمّه: أتظهر بسرعة، أم يحدّق في شاشةٍ بيضاء؟ وإذا نقر زرًّا، أتستجيب فورًا أم تتجمّد؟ وهل يثبت المحتوى مكانه أم يتقافز تحت إصبعه؟ هذا ما تقيسه «مؤشرات أداء الويب الأساسية».
سأشرح في هذا المقال ما هذه المؤشرات الثلاثة وأرقامها بالضبط، ومكانها الصحيح في الترتيب (فكثيرون يبالغون فيه)، والفرق الحاسم بين بيانات الميدان وبيانات المختبر، ثمّ أسباب ضعف كلّ مؤشرٍ وعلاجه، والأدوات التي تقيسه. والخيط الجامع: هذه المؤشرات تخدم زائرك أوّلًا، وأثرها في الترتيب حقيقيٌّ لكنّه خفيف.
ما هي، وأين مكانها الصحيح في الترتيب
مؤشرات أداء الويب الأساسية (Core Web Vitals) ثلاثة مقاييس تقدّر تجربة المستخدم الفعلية على صفحتك: سرعة ظهورها، وسرعة استجابتها، وثبات تخطيطها. وهي جزءٌ ممّا تسمّيه جوجل «تجربة الصفحة» (Page Experience). وتجربة الصفحة أوسع من هذه المؤشرات الثلاثة: تشمل أيضًا أن يكون موقعك آمنًا على HTTPS، وألّا تعترض القارئ نوافذ منبثقة تحجب المحتوى فور دخوله. لكنّ المؤشرات الأساسية هي القلب القابل للقياس من هذه التجربة.
وهنا تصحيحٌ مهمّ، لأنّ كثيرًا من المحتوى العربيّ يضخّم هذا الباب: ليست هذه المؤشرات «عامل الترتيب» الأكبر. تقول جوجل إنّه لا يوجد إشارةٌ واحدة اسمها «تجربة الصفحة»، وإنّ محرّك البحث «يسعى دائمًا لعرض المحتوى الأكثر صلة، حتى لو كانت تجربة الصفحة دون المستوى».[6] فالمحتوى وصلته بالباحث هما الأساس، والأداء إشارةٌ خفيفة ترجّح الكفّة بين صفحاتٍ متقاربةٍ في الجودة. لا تُهمِل الأداء، لكن لا تظنّ أنّ رفع أرقامك وحده يقفز بك على محتوًى أفضل منك.
لماذا هذه المقاييس بالذات؟
كانت المواقع تُقاس قديمًا بمقاييس آليّة كـ«زمن تحميل الصفحة» (Page Load Time)، لكنّها كانت تخدع: قد تعلن الصفحة أنّها «حمّلت» بينما الزائر ما زال يحدّق في فراغٍ أو ينتظر زرًّا لا يستجيب. فانتقلت جوجل إلى مقاييس «الأداء المُدرَك» (Perceived Performance): لا متى انتهى المتصفّح تقنيًّا، بل متى شعر الإنسان أنّ الصفحة ظهرت، واستجابت، واستقرّت. ومن هنا جاءت الثلاثة: واحدٌ للظهور، وواحدٌ للاستجابة، وواحدٌ للثبات. كلٌّ منها يجيب عن سؤالٍ يطرحه زائرٌ حقيقيّ لا آلة.
الثلاثة، وأرقامها بالضبط
ولكلّ مؤشرٍ عتبتان: «جيّد» وسيّئ. ونقطةٌ يغفلها الجميع تقريبًا: هذه الأرقام لا تُقاس بالمتوسّط، بل عند المئين الخامس والسبعين من مستخدميك الحقيقيّين، أي أنّ 75% من زياراتك يجب أن تحقّق العتبة الجيّدة.[1] بمعنًى آخر: لا يكفي أن تكون صفحتك سريعةً عندك، بل عند ثلاثة أرباع زوّارك على أجهزتهم وشبكاتهم الحقيقية. وتُقاس منفصلةً على الجوال وسطح المكتب، فقد تكون صفحتك جيّدةً على حاسوبك سيّئةً على الجوال؛ والجوال هو الأهمّ اليوم بعد أن صار الفهرسة تعتمد عليه أوّلًا.
LCP: سرعة عرض أكبر محتوى
Largest Contentful Paint يقيس متى يظهر أكبر عنصرٍ مرئيّ في الصفحة (غالبًا صورة الغلاف أو العنوان الكبير)، أي متى يشعر الزائر أنّ الصفحة «ظهرت» فعلًا. العتبة الجيّدة: 2.5 ثانية أو أقلّ، والسيّئة: أكثر من 4 ثوانٍ.[2] تخيّله كطبقٍ رئيسيّ في مطعم: قد تصلك المقبّلات بسرعة، لكنّ الزبون لا يشعر أنّ وجبته وصلت حتى يحضر الطبق الرئيس. وهو محطّةٌ أخيرة في سلسلة: أوّلًا يردّ الخادم (زمن أوّل بايت)، ثمّ تُرسَم أوّل بكسلات الصفحة (أوّل رسمة للمحتوى)، ثمّ يكتمل أكبر عنصر. فأيّ تأخّرٍ في أوّل السلسلة يتراكم في LCP، ولهذا يبدأ علاجه غالبًا من الخادم لا من الصورة وحدها.
INP: الاستجابة للتفاعل التالي
Interaction to Next Paint يقيس زمن الاستجابة: من لحظة تفاعل المستخدم (نقرة أو ضغطة زرّ) إلى ظهور الإطار التالي الذي يعكس أثر تفاعله على الشاشة. العتبة الجيّدة: 200 مِلّي ثانية أو أقلّ، والسيّئة: أكثر من 500.[3] وهو المقياس الذي حلّ محلّ FID رسميًّا في 12 مارس 2024، وأُلغي FID تمامًا من البرنامج، فمن رآه في مقالٍ يتحدّث عنه بوصفه مقياسًا حاليًّا فذلك مقالٌ قديم.[5] والفرق أنّ FID كان يقيس تأخّر أوّل تفاعلٍ فقط، أمّا INP فيقيس استجابة الصفحة عبر الزيارة كلّها. تخيّله نادلًا: النادل الجيّد يلتفت إليك فور أن تشير، لا بعد دقيقة. ويتكوّن هذا الزمن من ثلاثة أجزاء: تأخّر الإدخال (كم انتظر تفاعلك حتى يُعالَج)، ثمّ زمن المعالجة (تشغيل شيفرة الاستجابة)، ثمّ زمن العرض (رسم الإطار الجديد). وأطول هذه الأجزاء غالبًا انشغال الخيط الرئيسيّ بجافاسكربت، وهناك يكون العلاج.
CLS: إزاحة التخطيط التراكمية
Cumulative Layout Shift يقيس ثبات التخطيط: كم تتقافز عناصر الصفحة وتتزحزح أثناء تحميلها. وهو رقمٌ بلا وحدة (لأنّه حاصل ضرب مساحة الإزاحة في مسافتها)، عتبته الجيّدة: 0.1 أو أقلّ، والسيّئة: أكثر من 0.25.[4] تعرف أثره حين تهمّ بالنقر على زرٍّ فتقفز صورةٌ فوقه فتنقر خطأً على إعلان. هذا التقافز هو ما يقيسه CLS ويعاقب عليه. ويُحسَب الرقم بضرب مساحة ما تحرّك من الشاشة في مسافة تحرّكه، فكلّما كبر العنصر المتقافز وبعُدت قفزته ساء الرقم. والقاعدة الذهبية لعلاجه بسيطة: احجز لكلّ عنصرٍ مكانه قبل أن يصل، فلا يزيح ما حوله حين يظهر.
مثالٌ من صفحةٍ واحدة
لنجمع الثلاثة في مقالٍ عاديّ فيه صورة غلافٍ كبيرة، وقائمةٌ تفاعلية، وإعلانٌ في الأعلى. صورة الغلاف الثقيلة على استضافةٍ بطيئة تؤخّر ظهور أكبر محتوًى (LCP)، فيحدّق القارئ في فراغٍ ثوانيَ. والقائمة التي تُشغّل جافاسكربت ثقيلًا عند النقر تؤخّر الاستجابة (INP)، فتبدو «جامدة» لحظة يضغطها. والإعلان الذي يُحمَّل بلا مساحةٍ محجوزة يدفع النصّ للأسفل فجأةً فيسوء الثبات (CLS)، فيفقد القارئ سطره. صفحةٌ واحدة، وثلاث مشكلاتٍ في ثلاث طبقات: الاستضافة والصورة، وجافاسكربت، والتخطيط. عالِج كلّ داءٍ في موضعه.
الميدان والمختبر: أيّهما يُرتّبك؟
هنا الفرق الذي يخلط بين الجميع، وفهمه يوفّر عليك حيرةً طويلة. هناك نوعان من البيانات. بيانات الميدان (Field Data) مأخوذةٌ من مستخدميك الحقيقيّين عبر «تقرير تجربة مستخدمي كروم» (CrUX)، على مدى ثمانيةٍ وعشرين يومًا، عند المئين الخامس والسبعين. هذه هي المرتبطة بإشارة الترتيب.[7] وبيانات المختبر (Lab Data) ناتجةٌ عن محاكاةٍ في بيئةٍ مضبوطة (كأداة Lighthouse)، مفيدةٌ للتشخيص، لكنّها ليست ما يُرتّبك جوجل عليه.[1]
القاعدة العملية: بيانات الميدان تقول لك «أين المشكلة ولمن»، وبيانات المختبر تقول لك «لماذا وكيف أصلحها». ولاحظ أنّ INP وإزاحة CLS يحتاجان تفاعلًا حقيقيًّا وتمريرًا للصفحة، فلا تظهران كاملةً في محاكاة المختبر، وهذا يؤكّد أنّ الميدان هو الحقيقة. فلا تفرح بنتيجةٍ مختبريّةٍ ممتازة إن كانت بيانات ميدانك سيّئة؛ زوّارك هم الحَكَم.
وسير العمل عمليًّا: يريك تقرير Search Console المجموعات السيّئة من صفحاتك (ميدان)، فتأخذ نموذجًا منها إلى PageSpeed Insights لتشخيصه (مختبر)، فتصلح السبب، ثمّ تنتظر. وهنا صبرٌ لازم: بيانات الميدان متوسّطٌ متحرّكٌ على ثمانيةٍ وعشرين يومًا، فلن يظهر أثر إصلاحك في يومه، بل يتحسّن الرقم تدريجيًّا مع دخول بيانات المستخدمين الجدد. لا تحكم على إصلاحك بعد ساعة.
الأسباب والعلاج
الجميل أنّ معالجة هذه المؤشرات جزءٌ من السيو التقنيّ، فكلّ مؤشرٍ يعود غالبًا إلى طبقةٍ تعرفها من مهاراتك: LCP مشكلة استضافةٍ وصور، وINP مشكلة جافاسكربت، وCLS مشكلة HTML وCSS.
- LCP: أسبابه خادمٌ بطيء (زمن أوّل بايت طويل)، وموارد حاجبة للعرض (CSS/JS)، وصورة غلافٍ ثقيلة. علاجه: استضافةٌ أسرع أو شبكة توصيلٍ (CDN)، وإزالة ما يحجب العرض، وضغط صورة الغلاف وتحميلها مسبقًا (preload) مع رفع أولويّتها بـfetchpriority=”high” لتُجلب أوّلًا، وألّا تضع عليها loading=”lazy”، فهذا خطأٌ شائع يؤخّر أهمّ عنصر. واحرص أن يكون عنصر LCP ظاهرًا في شيفرة الصفحة الأولى لا مُحقَنًا بجافاسكربت، كي يكتشفه المتصفّح مبكرًا.[2]
- INP: سببه مهامّ جافاسكربت طويلة تشغل «الخيط الرئيسي» فتعجز الصفحة عن الاستجابة (تخيّل عاملًا واحدًا في مصنعٍ منشغلًا بمهمّةٍ ضخمة لا يسمع نداءك). علاجه: تقسيم «المهامّ الطويلة» (وهي أيّ مهمّةٍ تشغل الخيط الرئيسيّ أكثر من 50 مِلّي ثانية) إلى قطعٍ صغيرة، وتأجيل جافاسكربت غير الضروريّ، ونقل الحسابات الثقيلة إلى «عمّال الويب» (Web Workers).[3]
- CLS: سببه صورٌ أو إطاراتٌ بلا أبعادٍ محدّدة، وإعلاناتٌ تُحجَز بلا مساحة، وخطوطٌ تتبدّل متأخّرةً، ومحتوًى يُحقَن فوق محتوًى موجود. علاجه: حدّد width وheight (أو aspect-ratio) لكلّ وسائطك، واحجز مساحة الإعلانات مسبقًا، وحمّل الخطوط باكرًا، ولا تُقحم محتوًى فوق ما يقرؤه الزائر.[4]
ونصيحةٌ توفّر عليك التخمين: لا تحزر عنصر LCP في صفحتك، فأداة Lighthouse تسمّيه لك صراحةً في تقريرها. اعرف أوّلًا ما أكبر عنصرٍ مرئيّ، ثمّ وجّه إليه تحسينك بدل أن تحسّن ما لا يؤثّر.
بأيّها تبدأ؟
لا تعالج الثلاثة دفعةً واحدة. افتح بيانات ميدانك وابدأ بالمؤشّر الذي يقع فيه أكثر صفحاتك خارج نطاق «الجيّد». وكقاعدةٍ عامّة: إن كان LCP سيّئًا فهو الأظهر لزائرك (شاشةٌ بطيئة) والأسرع أثرًا حين تعالج الخادم والصور. وإن كان INP سيّئًا فهو الأصعب والأكثر ارتباطًا بالتفاعل، ومكانه جافاسكربتك. وإن كان CLS سيّئًا فهو غالبًا الأسهل: أبعادٌ ومساحاتٌ محجوزة. أصلح الأسوأ عند مستخدميك أوّلًا، لا الأسهل عليك أنت.
ولستَ مضطرًّا أن تكون خبير أداء. أكثر المواقع تحسّن مؤشراتها الثلاثة بخطواتٍ لا تحتاج خبرةً عميقة: استضافةٌ جيّدة (تعالج LCP من جذره)، وإضافة تخزينٍ مؤقّت، وضغط الصور وخدمتها بحجمٍ مناسبٍ وصيغةٍ حديثة، وقالبٌ خفيف لا يثقله جافاسكربت زائد. هذه الأربع تحلّ معظم مشكلات الموقع المتوسّط. أمّا التحسين الدقيق (تقسيم المهامّ، والتحميل المسبق، وحجز المساحات) فتصل إليه حين تُبقي بيانات ميدانك مؤشّرًا بعينه خارج «الجيّد». ابدأ بالأساسيات، ولا تغرق في التفاصيل قبل أن تحتاجها.
تحسيناتٌ عملية: الصور والخطوط والتخزين
أكثر ما يبطئ الصفحات ثلاثة: الصور، والخطوط، وغياب التخزين المؤقّت. والصور أثقلها. اخدم صورك بصيغةٍ حديثة (WebP أو AVIF) فهي أخفّ بكثير من JPEG وPNG بجودةٍ مماثلة، وبأبعادٍ لا تتجاوز ما يظهر على الشاشة (لا ترفع صورةً عرضها أربعة آلاف بكسل لتعرضها في ثمان مئة)، مع سمة srcset لتقديم الحجم المناسب لكلّ جهاز. وحمّل الصور تحت الطيّة تحميلًا كسولًا (lazy)، لكن لا تفعل ذلك بصورة LCP كما مرّ.[2]
والخطوط سببٌ خفيّ للإزاحة والبطء معًا: الخطّ الذي يُحمَّل متأخّرًا إمّا يقفز محلّ خطٍّ احتياطيّ فيسبّب إزاحة، أو يخفي النصّ حتى يصل. عالِج هذا بخاصّية font-display لعرض نصٍّ احتياطيّ فورًا، وبتحميل خطّك الأساسيّ مسبقًا (preload).[4] وأخيرًا، فعّل التخزين المؤقّت (caching) وشبكة توصيل المحتوى (CDN): الأوّل يجنّب الزائر العائد تحميل كلّ شيءٍ من جديد، والثانية تقرّب ملفّاتك منه جغرافيًّا فتخفّض زمن أوّل بايت الذي يبدأ منه LCP.
القاتل الصامت: السكربتات الخارجية
من أكثر ما يفسد الأداء دون أن ينتبه صاحب الموقع: السكربتات الخارجية. كلّ إعلانٍ، وأداة تحليلات، ونافذة دردشة، وزرّ مشاركةٍ اجتماعيّ، يحمّل شيفرةً من موقعٍ آخر تشغل الخيط الرئيسيّ وتؤخّر LCP وINP معًا. راجع ما حمّلته على صفحتك واسأل: أكلّ هذه ضرورية؟ احذف ما لا تحتاجه، وأجّل تحميل ما يمكن تأجيله (كأزرار المشاركة والدردشة) حتى يفرغ المتصفّح من عرض المحتوى الأساسيّ. تنظيف صفحتك من السكربتات الزائدة قد يفوق أثره أيّ تحسينٍ آخر تفعله، لأنّك تعالج السبب لا العَرَض.
كيف تقرأ تقرير PageSpeed
حين تفحص صفحةً في PageSpeed Insights، لا تتوقّف عند الرقم الملوّن الكبير، فهو مختبريّ. انظر أوّلًا إلى قسم «تقييم تجربة المستخدم الفعلية» في الأعلى: هذه بيانات الميدان من CrUX، وهي ما يهمّ للترتيب. إن كانت مؤشّراتك الثلاثة «جيّدة» هناك، فأنت بخيرٍ مهما كان الرقم المختبريّ أقلّ من المثاليّ. ثمّ انزل إلى قسمَي «التشخيص» و«الفرص»: يسمّي لك التقرير عنصر LCP، والموارد الحاجبة للعرض، والمهامّ الطويلة، ويقدّر كم من الوقت توفّر إن عالجت كلًّا منها. عالِج الأعلى أثرًا أوّلًا، ثمّ أعِد الفحص. بهذا تعمل على السبب لا على الرقم.
الأدوات: أيّها ميدانٌ وأيّها مختبر
اعرف طبيعة كلّ أداةٍ قبل أن تثق برقمها:
- PageSpeed Insights: يجمع الاثنين: بيانات ميدانٍ من CrUX (إن توفّرت) وتشخيصًا مختبريًّا من Lighthouse. ابدأ به.
- تقرير مؤشرات أداء الويب في Search Console: بيانات ميدانٍ لموقعك كلّه، يجمّع صفحاتك في مجموعات «جيّدة/تحتاج تحسينًا/سيّئة». هذا يريك حجم المشكلة على موقعك الحقيقيّ.
- Lighthouse وأدوات مطوّري كروم: مختبرٌ للتشخيص العميق أثناء التطوير، يسمّي لك عنصر LCP ويرصد الموارد الحاجبة والمهامّ الطويلة بالاسم.
- مكتبة web-vitals ولوحة CrUX: لقياس الميدان بنفسك بدقّة أكبر.
وملاحظةٌ ترفع عنك التباسًا: كان في Search Console «تقرير تجربة الصفحة» أزالته جوجل سنة 2023، لأنّ «تجربة الصفحة» مفهومٌ ومجموعة إشاراتٍ لا تقريرٌ واحد ولا درجةٌ واحدة. أمّا تقرير «مؤشرات أداء الويب» نفسه فما زال قائمًا وهو ما تعتمد عليه.[8]
جرّبه بنفسك
افتح PageSpeed Insights وأدخِل رابط صفحةٍ مهمّة من موقعك. انظر أوّلًا إلى قسم «بيانات الميدان» في الأعلى (إن وُجد): أهي «جيّدة» في المؤشرات الثلاثة عند المستخدمين الحقيقيّين؟ ثمّ انزل إلى «التشخيص» المختبريّ لتعرف ما يبطئ LCP أو يزيد CLS. لا تطارد الرقم 100؛ يكفي أن تجتاز العتبات. في دقائق تعرف أيّ طبقةٍ تحتاج عملك: الاستضافة، أم جافاسكربت، أم التخطيط.
لماذا يستحقّ الأداء عناءك؟
حتى لو كان أثر هذه المؤشرات في الترتيب خفيفًا، فالأداء يستحقّ عملك لأسبابٍ أثقل من الترتيب نفسه. الزائر الذي ينتظر ثوانيَ يغادر قبل أن يقرأ حرفًا، والزرّ الذي لا يستجيب يفقده الثقة، والمحتوى المتقافز يفقده موضعه فيتركك محبَطًا. الصفحة السريعة المستقرّة تُبقي القارئ، وترفع تحويلاتك، وتسهّل على أنظمة الذكاء الاصطناعيّ قراءة صفحتك واستخلاص جوابها منها. فاعمل على الأداء لأنّه يخدم الإنسان، لا لتصطاد إشارةً خفيفة في الخوارزمية.
خرافاتٌ يجب دفنها
- «FID ما زال مؤشرًا أساسيًّا»: أُلغي في 12 مارس 2024 وحلّ محلّه INP.[5]
- «تحتاج نتيجة 100 في PageSpeed»: لا؛ الهدف اجتياز العتبات عند المستخدمين الحقيقيّين، لا رقمٌ مثاليّ في المختبر.[1]
- «نتيجة المختبر هي ما يُرتّبك»: لا؛ بيانات الميدان (CrUX عند المئين 75) هي المرتبطة بالإشارة.[1]
- «الأداء يتفوّق على المحتوى في الترتيب»: لا؛ إشارةٌ خفيفة ترجّح بين المتقاربين، والمحتوى الأكثر صلة هو الأساس.[6]
- «العتبات متوسّطات»: لا؛ هي عند المئين الخامس والسبعين من مستخدميك الحقيقيّين.[1]
من الأداء إلى الفهم
ضبطتَ الآن كيف تُقدَّم صفحتك للزائر: سريعةً، مستجيبةً، ثابتة. لكنّ الصفحة السريعة قد تبقى غامضةً على المحرّك في معناها: ما هذا المحتوى بالضبط؟ منتجٌ بسعرٍ وتقييم، أم وصفةٌ بمكوّنات، أم مقالٌ بمؤلّفٍ وتاريخ؟ أن تصف محتواك للمحرّك بلغةٍ يفهمها هو البابُ التالي. ذلك موضوع المقال التالي: «البيانات المنظّمة (Schema)»، حيث تنتقل من سرعة الصفحة إلى إفهام المحرّك معناها. ابدأ اليوم بفحص صفحةٍ واحدة في PageSpeed Insights، وانظر بيانات ميدانها قبل مختبرها.
المصادر
- web.dev: Web Vitals. المؤشرات الثلاثة، وقياسها عند المئين الخامس والسبعين، والفرق بين الميدان والمختبر.
- web.dev: Largest Contentful Paint (LCP). عتبتا 2.5 و4 ثوانٍ، وأسباب البطء وعلاجه (preload، وعدم lazy على عنصر LCP).
- web.dev: Interaction to Next Paint (INP). عتبتا 200 و500 مِلّي ثانية، وتعريفه، وأسبابه في الخيط الرئيسي وعلاجها.
- web.dev: Cumulative Layout Shift (CLS). عتبتا 0.1 و0.25، وأسباب الإزاحة (الأبعاد، الإعلانات، الخطوط) وعلاجها.
- web.dev: INP becomes a Core Web Vital (March 12, 2024). حلول INP محلّ FID وإلغاء FID.
- Google Search Central: Understanding page experience. لا إشارة واحدة للتجربة، والمحتوى الأكثر صلة هو الأساس، والتجربة مرجّحٌ خفيف.
- Google Search Central: Core Web Vitals & Google Search. اعتماد الإشارة على بيانات الميدان.
- Search Engine Land: Google removes the Page Experience report. إزالة تقرير تجربة الصفحة سنة 2023 وبقاء تقرير مؤشرات أداء الويب.