आप किन Core Web Vitals के लिए optimize करते हैं, और Interaction to Next Paint असल में क्या नापता है?

तीन हैं: loading के लिए Largest Contentful Paint, responsiveness के लिए Interaction to Next Paint और दिखने की स्थिरता के लिए Cumulative Layout Shift। INP किसी interaction की पूरी latency नापता है, input event से लेकर आपके handler और rendering के काम तक, जब तक अगला frame paint न हो जाए। Google पेज पर मोटे तौर पर सबसे खराब interaction रिपोर्ट करता है, तो औसत ठीक होने के बावजूद एक धीमा handler पूरा स्कोर बिगाड़ देता है।

तीन हैं: LCP कि मुख्य content कितनी जल्दी दिखता है, INP responsiveness के लिए, और CLS layout की स्थिरता के लिए। INP दिलचस्प है क्योंकि उसने First Input Delay की जगह ली, और वह सिर्फ handler चलने से पहले का इंतज़ार नहीं, पूरा interaction नापता है। यानी main thread व्यस्त होने के दौरान का input delay, साथ में मेरा handler जितना समय लेता है, साथ में अगला frame दिखाने का presentation delay। दो सौ मिलीसेकंड से नीचे अच्छा खाना है, और यह असली यूज़र्स से field में नापा जाता है, तो इसमें मध्यम श्रेणी के Android फोन दिखते हैं, मेरा laptop नहीं। व्यावहारिक नतीजा यह है कि इसे ठीक करने का मतलब आमतौर पर handler ठीक करना होता है, bundle नहीं। जिस search पेज का मैं मालिक था, वहां टाइप करना करीब चार सौ मिलीसेकंड दिखा रहा था, और पता चला कि हर keystroke पर एक बड़ी result list synchronously दोबारा render हो रही थी। महंगे हिस्से को debounce करके और render से पहले ब्राउज़र को मौका देकर यह डेढ़ सौ से नीचे आ गया।