بهینه سازی تعامل به رنگ بعدی

بیاموزید که چگونه تعامل وب سایت خود را با Next Paint بهینه کنید.

جرمی واگنر

فیلیپ والتون

Interaction to Next Paint (INP) یک معیار سنجش حیاتی وب اصلی است که پاسخگویی کلی صفحه به تعاملات کاربر را با مشاهده تأخیر تمام تعاملات واجد شرایطی که در طول عمر بازدید کاربر از یک صفحه رخ می دهد، ارزیابی می کند. مقدار نهایی INP طولانی ترین برهمکنش مشاهده شده است (گاهی اوقات نادیده گرفتن مقادیر پرت).

برای ارائه یک تجربه کاربری خوب، وب سایت ها باید تلاش کنند تا تعامل با رنگ بعدی 200 میلی ثانیه یا کمتر داشته باشند. برای اطمینان از رسیدن به این هدف برای اکثر کاربران خود، یک آستانه خوب برای اندازه گیری صدک 75 بارگذاری صفحه است که در دستگاه های تلفن همراه و دسکتاپ تقسیم بندی شده است.

بسته به وب‌سایت، ممکن است تعاملات کمی وجود داشته باشد یا اصلاً وجود نداشته باشد - مانند صفحاتی که عمدتاً متنی و تصاویری با عناصر تعاملی کم یا بدون عناصر تعاملی هستند. یا در مورد وب‌سایت‌هایی مانند ویرایشگرهای متن یا بازی‌ها، ممکن است صدها – حتی هزاران – تعامل وجود داشته باشد. در هر صورت، جایی که INP بالایی وجود دارد، تجربه کاربر در خطر است.

بهبود INP به زمان و تلاش نیاز دارد، اما پاداش تجربه کاربری بهتر است. در این راهنما، مسیری برای بهبود INP بررسی خواهد شد.

بفهمید که چه چیزی باعث INP ضعیف می شود

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

تعاملات آهسته را در میدان پیدا کنید

در حالت ایده آل، سفر شما در بهینه سازی INP با داده های میدانی آغاز می شود. در بهترین حالت، داده‌های میدانی از یک ارائه‌دهنده نظارت واقعی کاربر (RUM) نه تنها مقدار INP یک صفحه را به شما می‌دهد، بلکه داده‌های متنی را نیز به شما می‌دهد که نشان می‌دهد چه تعامل خاصی مسئول ارزش INP بوده است، خواه این تعامل در طول یا بعد از صفحه رخ داده باشد. بارگذاری، نوع تعامل (کلیک، فشار دادن کلید یا ضربه زدن) و سایر اطلاعات ارزشمند.

اگر برای دریافت داده‌های میدانی به ارائه‌دهنده RUM متکی نیستید، راهنمای داده‌های فیلد INP توصیه می‌کند از گزارش تجربه کاربر Chrome (CrUX) از طریق PageSpeed ​​Insights استفاده کنید تا به پر کردن شکاف‌ها کمک کنید. CrUX مجموعه داده رسمی برنامه Core Web Vitals است و خلاصه سطح بالایی از معیارها را برای میلیون ها وب سایت از جمله INP ارائه می دهد. با این حال، CrUX اغلب داده‌های متنی را که از یک ارائه‌دهنده RUM دریافت می‌کنید برای کمک به تجزیه و تحلیل مسائل ارائه نمی‌کند. به همین دلیل، ما همچنان توصیه می کنیم که سایت ها در صورت امکان از یک ارائه دهنده RUM استفاده کنند یا راه حل RUM خود را برای تکمیل آنچه در CrUX موجود است پیاده سازی کنند.

فعل و انفعالات کند را در آزمایشگاه تشخیص دهید

در حالت ایده‌آل، زمانی که داده‌های میدانی به دست آوردید که نشان می‌دهد تعاملات کندی دارید، می‌خواهید آزمایش را در آزمایشگاه شروع کنید. در غیاب داده های میدانی، راهبردهایی برای شناسایی تعاملات کند در آزمایشگاه وجود دارد. چنین استراتژی‌هایی شامل دنبال کردن جریان‌های مشترک کاربر و آزمایش تعاملات در طول مسیر، و همچنین تعامل با صفحه در حین بارگذاری - زمانی که رشته اصلی اغلب شلوغ‌ترین است - به منظور آشکارسازی تعاملات آهسته در طول آن بخش حیاتی از تجربه کاربر است.

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

هنگامی که یک تعامل کند را شناسایی کردید و می توانید آن را به صورت دستی در آزمایشگاه بازتولید کنید ، گام بعدی بهینه سازی آن است. تعاملات را می توان به سه مرحله تقسیم کرد:

