چرا Google Lighthouse شامل INP نمی شود که جزء ضروری وب است

لایت هاوس گوگل از معیار تعامل با گرافیک بعدی (INP) در تست های بنچمارک خود استفاده نمی کند، با وجود اینکه INP یکی از شاخص های اصلی وب آن است.

بری پولارد، مدافع توسعه‌دهنده عملکرد وب گوگل کروم، دلیل این امر را توضیح داد و بینش‌هایی را در مورد اندازه‌گیری INP ارائه کرد.

Lighthouse بارهای صفحه را اندازه گیری می کند، نه تعاملات

Lighthouse یک بار ساده صفحه را اندازه گیری می کند و ویژگی های مختلفی را در طول این فرآیند ثبت می کند.

این می تواند بزرگترین پوشش محتوای (LCP) و جابجایی طرح تجمعی (CLS) را در شرایط بارگذاری خاص تخمین بزند، مشکلات را شناسایی کند و در مورد بهبود این معیارها توصیه کند.

با این حال، INP متفاوت است زیرا به تعاملات کاربر بستگی دارد.

پولارد توضیح داد:

«مشکل این است که Lighthouse، مانند بسیاری از ابزارهای بهینه‌سازی وب، معمولاً فقط صفحه را بارگیری می‌کند و با آن تعامل ندارد = بدون INP برای اندازه‌گیری!»

جریان های کاربر سفارشی امکان اندازه گیری INP را فراهم می کند

اگرچه Lighthouse نمی تواند INP را اندازه گیری کند، اما دانستن سفرهای رایج کاربران به شما امکان می دهد از User Flow برای اندازه گیری INP استفاده کنید.

پولارد افزود:

“اگر شما به عنوان مالک سایت می دانید چه سفرهای کاربر رایج است، می توانید آنها را در Lighthouse با استفاده از User Flow اندازه گیری کنید که سپس INP را اندازه گیری می کند.”

این سفرهای مشترک کاربر را می توان در یک محیط یکپارچه سازی مداوم خودکار کرد و به توسعه دهندگان این امکان را می دهد تا INP را در هر commit آزمایش کنند و رگرسیون های بالقوه را شناسایی کنند.

کل زمان بلوک به عنوان یک عامل INP

اگرچه Lighthouse نمی تواند INP را بدون تعامل اندازه گیری کند، اما می تواند علل بالقوه را اندازه گیری کند، به خصوص دلایل طولانی که منجر به مسدود ، وظایف جاوا اسکریپت می شود.

این جایی است که معیار زمان بلوک کل (TBT) وارد عمل می شود.

به گفته پولارد:

TBT (زمان بلوک کل) مجموع زمان را برای تمام وظایف بیش از 50 میلی ثانیه اندازه گیری می کند.

• بسیاری از وظایف طولانی و مسدود = خطر بالا برای INP!
• چند کار طولانی و مخرب = خطر کم برای INP!

محدودیت های TBT به عنوان جایگزینی برای INP

TBT به عنوان جایگزینی برای INP محدودیت هایی دارد.

پولارد خاطرنشان کرد:

“اگر در طول کارهای طولانی با هم تعامل نداشته باشید، ممکن است هیچ مشکلی در INP نداشته باشید، همچنین ممکن است جاوا اسکریپت بیشتری بارگیری شود که توسط Lighthouse قابل اندازه گیری نباشد.

او می افزاید:

بنابراین این یک راهنما است، اما جایگزینی برای اندازه گیری واقعی INP نیست.

بهینه سازی نتایج Lighthouse در مقابل تجربه کاربر

برخی از توسعه دهندگان نتایج Lighthouse را بدون در نظر گرفتن تأثیر کاربر بهینه می کنند.

پولارد هشدار می دهد:

“الگوی رایجی که من می بینم این است که همه JS را تا زمانی که کاربر با صفحه تعامل داشته باشد به تعویق بیاندازد: برای نتایج Lighthouse اغلب وحشتناک است!

• گاهی اوقات تا زمانی که ماوس را حرکت ندهید، هیچ چیز لود نمی شود.
• اولین تعامل شما اغلب با تاخیر بیشتری همراه است.

پست کامل پولارد

چرا این مهم است؟

درک روابط Lighthouse، INP و TBT برای بهبود تجربه کاربر ضروری است.

شناخت محدودیت ها در اندازه گیری INP به جلوگیری از پیشرفت های گمراه کننده کمک می کند.

توصیه پولارد برای اندازه گیری INP تمرکز بر تعاملات واقعی کاربر برای اطمینان از بهبود عملکرد و بهبود تجربه کاربر است.

از آنجایی که INP هنوز یکی از عناصر اصلی وب است، درک تفاوت های ظریف آن برای حفظ آن در محدوده قابل قبول ضروری است.

کاربردهای عملی

برای نظارت بر عملکرد سایت و INP:

1. از جریان های کاربر Lighthouse برای اندازه گیری INP در سواری های مشترک استفاده کنید.
2. جریان های کاربر در CI را برای نظارت بر INP و نظارت بر رگرسیون ها به طور خودکار انجام دهید.
3. از TBT به عنوان یک پروکسی INP استفاده کنید، اما محدودیت های آن را درک کنید.
4. برای به دست آوردن داده های INP دقیق، اندازه گیری های میدانی را اولویت بندی کنید.
5. متعادل ، بهبود عملکرد با ملاحظات تجربه کاربر.

تصویر ویژه: یی لیو/ شاتر استوک