تقيس مؤشرات Core Web Vitals هل صفحاتك سريعة بما يكفي لمن يزورها، بثلاثة قياسات مأخوذة من زيارات حقيقية: سرعة ظهور المحتوى الرئيسي (LCP)، وسرعة استجابة الصفحة للنقر واللمس والكتابة (INP)، ومقدار تحرّك عناصر الصفحة دون سابق إنذار (CLS).
يعرض هذا الدليل العتبات الحالية ومسارًا عمليًا يبدأ من البيانات الميدانية وينتهي بإصلاح ثبت أثره. واجتياز العتبات هدفٌ لتجربة المستخدم. وهو لا يضمن ترتيبًا أعلى ولا مبيعات أكثر، ولا يستطيع أحد أن يعدك بذلك.
تحدّد إرشادات Google عن Web Vitals على موقع web.dev العتبات الجيدة الحالية: 2.5 ثانية أو أقل لمقياس LCP، و200 ملّي ثانية أو أقل لمقياس INP، و0.1 أو أقل لمقياس CLS. وتقيّم الإرشادات كل مقياس عند المئين 75 من زيارات الصفحة، وتفصل الجوال عن سطح المكتب. أي أن الصفحة لا تجتاز العتبة إلا إذا حققتها أغلب الزيارات؛ والمتوسط الجيد وحده لا يُحتسب.
ويكشف كل مقياس نوعًا مختلفًا من الخلل:
- LCP يحدد لحظة اكتمال عرض أكبر عنصر محتوى في الشاشة، كصورة الواجهة أو كتلة العنوان. وضعفه يعني في أغلب الحالات أن المتصفح اكتشف المحتوى الرئيسي متأخرًا، أو أن المحتوى كان ثقيلًا، أو أنه انتظر الخادم أو ملفات تعطّل العرض.
- INP يراقب التفاعلات طوال الزيارة، ويعكس الزمن الذي احتاجته الصفحة لترسم استجابتها. وضعفه يعني غالبًا أن الخيط الرئيسي كان مشغولًا لحظة النقر، أو أن المعالج أدّى عملًا أكثر من اللازم.
- CLS يجمع الحركة غير المتوقعة للمحتوى الظاهر. وضعفه يعني غالبًا أن عنصرًا وصل بلا مساحة محجوزة: صورة بلا أبعاد، أو شريط يُدرَج أعلى الصفحة، أو خط متأخر يعيد توزيع النص.
ولأن لكل مقياس أسبابه، فعبارة «الموقع بطيء» لا تصلح تشخيصًا. وإذا كانت أداة أو تقرير ما يزال يعرض مقياس FID، فهو متأخر عن المجموعة الحالية؛ قِس الاستجابة بمقياس INP.
شكل 1: قِس الزيارات الحقيقية. حدود الأداء الجيد عند المئين 75.
تأتي البيانات الميدانية من زيارات حقيقية بأجهزتها وشبكاتها ولغاتها، أما بيانات المختبر فمن اختبار مضبوط تجريه بنفسك. من الأولى تعرف هل توجد مشكلة، ولمن، وفي أي صفحات؛ وبالثانية تعيد إنتاج المشكلة وتفحص سجل التتبّع وتجرّب الإصلاح قبل إطلاقه.
لا تناقض إذن في أن تكون نتيجة المختبر ممتازة بينما تخفق البيانات الميدانية. فاختبار تحميل على جهاز سريع، بلا نقر أو كتابة، لا يرى التفاعل البطيء الذي يواجهه زائر بهاتف متوسط القدرات بعد دقائق من التصفح. استخدم المختبر لتنظر عن قرب، والميدان لتحكم. وتأتي البيانات الميدانية من مجموعات بيانات عامة إن كانت زياراتك كافية لإدراج موقعك فيها، أو من مراقبة المستخدمين الحقيقيين (RUM) على صفحاتك.
لا تبدأ بالصفحة الرئيسية ولا بأسوأ نتيجة مختبرية، بل قسّم البيانات الميدانية حتى يصبح للمشكلة عنوان واضح:
- المقياس: أيّ المقاييس الثلاثة يخفق عند المئين 75؟
- نوع الجهاز: قد تجتاز الصفحة على سطح المكتب وتخفق على الجوال.
- قالب الصفحة: اجمع الروابط حسب القالب، كالمقال والمنتج وإتمام الطلب والبحث، لأن الإصلاح يحدث في القالب غالبًا.
- اللغة واتجاه الكتابة: كثيرًا ما تحمّل الصفحات العربية خطوطًا مختلفة، ويلتف نصها بطريقة أخرى، وقد تستخدم صور واجهة مختلفة؛ فقِس كل لغة على حدة.
- التفاعل: في حالة INP، سجّل التفاعل البطيء، كفتح القائمة أو الإضافة إلى السلة، إن كانت أدوات المراقبة تسجّله.
مثال توضيحي: متجر ثنائي اللغة يلاحظ أن LCP يخفق على الجوال في صفحات المنتجات العربية بينما تجتازه الإنجليزية. كان متوسط الموقع سيُخفي ذلك، لكن الشريحة تقودك إلى قالب واحد بلغة واحدة، تتنافس فيه صورة واجهة كبيرة وخط عربي على عرض النطاق في اللحظات الأولى من التحميل.
حاكِ الشريحة المتعثرة: القالب واللغة أنفسهما، وإبطاء للمعالج والشبكة يشبه أجهزة زوارك، والتفاعل الفعلي في حالة INP، يدويًا أو عبر سكربت. سجّل تتبّعًا للأداء، ثم اطرح السؤال المناسب للمقياس:
- LCP: ما العنصر الذي احتُسب، وما الذي أخّره: استجابة الخادم، أم تأخر اكتشاف الصورة، أم ملفات تنسيق أو خطوط تعطّل العرض، أم وزن الصورة؟
- INP: أيّ جزء من التفاعل كان بطيئًا: الانتظار قبل بدء المعالج، أم عمل المعالج نفسه، أم رسم الإطار التالي؟
- CLS: أيّ عنصر تحرّك، وما الذي وصل متأخرًا فدفعه؟
وإن لم تستطع إعادة إنتاج المشكلة، فالأرجح أن الشريحة ما تزال واسعة، أو أن السبب يعتمد على شيء غائب عن المختبر، كسكربت طرف ثالث لا يُحمَّل إلا لبعض الزوار.
لكل سبب مجموعة قصيرة من الإصلاحات المعتادة:
- محتوى رئيسي متأخر أو ثقيل (LCP): اجعل صورة الواجهة قابلة للاكتشاف في HTML الأولي، واضبط مقاسها على الشاشة، ولا تؤجّل تحميلها، وقلّل زمن استجابة الخادم بالتخزين المؤقت حيث يسمح المحتوى.
- خيط رئيسي مشغول لحظة التفاعل (INP): قسّم المهام الطويلة إلى أجزاء أصغر تفسح المجال للمتصفح، وقلّل JavaScript المرسلة إليه، وأجّل أعمال الطرف الثالث غير الضرورية، وأظهر استجابة بصرية فورية. وفي أطر React، يقلّل إبقاء الأجزاء غير التفاعلية على الخادم ما يحتاج المتصفح إلى تفعيله؛ ويشرح دليلنا عن مكوّنات الخادم والتخزين المؤقت في Next.js 15 هذه الحدود للفرق التي تصون هذا الإصدار.
- محتوى بلا مساحة محجوزة (CLS): حدّد أبعاد الصور والعناصر المضمّنة، واحجز مساحة للأشرطة ونوافذ الموافقة، وتجنّب إدراج محتوى فوق ما يقرؤه الزائر. وفي الخطوط العربية، حمّل المجموعات التي تحتاجها فقط، واختر طريقة تحميل لا يعيد فيها الخط البديل توزيع الصفحة.
وتدوم الإصلاحات أكثر حين تعيش في المكوّنات المشتركة: مكوّن صورة يرفض العرض بلا أبعاد، أو موضع ثابت الارتفاع للشريط الإعلاني. ويناقش مقالنا عن أنظمة التصميم بمساعدة الذكاء الاصطناعي كيف تبقى المكوّنات المولّدة متسقة وقابلة للمراجعة.
يبقى التحسّن في المختبر فرضية حتى تؤكده البيانات الميدانية. بعد الإطلاق، قارن الشريحة نفسها بالمقياس ونوع الجهاز واللغة أنفسها قبل التغيير وبعده، بعد أن تتراكم زيارات حقيقية كافية. ودوّن تواريخ الإطلاق حتى تربط أي تراجع لاحق بتغيير محدد.
ثم اجعل التراجع صعبًا:
- أضف ميزانيات أداء مختبرية إلى فحوص البناء أو طلبات الدمج إنذارًا مبكرًا، مع أنها لن تلتقط كل مشكلة ميدانية.
- أبقِ مراقبة المستخدمين الحقيقيين مقسّمة حسب القالب ونوع الجهاز واللغة.
- راجع سكربتات الطرف الثالث قبل إضافتها، فهي تشارك تفاعلات زوارك الخيط الرئيسي نفسه.
شكل 2: تحقق بعد الإطلاق. قارن الشريحة نفسها.
بعض الإصلاحات تفيد الجانبين: حجز مساحة لشريط متأخر يزيل إزاحة التخطيط ويمنع المحتوى من القفز تحت تركيز مستخدم لوحة المفاتيح. وبعض التغييرات تضر بإمكانية الوصول دون أن يظهر ذلك في أي مقياس، كإزالة مؤشر التركيز أو حذف النص البديل للصور أو تأجيل تحميل عنصر تحكم يحتاجه مستخدمو لوحة المفاتيح. ويسرد المرجع السريع لمعايير WCAG 2.2 الصادر عن W3C معايير للوصول بلوحة المفاتيح ووضوح التركيز والنصوص البديلة والتباين، فراجع تغييرات الأداء في ضوئها. ونجاح فحص آلي لا يعني إمكانية وصول كاملة، لذا أبقِ المراجعة البشرية باللغتين، بما فيها التخطيط من اليمين إلى اليسار.
وأحيانًا يكشف التتبّع سؤالًا عن المنتج بدل خلل في الأداء، مثل ما إذا كانت التجربة الشبيهة بالتطبيقات مكانها المتصفح أصلًا؛ ويشرح دليلنا عن الاختيار بين تطبيق الويب التقدمي والتطبيق الأصلي كيف تجمع أدلة القدرات على الأجهزة المستهدفة. وإن أردت مساعدة في تحويل بياناتك الميدانية إلى قائمة إصلاحات مرتّبة حسب الأولوية، فإن خدمة تحسين محركات البحث لدينا تجمع الإصلاحات التقنية مع المحتوى وخطة البحث.
- Google، موقع web.dev. Web Vitals: المقاييس الحالية وعتباتها الجيدة، والتقييم عند المئين 75 مع فصل الجوال عن سطح المكتب.
- مبادرة إمكانية الوصول إلى الويب في W3C. How to Meet WCAG 2.2 (Quick Reference): معايير إمكانية الوصول المشار إليها أعلاه.
تتغير تعريفات المقاييس والأدوات، فراجع الوثائق الحالية قبل أن تحدد أهدافك. والتوصيات الواردة هنا إرشادات من تكنوستاك، ولا تفرضها Google ولا W3C.
