INP Explained: Interaction to Next Paint
Sahifa tez yuklanishi mumkin, lekin baribir sekin ishlayotgandek tuyuladi. Menyuni bosasiz, “Add to cart” tugmasini tanlaysiz yoki qidiruv maydoniga yozishni boshlaysiz, ammo interfeys javob berishdan oldin biroz kutdiradi. Interaction to Next Paint (INP) aynan mana shu responsivlikni o‘lchaydi.
INP — Largest Contentful Paint (LCP) va Cumulative Layout Shift (CLS) bilan birga Google’ning uchta Core Web Vitals metrikasidan biri. U faqat birinchi interaction’ni emas, foydalanuvchining sahifadagi butun tashrifi davomida yuz bergan interaction’larni baholaydi. INP 2024-yil 12-martda Core Web Vitals tarkibida First Input Delay (FID) o‘rnini rasman egalladi. (developers.google.com)
INP nima?
Interaction to Next Paint foydalanuvchi interaction’idan keyin sahifa keyingi vizual frame’ni ko‘rsatishi uchun qancha vaqt kerak bo‘lishini o‘lchaydi.
U quyidagi interaction’larni kuzatadi:
- sichqoncha orqali bosish;
- sensorli ekranga tegish;
- klaviatura tugmalarini bosish.
Har bir interaction uchun INP foydalanuvchi amalni boshlagan paytdan brauzer keyingi frame’ni ko‘rsata oladigan paytgacha bo‘lgan vaqtni o‘lchaydi. Shu sababli u faqat JavaScript bajarilish vaqtini o‘lchamaydi. (web.dev)
Scrolling, hovering va zooming INP tarkibiga to‘g‘ridan-to‘g‘ri kirmaydi. (web.dev)
Past INP sahifa foydalanuvchi harakatlariga doimiy ravishda tez javob berishini anglatadi. Yuqori INP esa odatda ayrim muhim interaction’lar main thread’dagi yuklama, qimmat event handler’lar, rendering yoki ularning birgalikdagi ta’siri sabab kechikayotganini bildiradi.
INP chegaralari
Google va Chrome jamoasi hozir INP’ni quyidagi chegaralar asosida baholaydi:
| INP | Baho |
|---|---|
| ≤ 200 ms | Yaxshi |
| > 200 ms dan ≤ 500 ms gacha | Yaxshilash kerak |
| > 500 ms | Yomon |
Tavsiya etiladigan baholashda sahifa tashriflarining 75-percentili ishlatiladi va mobil hamda desktop foydalanuvchilar alohida hisoblanadi. (web.dev)
Bu farq muhim. Development laptop’ingizda interaction 150 ms bo‘lishi real foydalanuvchilarda ham INP yaxshi degani emas. Ular sekinroq CPU, boshqa brauzer sharoitlari, ko‘proq background task’lar yoki boshqa interaction pattern’laridan foydalanishi mumkin.
INP qanday ishlaydi?
INP barcha interaction’larning o‘rtacha qiymatini hisoblamaydi.
Chrome sahifaning butun ishlash davri davomida interaction’larni kuzatadi va eng sekin interaction’lardan birini ifodalovchi qiymatni tanlaydi. Ko‘pchilik tashriflarda eng yomon interaction INP uchun nomzod bo‘ladi. Juda ko‘p interaction bo‘ladigan sahifalarda esa kam uchraydigan outlier’larning ta’siri kamaytiriladi: har 50 ta interaction uchun eng yuqori latency’ga ega bitta interaction hisobga olinmaydi. (web.dev)
Bu yondashuv muhim savolga javob beradi:
Foydalanuvchi turli xil ko‘plab amallarni bajarganda ham sahifa barqaror ravishda tez javob berdimi?
Mahsulot sahifasini misol qilib olaylik:
- Navigatsiyani ochish — 70 ms.
- Mahsulot variantini tanlash — 110 ms.
- O‘lcham tanlash menyusini ochish — 90 ms.
- “Add to cart” tugmasini bosish — 620 ms.
Sahifa ko‘p vaqt tez ishlayotgandek tuyulishi mumkin, ammo savatga qo‘shish kabi muhim interaction aniq sekin. O‘rtacha qiymat bu muammoni yashirishi mumkin edi. INP aynan shunday sekin holatlarga sezgir bo‘lishi uchun yaratilgan.
INP’ning uch qismi
Interaction’ni uchta asosiy bosqichga ajratish mumkin:
Input delay → Processing duration → Presentation delay
Ularning yig‘indisi umumiy interaction latency’ni hosil qiladi. (web.dev)
Input Delay
Input delay — foydalanuvchi interaction’ni boshlagan paytdan brauzer unga tegishli event callback’larni bajarishni boshlaguncha o‘tgan vaqt.
Tasavvur qiling, foydalanuvchi tugmani bosdi, lekin brauzerning main thread’i katta JavaScript task’ni bajarish bilan band. Click allaqachon yuz berdi, ammo brauzer uni darhol qayta ishlay olmaydi.
Interaction kutadi.
Katta script’lar, uzoq davom etuvchi task’lar, timer’lar, parsing va JavaScript execution bu kechikishni oshirishi mumkin. (web.dev)
Processing Duration
Processing duration — interaction bilan bog‘liq event callback’larni bajarishga ketgan vaqt.
Masalan:
button.addEventListener('click', () => {
calculateLargeDataset();
updateApplicationState();
renderResults();
});
Agar bu operatsiyalar sinxron ravishda yuzlab millisekund vaqt olsa, brauzer foydalanuvchiga tez vizual javob ko‘rsata olmaydi.
Keraksiz ishlarni kamaytirish va katta vazifalarni kichikroq task’larga bo‘lish main thread’ning tezroq bo‘shashiga yordam beradi. (web.dev)
Presentation Delay
Event handler’lar ishlashni tugatgandan keyin ham brauzer style’larni hisoblash, layout bajarish, paint qilish va keyingi frame’ni tayyorlashga vaqt sarflashi mumkin.
Bu vaqt presentation delay hisoblanadi.
Shu sababli juda katta DOM, qimmat style recalculation, murakkab rendering yoki haddan tashqari ko‘p sinxron UI update’lar event handler’ning o‘zi tez ishlasa ham INP’ni yomonlashtirishi mumkin.
INTERNAL LINK: Browser Rendering Pipeline Explained
INP va FID
INP First Input Delay o‘rnini egalladi, chunki bu ikki metrika responsiveness’ni turlicha o‘lchaydi.
FID faqat birinchi interaction’dagi input delay’ni o‘lchagan.
INP esa sahifa tashrifi davomida yuz beradigan interaction’larni baholaydi va input’dan boshlab event processing orqali keyingi vizual frame’gacha bo‘lgan jarayonni o‘z ichiga oladi. (web.dev)
Shu sababli sahifa tarixan yaxshi FID ko‘rsatishi, ammo keyinroq foydalanuvchi uchun noqulay bo‘lib qolishi mumkin edi.
Masalan, menyuga birinchi bosish darhol ishlashi va yaxshi FID berishi mumkin. Ammo o‘n soniyadan keyin murakkab filtering interfeysi 700 ms’da javob berishi mumkin. FID ikkinchi muammoni umuman qayd etmaydi. INP esa qayd eta oladi.
Google 2024-yil 12-martda Core Web Vitals tarkibida FID’ni INP bilan almashtirdi. (developers.google.com)
INP’ni qanday o‘lchash mumkin?
INP’ni o‘lchashning ikkita asosiy yondashuvi bor: field data va lab testing.
Field Data
Field data real foydalanuvchilardan keladi va INP’ni baholashda eng muhim manba hisoblanadi.
PageSpeed Insights yetarli ma’lumot mavjud bo‘lsa, Chrome User Experience Report (CrUX) ma’lumotlarini ko‘rsatishi mumkin. Search Console ham Core Web Vitals hisobotlarini taqdim etadi. (web.dev)
CrUX quyidagi savolga javob berishda foydali:
Real foydalanuvchilarda INP muammosi bormi?
Ammo agregatsiya qilingan CrUX ma’lumotlari ko‘pincha aynan qaysi tugma, komponent, script yoki interaction muammoni keltirib chiqarganini ko‘rsatmaydi.
Bunday holatda Real User Monitoring foydaliroq bo‘ladi.
Google’ning web-vitals kutubxonasi qo‘llab-quvvatlanadigan brauzerlarda INP’ni to‘g‘ridan-to‘g‘ri yig‘ish imkonini beradi:
import {onINP} from 'web-vitals';
onINP(({value, rating}) => {
console.log(value, rating);
});
Kutubxonaning attribution build’i ham mavjud bo‘lib, u muammoli interaction’lar haqida diagnostika uchun qo‘shimcha kontekst bera oladi. (web.dev)
import {onINP} from 'web-vitals/attribution';
onINP(({value, rating, attribution}) => {
console.log({
value,
rating,
target: attribution.interactionTarget,
});
});
Production monitoring’da bu ma’lumotlarni faqat console’ga chiqarish o‘rniga analytics yoki observability tizimiga yuborish ma’qul.
Lab Testing
Lab testing sekin interaction aniqlangandan keyin uni qayta yuzaga keltirish va tekshirishga yordam beradi.
Quyidagi real amallarni test qiling:
- navigatsiyani ochish;
- filter’larni o‘zgartirish;
- accordion’larni ochish;
- qidiruv maydoniga yozish;
- formalarni yuborish;
- tab’lar orasida o‘tish;
- mahsulotni savatga qo‘shish.
Sahifa yuklanayotgan paytda ham interaction’larni test qilish foydali, chunki JavaScript parsing, compilation va execution shu vaqtda main thread’ni ayniqsa band qilishi mumkin. (web.dev)
Biroq lab sharoitidagi INP natijasi siz qaysi interaction’larni bajarganingizga bog‘liq. Agar test muammoli interaction’ni umuman ishga tushirmasa, real muammo to‘liq ko‘rinmay qolishi mumkin.
INP’ni qanday yaxshilash mumkin?
Avval sekin interaction’ni toping, keyin uning qaysi qismi latency’ga sabab bo‘layotganini aniqlang.
Foydali diagnostika oqimi:
Slow INP → identify interaction → inspect phase → confirm cause → optimize → measure again
Agar input delay yuqori bo‘lsa, event handler ishga tushishidan oldin main thread’ni band qilayotgan long task’lar va ortiqcha JavaScript’ni tekshiring.
Agar processing duration yuqori bo‘lsa, event callback’ning o‘zini tekshiring. Keraksiz sinxron ishlarni olib tashlang, hisob-kitoblarni soddalashtiring va imkon bo‘lsa, uzun task’larni bo‘laklarga ajrating.
Agar presentation delay yuqori bo‘lsa, style recalculation, layout, DOM murakkabligi va qimmat vizual update’lar kabi rendering xarajatlarini tekshiring.
JavaScript’ni tasodifiy o‘chirib tashlash yoki framework konfiguratsiyasini o‘zgartirishdan boshlamang. INP bir necha bosqichning natijasi bo‘lgani uchun optimizatsiya aynan sekin ishlayotgan bosqichga qaratilishi kerak. (web.dev)
INTERNAL LINK: Long Tasks and Main Thread Performance
INTERNAL LINK: How DOM Size Affects Web Performance
INP bo‘yicha keng tarqalgan xatolar
Keng tarqalgan xatolardan biri — faqat sahifa yuklanishini test qilish. INP butun tashrif davomida responsiveness’ni o‘lchaydi, shuning uchun sahifa mukammal yuklanishi, ammo keyingi interaction’larda sekin ishlashi mumkin.
Yana bir xato — Total Blocking Time’ni INP deb qabul qilish. TBT lab testlarda main thread blocking’ni aniqlashga yordam berishi mumkin, ammo web.dev uni ayrim vaziyatlarda ishlatilishi mumkin bo‘lgan proxy sifatida ta’riflaydi, real INP o‘rnini bosuvchi metrika sifatida emas. (web.dev)
Uchinchi xato — har bir sekin interaction tarmoq sababli yuz beradi deb o‘ylash. INP asosan keyingi frame ko‘rsatilishi mumkin bo‘lgan paytgacha davom etadigan davrni qamrab oladi. Keyinroq keladigan asinxron API response avtomatik ravishda dastlabki interaction’ning INP davomiyligiga kirmaydi. (web.dev)
Va nihoyat, yaxshi lokal natija yaxshi field result’ni kafolatlamaydi. Production foydalanuvchilar saytdan ancha turli qurilma va sharoitlarda foydalanadi.
INP va SEO
INP Core Web Vital hisoblanadi va Google Search Central Core Web Vitals real sharoitdagi loading performance, interactivity va visual stability’ni o‘lchashini aytadi. Google yaxshi foydalanuvchi tajribasi va Search’da muvaffaqiyatga erishish uchun Core Web Vitals ko‘rsatkichlarini yaxshi darajada ushlashni tavsiya qiladi. (developers.google.com)
Bu INP’ni yaxshilash ranking oshishini kafolatlaydi degani emas.
Google page experience’ni kengroq signal tizimining bir qismi sifatida ko‘rsatadi. Relevanti va foydali kontent page experience mukammal bo‘lmasa ham yaxshi rank olishi mumkin, yaxshi Core Web Vitals ko‘rsatkichlari esa o‘z-o‘zidan yuqori ranking’ni kafolatlamaydi. (developers.google.com)
Amaliy jihatdan to‘g‘ri xulosa shuki: INP’ni foydalanuvchilar uchun sahifa responsiveness’ini yaxshilagani va Core Web Vitals Google’ning page experience haqidagi bahosiga aloqador bo‘lgani uchun optimallashtiring. Muayyan millisekundlik yaxshilanishni to‘g‘ridan-to‘g‘ri ranking o‘sishiga aylantirish mumkin deb hisoblamang.
INP edge case’lari
Agar foydalanuvchi hech qachon click qilmasa, ekranga tegmasa yoki klaviatura tugmasini bosmasa, sahifada umuman INP qiymati bo‘lmasligi mumkin. Faqat scroll yoki hover qilgan foydalanuvchilarda ham INP uchun mos interaction hosil bo‘lmasligi mumkin. (web.dev)
Embedded content ham o‘lchashni murakkablashtiradi. Sahifa darajasidagi INP iframe ichidagi interaction’larni hisobga olishi mumkin, ammo top-level document ichida ishlayotgan JavaScript cross-origin frame ichidagi interaction timing’iga kira olmasligi mumkin. Bu CrUX va o‘zingiz yig‘gan RUM ma’lumotlari o‘rtasida farq paydo bo‘lishiga olib kelishi mumkin. (web.dev)
Event Timing API’ning o‘zida ham developer’lar bilishi kerak bo‘lgan implementatsiya tafsilotlari mavjud. Masalan, uning default buffering threshold qiymati 104 ms, lekin observer API cheklovlari doirasida bundan pastroq threshold so‘rashi mumkin. (w3c.github.io)
Ko‘pchilik jamoalar uchun INP hisoblash algoritmini boshidan o‘zlari yozishdan ko‘ra, qo‘llab-quvvatlanadigan web-vitals implementatsiyasidan foydalanish xavfsizroq.
SeoNest tavsiyasi
INP’ga PageSpeed Insights’dagi oddiy score sifatida emas, interaction darajasidagi observability muammosi sifatida qarang.
Real foydalanuvchi ma’lumotlaridan boshlang. Qaysi sahifa va user flow’larda natija yomonligini aniqlang. Keyin aynan qaysi interaction muammoga sabab bo‘layotganini bilish uchun attribution data yig‘ing. Shu interaction’larni real qurilmalarga yaqin sharoitda qayta yuzaga keltiring va latency’ni input delay, processing duration hamda presentation delay qismlariga ajrating.
Faqat shundan keyin optimizatsiya qiling.
Bu yondashuv “INP 480 ms” kabi umumiy hisobotni aniq engineering muammosiga aylantiradi:
Search filter click → 480 ms → 45 ms input delay + 310 ms processing + 125 ms presentation delay → expensive synchronous filtering and DOM update.
Bunday attribution darajasi shunchaki yashil performance score olishga urinishdan ancha foydaliroq.
FAQ
Qanday INP yaxshi hisoblanadi?
200 ms yoki undan kam INP yaxshi hisoblanadi. 200–500 ms oralig‘i yaxshilashni talab qiladi, 500 ms’dan yuqori qiymatlar esa yomon hisoblanadi. Saytni baholash uchun sahifa tashriflarining 75-percentilidan foydalanish tavsiya qilinadi. (web.dev)
INP sahifa yuklanish tezligini o‘lchaydimi?
Yo‘q. INP foydalanuvchi interaction’lariga responsiveness’ni o‘lchaydi. LCP esa loading performance’ga qaratilgan Core Web Vital hisoblanadi. (developers.google.com)
Scrolling INP’ga ta’sir qiladimi?
Scrolling’ning o‘zi INP uchun hisoblanadigan interaction turlaridan biri emas. Click, tap va keyboard interaction’lar o‘lchanadi. (web.dev)
INP Google ranking omilimi?
INP Core Web Vital hisoblanadi va Core Web Vitals Google’ning kengroq page experience baholash tizimiga kiradi. Biroq Google “INP’ni X millisekundga yaxshilash ranking’ni Y ga oshiradi” kabi oddiy qoida e’lon qilmagan. Yaxshi Core Web Vitals ham yuqori ranking’ni kafolatlamaydi. (developers.google.com)
Nega PageSpeed Insights INP ko‘rsatmaydi?
Muayyan URL yoki origin uchun yetarli real foydalanuvchi interaction ma’lumoti bo‘lmasligi mumkin. Bundan tashqari, foydalanuvchi hech qanday mos interaction bajarmagan alohida sahifa tashrifida INP umuman bo‘lmasligi ham mumkin. (web.dev)
Yakuniy xulosa
INP oddiy, ammo muhim savolga javob beradi: foydalanuvchi biror amal qilganida, sahifa unga qanchalik tez vizual javob beradi?
FID’dan farqli ravishda, INP butun tashrif davomida responsiveness’ni baholaydi va interaction’ni input delay’dan event processing orqali brauzerning keyingi paint’igacha kuzatadi. Maqsad — 75-percentilda 200 ms yoki undan kam, ammo faqat raqamning o‘zini ko‘r-ko‘rona optimallashtirish to‘g‘ri emas.
Sekin interaction’ni toping, latency qayerdan kelayotganini aniqlang, aynan o‘sha bottleneck’ni tuzating va real foydalanuvchilarda yana o‘lchang.
Sources
- web.dev — Jeremy Wagner and Barry Pollard, “Interaction to Next Paint (INP),” published May 6, 2022; updated September 2, 2025. (web.dev)
Interaction to Next Paint — web.dev - web.dev — Jeremy Wagner, Philip Walton and Barry Pollard, “Optimize Interaction to Next Paint,” published May 19, 2023; updated September 2, 2025. (web.dev)
Optimize Interaction to Next Paint — web.dev - Google Search Central — “Understanding Core Web Vitals and Google search results,” updated December 10, 2025. (developers.google.com)
Core Web Vitals and Google Search - Google Search Central — Martin Splitt, “Introducing INP to Core Web Vitals,” May 10, 2023; updated March 12, 2024. (developers.google.com)
Introducing INP to Core Web Vitals - W3C Web Performance Working Group — Event Timing API specification. (w3c.github.io)
Event Timing API specification - web.dev — “Find slow interactions in the field.” (web.dev)
Find slow interactions in the field - GoogleChrome —
web-vitalsJavaScript library and reference implementation. (github.com)
GoogleChrome web-vitals repository - web.dev — “Advancing Interaction to Next Paint.” (web.dev)
Advancing Interaction to Next Paint
