شرح Core Web Vitals لأصحاب المواقع
تقيس Core Web Vitals التحميل والاستجابة والثبات البصري. تعرّف على معنى LCP وINP وCLS والدرجات المستهدفة ومن أين تبدأ الإصلاح.
Core Web Vitals ثلاثة مقاييس تستخدمها Google لوصف شعور الزائر الحقيقي بالصفحة: مدى سرعة ظهور المحتوى الرئيسي، ومدى سرعة تفاعل الصفحة عند النقر أو اللمس، وهل يقفز التخطيط أثناء التحميل. وهي جزء من إشارات تجربة الصفحة لدى Google، لكن السبب الأهم للاهتمام بها أبسط: الزوار يغادرون الصفحات البطيئة والمتقافزة، ونادراً ما يخبرونك لماذا.
يشرح هذا الدليل المقاييس الثلاثة بلغة بسيطة، والعتبات التي تنشرها Google، وكيف تقرر ما تصلحه أولاً في موقع شركة صغيرة عادي.
المقاييس الثلاثة في لمحة
| المقياس | ما يقيسه | جيد | ضعيف |
|---|---|---|---|
| LCP (Largest Contentful Paint) | الزمن حتى يكتمل رسم أكبر عنصر مرئي | 2.5 ثانية أو أقل | أكثر من 4 ثوانٍ |
| INP (Interaction to Next Paint) | المدة التي تستغرقها الصفحة للاستجابة بصرياً بعد لمسة أو نقرة أو ضغطة مفتاح | 200 مللي ثانية أو أقل | أكثر من 500 مللي ثانية |
| CLS (Cumulative Layout Shift) | مقدار تحرك المحتوى المرئي بشكل غير متوقع | 0.1 أو أقل | أكثر من 0.25 |
القيم الواقعة بين «جيد» و«ضعيف» تقع ضمن نطاق «يحتاج إلى تحسين». وتقيّم Google الصفحة عند المئين الخامس والسبعين من الزيارات الحقيقية، أي أن ثلاثة أرباع زوارك ينبغي أن يحصلوا على تجربة عند العتبة أو أفضل منها. واختبار سريع واحد على حاسوبك المحمول لا يثبت نجاح الصفحة.
Largest Contentful Paint: هل تظهر الصفحة؟
يفحص LCP أكبر صورة أو ملصق فيديو أو كتلة نصية في الشاشة الأولى ويسجل متى ينتهي رسمها. وفي معظم المواقع يكون ذلك صورة رئيسية كبيرة أو عنواناً ضخماً. ويأتي بطء LCP عادةً من أحد أربعة أسباب: استجابة بطيئة من الخادم، أو صورة ثقيلة أو سيئة التنسيق، أو CSS أو JavaScript يعطل الرسم، أو اكتشاف المتصفح للصورة الأساسية متأخراً.
Interaction to Next Paint: هل تستجيب الصفحة؟
حلّ INP محل مقياس First Input Delay القديم في مارس 2024. فبينما كان First Input Delay ينظر إلى التفاعل الأول فقط وإلى التأخير قبل بدئه فقط، يأخذ INP التفاعلات على امتداد الزيارة كلها ويبلغ عن أحد أبطئها، من لحظة الإدخال إلى رسم الإطار التالي. والصفحات التي تُحمَّل بسرعة لكنها تبدو متثاقلة عند فتح قائمة أو ضغط زر يكون فيها عادةً مشكلة JavaScript: شيفرة أكثر من اللازم تعمل على الخيط الرئيسي دفعة واحدة.
Cumulative Layout Shift: هل تبقى الصفحة ثابتة؟
يجمع CLS الحركات غير المتوقعة للعناصر المرئية. لقد جربت هذا حين هممت بالنقر على رابط فتحمّل بانر فوقه ودفع الرابط إلى الأسفل. ومن المسببات الشائعة صور بلا سمتَي العرض والارتفاع، وإعلانات وتضمينات تتحمل متأخرة، وخطوط تتبدل فيتغير حجم النص، ولافتات ملفات تعريف الارتباط المحقونة أعلى الصفحة.
بيانات المختبر مقابل بيانات الميدان
هناك نوعان من القياس، وخلطهما يسبب الالتباس.
- بيانات الميدان تأتي من زوار حقيقيين يستخدمون أجهزة وشبكات حقيقية. تجمعها Google من مستخدمي Chrome وتعرضها في PageSpeed Insights وSearch Console حين يكون لموقعك زيارات كافية. وهذه هي المعتمدة في التقييم.
- بيانات المختبر تأتي من اختبار محاكى، مثل Lighthouse. يمكن تكراره، ما يجعله مثالياً لتصحيح الأخطاء، لكنه جهاز واحد على اتصال واحد.
قد لا يكون للموقع الصغير بيانات ميدانية على الإطلاق. في هذه الحالة استخدم اختبارات المختبر لإيجاد المشكلات وتعامل مع النتائج على أنها إرشاد لا حكم نهائي.
من أين تبدأ الإصلاح
- قِس الصفحات المهمة. اختبر صفحتك الرئيسية وأكثر صفحات الهبوط زيارةً ومقالاً أو صفحة منتج نموذجية بملف الجوال. لا تأخذ متوسط الموقع كله.
- أصلح المقياس الأبطأ أولاً. إذا كان LCP ضعيفاً وCLS جيداً، فاعمل على LCP.
- ابدأ بالمكاسب الرخيصة. اضغط الصورة الرئيسية وغيّر حجمها، وحدد أبعاد الصور، وفعّل التخزين المؤقت، وفكر في CDN، وأزل الإضافات أو السكربتات التي لم تعد تستخدمها.
- أعد الاختبار بعد كل تغيير. غيّر شيئاً واحداً في كل مرة لتعرف ما الذي أفاد.
- انتظر حتى تلحق بيانات الميدان. تُجمع الأرقام الواقعية على مدى فترة متحركة، لذا تحتاج التحسينات بضعة أسابيع لتظهر كاملة.
ما علاقة الاستضافة بذلك
تتعلق Core Web Vitals في معظمها بطريقة بناء الصفحة، لكن الاستضافة تحدد الحد الأدنى. فاستجابة الخادم البطيئة تؤخر كل ما يليها، وهذا يضر LCP مباشرة. والخوادم المزدحمة وإصدارات PHP القديمة وغياب التخزين المؤقت على جانب الخادم كلها تضيف وقتاً قبل أن يتلقى المتصفح أول بايت. ولا يستطيع العمل الجيد على الواجهة الأمامية التعويض كلياً عن خلفية بطيئة.
توقع واقعي
اجتياز المقاييس الثلاثة هدف يستحق العناء، لكنه ليس مفتاح ترتيب سحرياً. فملاءمة المحتوى ما تزال أهم بكثير. فكّر في Core Web Vitals على أنها إزالة للاحتكاك: لن تجعل صفحة ضعيفة تتصدر النتائج، لكن الصفحة البطيئة المتقافزة تصعّب عليك الاحتفاظ بالزوار الذين كسبتهم أصلاً.
أخطاء شائعة يرتكبها أصحاب المواقع
- مطاردة درجة Lighthouse مثالية. الدرجة 100 في اختبار مختبر ليست الهدف. الهدف اجتياز العتبات الثلاث لدى الزوار الحقيقيين.
- الاختبار على سطح المكتب فقط. يجري معظم التقييم على الجوال، وأجهزة الجوال أبطأ معالجاتٍ واتصالاتٍ.
- تثبيت إضافة سرعة والتوقف عندها. قد تساعد الإضافات في التخزين المؤقت ومعالجة الصور، لكنها لا تستطيع إزالة صورة رئيسية بحجم 3 ميغابايت أو عشرات سكربتات التسويق.
- تجاهل القوالب. الصفحات المبنية من القالب نفسه تتشارك عادةً المشكلات نفسها، فإصلاح القالب يصلح صفحات كثيرة دفعة واحدة. وتجمّع Search Console الروابط المتشابهة لهذا السبب بالضبط.
احتفظ بسجل بسيط لما غيّرته والدرجة قبل التغيير وبعده. فهو يوفر التخمين حين يتراجع شيء بعد تحديث إضافة.
الصفحات السريعة تبدأ من الخادم
في Zebra Hosting Cloud، تشمل كل خطة لوحة تحكم Plesk التي تتيح لك اختيار إصدارات PHP الحديثة، وتتوفر Cloudflare CDN على المواقع المستضافة لتقديم الملفات الثابتة أقرب إلى الزوار. وهذان معاً يغطيان جانب الخادم من المعادلة فتتفرغ للصفحة نفسها. اطلع على ما تقدمه كل خطة في نظرة عامة على الاستضافة.