برای سالها، منظر عملکرد فرانتاند تحت سلطه دو غول بود: Largest Contentful Paint (LCP) برای سرعت بارگذاری و Cumulative Layout Shift (CLS) برای پایداری بصری. اگرچه این معیارها همچنان حیاتی هستند، اما گذر گوگل از First Input Delay (FID) به Interaction to Next Paint (INP) تمرکز را به طور بنیادین به سمت تعاملپذیری تغییر داده است. INP پاسخگویی یک صفحه به ورودی کاربر را در طول کل عمر یک بازدید اندازهگیری میکند و آن را به شاخصی جامعتر از تجربه کاربری تبدیل کرده است. به عنوان توسعهدهندگان، ما اکنون باید فراتر از سرعت ساده رندرینگ نگاه کنیم و به دنیای پیچیده تأخیر تعامل بپردازیم.
درک تغییر به سمت INP
برخلاف FID که تنها اولین تعامل را اندازهگیری میکرد، INP تمام تعاملاتی را که یک کاربر با صفحه دارد، از جمله کلیکها، لمسها و ورودیهای صفحهکلید در نظر میگیرد. این معیار دهمین صدم (p98) از تمام تأخیرهای تعاملی را گزارش میدهد. این بدان معناست که حتی اگر یک صفحه به سرعت بارگذاری شود، یک مودال کند یا منوی کشویی قفلشده میتواند نمره شما را کاهش دهد. برای بهینهسازی بر اساس INP، باید مراحل یک رویداد را درک کنیم: تأخیر ورودی، زمان پردازش و تأخیر ارائه. هدف کاهش زمان کلی از اقدام کاربر تا بازخورد بصری روی صفحه است.
راهکارهایی برای کاهش تأخیر ورودی
تأخیر ورودی عمدتاً توسط وظایف اجرای طولانی جاوااسکریپت که رشته اصلی (main thread) را مسدود میکنند، ایجاد میشود. وقتی مرورگر مشغول تجزیه یک اسکریپت بزرگ یا انجام محاسبات سنگین است، نمیتواند رویدادهای کاربر را پردازش کند. مؤثرترین راهکار در اینجا تقسیم وظایف است. با شکستن وظایف طولانی به قطعات کوچکتر با استفاده از تکنیکهایی مانند requestAnimationFrame یا setTimeout، به مرورگر اجازه میدهیم تا اولویت را به تعاملات کاربر بدهد.
// بد: مسدود کردن رشته اصلی با محاسبات سنگین
function processHeavyData(data) {
const results = [];
for (let i = 0; i < data.length; i++) {
// این حلقه در طول اجرا رابط کاربری را مسدود میکند
results.push(computeExpensiveValue(data[i]));
}
return results;
}
// خوب: استفاده از Web Workers برای انتقال محاسبات سنگین
const worker = new Worker('computation-worker.js');
worker.postMessage(data);
worker.onmessage = (e) => {
updateUI(e.data);
};
انتقال محاسبات سنگین به Web Workers یکی از تأثیرگذارترین تغییراتی است که میتوانید ایجاد کنید. کارگران (Workers) در یک رشته جداگانه اجرا میشوند و تضمین میکنند که رشته اصلی شما به ورودیهای کاربر پاسخگو باقی بماند. برای وظایف سادهتر، به تعویق انداختن اجرای جاوااسکریپت غیرحیاتی تا پس از اولین رندر نیز میتواند تأخیر ورودی را در طول مسیر رندرینگ حیاتی به طور قابل توجهی کاهش دهد.
بهینهسازی تأخیر ارائه
پس از مدیریت رویداد، مرورگر باید نتیجه را رندر کند. تأخیر ارائه زمانی مشکلساز میشود که مرورگر مشغول رندرینگ است یا وقتی انیمیشنهای CSS با تعاملات کاربر تداخل دارند. یکی از دامهای رایج، استفاده از ویژگیهای سنگین CSS است که عملیات پرهزینه چیدمان یا ترکیب را فعال میکند، مانند انیمیشن دادن به عرض یا ارتفاع به جای استفاده از transform. علاوه بر این، اطمینان از اینکه CSS حیاتی شما درونخطی (inline) و غیرمسدودکننده است، به مرورگر کمک میکند تا سریعتر رندر کند.
جنبه حیاتی دیگر، کاهش اندازه بستههای جاوااسکریپت شماست. بستههای بزرگ زمان صرفشده برای تجزیه و کامپایل جاوااسکریپت را افزایش میدهند که هم LCP و هم تعاملات بعدی را به تأخیر میاندازند. پیادهسازی تقسیم کد (code splitting) و بارگذاری تنبل (lazy loading) برای اجزای غیرحیاتی تضمین میکند که تنها کد ضروری در زمان نیاز بارگذاری شود و قدرت پردازش بیشتری برای تعاملات فوری کاربر در دسترس باشد.
پایش و اشکالزدایی INP
تست کردن برای INP نیازمند چیزی فراتر از نگاه کردن به نمرات Lighthouse به صورت جداگانه است. Lighthouse یک تصویر لحظهای ارائه میدهد، اما عملکرد واقعی در دستگاهها و شرایط شبکه مختلف متفاوت است. از API PerformanceObserver در کنسول مرورگر برای ردیابی تعاملات در زمان واقعی استفاده کنید. این به شما امکان میدهد تعاملات خاصی را که باعث افزایش تأخیر میشوند، شناسایی کنید.
const observer = new PerformanceObserver((list) => {
for (const entry of list.getEntries()) {
console.log(`Interaction: ${entry.name}, Duration: ${entry.duration}ms`);
}
});
observer.observe({ entryTypes: ['event'] });
با تحلیل این لاگها، میتوانید مشخص کنید کدام رویدادهای DOM کند هستند و دستورات جاوااسکریپت مرتبط با آنها را بررسی کنید. نقاط شکست (Breakpoints) شنونده رویدادها در Chrome DevTools نیز برای تشخیص دلیل طولانی شدن پردازش یک تعامل خاص بینظیر هستند.
نتیجهگیری
بهینهسازی برای INP نشاندهنده بلوغی در مهندسی عملکرد وب است. دیگر ساخت صفحات سریع کافی نیست؛ ما باید صفحات پاسخگو بسازیم. با درک مکانیکهای تأخیر تعامل و به کارگیری تکنیکهایی مانند تقسیم وظایف، Web Workers و بهینهسازی بستهها، توسعهدهندگان میتوانند تجربههای بینقصی ارائه دهند که کاربران را شادمان کرده و الگوریتمهای موتورهای جستجو را راضی نگه میدارد. با پیچیدهتر شدن برنامههای وب، مدیریت پیشدستانه رشته اصلی همچنان تمایزدهنده اصلی بین تجربههای وب متوسط و استثنایی باقی خواهد ماند.