El 12 de març de 2024, aproximadament 600.000 webs que fins llavors aprovaven tots els Core Web Vitals van començar a suspendre’n un. No perquè haguessin empitjorat: Google va substituir el FID per l’INP, un criteri molt més estricte d’interactivitat. La transició va revelar el que les dades de camp ja indicaven des de feia mesos: molts llocs carreguen ràpid però responen lentament.
L’INP (Interaction to Next Paint) mesura quant tarda la teva pàgina a respondre visualment al que fa l’usuari. No només a la primera acció, com feia el FID, sinó a cada clic, cada tap i cada pulsació de teclat durant tota la sessió. Un usuari que omple un formulari, filtra resultats o navega per un menú desplegable genera desenes d’interaccions. L’INP reporta la pitjor d’elles.
El llindar és concret: 200ms o menys per considerar-se bo. En aquest marge, el navegador ha de rebre l’input, executar tots els handlers d’events, fer qualsevol recàlcul de DOM necessari i pintar el frame següent en pantalla. En molts llocs amb JavaScript intensiu, aquest cicle s’estén fins als 800ms o més.
Com funciona l’INP: les tres fases d’una interacció
Per optimitzar l’INP cal entendre exactament què mesura. Cada interacció registrada pel navegador es divideix en tres fases:
1. Retard d’entrada (Input delay)
El temps que transcorre des que l’usuari fa clic o prem fins que el navegador pot començar a executar els handlers d’aquell event. Si el fil principal està ocupat amb una altra tasca — una petició en vol processant dades, un timer executant codi, el parsing d’un script — l’event es queda en cua. Aquest temps en cua és el retard d’entrada.
Un retard d’entrada alt sol indicar tasques llargues bloquejant el fil principal. La referència estàndard és que cap tasca hauria de durar més de 50ms en el fil principal per garantir capacitat de resposta immediata.
2. Durada de processament (Processing duration)
El temps que tarda a executar-se tot el codi dels callbacks d’event associats a aquella interacció. Si un clic en un botó dispara tres handlers que actualitzen l’estat de React, fan una crida a una API i re-renderitzen un component complex, tota aquesta execució se suma aquí.
Aquest és el component on es pot intervenir més amb canvis al codi.
3. Retard de presentació (Presentation delay)
El temps des que els callbacks acaben fins que el navegador renderitza el frame següent amb els canvis aplicats. Inclou el recàlcul d’estils, el layout i la composició. Un DOM molt gran, canvis d’estil que forcen reflow o transformacions CSS no-compositor poden inflar aquest número.
La suma de les tres fases és l’INP d’aquella interacció. L’INP de la pàgina és el valor més alt (o proper al màxim) de totes les interaccions registrades durant la sessió.
L’estat real de l’INP el 2025: qui suspèn i per què
Les dades del Chrome UX Report processades per DebugBear el 2025 mostren la foto actual de l’INP global. En desktop, el 97% dels webs aconsegueixen un INP bo (≤200ms). En mòbil, aquest percentatge baixa al 77%. Aquesta bretxa de 20 punts percentuals no s’explica principalment per codi mal optimitzat: s’explica pels dispositius.
Als Estats Units, Alemanya o el Japó, la mediana de l’INP en mòbil és de 100ms — dins del llindar bo. A Filipines, el percentil 90 dels llocs més lents arriba als 600ms. A Lesoto o Angola, fins i tot webs medianes superen els 300ms. El 23% de webs mòbils que suspenen l’INP són, en gran mesura, usuaris a països amb dispositius de gamma baixa i connexions inestables processant el mateix JavaScript que altres usuaris executen en un iPhone recent.
La Web Almanac de l’HTTP Archive del 2025 confirma que els 1.000 llocs més visitats del món van millorar del 53% al 63% de pàgines amb INP bo en aquell any — un guany de 10 punts percentuals en 12 mesos. Però a la totalitat del web, el marge de millora segueix sent significatiu.
Els sectors amb pitjor INP de forma consistent són l’e-commerce (molta lògica de filtres, cistella, validacions en temps real) i els mitjans de comunicació (scripts de publicitat programàtica, trackers d’analytics amb handlers costosos). Els llocs estàtics o amb poc JavaScript són els que més fàcilment aconsegueixen INP en el rang bo.
Per què l’INP importa per al negoci: el cas redBus
Les mètriques de rendiment tenen sentit quan es tradueixen en resultats concrets. El cas de redBus — la plataforma de reserva d’autobusos més gran de l’Índia — és el benchmark de referència per a l’impacte de l’INP en el negoci.
redBus tenia problemes d’INP específicament en camps de cerca i filtres. Les seves interaccions més crítiques arribaven a duracions d’entre 870 i 900ms — quatre vegades el llindar bo de Google. L’equip va identificar tres fonts de latència:
Handler de scroll sense debouncear: El handler de scroll s’executava en cada píxel de moviment, saturant el fil principal. La solució va ser afegir debounce al handler i usar requestAnimationFrame per prioritzar el treball de renderitzat abans del frame següent.
Càrrega lazy de resultats en lots de 30: Cada lazy load carregava 30 ítems, generant una tasca de processament i renderitzat costosa. Reduir el lot a 10 ítems va fragmentar el treball en tasques més petites i va repartir la càrrega.
Estat de formulari sincronitzat a Redux en cada keystroke: Actualitzar el store global de Redux en cada tecla disparava re-renders complets de l’arbre de components. La solució va ser gestionar l’estat de l’input localment (estat local de React) i sincronitzar al store només en l’event blur — quan l’usuari abandona el camp.
El resultat: una reducció del 72% en l’INP dels camps d’input, amb interaccions que van passar de 870-900ms a 350-370ms. L’impacte en el negoci va ser un increment del 7% en vendes totals. redBus va documentar la metodologia completa usant la llibreria web-vitals de Google amb RUM a través d’una pila ELK (Elasticsearch-Logstash-Kibana), mesurant al percentil 95 — no en la mediana.
Les quatre causes arrel d’un INP deficient
1. Tasques llargues en el fil principal
Una tasca llarga és qualsevol tasca que ocupa el fil principal durant més de 50ms. Durant aquest temps, el navegador no pot respondre a events d’usuari, cosa que es tradueix directament en retard d’entrada. Els culpables habituals: parsing i execució de JavaScript pesat en el moment de la interacció, timers que executen treball costós, i scripts de tercers (analytics, widgets de xat, scripts d’A/B testing) que s’executen en el fil principal sense cedir control.
La solució és fragmentar aquestes tasques llargues. Addy Osmani, engineering manager a Google Chrome i referència en rendiment web, ho resumeix directament: “JavaScript is your most expensive asset” — no per la seva mida de descàrrega, sinó per la feina de parsing i execució que exigeix en el fil principal.
2. Handlers d’event amb massa treball síncron
Un handler d’event que fa massa treball de forma síncrona bloqueja el fil principal fins que acaba. Si un clic en “afegir al carret” dispara una validació d’estoc, actualitza l’estat global, recalcula el preu total i re-renderitza la capçalera amb el comptador actualitzat, tot això ocorre en la mateixa tasca. El frame següent no es pot pintar fins que aquella tasca acabi.
La solució és separar el treball urgent (actualitzar la UI immediatament per donar feedback visual a l’usuari) del treball diferible (sincronitzar amb el servidor, actualitzar comptadors secundaris, registrar l’event d’analytics). El treball diferible pot executar-se en una tasca separada després del frame renderitzat.
3. Reconciliació costosa en frameworks JavaScript
React, Angular i Vue gestionen el DOM a través d’una capa d’abstracció que afegeix treball addicional quan l’estat canvia. En aplicacions grans, una interacció simple pot desencadenar el re-renderitzat d’un arbre de components que inclou desenes o centenars d’elements.
Per a React específicament, les eines més efectives són: React.memo per evitar re-renders innecessaris de components que no han canviat, useMemo per memoritzar càlculs costosos, useCallback per estabilitzar referències de funcions, i startTransition (React 18+) per marcar actualitzacions d’estat com a no urgents i permetre que el navegador prioritzi el feedback visual immediat.
4. DOM excessivament gran
Un DOM amb més de 1.400 nodes és un senyal d’advertència de Lighthouse. Cada cop que JavaScript modifica el DOM, el navegador ha de recalcular estils i layout. En un arbre DOM molt gran, aquests recàlculs són més costosos i contribueixen al retard de presentació. La virtualització de llistes llargues — renderitzar només els elements visibles al viewport — és la tècnica estàndard per a webs amb contingut dinàmic extens.
Tècniques concretes d’optimització de l’INP
Yielding al fil principal
La tècnica de yielding consisteix a fragmentar una tasca llarga en subtasques més petites, cedint el control al navegador entre elles perquè pugui processar events pendents. El patró més senzill usa setTimeout amb delay 0:
button.addEventListener('click', () => {
// Treball urgent: feedback visual immediat
updateButtonState('loading');
// Cedeix el control al navegador abans de continuar
setTimeout(() => {
processExpensiveWork();
updateUI();
}, 0);
});L’API scheduler.yield() (disponible a Chromium des del 2024) ofereix una versió més granular d’aquest patró amb millors garanties de priorització. És l’evolució del yielding manual amb setTimeout i s’espera que el seu suport s’expandeixi a altres navegadors.
Separar treball de renderitzat del treball posterior al frame
Per a interaccions on cal actualitzar alguna cosa visualment i després fer treball addicional, el patró requestAnimationFrame + setTimeout(0) de web.dev és precís:
textInput.addEventListener('input', (event) => {
// Actualitza la UI (treball de renderitzat — ha d'anar abans del frame)
updateDisplay(event.target.value);
// Programa treball no visual per després del frame
requestAnimationFrame(() => {
setTimeout(() => {
runSpellCheck(event.target.value);
syncToStore(event.target.value);
}, 0);
});
});El requestAnimationFrame garanteix que updateDisplay s’executa en el cicle de renderitzat correcte. El setTimeout(0) dins del callback endarrereix la resta del treball a una nova tasca, després que el frame s’hagi pintat.
Debounce i throttle per a events d’alta freqüència
Els events input, scroll i resize poden disparar-se desenes de vegades per segon. Executar lògica costosa en cada disparament satura el fil principal. Debounce (executar només quan l’usuari ha deixat d’interactuar durant N ms) i throttle (executar com a màxim un cop cada N ms) redueixen dràsticament el nombre d’execucions sense afectar la percepció de resposta.
CSS content-visibility per a DOM gran
La propietat CSS content-visibility: auto indica al navegador que pot ometre el renderitzat de seccions fora del viewport, reduint el cost de layout i paint. En pàgines amb molt contingut sota el fold, aquesta propietat pot reduir el temps de renderitzat inicial i alleujar el retard de presentació en interaccions que modifiquen el DOM.
Com diagnosticar l’INP amb eines reals
PageSpeed Insights: Introdueix la URL per obtenir l’INP de camp (dades del CrUX amb usuaris reals) i l’INP de laboratori (Lighthouse simulat). La dada de camp és la que Google usa per al rànquing. Si hi ha una diferència gran entre tots dos, investiga si hi ha interaccions que Lighthouse no simula però els usuaris reals sí fan.
Chrome DevTools — pestanya Performance: Grava mentre interactues amb la pàgina. Busca les barres vermelles en el fil principal que indiquen tasques llargues (>50ms). Fes clic en una interacció per veure la descomposició en retard d’entrada, temps de processament i retard de presentació. El flame chart mostra quines funcions consumeixen més temps dins de cada tasca.
Extensió Web Vitals de Google: Mostra l’INP en temps real mentre navegues. Útil per identificar quines interaccions específiques són les més lentes en el teu flux d’usuari real.
Llibreria web-vitals.js en producció: Per a RUM en producció, la llibreria oficial de Google reporta l’INP amb atribució de l’element que el va desencadenar. Aquesta és la mateixa metodologia que va usar redBus per identificar els seus camps d’input com la font dels seus problemes.
import { onINP } from 'web-vitals/attribution';
onINP(({ value, attribution }) => {
console.log(`INP: ${value}ms`);
console.log(`Element: ${attribution.interactionTarget}`);
console.log(`Tipus: ${attribution.interactionType}`);
});L’INP i la seva relació amb el posicionament a Google
L’INP és un dels tres Core Web Vitals que Google usa com a senyal de rànquing des del març de 2024, juntament amb el LCP i el CLS. Un INP deficient no genera una penalització directa de posicions, però funciona com a desavantatge comparatiu: quan dues pàgines són equivalents en contingut i autoritat, els senyals d’experiència de pàgina — inclòs l’INP — actuen com a factor de desempat.
L’informe de DebugBear sobre el Google Core Update de desembre de 2025 va documentar caigudes del 31% de visibilitat en pàgines amb INP superior a 300ms en mòbil. No totes les pèrdues de posicionament s’atribueixen exclusivament a l’INP — la majoria d’actualitzacions core afecten múltiples senyals — però el patró confirma que un INP deficient forma part del perfil tècnic de les pàgines que perden posicions.
Per a l’e-commerce, on la velocitat de resposta del carret, els filtres i el cercador intern té impacte directe en la conversió, l’optimització de l’INP té un ROI doble: millora el rànquing i millora la taxa de conversió de forma independent.
Vols saber on es troba l’INP del teu web i quines interaccions específiques l’estan arrossegant cap avall? Ho revisem com a part de qualsevol auditoria tècnica. Explica’ns el teu cas.
Comparteix aquest article
Si t'ha resultat útil aquest contingut, comparteix-lo amb els teus col·legues.
Preguntes Freqüents
¿Con qué frecuencia publican contenido nuevo?
Publicamos artículos nuevos semanalmente, enfocados en las últimas tendencias de SEO técnico, casos de estudio reales y mejores prácticas. Suscríbete a nuestro newsletter para no perderte ninguna actualización.
¿Los consejos son aplicables a cualquier tipo de sitio web?
Nuestros consejos se adaptan a diferentes tipos de sitios: ecommerce, blogs, sitios corporativos y aplicaciones web. Siempre indicamos cuándo una técnica es específica para cierto tipo de sitio o requerimientos técnicos.
¿Puedo implementar estas técnicas yo mismo?
Muchas técnicas básicas puedes implementarlas tú mismo siguiendo nuestras guías paso a paso. Para optimizaciones avanzadas o auditorías completas, recomendamos consultar con especialistas en SEO técnico como nuestro equipo.
¿Ofrecen servicios de consultoría personalizada?
Sí, ofrecemos servicios de consultoría SEO técnica personalizada, auditorías completas y optimización integral. Contáctanos para discutir las necesidades específicas de tu proyecto y cómo podemos ayudarte.