1. تأخیر ورودی، که زمانی شروع می‌شود که کاربر تعامل با صفحه را آغاز می‌کند و زمانی پایان می‌یابد که تماس‌های رویداد برای تعامل شروع به اجرا می‌کنند.
2. زمان پردازش، که شامل مدت زمانی است که برای تکمیل تماس‌های رویداد طول می‌کشد.
3. تأخیر ارائه، یعنی زمانی که مرورگر برای ارائه فریم بعدی که حاوی نتیجه بصری تعامل است، طول می کشد.

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

شناسایی و کاهش تاخیر ورودی

هنگامی که کاربر با یک صفحه تعامل دارد، اولین بخش از آن تعامل تاخیر ورودی است. بسته به فعالیت های دیگر در صفحه، تاخیرهای ورودی می تواند از نظر طولانی مدت قابل توجه باشد. این می تواند به دلیل فعالیت روی رشته اصلی (شاید به دلیل بارگیری، تجزیه و کامپایل کردن اسکریپت ها)، مدیریت واکشی، عملکردهای تایمر، یا حتی به دلیل تعاملات دیگری باشد که به صورت متوالی و سریع اتفاق می افتد و با یکدیگر همپوشانی دارند.

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

رابطه بین ارزیابی اسکریپت و وظایف طولانی در طول راه اندازی

یکی از جنبه‌های مهم تعامل در چرخه حیات صفحه، هنگام راه‌اندازی است. هنگامی که یک صفحه بارگیری می شود، در ابتدا رندر می شود، اما مهم است که به خاطر داشته باشید که صرفاً به این دلیل که یک صفحه رندر شده است، به این معنی نیست که بارگیری صفحه تمام شده است. بسته به تعداد منابعی که یک صفحه برای عملکرد کامل نیاز دارد، ممکن است کاربران سعی کنند در حالی که صفحه هنوز در حال بارگذاری است، با آن ارتباط برقرار کنند.

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

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

بهینه سازی تماس های رویداد

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

اغلب به موضوع اصلی تسلیم شوید

بهترین توصیه کلی در بهینه سازی تماس های رویداد این است که تا حد امکان کمتر در آنها کار کنید. با این حال، منطق تعامل شما ممکن است پیچیده باشد، و شما ممکن است فقط بتوانید کاری که انجام می دهند را به طور جزئی کاهش دهید.

اگر متوجه شدید که این مورد برای وب‌سایت شما صادق است، چیزی که می‌توانید امتحان کنید این است که کار در تماس‌های رویداد را به کارهای جداگانه تقسیم کنید. این مانع از تبدیل شدن کار جمعی به یک کار طولانی می شود که رشته اصلی را مسدود می کند، که اجازه می دهد تا تعاملات دیگری که در غیر این صورت روی رشته اصلی منتظر می ماندند زودتر اجرا شوند.

setTimeout یکی از راه‌های جدا کردن وظایف است، زیرا پاسخ تماس ارسال شده به آن در یک کار جدید اجرا می‌شود. می توانید از setTimeout به تنهایی استفاده کنید یا استفاده از آن را در یک تابع جداگانه برای عملکرد ارگونومیک بیشتر انتزاع کنید.

تسلیم بی رویه بهتر از تسلیم نشدن است - با این حال، روش ظریف تری برای تسلیم شدن به رشته اصلی وجود دارد، و آن فقط شامل تسلیم شدن بلافاصله پس از تماس رویداد است که رابط کاربری را به روز می کند تا منطق رندر زودتر اجرا شود.

بازده تا اجازه دهید کار رندر زودتر انجام شود

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

به عنوان مثال، یک ویرایشگر متن غنی را تصور کنید که متن را هنگام تایپ قالب بندی می کند، اما در پاسخ به آنچه نوشته اید، سایر جنبه های UI را نیز به روز می کند (مانند شمارش کلمات، برجسته کردن اشتباهات املایی، و سایر بازخوردهای مهم بصری). علاوه بر این، برنامه ممکن است نیاز داشته باشد آنچه را که نوشته‌اید ذخیره کند تا در صورت خروج و بازگشت، هیچ اثری را از دست ندهید.

در این مثال، چهار مورد زیر باید در پاسخ به کاراکترهای تایپ شده توسط کاربر اتفاق بیفتد. با این حال، فقط اولین مورد باید قبل از ارائه فریم بعدی انجام شود.

1. کادر متن را با آنچه کاربر تایپ کرده به روز کنید و هر قالب بندی مورد نیاز را اعمال کنید.
2. بخشی از رابط کاربری را که تعداد کلمات فعلی را نمایش می دهد، به روز کنید.
3. منطق را اجرا کنید تا اشتباهات املایی را بررسی کنید.
4. آخرین تغییرات (به صورت محلی یا در پایگاه داده راه دور) را ذخیره کنید.

کد انجام این کار ممکن است چیزی شبیه به زیر باشد:

