INP: La Nova Mètrica de Google per a Interactivitat

La mètrica que ningú mesurava fins al març de 2024

Durant anys, la comunitat SEO es va obsessionar amb el LCP i el CLS com les mètriques de Core Web Vitals més rellevants per al posicionament. El FID (First Input Delay) existia com a tercera mètrica, però rarament causava problemes: mesurava únicament el retard entre la primera interacció de l’usuari i l’inici del seu processament, i la majoria de les pàgines el superaven sense esforç. N’hi havia prou que el fil principal no estigués completament bloquejat en el moment del primer clic.

El març de 2024, Google va eliminar el FID i el va substituir per l’INP (Interaction to Next Paint). El canvi no va ser cosmètic. INP mesura quelcom fonamentalment diferent: la latència completa de totes les interaccions de l’usuari durant tota la vida de la pàgina, no només la primera. I el resultat va ser revelador: segons dades del Web Almanac de HTTPArchive publicades el 2025, el 27% dels llocs web que superaven el llindar de FID ara suspenen el d’INP. Gairebé tres de cada deu llocs que creien tenir bona interactivitat van descobrir que no la tenien.

El que fa que l’INP sigui rellevant per al SEO és el seu pes com a senyal de posicionament. Google el va integrar als Core Web Vitals amb la mateixa importància que el LCP i el CLS. Les pàgines amb un INP superior a 500ms són classificades com a deficients a Google Search Console, i les dades de camp que Google utilitza per avaluar aquest factor provenen del Chrome UX Report, on es recull el percentil 98 de totes les interaccions reals dels últims 28 dies. No hi ha marge per ignorar aquesta mètrica.

Què és l’INP i per què va substituir el FID

L’Interaction to Next Paint mesura la capacitat de resposta d’una pàgina web quantificant quant de temps transcorre des que l’usuari interactua — un clic, un tap, una pulsació de teclat — fins que el navegador pinta l’actualització visual resultant. Aquest cicle complet inclou tres fases:

L’input delay és el temps que transcorre entre la interacció de l’usuari i el moment en què el navegador comença a executar els event handlers associats. Si el fil principal està ocupat executant JavaScript, la interacció queda en cua fins que el fil s’allibera. Aquesta era l’única fase que mesurava FID.

El processing time és el temps que triguen els event handlers (callbacks de JavaScript) a executar-se. Un event handler de clic que executa una funció complexa — filtrar una llista, validar un formulari, recalcular un layout — pot trigar centenars de mil·lisegons si el codi no està optimitzat.

El presentation delay és el temps que transcorre des que els event handlers acaben fins que el navegador completa el següent frame visual (paint). Inclou el temps de style recalculation, layout, composite i paint. Si els event handlers modifiquen el DOM o els estils de forma extensiva, aquesta fase pot ser la més costosa.

FID només mesurava la primera fase de la primera interacció. INP mesura les tres fases de totes les interaccions i reporta el percentil 98 com a valor final. Això significa que una sola interacció extremadament lenta a tota la sessió és suficient per degradar l’INP.

Google va prendre la decisió de reemplaçar FID per INP perquè les dades de camp mostraven que el FID no reflectia l’experiència real de l’usuari. Un lloc podia tenir un FID excel·lent — el fil principal estava lliure quan l’usuari feia el seu primer clic — però oferir una experiència terrible en interaccions subsegüents: botons que triguen 400ms a respondre, formularis que es congelen en validar, filtres que bloquegen el navegador durant mig segon.

Com mesura l’INP la interactivitat: el cicle complet

Per entendre com optimitzar l’INP, cal comprendre el cicle complet de processament d’una interacció al navegador.

Quan un usuari fa clic a un botó, la seqüència és la següent:

1. El navegador registra l’event i l’afegeix a la cua del fil principal. Si el fil principal està lliure, comença a processar-lo immediatament. Si està executant una long task de JavaScript (> 50ms), l’event espera fins que la task actual acabi. Aquest temps d’espera és l’input delay.

2. Els event handlers s’executen. Tot el JavaScript associat a l’event (listeners de click, pointerdown, keydown, etc.) s’executa seqüencialment al fil principal. Si múltiples handlers estan registrats per al mateix event, s’executen en ordre. El temps total d’execució és el processing time.

3. El navegador recalcula estils, executa layout i pinta. Si els event handlers van modificar el DOM o els estils CSS, el navegador ha de recalcular tot el layout afectat, compondre les capes visuals i pintar els píxels actualitzats. Aquest procés és el presentation delay.

4. El següent frame visual apareix a la pantalla. El temps total des del pas 1 fins al pas 4 és el que INP mesura per a cada interacció.

