مؤشرات أداء الويب: تحسين LCP وINP وCLS
· PoolByte
لا تقتصر الصفحة السريعة على وصول الملف الأول بسرعة فحسب. متى يرى الزائر المحتوى الرئيسي، وكم من الوقت ينتظر عندما يضغط على الزر، وهل تتغير المنطقة التي يحاول قراءتها؟ تقيس مؤشرات أداء الويب الأساسية ثلاثة أجزاء مختلفة من هذه التجربة باستخدام LCP وINP وCLS. إن تقييم المقاييس بشكل منفصل يمنع تطبيق الحل الخاطئ على المشكلة الخاطئة.
على سبيل المثال، قد يتم تحميل صورة صفحتك الرئيسية بسرعة، ولكن عند النقر على قائمة الهاتف المحمول، قد يتوقف الهاتف عن العمل لفترة قصيرة. بينما يكون التفاعل سلسًا على صفحة أخرى، قد يؤدي الشعار التالي إلى الضغط على زر الدفع لأسفل. ولا تفسر النتيجة الإجمالية الواحدة السبب الجذري لهاتين المشكلتين.
ماذا تقول العتبات الحالية؟
في وثائق web.dev التي تم فحصها في 11 أكتوبر 2026، حدود الخبرة الجيدة هي:
- LCP: 2.5 ثانية أو أقل.
- INP: 200 مللي ثانية أو أقل.
- CLS: 0.1 أو أقل.
يتم التقييم على أساس النسبة المئوية الخامسة والسبعين من مشاهدات الصفحة، مع الأخذ في الاعتبار الأجهزة المحمولة وسطح المكتب بشكل منفصل. فمجرد كون أحد المقاييس جيدًا لا يعني أن المقاييس الأخرى جيدة أيضًا. اتبع الثلاثة معًا. للحصول على الإصدار الحالي من الحدود، راجع الوثائق الرسمية في نهاية المقالة.
النسبة المئوية ليست المتوسط. من الناحية الافتراضية، إذا حققت قيمة LCP البالغة خمسة وسبعين من أصل مائة زائر الهدف، وكان الباقي أعلى، فستحتاج إلى التحقق من مجموعة المستخدمين الذين يواجهون التجربة البطيئة. إن معرفة الجهاز ونوع الصفحة والرابط المتأثر يؤدي إلى اتخاذ قرار أكثر وظيفية من المتوسط العام.
LCP: متى يظهر المحتوى الرئيسي؟
يتتبع LCP محتوى الرسم، مثل الصورة أو كتلة النص أو الفيديو، الأكبر حجمًا في المنطقة المرئية. ستكون صورة الغلاف الكبيرة مرشحة لمعظم التصاميم؛ ولكنها ليست نفس العنصر في كل صفحة. لا تركز فقط على تصغير جميع الصور دون معرفة العنصر الذي يمثل LCP في تقرير القياس.
كسر سلسلة البطء: الاستجابة الأولية للخادم، واكتشاف المصدر، وتنزيل الصورة وعرضها. إذا استجاب الخادم متأخرًا، تكون الأولوية لجانب التطبيق والاستضافة. إذا تم طلب صورة كبيرة في وقت متأخر، فقد يتأخر اكتشاف الموارد بسبب HTML أو التصميم أو JavaScript. وينبغي أيضًا مراعاة ترك الصورة الرئيسية للمنطقة المرئية الأولى للتحميل البطيء غير الضروري.
قم بإعداد حجم الصورة وفقًا لمنطقة الاستخدام. قم باختيار المتغير المناسب للمساحة الصغيرة التي سيعرضها الهاتف بدلاً من تنزيل ملف سطح المكتب العملاق. تطبيق إعدادات التحميل المسبق والأولوية العالية فقط على الموارد الضرورية حقًا؛ إن جعل كل ملف أولوية ليس خطة.
INP: كيف تستجيب الصفحة للتفاعل؟
يقوم INP بتقييم التأخير بعد نقر الزائر وتفاعلات لوحة المفاتيح حتى التحديث المرئي التالي. إنه ليس قياسًا دقيقًا للمدة الكاملة لتشغيل شبكة الخلفية للزر. قد يكون هناك عمل كبير في الخيط الرئيسي مما يؤدي إلى تأخير التعليقات المرئية الأولية للمستخدم.
قد تؤدي مهام JavaScript الطويلة أو التصفية المكثفة أو عرض أجزاء كبيرة من الشاشة إلى إبطاء الاستجابة. في مثال تصفية المنتج، يمكن اعتباره أولاً إظهار قبول الاختيار، وتقسيم العمل الباهظ الثمن إلى أجزاء صغيرة وتقليل التكرار غير الضروري. قم أيضًا بقياس تأثير أدوات الطرف الثالث المضافة إلى الصفحة.
قد لا يمثل إطلاق الصفحة لمرة واحدة تجربة INP بشكل مناسب. جرب مسارات حقيقية مثل قائمة الهاتف المحمول، والبحث، وعلامات التبويب، وأخطاء النماذج، والإضافة إلى سلة التسوق. عندما تكتشف تأخرًا في الاختبارات المعملية، تحقق من عدد مرات ظهور نفس السلوك في مقاييس الزائر.
CLS: ما مدى استقرار التسوية؟
يعبر CLS عدديًا عن تحولات الطلب غير المتوقعة. قد تؤدي أسباب مثل عدم تخصيص مساحة لصورة يتم تحميلها لاحقًا أو إضافة منطقة إعلان أو إعلان من الأعلى أو تغيير الخط إلى نقل الصفحة. يعد تغيير الهدف عندما يكون المستخدم على وشك الضغط على الزر أكثر من مجرد قطعة أثرية بصرية بسيطة.
حدد حجم أو نسبة العرض إلى الارتفاع للصور ومقاطع الفيديو مسبقًا. تخصيص المساحة المناسبة للمكونات اللاحقة. اختبر رسائل التأكيد والأخطاء وإشعارات ملفات تعريف الارتباط على شاشات مختلفة. مجرد التحقق من الصورة الأولى على الشاشة لا يكفي؛ التمرير والمحتوى المتأخر مهمان أيضًا.
بيانات ميدانية منفصلة واختبارات معملية
بيانات المستخدم الحقيقية التي تظهر في أدوات مثل PageSpeed Insights ونتائج الاختبار الخاضع للرقابة تجيب على أسئلة مختلفة. تُظهر البيانات الميدانية تجربة الأجهزة والاتصالات المختلفة. تساعدك بيئة المختبر على إعادة إنتاج الخطأ والتحقيق في سببه.
قد تتغير نتيجة المختبر فورًا بعد التحسن، لكن لا تتوقع أن يتحسن التقرير الميداني من الزيارات السابقة في نفس الوقت. إذا كانت البيانات الميدانية غير مرئية بسبب عدم وجود حركة مرور كافية، فلا تفسر ذلك على أنه "أداء مثالي". في القياس الخاص بك، ضع في اعتبارك نطاق البيانات التي تجمعها وخصوصية المستخدم.
أمر العمل المعمول به
- حدد أنواع الصفحات الأكثر استخدامًا ومسارات المستخدم المهمة.
- تاريخ بدء القيم للجوال وسطح المكتب.
- تحديد عنصر أو تفاعل المقياس الضعيف.
- قم بتطبيق مجموعة واحدة من التغييرات واختبارها مرة أخرى.
- التحقق من حماية النموذج والدفع وسلوكيات الوصول.
- رصد الاتجاه في البيانات الميدانية بعد النشر.
يساعد دليل موارد الاستضافة على فهم قيود الخادم، ويساعد دليل CDN على فهم طبقة التوزيع. لمناقشة الحزمة المناسبة، يمكنك إرسال سيناريو القياس والاستخدام إلى صفحة الاتصال.
الأسئلة المتداولة
إذا كانت نتيجة المنارة 100، فهل تنتهي المهمة؟
لا. يتم أيضًا تقييم الأجهزة الحقيقية وتدفقات الجلسة والمحتوى اللاحق. تدعم المقاييس الجيدة تجربة الزائر؛ جوجل لا تضمن الترتيب.
هل يمكن حل كل مشكلة بخادم أكثر قوة؟
قد تتحسن استجابة الخادم، ولكن يجب إصلاح الأسباب مثل تعليمات العميل الثقيلة أو الصورة غير المحددة من جانب التطبيق.