textBox.addEventListener('input', (inputEvent) => {
  // Update the UI immediately, so the changes the user made
  // are visible as soon as the next frame is presented.
  updateTextBox(inputEvent);

  // Use `setTimeout` to defer all other work until at least the next
  // frame by queuing a task in a `requestAnimationFrame()` callback.
  requestAnimationFrame(() => {
    setTimeout(() => {
      const text = textBox.textContent;
      updateWordCount(text);
      checkSpelling(text);
      saveChanges(text);
    }, 0);
  });
});

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

در حالی که استفاده از setTimeout() در داخل یک فراخوانی requestAnimationFrame() در مثال کد قبلی مسلماً کمی باطنی است، این روش موثری است که در همه مرورگرها کار می کند تا اطمینان حاصل شود که کد غیر بحرانی فریم بعدی را مسدود نمی کند.

از کوبیدن طرح بندی خودداری کنید

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

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

تأخیر ارائه را به حداقل برسانید

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

اندازه DOM را به حداقل برسانید

وقتی DOM صفحه کوچک است، کار رندر معمولاً به سرعت تمام می شود. با این حال، زمانی که DOM ها بسیار بزرگ می شوند، کار رندر با افزایش اندازه DOM مقیاس می شود. رابطه بین کار رندر و اندازه DOM یک رابطه خطی نیست، اما DOM های بزرگ نسبت به DOM های کوچک به کار بیشتری برای ارائه نیاز دارند. یک DOM بزرگ در دو مورد مشکل ساز است:

1. در طول رندر صفحه اولیه، جایی که یک DOM بزرگ به کار زیادی برای رندر کردن حالت اولیه صفحه نیاز دارد.
2. در پاسخ به یک تعامل کاربر، که در آن یک DOM بزرگ می‌تواند باعث شود که به‌روزرسانی‌های رندر بسیار گران باشد و بنابراین زمان لازم برای ارائه فریم بعدی توسط مرورگر را افزایش می‌دهد.

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

از content-visibility برای ارائه تنبلی عناصر خارج از صفحه استفاده کنید

یکی از راه‌هایی که می‌توانید هم میزان کار رندر در حین بارگذاری صفحه و هم کار رندر را در پاسخ به تعاملات کاربر محدود کنید، تکیه بر ویژگی CSS content-visibility است که عملاً به معنای رندر کردن تنبل عناصر با نزدیک شدن به viewport است. در حالی که content-visibility می‌تواند برای استفاده مؤثر کمی تمرین داشته باشد، ارزش بررسی دارد که آیا نتیجه زمان رندر کمتر است که می‌تواند INP صفحه شما را بهبود بخشد.

هنگام رندر HTML با استفاده از جاوا اسکریپت از هزینه های عملکرد آگاه باشید

در جایی که HTML وجود دارد، تجزیه HTML نیز وجود دارد، و پس از اینکه مرورگر تجزیه HTML را به یک DOM به پایان رساند، باید استایل‌ها را روی آن اعمال کند، محاسبات طرح‌بندی را انجام دهد و متعاقباً آن طرح‌بندی را ارائه دهد. این یک هزینه اجتناب ناپذیر است، اما نحوه ارائه HTML مهم است.

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

در حالی که اولین بازدید از هر وب سایت همیشه مقداری HTML را شامل می شود، یک رویکرد رایج با حداقل بیت اولیه HTML شروع می شود و سپس از جاوا اسکریپت برای پر کردن منطقه محتوا استفاده می شود. به روز رسانی های بعدی در آن منطقه محتوا نیز در نتیجه تعاملات کاربر رخ می دهد. این معمولاً مدل برنامه تک صفحه ای (SPA) نامیده می شود. یکی از اشکالات این الگو این است که با رندر کردن HTML با جاوا اسکریپت بر روی کلاینت، نه تنها هزینه پردازش جاوا اسکریپت برای ایجاد آن HTML را دریافت می کنید، بلکه مرورگر نیز تا زمانی که تجزیه HTML و رندر آن را به پایان نرساند، نتیجه نمی دهد. .

با این حال، بسیار مهم است که به یاد داشته باشید، که حتی وب سایت هایی که SPA نیستند، احتمالاً در نتیجه تعاملات، مقداری رندر HTML از طریق جاوا اسکریپت را شامل می شوند. این به طور کلی خوب است، تا زمانی که شما مقادیر زیادی HTML را روی کلاینت ارائه نمی کنید، که می تواند ارائه فریم بعدی را به تاخیر بیندازد. با این حال، درک مفاهیم عملکرد این رویکرد برای رندر کردن HTML در مرورگر و اینکه چگونه می‌تواند بر پاسخ‌دهی وب‌سایت شما به ورودی کاربر تأثیر بگذارد، اگر HTML زیادی را از طریق جاوا اسکریپت رندر می‌کنید، مهم است.

نتیجه

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

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

تصویر قهرمان از Unsplash توسط David Pisnoy و مطابق با مجوز Unsplash اصلاح شده است.