فریم ورک های مدرن چگونه بر روی معیار INP جدید کار می کنند

درک کنید که چگونه معیار INP جدید بر تجربه سایت های ساخته شده با استفاده از چارچوب ها و کتابخانه های جاوا اسکریپت تأثیر می گذارد.

Leena Sohoni

Addy Osmani

Keen Yee Liau

Chrome اخیراً یک معیار سنجش پاسخگویی آزمایشی جدید را در گزارش Chrome UX Report معرفی کرده است. این معیار که اکنون آن را به عنوان تعامل با رنگ بعدی (INP) می شناسیم، پاسخگویی کلی به تعاملات کاربر در صفحه را اندازه گیری می کند. امروز می‌خواهیم بینش‌هایی درباره جایگاه وب‌سایت‌هایی که با استفاده از چارچوب‌های جاوا اسکریپت مدرن ساخته شده‌اند در رابطه با این معیار به اشتراک بگذاریم. ما می خواهیم در مورد اینکه چرا INP به چارچوب ها مرتبط است و چگونه Aurora و فریم ورک ها برای بهینه سازی پاسخگویی کار می کنند بحث کنیم.

زمینه

Chrome از تاخیر ورودی اول ( FID ) به عنوان بخشی از Core Web Vitals ( CWV ) برای اندازه‌گیری پاسخگویی بار وب‌سایت‌ها استفاده می‌کند. FID زمان انتظار را از اولین تعامل کاربر تا لحظه ای که مرورگر قادر به پردازش گردانندگان رویداد متصل به تعامل است اندازه گیری می کند. این شامل زمان پردازش کنترل‌کننده‌های رویداد، پردازش تعاملات بعدی در همان صفحه، یا نقاشی فریم بعدی پس از اجرای تماس‌های رویداد نمی‌شود. با این حال، پاسخگویی برای تجربه کاربر در طول چرخه عمر صفحه بسیار مهم است زیرا کاربران تقریباً 90٪ از زمان را پس از بارگیری صفحه در آن صرف می کنند.

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

از آنجایی که FID فقط تاخیر ورودی اولین تعامل را اندازه گیری می کند، این احتمال وجود دارد که توسعه دهندگان وب به طور فعال تعاملات بعدی را به عنوان بخشی از فرآیند بهبود CWV خود بهینه نکرده باشند. بنابراین، سایت‌ها، به‌ویژه آن‌هایی که میزان تعامل بالایی دارند، باید سخت کار کنند تا بتوانند این معیار را به خوبی انجام دهند.

نقش چارچوب ها

از آنجایی که بسیاری از وب سایت ها برای ارائه تعامل به جاوا اسکریپت متکی هستند، امتیاز INP در درجه اول تحت تأثیر میزان جاوا اسکریپت پردازش شده در رشته اصلی قرار می گیرد. چارچوب‌های جاوا اسکریپت بخش مهمی از توسعه وب پیشرفته مدرن هستند و انتزاع‌های ارزشمندی را برای مسیریابی، مدیریت رویدادها و تقسیم‌بندی کد جاوا اسکریپت در اختیار توسعه‌دهندگان قرار می‌دهند. بنابراین، آنها نقش مرکزی در بهینه سازی پاسخگویی و تجربه کاربری وب سایت هایی دارند که از آنها استفاده می کنند.

Frameworks ممکن است با بهبود FID برای وب‌سایت‌ها، قدم‌هایی برای پاسخ‌گویی بهتر برداشته باشد. با این حال، آنها اکنون باید داده های متریک پاسخگویی موجود را تجزیه و تحلیل کنند و برای رفع شکاف های شناسایی شده تلاش کنند. به طور کلی، INP تمایل به نرخ عبور پایین‌تری دارد و تفاوت در فرآیند اندازه‌گیری نیازمند بهینه‌سازی کد اضافی است. جدول زیر به طور خلاصه دلیل آن را نشان می دهد.

تیم Aurora در Chrome با چارچوب‌های وب منبع باز کار می‌کند تا به توسعه‌دهندگان کمک کند جنبه‌های مختلف تجربه کاربر، از جمله عملکرد و معیارهای CWV ​​را بهبود بخشند. با معرفی INP، ما می خواهیم برای تغییر معیارهای CWV ​​برای وب سایت های مبتنی بر چارچوب آماده باشیم. ما داده ها را بر اساس معیار پاسخگویی آزمایشی در گزارش های CrUX جمع آوری کرده ایم. برای سهولت انتقال به معیار INP برای وب‌سایت‌های مبتنی بر چارچوب، بینش‌ها و موارد اقدام را به اشتراک می‌گذاریم.

داده های متریک پاسخگویی تجربی

INP کمتر یا مساوی 200 میلی ثانیه نشان دهنده پاسخگویی خوب است. داده های گزارش CrUX و گزارش فناوری CWV ​​برای ژوئن 2023 اطلاعات زیر را در مورد پاسخگویی برای چارچوب های محبوب جاوا اسکریپت به ما می دهد.

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

جاوا اسکریپت چگونه بر INP تأثیر می گذارد؟

