Sprint de optimización de Core Web Vitals: arregla el INP que te frena

INP: el Core Web Vital que más se falla en 2026

De las tres métricas que forman los Core Web Vitals, hay una que se volvió el dolor de cabeza de 2026: INP, que mide cuánto tarda tu web en responder cuando alguien interactúa con ella. Reemplazó a la antigua métrica FID en marzo de 2024, y es bastante más dura, porque no mide solo el primer toque sino la respuesta a lo largo de toda la visita. El dato lo confirma: alrededor del 43% de los sitios no pasa el umbral de 200 milisegundos de INP, una proporción mayor que la de los que fallan en carga o en estabilidad visual. Cuando llegó esta métrica, las tasas de aprobación de Core Web Vitals en móvil cayeron varios puntos de golpe, porque muchos sitios que pasaban con la métrica anterior dejaron de pasar.

Esto importa porque los Core Web Vitals son factor de posicionamiento, y INP, al ser el que más se falla, se vuelve a menudo el desempate entre dos páginas que por lo demás compiten parejo. No es la única señal que Google mira, pero es de las que separan al sitio que aparece arriba del que se queda debajo cuando todo lo demás está igualado. Fallarlo, entonces, no es un detalle técnico abstracto: es perder posiciones y, con ellas, visitas y ventas, por una causa que casi siempre se puede atacar.

Por qué tu web falla INP: casi siempre es JavaScript

La causa de fondo, en la enorme mayoría de los casos, es el exceso de JavaScript compitiendo por el hilo principal del navegador. El navegador hace muchas cosas en un solo hilo, y entre ellas está responder a los toques del usuario; si ese hilo está ocupado ejecutando código, la respuesta se retrasa, y eso es exactamente lo que INP penaliza. Los constructores de páginas y las plantillas cargadas de funciones suelen mandar entre 200 y 500 kilobytes de JavaScript, gran parte del cual ni siquiera se usa, y todo ese peso se traduce en un navegador ocupado justo cuando el usuario quiere que reaccione.

Hay un contraste que lo dice todo: los sitios estáticos bien construidos, con menos de 100 kilobytes de JavaScript, pasan INP por debajo de 100 milisegundos sin necesidad de optimización alguna, simplemente porque no le dan al navegador ese peso que atender. Es decir, el problema no es inevitable, es una consecuencia directa de cómo está construida la web. Por eso un sprint de optimización ataca precisamente ese exceso: lo que se puede diferir, lo que se puede reducir, lo que se puede quitar porque no aporta. Recortar el peso que ahoga al hilo principal es el corazón del trabajo.

Qué arregla el sprint, y cómo

El sprint ataca las tres métricas, con el foco donde más duele. Para INP, el trabajo es sobre el JavaScript: diferir lo que no hace falta de inmediato, dividir el código para que no se ejecute todo de golpe, reducir o eliminar lo que sobra, y aligerar las tareas que bloquean el hilo principal, de modo que el navegador quede libre para responder rápido a cada interacción. Para la carga, atacamos lo que retrasa que aparezca el contenido principal: imágenes sin optimizar, fuentes que bloquean el render, recursos que compiten por el ancho de banda en el peor momento.

Para la estabilidad visual, corregimos los elementos que se mueven mientras la página carga —imágenes sin dimensiones reservadas, anuncios o bloques que empujan el contenido—, que son los que provocan esos saltos molestos justo cuando vas a tocar algo. Todo esto con un alcance fijo acordado de antemano: sabes qué se va a tocar, qué resultado se busca, y cuándo termina. No es un mantenimiento abierto ni una bolsa de horas, es un trabajo con principio, alcance y final claros, medido antes y después para que la mejora sea verificable y no una sensación.

El techo honesto: cuándo es arquitectura, no ajuste

Aquí va la parte que casi nadie te dice: un sprint de optimización tiene un techo, y conviene conocerlo antes de empezar. Sobre una web razonablemente sana, el ajuste alcanza para cruzar los umbrales y la mejora es clara. Pero si la causa de fondo es una arquitectura pesada —un constructor que carga su propio peso inevitable, una maraña de plugins que no se puede desenredar sin desmontar el sitio—, el ajuste choca contra un límite: puedes mejorar, pero no llegar, y forzarlo significa pagar mucho por un resultado a medias.