Una dada tècnica rellevant: el navegador funciona a 60fps (frames per segon) quan tot va bé, cosa que significa un frame cada 16.7ms. Si el processament complet d’una interacció cap en un sol frame, la resposta és instantània per a l’usuari. Quan el processament supera els 200ms — el llindar d’INP de Google — l’usuari percep un retard notable.

La Long Animation Frames API (LoAF), disponible a Chrome des de la versió 123, permet mesurar amb precisió què ocorre durant cada frame prolongat. Proporciona dades granulars sobre quins scripts s’estan executant, quant tarda cadascun, i on es produeix el coll d’ampolla. Aquesta API reemplaça la Long Tasks API per al diagnòstic d’INP perquè reporta no només la durada sinó també la cadena de scripts responsables del retard.

Llindars d’INP: bo, necessita millora i deficient

Google defineix tres rangs per a l’INP:

• Bo: inferior a 200ms. La interacció es percep com a instantània o gairebé instantània. Segons dades de CrUX del 2025, el 63% dels orígens web assoleixen aquest llindar en mòbil.

• Necessita millora: entre 200ms i 500ms. L’usuari percep un retard notable però no suficientment llarg com per abandonar la interacció. El 21% dels orígens se situen en aquest rang.

• Deficient: superior a 500ms. La interacció es percep com a bloquejada o congelada. L’usuari pot intentar fer clic repetidament o abandonar la pàgina. El 16% dels orígens tenen un INP deficient.

Un aspecte que distingeix l’INP de les altres mètriques de Core Web Vitals és que utilitza el percentil 98 en lloc del percentil 75 per a l’avaluació. Això té una implicació pràctica significativa: si una pàgina rep 100 interaccions durant una sessió, l’INP reportat serà la segona pitjor interacció. Aquest percentil tan alt va ser escollit deliberadament per Google per capturar la pitjor experiència representativa sense ser distorsionat per outliers extrems.

L’impacte de l’INP en el posicionament es mesura a nivell d’origen (domini), no d’URL individual. Google agrega les dades de camp de totes les pàgines d’un domini per calcular l’INP general. Això significa que unes poques pàgines amb formularis o filtres molt lents poden degradar l’INP de tot el domini, fins i tot si la resta de les pàgines són ràpides.

Diagnòstic: com identificar interaccions lentes

Diagnosticar problemes d’INP requereix eines que permetin identificar quines interaccions específiques són lentes i què està causant el retard a cada fase del cicle.

Chrome DevTools — pestanya Performance: graveu una sessió en la qual interactueu amb els elements problemàtics de la pàgina. A la gravació, cerqueu les interaccions marcades amb un indicador vermell o groc a la secció “Interactions”. Cada interacció mostra l’input delay, processing time i presentation delay desglossats.

Long Animation Frames API (LoAF): a la consola de Chrome, performance.getEntriesByType('long-animation-frame') retorna tots els frames que van superar els 50ms, incloent els scripts específics executats durant cada frame. Aquesta API identifica no només l’script sinó la funció específica i la línia de codi responsable del retard.

Web Vitals Chrome Extension: mostra l’INP en temps real i ressalta la interacció que determina el valor actual. En passar el cursor sobre l’indicador d’INP, l’extensió mostra quin element va ser interactuat i quin va ser el desglossament de temps.

PageSpeed Insights i CrUX: proporcionen l’INP de camp — el percentil 98 real dels últims 28 dies — que és el valor que Google utilitza per al posicionament. L’INP de laboratori és útil per al diagnòstic però pot no coincidir amb el de camp si els patrons d’interacció dels usuaris reals difereixen dels que el desenvolupador simula.

Google Search Console: l’informe de Core Web Vitals classifica les URLs del domini pel seu estat d’INP i agrupa les URLs amb patrons similars, cosa que permet identificar plantilles o tipus de pàgina que comparteixen un problema comú.

Les causes més comunes d’un INP alt

Les causes d’INP alt s’agrupen en tres categories directament relacionades amb les tres fases del cicle d’interacció:

Long tasks al fil principal (input delay)

Qualsevol tasca de JavaScript que duri més de 50ms bloqueja el fil principal i retarda el processament d’interaccions. Les fonts més freqüents de long tasks són: scripts d’analítica (Google Analytics, Hotjar, Mixpanel) que processen dades de forma síncrona, scripts de publicitat que avaluen bidding i carreguen creatius, polyfills o transpilacions de JavaScript que executen codi innecessari en navegadors moderns, i frameworks JavaScript que realitzen hydration pesada en carregar la pàgina.

