LCP وINP أصبحا الآن خط الأساس المتوفر حديثًا | مدونة | web.dev
تاريخ النشر: 17 ديسمبر 2025
مع إصدار Safari 26.2 في 12 ديسمبر، حصل أداء الويب على هدية رائعة لنهاية العام مع أكبر رسم محتوى (LCP) والتفاعل مع الطلاء التالي (INP) الذي أصبح خطًا أساسيًا متاحًا حديثًا حيث يتضمن الإصدار الأحدث من جميع المتصفحات الرئيسية الآن أكبر واجهة برمجة تطبيقات للرسم المحتوى وواجهة برمجة تطبيقات توقيت الأحداث اللازمة لقياس هذه المقاييس. كان هذا جزءًا من مشروع Interop 2025، ومن الرائع أن يتم تسليمها هذا العام!
ماذا يعني هذا
أصبحت مؤشرات أداء الويب الأساسية معيارًا معتمدًا على نطاق واسع لقياس تجربة صفحة الويب لكل من مطوري الويب وأصحاب المصلحة في الأعمال. إنهم يحاولون تلخيص القصة المعقدة لأداء الويب في عدد من المقاييس الرئيسية لمدى سرعة تحميل الصفحة (LCP)، ومدى سرعة استجابتها للتفاعلات (INP)، ومدى استقرار محتوياتها (CLS).
لفترة طويلة، كانت هذه قابلة للقياس فقط في المتصفحات المستندة إلى Chromium مثل Chrome وEdge. كما أنها لم تكن متوفرة على الإطلاق على أجهزة iOS حيث تستخدم جميع المتصفحات محرك متصفح WebKit الذي يقوم بتشغيل Safari. يؤدي هذا إلى نقطة عمياء حيث قد يكون لنسبة كبيرة من زوار الموقع تجربة مختلفة تمامًا دون علم الموقع. في حين أن العديد من تحسينات أداء الويب تفيد جميع المتصفحات، إلا أن بعض التقنيات وواجهات برمجة التطبيقات متوفرة فقط في بعض المتصفحات. بالإضافة إلى ذلك، قد تختلف طريقة عمل المتصفحات داخليًا وتحميل الصفحات والتعامل مع التفاعلات عن بعضها البعض. إن الحصول على عرض جزئي لأداء موقعك ليس بالأمر المثالي على الإطلاق.
مع دعم جميع المتصفحات الرئيسية الآن لاثنين من هذه المقاييس، يمكننا الآن الحصول على رؤية أفضل حول التحميل الرئيسي والتفاعل لموقع الويب. سيسمح هذا لمالكي المواقع بفهم مشكلات الأداء بشكل أفضل وتحديد أي تحسينات يمكنهم إجراؤها، مما يفيد المستخدمين ومقاييس الأعمال في النهاية.
هل تغذي البيانات من المتصفحات الأخرى CrUX؟
لا. يعتمد تقرير تجربة مستخدم Chrome (CrUX) فقط على مستخدمي Chrome المؤهلين ولن يتغير هذا. وينطبق هذا أيضًا على الأنظمة النهائية التي تستخدم هذه البيانات مثل PageSpeed Insights وGoogle Search Console وCrUX Vis.
وسيستمر هذا أيضًا في استبعاد مستخدمي Chrome iOS نظرًا لاستخدامهم محرك متصفح WebKit.
كيفية القياس من المتصفحات الأخرى
لا تزال بيانات CrUX مفيدة كملخص لأداء الموقع، ولقياس الأداء مقارنةً بالمواقع الأخرى على الويب. ومع ذلك، نظرًا لأنه ملخص عالي المستوى، فقد أوصينا منذ فترة طويلة بقياس بيانات ميدانية أكثر تفصيلاً للمساعدة في تحديد الأداء وتحسينه.
أصبحت أدوات مراقبة المستخدم الحقيقية (RUM) الآن قادرة على جمع البيانات الميدانية الإضافية، بما في ذلك تلك التي تم قياسها من خلال مكتبة مؤشرات أداء الويب من فريق Chrome. في معظم الحالات، من المفترض أن يبدأ تضمين ذلك تلقائيًا من خلال حلولك الحالية، ولكن تحقق مع موفر RUM الخاص بك إذا كانت لديك أي أسئلة.
انتبه إلى أنه قد تكون هناك اختلافات بين RUM وCrUX، ومن المحتمل أن يكون هذا أكثر صحة الآن حيث تتوفر هذه المقاييس في المزيد من المتصفحات غير المضمنة في CrUX.
هل هناك أي اختلافات في التنفيذ؟
في حين أن جميع محركات المتصفح تقوم بنفس المهمة بشكل عام في تحميل صفحات الويب وعرضها، إلا أن هناك العديد من الاختلافات في كيفية إنشاء هذه المتصفحات، وخاصة في خطوط العرض الخاصة بها التي تترجم كود موقع الويب (في المقام الأول HTML وCSS وJavaScript) إلى وحدات بكسل على الشاشة.
نهاية حلقة العرض قابلة للتشغيل المتبادل على نطاق واسع ويتم تعريفها على أنها paintTime. ولكن بعد هذا هناك وقت لاحق presentationTime وهو خاص بالتنفيذ ويهدف إلى الإشارة إلى الوقت الذي يتم فيه رسم وحدات البكسل فعليًا على الشاشة. يقيس Chrome LCP حتى نهاية presentationTime، بينما لا يتضمن Firefox وSafari presentationTime وهكذا التدبير حتى وقت سابق paintTime. وينتج عن هذا ميلي ثانية طفيفة من الاختلاف بين التدابير. من Chrome 145، paintTime سيتم أيضًا عرض المقياس لـ LCP لأولئك الذين يريدون أن يكونوا قادرين على مقارنة المثل بالمثل عبر المتصفحات.
ينطبق نفس الاختلاف على INP أيضًا.
وقد ساعدت حقيقة قيام المتصفحات الأخرى بتنفيذ هذه المقاييس في تحديد بعض المشكلات المعلقة التي يتعين توضيحها وتحديدها بشكل أفضل. قد يؤدي هذا مرة أخرى إلى اختلافات طفيفة، على الرغم من أن هذه الاختلافات تكون في الغالب في حالات الحافة. هذه هي فائدة وجود تطبيقات متعددة وعين على واجهة برمجة التطبيقات! سنواصل العمل على هذه التحسينات بالإضافة إلى أي تحسينات أخرى على المقاييس.
ومع ذلك، على الرغم من هذه الاختلافات الصغيرة، نحن واثقون من أن LCP وINP قابلان للتشغيل المتبادل على نطاق واسع، لذلك نحن سعداء بتصنيفهما Baseline Newly متاح. قد يلاحظ أولئك الذين ينفذون حلول RUM أو يتعمقون في البيانات بعضًا من هذه الاختلافات، ولكن يجب أن يكون مطورو الويب واثقين من قياس هذه المقاييس عبر المتصفحات على الرغم من هذه الاختلافات الطفيفة.
ماذا عن المتصفحات التي لا تدعم واجهات برمجة التطبيقات هذه؟
الميزات الأساسية المتوفرة حديثًا متاحة فقط في أحدث الإصدارات من جميع المتصفحات الرئيسية. قد لا تتم ترقية قاعدة المستخدمين الخاصة بك على الفور، أو قد لا تتمكن من الترقية اعتمادًا على نظام التشغيل وموفر الخدمة الخاص بهم. وبعد مرور 30 شهرًا، سيتم اعتبارها متاحة على نطاق واسع حيث من المرجح أن يكون معظم المستخدمين يستخدمون المتصفحات الداعمة.
ومع ذلك، باعتبارك واجهة برمجة تطبيقات للقياس وليس وظيفة أساسية لموقع ويب، يمكنك قياس هذه المقاييس بأمان لدعم المتصفحات – كما فعلت على الأرجح حتى الآن. فقط انتبه إلى أنك قد تشاهد عرضًا تمت تصفيته للمستخدمين لديك – أولئك الذين قاموا بالترقية – خاصة في الأشهر القليلة الأولى.
ماذا عن التحول التراكمي للتخطيط؟
العنصر الأساسي الثالث للويب الحيوي هو التحول التراكمي للتخطيط (CLS)، وهو ليس جزءًا من مشروع Interop 2025 – على الرغم من أنه تم اقتراحه لـ Interop 2026. في الوقت الحالي، لا يتم دعمه خارج المتصفحات المستندة إلى Chromium.
خاتمة
كان هدف مبادرة Web Vitals هو تحسين أداء الويب من خلال إنشاء مجموعة من واجهات برمجة التطبيقات القياسية لمنصة الويب للسماح بقياس المقاييس الرئيسية وفهمها على نطاق واسع من قبل مالكي مواقع الويب. من الرائع أن نرى اثنين من هذه المقاييس مدعومة الآن بواسطة جميع المتصفحات الرئيسية. ونحن نتطلع إلى رؤية الرؤى التي توفرها هذه لأصحاب مواقع الويب، وكيف يؤدي ذلك إلى تحسين تجارب المستخدم!
