La respuesta corta
- La decisión: Si financiar un proyecto de velocidad del sitio ahora, o dedicar esas mismas semanas de ingeniería a otro trabajo de conversión. Trata los Core Web Vitals como una línea de ingresos con un retorno esperado, no como una lista de verificación técnica que hay que poner en verde.
- Cuánto vale un proyecto de velocidad: Google y Deloitte midieron que una mejora de 0,1 segundos en la velocidad móvil elevó la tasa de conversión del retail en un 8,4% y el valor promedio de pedido en un 9,2%. Rakuten 24 convirtió un aprobado completo de Core Web Vitals en un aumento del 33,13% en la tasa de conversión y un 53,37% más de ingresos por visitante. El dinero es real, pero se concentra en un lugar muy específico.
- Cuándo es prematuro: Si los datos de campo móvil de tu tienda ya pasan los tres umbrales, otro sprint de velocidad devuelve casi nada. La elasticidad de la conversión es pronunciada mientras estás fallando y casi plana una vez que apruebas. Pulir un LCP de 2,0s hasta 1,5s es vanidad de ingeniería.
- En resumen: Financia el proyecto de velocidad cuando tus datos de campo móvil (CrUX, no de laboratorio) fallen al menos una métrica y el arreglo se pueda dimensionar en semanas, no en una re-plataforma. Si ya apruebas, ese presupuesto rinde más en trabajo de checkout y páginas de producto.
Toda guía de rendimiento trata a los Core Web Vitals de la misma manera: aquí hay tres métricas, aquí están los umbrales, aquí tienes una lista de verificación para ponerlas en verde. Ese enfoque es la razón por la que los proyectos de velocidad se financian en las tiendas equivocadas y se ignoran en las correctas. El verde no es el objetivo. El objetivo es el ingreso recuperado, y esos dos no son el mismo número.
Este artículo replantea la decisión. Un proyecto de velocidad es una asignación de capital: semanas de ingeniería que podrías gastar en otra cosa. Así que la pregunta no es "¿somos lo suficientemente rápidos?". Es "¿cuál es el retorno de ingresos esperado de este proyecto a nuestro nivel de tráfico, y supera al mejor uso alternativo de esas mismas horas?". Esa pregunta tiene una respuesta defendible. A continuación, un modelo para dimensionarla, los culpables específicos que mueven cada métrica y un umbral para saber cuándo el trabajo de velocidad se vuelve pulido prematuro.
¿Cuánto mueve realmente la velocidad del sitio los ingresos?
Las cifras principales son reales y provienen de estudios de campo con nombre propio, no de presentaciones de proveedores.
El informe Milliseconds Make Millions de Google y Deloitte analizó datos móviles de 37 marcas de retail, viajes y lujo. Una mejora de 0,1 segundos en la velocidad del sitio móvil elevó la tasa de conversión del retail en un 8,4% y el valor promedio de pedido en un 9,2%. El salto individual más pronunciado se dio en lo profundo del embudo —una subida del 9,1% al pasar del detalle del producto a añadir al carrito— lo que te dice que la velocidad hace más daño donde la intención es más alta.
Los casos de estudio son más dramáticos. Rakuten 24 realizó una prueba A/B optimizando los tres vitals y registró un aumento del 33,13% en la tasa de conversión, un 53,37% más de ingresos por visitante y un valor promedio de pedido un 15,20% mayor. redBus se enfocó de forma acotada en la capacidad de respuesta a la interacción, mejoró su INP en un 72% y vio un aumento del 7% en las ventas totales.
Ahora la parte que toda lista de verificación omite: no puedes extrapolar el coeficiente de Deloitte de forma lineal. La cifra del 8,4% por cada 100ms es una elasticidad marginal medida cerca de la banda del umbral. Multiplicarla —"vamos a recortar 1.000ms, así que eso es un 84% de subida"— es matemática de fantasía que va a matar tu proyecto el trimestre después de que se lance y no cumpla. La relación se aplana con fuerza. La conversión es muy sensible a la velocidad mientras eres lento, y progresivamente indiferente una vez que eres rápido. Mantén esa forma en mente; es toda la decisión de financiamiento, y volvemos a ella más abajo.
El contexto del mercado agudiza el argumento. A partir del conjunto de datos del Chrome UX Report de julio de 2025, solo alrededor del 48% de los orígenes móviles pasaba los tres Core Web Vitals. Aproximadamente la mitad del comercio móvil sigue fallando. Si tu tienda está en esa mitad, estás perdiendo conversión frente a competidores que no lo están, y el arreglo está dentro de tu código, no en tu presupuesto publicitario.
¿Qué es el INP, y por qué importa más en 2026?
En marzo de 2024, Interaction to Next Paint (INP) reemplazó a First Input Delay como Core Web Vital. Esto importa más que un simple cambio de métrica. FID solo medía el retraso antes de la primera interacción —un listón bajo que la mayoría de los sitios superaba por accidente. El INP mide la capacidad de respuesta a lo largo de cada interacción de una sesión: cada toque en añadir al carrito, cada selector de variante, cada filtro, cada pulsación de tecla en la búsqueda.
Para el comercio, esa es la diferencia entre una métrica que te halagaba y una que mide los momentos donde el dinero cambia de manos. Un primer renderizado lento pierde curiosos. Un añadir-al-carrito perezoso pierde compradores: personas que ya habían decidido. El INP pone un número a las interacciones que están más cerca de los ingresos.
La brecha se concentra en móvil, y dentro del JavaScript de terceros. Las tasas de aprobación de INP en móvil son en realidad las más fuertes de las tres métricas —alrededor del 77% de los orígenes registran un buen INP— lo que significa que la mayoría de las tiendas que fallan están fallando en velocidad de carga (LCP), no en capacidad de respuesta. Pero cuando el INP sí falla, la causa es casi siempre la misma: scripts de terceros pesados y tareas largas del hilo principal. Cada app de reseñas, widget de chat, etiqueta de analítica y píxel de personalización compite por el mismo único hilo que también tiene que responder al toque del comprador. Aquí es donde el INP se solapa con el costo acumulado de la deuda técnica en eCommerce: cada instalación de "solo una app más" es un impuesto pequeño y permanente sobre la capacidad de respuesta.
Dos realidades estructurales determinan dónde buscar. Primero, el móvil es donde vive la mayor parte del tráfico de comercio y donde el hardware es más débil, por lo que el mismo script bloquea el hilo por más tiempo en un Android de gama media que en tu MacBook; por eso las pruebas de laboratorio en la máquina de un desarrollador mienten. Si aún estás sopesando cuánto de tu experiencia debería siquiera vivir en la web móvil, esa es una decisión aparte que vale la pena tomar de forma deliberada. Segundo, los culpables difieren según la métrica, y saber qué palanca mueve qué número es lo que mantiene acotado un proyecto de velocidad.
| Métrica | Umbral (bueno) | Palanca de ingresos | Culpable común |
|---|---|---|---|
| LCP | <2.5s | Menos rebotes antes de que la página sea usable — velocidad de la primera impresión | Imágenes de portada sin optimizar, CSS/JS que bloquea el renderizado, respuesta lenta del servidor (TTFB) |
| INP | <200ms | Confianza en la interacción — añadir al carrito, filtros y toques de variante se sienten instantáneos | Scripts de terceros pesados, tareas largas del hilo principal, controladores de eventos sin optimizar |
| CLS | <0.1 | Menos toques errados — los botones no saltan mientras la página se asienta | Imágenes e incrustaciones sin dimensiones fijadas, banners y anuncios inyectados tarde, fuentes web |
El CLS merece una nota específica porque los operadores le dan poco peso. Un desplazamiento de diseño no es solo feo: en móvil provoca toques errados, y un toque errado en un selector de talla o en un botón de pago es un pedido perdido o abandonado. También retroalimenta al INP: un desplazamiento disparado por un clic retrasa el siguiente renderizado, así que una tienda con diseño inestable a menudo falla también en capacidad de respuesta. Los culpables son aburridos y baratos de arreglar: fija un ancho y alto explícitos en imágenes e incrustaciones, reserva espacio para cualquier cosa inyectada después de la carga. Aburrido y barato es exactamente el perfil que quieres en un proyecto financiado.
Por qué el ingreso está en la banda de fallo, no en la banda de aprobado
Aquí está el mecanismo no obvio que decide si tu proyecto se paga solo.
La respuesta de la conversión a la velocidad no es lineal. Se parece más a una curva que es pronunciada en la banda de fallo y plana en la banda de aprobado. Mover el LCP móvil de 4,0s a 2,5s —salir del fallo y entrar en aprobado— se sitúa en la parte pronunciada de esa curva, y por eso los casos de estudio que cruzan el umbral reportan subidas de conversión de dos dígitos. Mover el LCP de 2,0s a 1,5s se sitúa en la parte plana. Ambos son "1.500ms" y "500ms" de trabajo respectivamente, pero solo uno de ellos toca los ingresos.
Por eso el mismo sprint de velocidad es una gran inversión en una tienda y un desperdicio en otra. No se trata de cuántos milisegundos ahorras. Se trata de en qué parte de la curva los ahorras. Una tienda que falla en el percentil 75 tiene un enorme potencial de mejora porque está perdiendo compradores cuyos dispositivos y conexiones los colocan más allá del punto en que la página se siente rota. Una tienda que ya aprueba ha gastado ese potencial; el comprador marginal ya tiene una experiencia usable, y recortar otros 400ms no cambia casi nada que pueda percibir.
La velocidad es un bien de umbral, no un bien lineal
Cómo dimensionar el retorno: un modelo de financiamiento para un proyecto de velocidad
Trata el proyecto de velocidad como cualquier otra inversión: estima el retorno, compáralo con las alternativas, decide. Aquí tienes un modelo que puedes correr en una hoja de cálculo en veinte minutos.
Paso 1 — Aísla el ingreso en riesgo. Este es el ingreso anual que fluye a través de la superficie que falla los Core Web Vitals. Para casi toda tienda, eso es el móvil. Extrae la participación del móvil en los ingresos (no en las sesiones, en los ingresos), porque eso es lo que realmente está expuesto.
Ingreso en riesgo = GMV anual × participación del móvil en los ingresos
Paso 2 — Elige una estimación acotada de subida de conversión. No extrapoles el coeficiente de Deloitte. En cambio, ánclate a lo que los casos de estudio de campo realmente entregaron cuando una tienda cruzó el umbral, y elige un número de planificación dentro de ese rango de evidencia:
- Piso (arreglo de una sola métrica, p. ej. solo INP): ~5–7% — el rango de redBus.
- Medio (dos métricas hacia la banda de aprobado): ~10–15% — consistente con la elasticidad cercana al umbral de Deloitte aplicada de forma conservadora.
- Techo (aprobado completo, página reestructurada): hasta ~33% — el resultado de Rakuten 24, alcanzable pero por lo general requiere un rediseño, no un ajuste.
Planifica sobre el piso o el medio. Si construyes el caso de negocio sobre el techo, estás vendiendo, no dimensionando.
Paso 3 — Calcula la subida anual esperada.
Subida anual esperada de ingresos = Ingreso en riesgo × estimación de subida de conversión
Paso 4 — Compénsalo contra el costo. Resta el costo de ingeniería totalmente cargado (semanas de desarrollador a la tarifa real con cargas, más cualquier herramienta de monitoreo). Lo que queda es tu neto del primer año.
Ejemplo trabajado. Una tienda que hace $2,4M de GMV, con el 55% de los ingresos en móvil, fallando LCP y CLS en el percentil 75:
- Ingreso en riesgo = $2,4M × 0,55 = $1,32M
- Estimación de subida de conversión (dos métricas, caso medio) = 10%
- Subida anual esperada = $1,32M × 0,10 = $132.000
- Verificación conservadora (piso, 5%) = $66.000
- Costo del proyecto = ~4 semanas de ingeniería ≈ $30.000–$50.000
Incluso en el piso del 5%, el retorno de la inversión llega dentro del primer año, y cada año posterior compone. Financíalo. Ahora corre la misma tienda con las tres métricas ya aprobando en móvil: la estimación honesta de subida es del 0–2%, el retorno anual esperado es de $0–$26K contra el mismo costo de $30–50K, y el caso de retorno colapsa. No lo financies — el dinero pertenece a otra parte.
Conclusión clave
¿Cuándo vale la pena financiar un proyecto de velocidad, y cuándo es prematuro?
El modelo produce un número, pero tres condiciones deciden la decisión. Financia el proyecto cuando las tres se cumplan; si alguna falla, el dinero trabaja más duro en otra parte.
1. Fallas al menos una métrica en el campo, no en el laboratorio. Usa datos del Chrome UX Report —usuarios reales en el percentil 75— no una puntuación de Lighthouse en tu portátil. Las herramientas de laboratorio corren en hardware rápido y redes limpias; de manera rutinaria muestran verde mientras tus compradores móviles reales experimentan rojo. Si apruebas en el campo, ya has capturado el cruce, y esta es la razón individual más común por la que un proyecto de velocidad no devuelve nada. Aprobar en laboratorio pero fallar en campo significa financiarlo; fallar en laboratorio pero aprobar en campo significa dejarlo en paz.
2. La subida esperada supera a tu mejor proyecto de conversión alternativo. La velocidad compite con otro trabajo de conversión por las mismas horas, y parte de ese trabajo tiene un techo más alto. La investigación de Baymard sitúa la ganancia de conversión alcanzable con un mejor diseño de checkout en alrededor del 35% —a menudo un premio mayor que un aprobado de velocidad. Antes de financiar la velocidad, pon precio a las alternativas con honestidad: dónde el trabajo de conversión en la página de producto realmente rinde frente a dónde es puro teatro, la porción recuperable del abandono de checkout y carrito, y el ROI de arreglar la búsqueda y navegación en el sitio. Financia lo que tenga el mayor retorno esperado por semana de ingeniería —a veces es la velocidad, a menudo no lo es.
3. El arreglo es un ajuste, no una re-plataforma. Optimizar imágenes, diferir scripts de terceros, reservar espacio de diseño y arreglar recursos que bloquean el renderizado son días o semanas de trabajo con un retorno limpio. Si la única forma de aprobar es reconstruir el front end o abandonar tu plataforma, esa es una decisión mucho más grande con su propia economía, y el argumento de la velocidad por sí solo no la sostendrá.
| Escenario | Estado de campo móvil (CrUX, p75) | Subida de conversión esperada | Decisión de financiamiento |
|---|---|---|---|
| Fallando LCP y CLS | 2 de 3 fallando | ~10–15% (caso medio) | Financiar — estás en la parte pronunciada de la curva |
| Fallo solo en INP | 1 de 3 fallando | ~5–7% (rango de redBus) | Financiar si el arreglo se dimensiona en días, no una reconstrucción |
| Las tres aprobando | 0 de 3 fallando | ~0–2% | No financiar — pulido prematuro; gasta en checkout o PDP |
| Fallando en laboratorio, aprobando en campo | 0 de 3 fallando | ~0% | No financiar — optimizar un número que ningún usuario percibe |
Las dos maneras en que este proyecto desperdicia dinero en silencio
Una disciplina de medición subyace a todo esto: juzga el proyecto por los ingresos y por la tasa de aprobación de datos de campo, no por la tasa de conversión por sí sola en las semanas posteriores al lanzamiento. La tasa de conversión se mueve por una docena de razones —mezcla de tráfico, promociones, estacionalidad— y atribuir cada oscilación a tu trabajo de velocidad es como los buenos proyectos son declarados fracasos por error. Instrumenta esto como lo harías con cualquier otro cambio, y sé honesto sobre lo que el número te está diciendo, lo cual es una disciplina en sí misma —ve por qué la tasa de conversión tan a menudo se lee como una métrica de vanidad.
Preguntas Frecuentes
¿Una puntuación de Lighthouse de 90+ es suficiente para saltarse un proyecto de velocidad?
No. Lighthouse es una herramienta de laboratorio que corre en hardware rápido y una red limpia. Puede mostrar verde mientras tus compradores móviles reales —en teléfonos Android de gama media y datos móviles— experimentan Core Web Vitals que fallan. La decisión de financiamiento debe basarse en datos de campo del Chrome UX Report en el percentil 75, que reflejan a los usuarios reales. Una puntuación alta de laboratorio con datos de campo que fallan es una señal para financiar; una puntuación baja de laboratorio con datos de campo que aprueban normalmente no lo es.
¿Qué Core Web Vital deberíamos arreglar primero para el mejor retorno de ingresos?
Arregla el que estés fallando en el percentil 75 en datos de campo, empezando por el LCP si fallas varios. La velocidad de carga (LCP) es el punto de fallo más común para el comercio y está más cerca del problema de rebotar-antes-de-usable. El INP viene después porque gobierna las interacciones de añadir al carrito y de filtros donde se pierden los compradores con intención. El CLS suele ser el más barato de arreglar y vale la pena hacerlo junto con los otros porque la estabilidad del diseño también retroalimenta al INP.
¿Cómo estimamos el retorno de ingresos antes de comprometer tiempo de ingeniería?
Multiplica tu ingreso en riesgo (GMV anual × participación del móvil en los ingresos) por una estimación de subida de conversión anclada a casos de estudio reales —aproximadamente 5–7% para un arreglo de una sola métrica, 10–15% para cruzar dos métricas hacia la banda de aprobado. No extrapoles linealmente la cifra del "8,4% por cada 100ms"; es una elasticidad cercana al umbral que se aplana, y usarla como un multiplicador de línea recta sobrestimará el retorno gravemente.
Ya pasamos los tres vitals en móvil. ¿Deberíamos seguir invirtiendo en velocidad?
Por lo general, no. La respuesta de la conversión a la velocidad es pronunciada mientras estás fallando y casi plana una vez que apruebas. La velocidad adicional por debajo de los umbrales es trabajo de ingeniería real con un retorno de conversión cercano a cero. Redirige ese presupuesto hacia trabajo de conversión con un techo restante más alto —las mejoras en checkout, página de producto y búsqueda en el sitio normalmente rinden más por semana de ingeniería una vez que tus vitals están en verde.
¿De verdad las apps de terceros dañan el rendimiento lo suficiente como para importar?
Sí, y son la principal causa de un INP pobre en sitios de comercio. Cada widget de reseñas, herramienta de chat, etiqueta de analítica y script de personalización compite por el mismo hilo principal que debe responder al toque del comprador. Cada instalación es un pequeño y permanente impuesto sobre la capacidad de respuesta que se acumula. Audita los scripts de terceros antes de asumir que tu propio código es el problema —diferir o eliminar los que no se usan suele ser la parte de mayor retorno y menor esfuerzo de un proyecto de velocidad.