مقادیر INP در این زمینه به خوبی با زمان انسداد کل (TBT) مشاهده شده در آزمایشگاه همبستگی دارد. این می تواند به این معنی باشد که هر اسکریپتی که رشته اصلی را برای مدت طولانی مسدود کند برای INP بد است. اجرای سنگین جاوا اسکریپت پس از هر تعاملی می تواند رشته اصلی را برای مدت طولانی مسدود کند و پاسخ به آن تعامل را به تاخیر بیندازد. برخی از دلایل رایجی که منجر به مسدود کردن اسکریپت ها می شود عبارتند از:

• جاوا اسکریپت بهینه نشده: کد اضافی یا استراتژی‌های ضعیف تقسیم کد و بارگذاری می‌تواند باعث نفخ جاوا اسکریپت شود و رشته اصلی را برای مدت طولانی مسدود کند. تقسیم کد، بارگذاری تدریجی، و شکستن کارهای طولانی می تواند زمان پاسخگویی را به طور قابل توجهی بهبود بخشد.

• اسکریپت‌های شخص ثالث: اسکریپت‌های شخص ثالث ، که گاهی برای پردازش یک تعامل (مثلاً اسکریپت‌های تبلیغاتی) مورد نیاز نیستند، می‌توانند رشته اصلی را مسدود کرده و باعث تاخیرهای غیرضروری شوند. اولویت بندی اسکریپت های ضروری می تواند به کاهش تاثیر منفی اسکریپت های شخص ثالث کمک کند.

• کنترل‌کننده‌های رویداد چندگانه: کنترل‌کننده‌های رویداد چندگانه مرتبط با هر تعامل، که هر کدام یک اسکریپت متفاوت را اجرا می‌کنند، می‌توانند با یکدیگر تداخل داشته باشند و باعث تأخیر طولانی شوند. برخی از این کارها ممکن است غیر ضروری باشند و می‌توانند در وب‌کارگر یا زمانی که مرورگر غیرفعال است، برنامه‌ریزی شوند.

• سربار چارچوب در مدیریت رویداد: فریم ورک ها ممکن است ویژگی ها/ نحو اضافی برای مدیریت رویداد داشته باشند. به عنوان مثال، Vue از v-on برای اتصال شنوندگان رویداد به عناصر استفاده می کند، در حالی که Angular کنترل کننده رویداد کاربر را می پوشاند. پیاده‌سازی این ویژگی‌ها به کد فریمورک اضافی بالای جاوا اسکریپت vanilla نیاز دارد.

• Hydration: هنگام استفاده از یک چارچوب جاوا اسکریپت، غیر معمول نیست که یک سرور HTML اولیه یک صفحه را تولید کند که سپس باید با کنترل کننده رویداد و وضعیت برنامه افزوده شود تا بتواند در یک مرورگر وب تعاملی باشد. ما این فرآیند را هیدراتاسیون می نامیم. بسته به مدت زمان بارگیری جاوا اسکریپت و اتمام هیدراتاسیون، این می تواند فرآیند سنگینی در حین بارگذاری باشد. همچنین می تواند منجر به این شود که صفحات به نظر تعاملی باشند در حالی که نیستند. اغلب هیدراتاسیون به طور خودکار در حین بارگذاری صفحه یا با تنبلی (مثلاً در تعامل با کاربر) اتفاق می‌افتد و به دلیل زمان‌بندی کار می‌تواند بر INP یا زمان پردازش تأثیر بگذارد. در کتابخانه‌هایی مانند React، می‌توانید از useTransition استفاده کنید تا بخشی از رندر کامپوننت در فریم بعدی باشد و هر گونه عوارض جانبی پرهزینه‌تر به فریم‌های آینده سپرده شود. با توجه به این موضوع، به‌روزرسانی‌هایی که در مرحله انتقال به‌روزرسانی‌های فوری‌تری مانند کلیک‌ها ارائه می‌شوند، می‌توانند الگوی خوبی برای INP باشند.

• واکشی اولیه: واکشی تهاجمی منابع مورد نیاز برای پیمایش‌های بعدی، زمانی که به درستی انجام شود، می‌تواند یک پیروزی در عملکرد باشد. با این حال، اگر مسیرهای SPA را از قبل واکشی و به صورت همزمان رندر کنید، می‌توانید تأثیر منفی بر INP داشته باشید زیرا تمام این رندرهای گران قیمت تلاش می‌کنند در یک فریم کامل شوند. این را با عدم واکشی از قبل مسیر خود و در عوض شروع کار مورد نیاز (مثلا fetch() ) و رفع انسداد رنگ مقایسه کنید. توصیه می‌کنیم دوباره بررسی کنید که آیا رویکرد چارچوب شما برای واکشی اولیه UX بهینه را ارائه می‌کند و چگونه (اگر اصلاً باشد) این ممکن است بر INP تأثیر بگذارد.

