چرا Google Lighthouse شامل INP، یک وب اصلی حیاتی نیست؟
لایت هاوس گوگل از معیار Interaction to Next Paint (INP) در تست های استاندارد خود استفاده نمی کند، علیرغم اینکه INP یکی از Core Web Vitals است.
بری پولارد، مدافع توسعه دهنده عملکرد وب در گوگل کروم، دلیل این امر را توضیح داد و بینش هایی را در مورد اندازه گیری INP ارائه کرد.
فانوس دریایی بارهای صفحه را اندازه گیری می کند، نه تعاملات
Lighthouse یک بار ساده صفحه را اندازه گیری می کند و ویژگی های مختلفی را در طول این فرآیند ثبت می کند.
می‌تواند بزرگترین رنگ محتوایی (LCP) و تغییر چیدمان تجمعی (CLS) را در شرایط بار خاص تخمین بزند، مشکلات را شناسایی کند و در مورد بهبود این معیارها توصیه کند.
با این حال، INP متفاوت است زیرا به تعاملات کاربر بستگی دارد.
پولارد توضیح داد:
مشکل اینجاست که Lighthouse، دوباره مانند بسیاری از ابزارهای web perf، معمولاً صفحه را بارگذاری می‌کند و با آن ارتباط برقرار نمی‌کند. بدون تعامل = بدون INP برای اندازه گیری!
جریان های کاربر سفارشی اندازه گیری INP را فعال می کند
در حالی که Lighthouse نمی تواند INP را اندازه گیری کند، دانستن سفرهای معمول کاربر به شما امکان می دهد از “جریان های کاربر” برای اندازه گیری INP استفاده کنید.
پولارد افزود:
“اگر شما به عنوان یک مالک سایت از سفرهای مشترک کاربران خود مطلع هستید، می توانید آنها را در Lighthouse با استفاده از “جریان های کاربر” اندازه گیری کنید که سپس INP را اندازه گیری می کند.”
این سفرهای مشترک کاربر را می توان در یک محیط یکپارچه سازی مداوم خودکار کرد و به توسعه دهندگان این امکان را می دهد تا INP را در هر commit آزمایش کنند و رگرسیون های بالقوه را شناسایی کنند.
کل زمان مسدود شدن به عنوان یک پروکسی INP
اگرچه Lighthouse نمی‌تواند INP را بدون تعامل اندازه‌گیری کند، اما می‌تواند علل احتمالی، به‌ویژه طولانی‌مدت، مسدود کردن وظایف جاوا اسکریپت را اندازه‌گیری کند.
اینجاست که معیار کل زمان انسداد (TBT) وارد عمل می شود.
به گفته پولارد:
TBT (زمان مسدود کردن کل) مجموع زمان تمام وظایف را بیشتر از 50 میلی ثانیه اندازه گیری می کند. نظریه این است:
- بسیاری از کارهای طولانی و مسدود کننده = خطر بالای INP!
- چند کار طولانی و مسدود کننده = خطر کم INP!
محدودیت های TBT به عنوان یک جایگزین INP
TBT به عنوان یک جایگزین INP محدودیت هایی دارد.
پولارد خاطرنشان کرد:
«اگر در طول کارهای طولانی تعامل نداشته باشید، ممکن است مشکل INP نداشته باشید. همچنین فعل و انفعالات ممکن است جاوا اسکریپت بیشتری را بارگیری کنند که توسط Lighthouse اندازه گیری نمی شود.
او می افزاید:
بنابراین این یک سرنخ است، اما نه جایگزینی برای اندازه گیری واقعی INP.
بهینه سازی امتیازات فانوس دریایی در مقابل تجربه کاربر
برخی از توسعه دهندگان امتیازات Lighthouse را بدون در نظر گرفتن تأثیر کاربر بهینه می کنند.
پولارد در این مورد هشدار می دهد و می گوید:
«الگوی رایجی که من می بینم این است که همه JS را تا زمانی که کاربر با یک صفحه تعامل کند به تأخیر بیاندازد: برای امتیازات Lighthouse عالی است! اغلب برای کاربران وحشتناک 😢:
- گاهی اوقات تا زمانی که ماوس را حرکت ندهید هیچ چیز بارگذاری نمی شود.
- اغلب اولین تعامل شما با تاخیر بیشتری همراه است.
پست کامل پولارد
چرا این مهم است
درک روابط Lighthouse، INP و TBT برای بهینه سازی تجربه کاربر ضروری است.
شناخت محدودیت ها در اندازه گیری INP به جلوگیری از بهینه سازی های نادرست کمک می کند.
توصیه پولارد برای اندازه گیری INP این است که بر تعاملات واقعی کاربر تمرکز کنید تا اطمینان حاصل شود که بهبود عملکرد باعث افزایش UX می شود.
از آنجایی که INP یک Core Web Vital باقی می ماند، درک نکات ظریف آن برای حفظ آن در یک آستانه قابل قبول ضروری است.
کاربردهای عملی
برای نظارت بر عملکرد سایت و INP:
- از “جریان های کاربر” Lighthouse برای اندازه گیری INP در سفرهای معمولی استفاده کنید.
- برای نظارت بر INP و گرفتن رگرسیون، جریان های کاربر در CI را خودکار کنید.
- از TBT به عنوان یک پروکسی INP استفاده کنید، اما محدودیت های آن را درک کنید.
- برای داده های INP دقیق، اندازه گیری های میدانی را اولویت بندی کنید.
- بهینه سازی عملکرد را با ملاحظات UX متعادل کنید.
تصویر ویژه: Ye Liew/Shutterstock