Segons dades del Web Almanac 2025, el JavaScript de tercers és responsable del 65% de les long tasks en llocs comercials. Un sol script d’analítica mal configurat pot afegir entre 100 i 300ms de bloqueig al fil principal, degradant l’input delay de qualsevol interacció que es produeixi durant la seva execució.

Event handlers lents (processing time)

Els callbacks de JavaScript que s’executen en resposta a una interacció poden ser costosos per múltiples raons: manipulació extensiva del DOM (inserir, eliminar o reorganitzar centenars de nodes), execució de lògica computacionalment pesada al fil principal (sorting, filtering, validació de formularis complexos), crides síncrones a APIs o localStorage, i recàlcul forçat de layout per llegir propietats com offsetHeight o getBoundingClientRect() després de modificar el DOM.

Actualitzacions visuals costoses (presentation delay)

Quan els event handlers modifiquen el DOM o els estils CSS de forma extensiva, el navegador ha d’executar style recalculation, layout, composite i paint abans de mostrar el següent frame. Les operacions més costoses són: modificar propietats que forcen relayout (width, height, top, left, font-size), afegir o eliminar elements del flux del document, i canviar classes CSS que afecten molts elements del DOM.

Tècniques d’optimització: long tasks, event handlers i web workers

L’optimització de l’INP s’estructura en tres nivells que corresponen a les tres fases del cicle d’interacció:

Nivell 1: Eliminar o reduir long tasks (input delay). La tècnica més eficaç és dividir les long tasks en blocs menors de 50ms que permetin al navegador processar interaccions entre blocs. Les opcions modernes inclouen:

• scheduler.yield() (disponible a Chrome 129+): permet al navegador pausar l’execució de l’script per processar events pendents i reprendre després. És l’API més neta per dividir long tasks.
• scheduler.postTask(): programa tasques amb prioritat (user-blocking, user-visible, background), permetent que les interaccions de l’usuari sempre tinguin prioritat sobre el treball de fons.
• requestIdleCallback(): delega treball a moments en què el navegador està inactiu, ideal per a tasques que no són urgents com la pre-càrrega de dades o analítica.

Per a scripts de tercers que causen long tasks però no es poden modificar, la solució és carregar-los amb defer o async, o moure’ls a un Web Worker. Un Web Worker executa JavaScript en un fil separat que no bloqueja el fil principal, eliminant el seu impacte en l’input delay.

Nivell 2: Optimitzar event handlers (processing time). Les tècniques clau són:

• Debounce i throttle: per a interaccions que es disparen repetidament (scroll, input, resize), limitar la freqüència d’execució del handler evita processament redundant. Un input de cerca amb debounce de 150ms executa la funció de filtratge només quan l’usuari deixa de teclejar, en lloc de a cada pulsació.
• Virtualització de llistes: per a interfícies que mostren centenars d’elements, renderitzar només els visibles al viewport i reciclar els nodes del DOM redueix el processing time de O(n) a O(1). Biblioteques com react-window o @tanstack/virtual implementen aquest patró.
• Offload a Web Workers: qualsevol lògica computacionalment pesada — sorting, processament de dades, transformació d’imatges — pot executar-se en un Worker sense bloquejar el fil principal. El handler de l’event envia les dades al Worker via postMessage() i rep el resultat de tornada.

Nivell 3: Reduir el cost visual (presentation delay). Les tècniques per minimitzar l’impacte dels canvis al DOM són:

• Usar transform i opacity en lloc de propietats que forcen relayout per a animacions desencadenades per interaccions.
• Agrupar les modificacions del DOM perquè el navegador executi un sol cicle de layout en lloc de múltiples.
• Usar content-visibility: auto en seccions fora del viewport perquè el navegador no recalculi el seu layout durant les interaccions.
• Evitar forçar layout síncron llegint propietats de layout després d’escriure al DOM dins del mateix frame.

La combinació d’aquestes tres capes d’optimització pot reduir l’INP d’un lloc de 500ms a menys de 150ms sense alterar la funcionalitat visible. Segons dades publicades per web.dev el 2025, els llocs que van implementar scheduler.yield() per dividir les seves long tasks principals van reportar millores d’INP del 40 al 60% en dades de camp.

La velocitat web i la interactivitat comparteixen les mateixes causes arrel: un fil principal sobrecarregat de JavaScript retarda tant la càrrega inicial (LCP) com la resposta a interaccions (INP). Optimitzar una mètrica sol millorar l’altra, cosa que converteix el rendiment del fil principal en el factor tècnic més determinant dels tres Core Web Vitals.