Por eso el sprint siempre empieza por un diagnóstico que responde una pregunta clave: ¿esto se arregla sobre tu web actual, o el techo es arquitectura? Si es lo primero, hacemos el sprint y listo. Si es lo segundo, te lo decimos con honestidad en lugar de cobrarte por pelear contra un techo, y planteamos la reconstrucción sobre una base rápida que, por diseño, pasa estas métricas sin esfuerzo. Esa honestidad es el servicio: preferimos perder la venta del sprint antes que venderte uno que sabemos que no va a alcanzar el umbral.

Cómo medimos: de verdad, no en la demo

Medir bien es la mitad del trabajo, y es donde más se engaña. Hay dos tipos de medición de Core Web Vitals, y confundirlos es la trampa más común. La de laboratorio es la que da una herramienta en un momento puntual, con un dispositivo simulado: produce números que se ven bien pero que no son los que Google usa para posicionar. La de campo es la que cuenta de verdad: proviene de las visitas reales de tus usuarios, con sus teléfonos y conexiones reales, y es la que determina si pasas o no pasas a efectos de posicionamiento.

Nosotros trabajamos para los umbrales reales y medimos con esa lógica, no con la captura de un número inflado. Por eso no prometemos un puntaje de cien en una herramienta: ese puntaje puede ser perfecto en laboratorio y seguir fallando en campo, donde están tus usuarios de verdad. Lo que prometemos es atacar las causas reales, medir antes y después con datos que reflejen la experiencia real, y dejar constancia verificable de la mejora. Es la misma filosofía que define a este sitio: no describimos la calidad, la demostramos con métricas que cualquiera puede comprobar.

Planes y precios públicos

Publicamos los precios porque la transparencia es parte del producto. Tres niveles, según quieras saber dónde está el cuello de botella, arreglarlo, o resolver el caso en que el techo es arquitectura.

Cualquier plan se ajusta a tu caso. El diagnóstico define el alcance y el precio final, que ves antes de comprometerte. Para un negocio que pierde posiciones y ventas por una web lenta a responder, recuperar los umbrales suele pagarse solo.

Qué gana tu negocio cuando la web responde rápido

Conviene cerrar con lo que de verdad importa: no los milisegundos en sí, sino lo que cambian para tu negocio. Hay un principio viejo de la interacción con computadoras, el umbral de Doherty, que observó algo que sigue vigente: cuando un sistema responde en menos de 400 milisegundos, la persona se mantiene enganchada y en flujo; cuando tarda más, su atención se dispersa y la sensación de control se rompe. Una web que responde por debajo de ese umbral se siente fluida y mantiene al usuario avanzando; una que se arrastra al tocar la empuja, sin que sepa nombrarlo, a dudar y a irse. INP mide justamente esa frontera entre fluido y frustrante.

Eso se traduce en dos efectos concretos. El primero es conversión: cada fricción en la respuesta es una oportunidad de que el visitante abandone antes de comprar, reservar o contactar, así que una web que responde rápido convierte mejor con el mismo tráfico. El segundo es posicionamiento: al ser INP factor de posicionamiento y el que más sitios fallan, pasar el umbral te separa de la mayoría que no lo pasa, justo en el desempate. Sumados, significan más visitas que llegan y más visitas que se quedan y actúan. Por eso un sprint de Core Web Vitals no es un capricho técnico: es recuperar ventas y posiciones que una web lenta a responder está perdiendo en silencio, y hacerlo de forma medible para que el resultado se vea, no se prometa.

Y hay un detalle que lo vuelve aún más rentable: a diferencia de una campaña de anuncios, que deja de rendir el día que dejas de pagar, una web que responde rápido sigue convirtiendo y posicionando mejor mes tras mes sin costo adicional. El sprint es una inversión que se hace una vez y rinde de forma sostenida, porque arregla la causa en lugar de comprar tráfico que tape el síntoma.

Cómo se relaciona con la auditoría y el test de velocidad

Conviene ubicar este sprint junto a otras dos cosas que ofrecemos, porque son etapas distintas y se confunden. El test de velocidad gratuito es una primera señal que corres tú mismo para ver si tienes un problema. La auditoría web es un diagnóstico amplio de todo tu sitio, no solo de la velocidad. El sprint de Core Web Vitals es la ejecución del arreglo de rendimiento, con alcance fijo y resultado medible. Dicho corto: el test te avisa, la auditoría te da el panorama completo, y el sprint arregla la velocidad. Si ya sabes que tu problema es que tu web responde lento, el sprint va directo a eso sin rodeos.