رؤية مؤشر أحمر سهلة؛ اختيار الإصلاح الأعلى أثراً أصعب. ضغط صورة أو إزالة سكربت طرف ثالث أو إعادة تصميم فلتر ليست أعمالاً متساوية في الكلفة أو النتيجة، كما أن صفحة سريعة في المختبر قد تتعثر على أجهزة المستخدمين الحقيقية.
المؤشرات المستقرة الحالية هي LCP وINP وCLS. يستهدف web.dev عند المئين 75 من الزيارات LCP لا يتجاوز 2.5 ثانية، وINP لا يتجاوز 200 مللي ثانية، وCLS لا يتجاوز 0.1، مع تقييم الجوال وسطح المكتب كلٌ على حدة.web.dev — تعريف حدود Core Web Vitals (يُفتح في علامة تبويب جديدة)
1. ثلاثة مؤشرات لثلاث مشكلات مستخدم مختلفة
يقرّب LCP وقت ظهور المحتوى الرئيسي، وقد يكون صورة المنتج أو العنوان الكبير. يتأثر باستجابة الخادم واكتشاف المورد وأولويته وتأخر العرض؛ وسؤال المستخدم هو: متى أرى الوعد الأساسي؟
يقيس INP اتساق استجابة الصفحة للنقر واللمس ولوحة المفاتيح. تؤدي مهام JavaScript الطويلة وDOM الكبير وإعادة العرض المكلفة إلى فلتر أو نموذج يبدو معطلاً.
يقيس CLS الحركة غير المتوقعة للعناصر بسبب وسائط بلا أبعاد أو banner متأخر أو خط متبدل. لا يعوض مؤشر آخر؛ قد يكون LCP جيداً وINP سيئاً.
| المؤشر | سؤال المستخدم | سبب شائع | الخطر |
|---|---|---|---|
| LCP | متى يظهر المحتوى؟ | خادم بطيء أو صورة متأخرة | مغادرة مبكرة |
| INP | متى يستجيب التفاعل؟ | مهمة JS طويلة أو DOM كبير | احتكاك النموذج أو السلة |
| CLS | لماذا تتحرك الصفحة؟ | وسائط أو محتوى ديناميكي | نقرة خاطئة وفقد ثقة |
2. لا تخلط بيانات الميدان باختبار المختبر
بيانات الميدان تجمع تجارب حقيقية على أجهزة وشبكات مختلفة، بينما المختبر يعيد ظروفاً مضبوطة لتشخيص السبب. استخدم الأولى لتحديد حجم المشكلة والثانية لتجربة الإصلاح.web.dev — Web Vitals (يُفتح في علامة تبويب جديدة)
لا تفسر غياب بيانات ميدانية لصفحة جديدة على أنه أداء جيد. استخدم بيانات الأصل أو القالب، والمختبر والمراقبة الخاصة حتى تتوافر عينة مناسبة.
قسّم حسب الجهاز والقالب والبلد عند الحاجة؛ المتوسط قد يخفي شريحة بطيئة ذات قيمة تجارية.
3. رتّب قائمة العمل بالأثر التجاري
اجمع حجم الوصول وأهمية المهمة وشدة المشكلة وقابلية الإصلاح. مشكلة INP في الدفع قد تسبق CLS في مقال قليل الاستخدام حتى لو كان الأخير أسهل.
اربط كل بند بقالب ومسار مستخدم ومؤشر عمل مثل إكمال النموذج أو إضافة السلة، لا برقم أداء فقط. اكتب فرضية قابلة للاختبار قبل التنفيذ.
لا تحول قيمة الصفحة المالية إلى العذر الوحيد؛ صفحات المساعدة قد تقلل الضغط على الدعم وتحمي الثقة.
| الحالة | الوصول | أهمية العمل | القرار الأول |
|---|---|---|---|
| LCP في فئة رئيسية | مرتفع | مرتفعة | شخّص القالب فوراً |
| CLS في محتوى نادر | منخفض | منخفضة | أجله إن لم يكن مكوناً مشتركاً |
| INP في الدفع | متوسط | شديدة | أعطه الأولوية |
| بطء سكربت طرف ثالث | مرتفع | متغيرة | وازن فائدته وكلفته |
4. ابنِ شجرة سبب جذري لكل مؤشر
قسّم LCP إلى استجابة الخادم وتأخر اكتشاف المورد ووقت التنزيل والعرض. عالج السبب المحدد: caching أو preload أو أولوية الصورة أو تقليل CSS الحاجب.
في INP حدد التفاعل البطيء ومهمة main thread التي تلته، ثم افصل تأخر الإدخال عن وقت المعالجة وتأخر العرض التالي. لا يقيس Lighthouse غير التفاعلي INP مباشرة؛ يمكن أن يساعد TBT في التشخيص المختبري لكنه ليس بديلاً عن بيانات INP الميدانية. قسّم العمل الطويل، وقلل JavaScript، وتجنب إعادة العرض غير الضرورية.
في CLS سجل مناطق الحركة في تسجيل أو أدوات التشخيص، ثم افحص الوسائط بلا أبعاد، والمساحات غير المحجوزة، وتبدل الخطوط، والمكونات الشرطية أو التابعة لطرف ثالث. أضف الأبعاد واحجز المساحة وثبّت استراتيجية الخط، ثم اختبر الإصلاح في الإنتاج وعلى أحجام شاشات مختلفة.
- جمعنا المشكلات حسب القالب والمكوّن.
- حددنا عنصر LCP ومرحلة التأخير.
- سمّينا تفاعل INP البطيء.
- تحققنا من مصدر CLS بالتسجيل.
- نعيد القياس في الميدان ومع مؤشر العمل.
5. مثال افتراضي: ربط سرعة صفحة فئة بالنتيجة
تظهر صفحة فئة افتراضية LCP ضعيفاً وتركاً مرتفعاً على الجوال. يكشف المختبر أن banner كبيراً يكتشف متأخراً، بينما تكشف التسجيلات أن الفلتر يعلق بعد النقر.
يصلح الفريق أولوية الصورة ثم يقسم عمل الفلتر، وينشر كل تغيير منفصلاً. يقارن CWV وإكمال الفلتر والانتقال إلى المنتج مع توثيق تغيرات السعر والحملة.
تحسن المقاييس معاً إشارة مفيدة، لكنه لا يثبت وحده سببية الزيادة التجارية.
6. ضع ميزانية أداء تحمي التحسن
حدد حدوداً للقالب: وزن الصور وJavaScript وعدد الأطراف الخارجية ووقت المهمة الطويلة. اجعل الحدود مرتبطة بالأجهزة المستهدفة لا بحاسوب الفريق.
شغّل فحوصاً في CI وراقب الميدان بعد النشر. لا تمنع الإصدار آلياً على تغير ضئيل بلا سياق؛ اطلب تفسيراً ومالكاً وانتهاء صلاحية للاستثناء.
راجع السكربتات الخارجية دورياً؛ الأداة التي لا يملك أحد هدفها تتحول إلى دين دائم. أنشئ سجلاً يضم المورد والغرض التجاري ونطاق البيانات وشرط التحميل والمالك وتاريخ انتهاء المراجعة، ولا تحمّل أداة في كل صفحة إذا كانت تخدم حملة واحدة فقط.
لا تجعل الميزانية رقماً واحداً لكل القوالب. قد يحتاج الدفع حداً أشد للتفاعل، بينما تحتاج المقالات حدوداً للصور والخطوط. اربط كل استثناء بسبب ومدة ومالك، ثم أعده إلى المراجعة بدلاً من تحويله إلى خط أساس جديد.
راقب الانحدار في المختبر والميدان معاً. قد يمر البناء ضمن حد الحجم بينما يبطئ API أو تتغير شيفرة طرف ثالث في الإنتاج. التنبيه الجيد يذكر القالب والمكوّن والتغير والمالك ويقود إلى قرار.
7. أخطاء شائعة وخطة أول 30 يوماً
تجنب مطاردة درجة 100 أو تحسين صفحة العرض فقط أو حذف وظائف نافعة بلا قياس. لا تستخدم جهازاً واحداً ولا تهمل الوصول والأخطاء.
الأسبوع الأول للجرد وبيانات الميدان، والثاني لتشخيص قوالب حرجة، والثالث لإصلاحين عاليي الأثر، والرابع للتحقق ووضع الميزانية.
اجعل الأداء مسؤولية منتج مستمرة بين التصميم والتطوير والتسويق، لا حملة طوارئ قبل الإطلاق.
- نفصل بيانات الجوال وسطح المكتب.
- ربطنا المسارات الحرجة بالأولوية.
- لكل إصلاح فرضية تقنية وتجارية.
- للسكربتات الخارجية مالك وتاريخ مراجعة.
- الميزانية مفحوصة في النشر.
- نقيس الوصول والأخطاء وإكمال المهمة مع CWV.
الخلاصة
الأداء الجيد ليس رقماً تجميلياً، بل قدرة المستخدم على رؤية المهمة وتنفيذها بثقة. قِس الميدان، وشخّص في المختبر، ورتّب العمل تجارياً، ثم احمِ التحسن بميزانية نشر.
الأسئلة الشائعة
المصادر
- web.dev — تعريف حدود Core Web Vitals (يُفتح في علامة تبويب جديدة)
أهداف LCP وINP وCLS ونهج المئين 75
- web.dev — Web Vitals (يُفتح في علامة تبويب جديدة)
المؤشرات المستقرة وقياس الميدان والمختبر
رتّب مشكلات السرعة حسب أثرها على المستخدم والعمل
لنجمع القوالب الحرجة وبيانات المستخدم والسبب التقني في خارطة أداء واحدة.
أنشئ خريطة أداء لموقعي
