Ett bra INP-värde är 200 millisekunder eller mindre, mätt vid den 75:e percentilen av verkliga besök. Mellan 200 och 500 ms “behöver sidan förbättras”, och över 500 ms bedöms den som dålig. Google tillämpar gränsvärdena separat för mobil och dator, så en sida kan klara sig på den ena och underkännas på den andra.
Interaction to Next Paint (INP) mäter hur snabbt en sida svarar visuellt efter att någon klickar, trycker eller använder tangentbordet. INP blev en Core Web Vital den 12 mars 2024 och ersatte First Input Delay (FID), som bara mätte fördröjningen innan den första interaktionen hanterades. INP tittar på interaktionerna under hela besöket och rapporterar en av de långsammaste.
I praktiken betyder “bra” tre saker: minst 75 % av de verkliga besöken får svar inom 200 ms, ni mäter med fältdata i stället för ett enda labbtest, och ni har en viss marginal under gränsen så att ett nytt skript eller en intensiv kampanjvecka inte tar er över den.
Den här guiden förklarar hur värdet beräknas, var ni hittar ert, varför vissa verktyg inte visar något och hur ni diagnostiserar och åtgärdar en långsam INP utan att gissa.
Vilka är gränsvärdena för INP?
Google använder tre nivåer, och gränsvärdena spelar roll. Tabellen nedan bygger på web.devs dokumentation om INP och rapporten Core Web Vitals i Search Console.
| Bedömning | INP-värde | Vad det betyder för användarna |
|---|---|---|
| Bra | 200 ms eller mindre | Klick och tryck känns omedelbara för de flesta besök |
| Behöver förbättras | Över 200 ms, upp till 500 ms | Märkbar fördröjning i menyer, filter, formulär eller lägg i varukorgen |
| Dålig | Över 500 ms | Användarna klickar igen, tror att sidan är trasig eller lämnar |
Är exakt 200 ms bra? Ja. web.dev definierar bra som “below or at” 200 ms, så 200 klarar sig men inte 201. Samma logik gäller vid 500 ms: exakt 500 räknas fortfarande som behöver förbättras, och allt över det är dåligt.
Som jämförelse använder de andra två Core Web Vitals i Search Console gränsvärden för LCP på 2,5 s och 4 s och för CLS på 0,1 och 0,25. INP är det enda som mäts i millisekunder av responsivitet i stället för laddning eller visuell stabilitet.
Hur beräknas ert INP-värde egentligen?
INP beräknas först per besök och sammanfattas sedan över alla besök vid den 75:e percentilen. Att förstå båda stegen förklarar det mesta av förvirringen kring siffran.
Under ett besök tidtar webbläsaren varje klick, tryck och tangenttryckning. Varje interaktion har tre delar:
- Indatafördröjning: väntetiden innan era händelsehanterare startar, oftast för att huvudtråden är upptagen med annat arbete.
- Bearbetningstid: tiden det tar för era händelsehanterare att köras.
- Presentationsfördröjning: tiden från att hanterarna är klara tills webbläsaren ritar nästa bildruta.
Besökets INP är den längsta av dessa interaktioner, med ett undantag för sidor med mycket interaktion: web.dev anger att den högsta interaktionen ignoreras för varje 50 interaktioner, så att en enstaka extrem topp under en lång session inte avgör värdet. Hovring, skrollning och zoomning räknas inte som interaktioner.
Därefter slås värdena från alla besök ihop och den 75:e percentilen rapporteras. Det är “75 %-regeln”: er sida är bra om minst tre av fyra besök hade en INP på 200 ms eller mindre. Den återstående fjärdedelen kan vara långsammare utan att sidan underkänns, och därför är det viktigare att åtgärda er typiska långsammaste interaktion än att jaga ett sällsynt specialfall.
Ett besök där användaren aldrig klickar, trycker eller skriver ger inget INP-värde alls. Sidor som människor mest läser, som långa artiklar, har ofta mindre INP-data än sidor som människor använder aktivt, som kategorifilter eller kassan.
Skiljer sig ett bra INP-värde mellan mobil och dator?
Gränsvärdet är detsamma, 200 ms, men resultaten skiljer sig mycket. Telefoner har långsammare processorer, så samma JS-kod tar längre tid att köra, och Google rapporterar mobil och dator separat i både PageSpeed Insights och Search Console.
Prestandakapitlet i HTTP Archives Web Almanac 2024 visade att 74 % av webbplatserna på mobil och 97 % av webbplatserna på dator hade bra INP. Med andra ord är INP främst ett mobilproblem. Om er rapport för dator är grön och er rapport för mobil är gul är det det normala mönstret, inte ett mätfel.
Prioritera den enhet som står för er trafik och era intäkter. För de flesta konsumentsajter är det mobilen, vilket också betyder att ni ska testa på en Android-telefon i mellanklassen eller med CPU-begränsning i Chrome DevTools, inte på en snabb laptop. Vår guide till mobil SEO beskriver helheten för mobilen.
Var kan ni kontrollera ert INP-värde?
Använd fältdata för att veta om ni klarar gränsen och labbverktyg för att ta reda på varför ni inte gör det. Varje verktyg besvarar en annan fråga.
| Verktyg | Datatyp | Bäst för |
|---|---|---|
| Search Console, rapporten Core Web Vitals | Fält (CrUX), grupperade URL:er | Se vilka grupper av sidor som underkänns på mobil eller dator och validera åtgärder |
| PageSpeed Insights | Fält (CrUX, de senaste 28 dagarna) plus labbtest i Lighthouse | Snabbt kontrollera en URL eller hela domänen |
| CrUX API, BigQuery eller CrUX Vis | Fält (CrUX) | Trender över tid och jämförelser med konkurrenter |
| Real user monitoring (RUM), till exempel JS-biblioteket web-vitals | Fält, era egna besökare | Hitta vilket element och vilken interaktion som orsakade en långsam INP |
| Panelen Performance i Chrome DevTools | Labb | Spela in en interaktion och se vilken uppgift som blockerade den |
| Lighthouse (navigeringsläge) | Labb | Total Blocking Time som en grov indikator; mäter inte INP vid ett test av sidladdning |
Googles egen dokumentation är tydlig med rangordningen: fältdata från verkliga användare är det bästa sättet att mäta INP. Total Blocking Time kan antyda problem, men web.dev beskriver det som en rimlig indikator, “not a substitute for INP”. Ett perfekt resultat i Lighthouse betyder inte att ni klarar INP.
Varför visar PageSpeed Insights inget INP-värde för vissa sidor?
Oftast för att det inte finns tillräckligt med data från verkliga användare för den URL:en. PageSpeed Insights hämtar fältdata från Chrome UX Report (CrUX), som bara omfattar sidor som är offentligt tillgängliga och har tillräckligt många besökare. Google publicerar inte den exakta trafikgränsen.
När en enskild URL saknar data försöker PageSpeed Insights i stället visa data på domännivå, det vill säga för hela er domän. Om även domänen saknar data visar fältavsnittet “No Data”, och bara labbresultaten från Lighthouse återstår. Andra vanliga orsaker:
- Sidan är ny och har ännu inte samlat in 28 dagars besök
- Sidan ligger bakom inloggning eller är blockerad från indexering, så CrUX tar inte med den
- Besökarna interagerar sällan med sidan, så det finns få INP-mätningar även med bra trafik
Den praktiska lösningen är att lägga till egen RUM. Funktionen onINP i biblioteket web-vitals rapporterar INP från varje besök, och attribueringsversionen visar vilket element som var inblandat och hur lång tid var och en av de tre faserna tog. Det ger er data även för sidor med lite trafik och, viktigare, sammanhanget för att felsöka.
Hur hittar ni vad som gör INP långsam?
Diagnostisera fasen först och sedan orsaken. Varje fas pekar mot en annan typ av åtgärd.
| Långsam fas | Typisk orsak | Var ni ska titta |
|---|---|---|
| Indatafördröjning | Huvudtråden upptagen med andra skript: tagghanterare, chattwidgetar, A/B-tester, tung hydrering under laddningen | Långa uppgifter i DevTools runt tidpunkten för klicket |
| Bearbetningstid | Händelsehanteraren gör för mycket: filtrerar en stor produktlista, analysanrop, synkron lagring, omrendering av hela komponenter | Hanteraren för click eller keydown i panelen Performance |
| Presentationsfördröjning | Stort DOM, kostsam omberäkning av stil och layout, rendering av stora block HTML med JS | Posterna “Recalculate Style” och “Layout” efter hanteraren |
Ett enkelt arbetsflöde:
- I Search Console, hitta URL-grupperna med “INP issue” på mobil.
- Öppna en exempel-URL och identifiera de interaktioner som människor faktiskt gör: menyn, ett filter, storleksväljaren, lägg i varukorgen, ett formulärfält.
- I Chrome DevTools, aktivera CPU-begränsning, starta en inspelning i Performance, utför interaktionen och stoppa.
- Leta efter långa uppgifter, som web.dev definierar som uppgifter på över 50 ms, och notera vilket skript de kommer från.
- Upprepa interaktionen medan sidan fortfarande laddas. Huvudtråden är ofta som mest upptagen då, och det är då verkliga användare klickar.
Hur förbättrar ni ett dåligt INP-värde?
Gör mindre arbete på huvudtråden i interaktionsögonblicket och ge webbläsaren en chans att rita tidigare. Åtgärderna nedan är ungefär ordnade från enklast till mest tekniska.
Granska skript från tredje part först
På många marknadsföringssajter är den största INP-kostnaden inte er egen kod. Chattwidgetar, värmekartor, samtyckesverktyg, omdömeswidgetar och flera analystaggar konkurrerar alla om huvudtråden. Lista alla skript i er tagghanterare, ta bort det som ingen använder och fördröj icke nödvändiga taggar tills sidan har laddats eller till efter den första interaktionen.
Visa återkoppling först och gör resten sedan
Uppdatera gränssnittet direkt (öppna menyn, visa laddningsindikatorn, markera knappen som nedtryckt) och kör sedan det långsammare arbetet i en separat uppgift. Det kallas att släppa åt huvudtråden (yielding). En liten hjälpfunktion som den nedan använder scheduler.yield() där webbläsaren stöder det och faller tillbaka på setTimeout i övrigt:
function yieldToMain() {
if (globalThis.scheduler?.yield) {
return scheduler.yield();
}
return new Promise(resolve => setTimeout(resolve, 0));
}
button.addEventListener('click', async () => {
showFilterResultsLoading(); // visible update first
await yieldToMain(); // let the browser paint
applyFilters(); // heavier work afterwards
sendAnalyticsEvent();
});Enligt web.dev stöds scheduler.yield() i Chrome och Edge från version 129 och i Firefox från version 142, men inte i Safari, och därför är reservlösningen viktig.
Dela upp långa uppgifter
Varje uppgift som är längre än 50 ms blockerar indata. Dela upp långa loopar, till exempel bearbetning av hundratals produkter, i delar med en yield emellan. Be er utvecklare granska hydreringen i JS-ramverk, som ofta körs som en enda stor uppgift under laddningen.
Håll DOM:et slankt
Varje extra element gör omberäkningen av stil och layout långsammare. Paginera eller virtualisera långa listor, ta bort dolda dubblettmenyer för mobil och dator och använd CSS-egenskapen content-visibility för att hoppa över rendering av avsnitt utanför skärmen.
Undvik layout thrashing
Att läsa ett layoutvärde, till exempel ett elements höjd, direkt efter att ha ändrat stilar tvingar webbläsaren att beräkna layouten omedelbart. Gruppera läsningar före skrivningar i era händelsehanterare.
Kontrollera igen efter varje ändring
Fältdata tar tid att förändras. CrUX i PageSpeed Insights omfattar de senaste 28 dagarna, och valideringen i Search Console körs med ett övervakningsfönster på 28 dagar. Använd er egen RUM för att bekräfta åtgärden inom några dagar och låt sedan Googles rapporter komma ikapp.
Påverkar INP rankningen i SEO?
INP är en del av Core Web Vitals, som Google säger ligger i linje med vad dess kärnsystem för rankning vill belöna, men det är ingen genväg till toppen av resultaten. Google rekommenderar starkt (“highly recommends”) bra Core Web Vitals för framgång i Search, medan relevans och innehållskvalitet fortfarande är avgörande.
Det starkare argumentet för att åtgärda INP är kommersiellt. Långsamma filter, tröga knappar för lägg i varukorgen och formulär som inte svarar kostar konverteringar direkt, särskilt på mobil. Se ett bra INP-värde som en grundnivå för en användbar webbplats och lägg sedan huvuddelen av ert SEO-arbete på innehåll och struktur. Vår guide till SEO för e-handel visar var prestanda passar in bland en butiks prioriteringar.
Vad bör ni sikta på?
Sikta på en INP vid den 75:e percentilen som ligger med god marginal under 200 ms på mobil, inte bara precis under. En sida på 190 ms klarar sig i dag men kan underkännas efter en ny marknadsföringstagg eller en trafiktopp från långsammare enheter. En buffert på några tiotal millisekunder ger ert team utrymme att lägga till funktioner.
Sätt mål per mall snarare än per URL: kategorisidor, produktsidor, artiklar, formulär och kassa. Åtgärda först mallen med mest trafik och sämst INP, och gör INP till en del av checklistan inför lansering så att nya skript granskas innan de går live.
Var passar Marketer Coffee in?
Marketer Coffee är en byrå för AI SEO och GEO; vi behandlar prestanda som en del av teknisk SEO, tillsammans med arkitektur, strukturerad data och innehåll. Resultat från andra branscher:
- Aldi.pl (detaljhandel). De organiska klicken ökade från 367 127 till 852 724 per månad på 12 månader (+132 %) med produktinnehåll, Product-schema, en slankare arkitektur och samordnade butiksdata. Läs kundcaset om Aldi.
- IDG-Online (tjänster inom kameraövervakning och affiliate). Från 500 till över 30 000 klick per månad på 16 månader i konkurrens med Ceneo, MediaExpert och MediaMarkt, med rankingsidor, fråga och svar-innehåll och schema. Läs kundcaset om IDG-Online.
Vem vi passar för: webbplatser där hastighet, struktur och innehåll behöver en gemensam plan, ofta butiker eller internationella webbplatser. Vem vi inte passar för: team som bara behöver en prestandaingenjör för JS-kod för en engångsomskrivning av ett ramverk; anlita en specialiserad utvecklare för det. För att se hur er webbplats presterar i AI-sökning såväl som i Google, börja med vår kostnadsfria analys av AI-synlighet.
Vanliga frågor om INP-värden
Vad är ett bra INP-värde?
200 millisekunder eller mindre vid den 75:e percentilen av verkliga sidbesök, mätt separat för mobil och dator. Över 200 ms och upp till 500 ms behöver förbättras; över 500 ms är dåligt.
När ersatte INP FID?
INP blev en Core Web Vital den 12 mars 2024 och ersatte First Input Delay. Search Console tog bort FID samma datum.
Varför är min INP bra på dator men dålig på mobil?
Telefoner har långsammare processorer, så samma skript tar längre tid att köra. Web Almanac 2024 visade bra INP på 97 % av webbplatserna på dator men bara på 74 % av webbplatserna på mobil.
Kan Lighthouse mäta INP?
Ett vanligt test av sidladdning i Lighthouse innehåller inga användarinteraktioner, så det kan inte rapportera INP. Det visar Total Blocking Time, som är en grov indikator. Använd fältdata från CrUX eller er egen RUM för att bedöma INP.
Hur lång tid tar det innan en INP-åtgärd syns i Search Console?
Fältdata omfattar ett rullande fönster på 28 dagar, och valideringen i Search Console övervakar i 28 dagar, så räkna med ungefär fyra veckor innan rapporterna helt speglar en åtgärd. Er egen RUM kan bekräfta den tidigare.
Vad är den korta versionen?
Bra INP är 200 ms eller mindre för minst 75 % av de verkliga besöken, för varje enhetstyp. Hitta mallar som underkänns i Search Console, spela in de långsamma interaktionerna i DevTools, avgör vilken fas som är långsam och åtgärda orsaken: färre skript från tredje part, snabbare återkoppling, kortare uppgifter och ett mindre DOM. Lämna sedan en buffert.
Om ni vill ha en andra bedömning av var prestanda hör hemma bland era SEO-prioriteringar, boka en kostnadsfri konsultation.
Källor: web.dev, “Interaction to Next Paint (INP)” (gränsvärden, 75:e percentilen, interaktionsfaser, regel för extremvärden, TBT som indikator); blogginlägg på web.dev av Jeremy Wagner och Rick Viscomi om INP som Core Web Vital den 12 mars 2024; web.dev, “Optimize Interaction to Next Paint” och “Optimize long tasks” (långa uppgifter på 50 ms, stöd för scheduler.yield); Google Search Console Help, rapporten Core Web Vitals (gränsvärden, validering på 28 dagar); Google Search Central, “Understanding Core Web Vitals and Google search results”; Chrome for Developers, CrUX-metodik och CrUX i PageSpeed Insights (behörighet, fönster på 28 dagar, reserv på domännivå); HTTP Archive, Web Almanac 2024, kapitlet Performance; Marketer Coffee, kundcase om Aldi och IDG-Online (andra branscher).
