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

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

جرمی واگنر
فیلیپ والتون
بری پولارد

منتشر شده: ۱۹ مه ۲۰۲۳، آخرین به‌روزرسانی: ۲ سپتامبر ۲۰۲۵

تعامل تا رنگ بعدی (INP) یک معیار پایدار Core Web Vital است که با مشاهده تأخیر تمام تعاملات واجد شرایط که در طول عمر بازدید کاربر از یک صفحه رخ می‌دهد، میزان پاسخگویی کلی یک صفحه به تعاملات کاربر را ارزیابی می‌کند. مقدار نهایی INP طولانی‌ترین تعامل مشاهده شده است (گاهی اوقات موارد پرت را نادیده می‌گیرد).

برای ارائه یک تجربه کاربری خوب، وب‌سایت‌ها باید تلاش کنند تا زمان تعامل با Next Paint، ۲۰۰ میلی‌ثانیه یا کمتر باشد . برای رسیدن به این هدف برای اکثر کاربران، آستانه خوبی برای اندازه‌گیری، صدک ۷۵ام بارگذاری صفحه است که در دستگاه‌های تلفن همراه و دسکتاپ تقسیم‌بندی شده است.

مقادیر INP خوب ۲۰۰ میلی‌ثانیه یا کمتر هستند، مقادیر ضعیف بیشتر از ۵۰۰ میلی‌ثانیه هستند و هر مقداری بین این دو نیاز به بهبود دارد.
آستانه‌های INP

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

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

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

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

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

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

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

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

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

بهینه سازی تعاملات

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

تعاملات را می‌توان به سه زیربخش تقسیم کرد:

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

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

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

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

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

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

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

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

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

بهینه‌سازی فراخوانی‌های رویداد

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

اغلب به نخ اصلی تسلیم شوید

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

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

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

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

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

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

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

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

  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() در مثال کد قبلی مسلماً کمی پیچیده است، اما روشی مؤثر است که در همه مرورگرها برای جلوگیری از مسدود شدن فریم بعدی توسط کد غیر ضروری کار می‌کند.

از درهم‌ریختگی طرح‌بندی خودداری کنید

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

تصویری از فشرده‌سازی طرح‌بندی همانطور که در پنل عملکرد Chrome DevTools نشان داده شده است.
مثالی از فشرده‌سازی طرح‌بندی، همانطور که در پنل عملکرد Chrome DevTools نشان داده شده است. وظایف رندرینگ که شامل فشرده‌سازی طرح‌بندی می‌شوند، با یک مثلث قرمز در گوشه سمت راست بالای بخشی از پشته فراخوانی، که اغلب با برچسب Recalculate Style یا Layout مشخص می‌شود، مشخص می‌شوند.

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

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

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

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

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

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

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

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

یکی از راه‌هایی که می‌توانید میزان کار رندرینگ را در حین بارگذاری صفحه و همچنین کار رندرینگ در پاسخ به تعاملات کاربر محدود کنید، تکیه بر ویژگی content-visibility در CSS است که عملاً به رندر تنبل عناصر هنگام نزدیک شدن به 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 ، اثر دیوید پیسنوی و مطابق با مجوز Unsplash اصلاح شده است.