از این پس، برای کسب امتیاز INP خوب، توسعه‌دهندگان باید روی مرور کدهایی که پس از هر تعامل در صفحه اجرا می‌شود تمرکز کنند و استراتژی‌های chunking، rehydration، بارگذاری و اندازه هر به‌روزرسانی () render را برای هر دو بهینه‌سازی کنند. اسکریپت های شخص و شخص ثالث،

Aurora و چارچوب ها چگونه به مسائل INP رسیدگی می کنند؟

Aurora با استفاده از بهترین روش‌ها برای ارائه راه‌حل‌های آماده برای مشکلات رایج، با چارچوب‌ها کار می‌کند. ما با Next.js، Nuxt.js، Gatsby و Angular روی راه‌حل‌هایی کار کرده‌ایم که پیش‌فرض‌های قوی را در چارچوب برای بهینه‌سازی عملکرد ارائه می‌دهند. نکات برجسته کار ما در این زمینه به شرح زیر است:

• React و Next.js: جزء Next.js Script به رفع مشکلات ناشی از بارگذاری ناکارآمد اسکریپت های شخص ثالث کمک می کند. تکه تکه‌سازی دانه‌ای در Next.js معرفی شد تا امکان ایجاد تکه‌های کوچک‌تر برای کدهای مشترک را فراهم کند. این به کاهش مقدار کدهای رایج استفاده نشده که در همه صفحات دانلود می شود کمک می کند. ما همچنین با Next.js کار می کنیم تا داده های INP را به عنوان بخشی از سرویس Analytics آنها در دسترس قرار دهیم.

• Angular: Aurora در حال همکاری با تیم Angular برای بررسی بهبودهای رندر سمت سرور و هیدراتاسیون است. ما همچنین قصد داریم به اصلاحات در مدیریت رویداد و تشخیص تغییرات برای بهبود INP توجه کنیم.

• Vue و Nuxt.js: ما در حال بررسی راه‌هایی برای همکاری، عمدتاً در رابطه با بارگیری و رندر اسکریپت هستیم.

چارچوب ها چگونه به بهبود INP فکر می کنند؟

React و Next.js

برش زمان React.js که از طریق startTransition و Suspense پیاده سازی شده است، به شما امکان می دهد هیدراتاسیون انتخابی یا پیشرونده را انتخاب کنید. این بدان معنی است که هیدراتاسیون یک بلوک همزمان نیست. این کار در برش های کوچکی انجام می شود که در هر نقطه ای قابل وقفه هستند.

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

Next.js یک چارچوب مسیریابی جدید را پیاده سازی کرده است که از startTransition به طور پیش فرض برای انتقال مسیر استفاده می کند. این به صاحبان سایت Next.js اجازه می‌دهد تا زمان‌بندی React را اتخاذ کنند و پاسخ‌گویی انتقال مسیر را بهبود بخشند.

زاویه ای

تیم Angular در حال بررسی چندین ایده است که باید به INP نیز کمک کند:

• Zoneless: اندازه اولیه بسته نرم افزاری و کدهای مورد نیاز را کاهش می دهد که باید قبل از اینکه برنامه بتواند هر چیزی را ارائه کند، بارگیری شود.
• هیدراتاسیون: آبرسانی به سبک جزیره برای محدود کردن مقداری از برنامه که برای تعامل باید بیدار شود.
• کاهش هزینه های اضافی CD: به عنوان مثال، هزینه تشخیص تغییر را کم کنید، راه هایی برای بررسی کمتر برنامه پیدا کنید و از سیگنال های واکنشی در مورد آنچه تغییر کرده است استفاده کنید.
• تقسیم کد دانه ای بیشتر: بسته اولیه را کوچکتر کنید.
• پشتیبانی بهتر از نشانگرهای بارگیری: به عنوان مثال، در هنگام رندر مجدد SSR، در طول مسیریابی مسیر، و در عملیات بارگیری تنبل.
• ابزارهای پروفایل: ابزارهای توسعه دهنده بهتر برای درک هزینه تعامل، به ویژه در مورد هزینه تشخیص تغییر برای تعاملات خاص.

از طریق این پیشرفت‌ها، می‌توانیم به مسائل مختلفی که منجر به پاسخ‌گویی ضعیف و تجربه کاربر می‌شود، رسیدگی کنیم و معیارهای CWV ​​و معیار INP جدید را برای وب‌سایت‌های مبتنی بر چارچوب تقویت کنیم.

نتیجه

ما انتظار داریم که امتیاز INP قطب نمای بهتری برای وب سایت ها برای بهبود پاسخگویی و عملکرد در آینده ارائه کند. ما بر اساس راهنمای INP موجود خود می‌سازیم تا در سال 2023 نکات عملی‌تری را برای توسعه‌دهندگان چارچوب ارائه کنیم. امیدواریم با موارد زیر به این مهم دست یابیم:

• ایجاد کانال هایی برای دسترسی آسان به داده های میدانی در INP برای چارچوب ها و توسعه دهندگان وب.
• برای ایجاد ویژگی هایی که به طور پیش فرض INP را بهبود می بخشد، با چارچوب ها کار کنید.

ما از بازخورد کاربران فریم ورک هنگام شروع سفر بهینه سازی INP خود استقبال می کنیم.