Hay una conversación que casi todo dueño de un sitio ya tuvo con un desarrollador y de la que salió insatisfecho. “Tu sitio está lento.” “Vale, pero ¿cuánto me cuesta eso?” Y ahí viene la respuesta que no convence a nadie: “mejora la experiencia”. La experiencia es abstracta. La facturación es concreta. Mientras la lentitud no se convierte en un número en dinero, siempre queda al final de la lista de prioridades — detrás del banner nuevo y de la promoción del mes.
Este post existe para cerrar esa brecha. La velocidad de un sitio sí tiene una relación medida con los ingresos — y se puede estimar cuánto cuesta tu lentitud por mes con un modelo simple. También vamos a separar lo que de verdad mueve la aguja (las métricas que el usuario siente) del teatro de la nota bonita de PageSpeed. Porque optimizar para el número equivocado es gastar energía sin ver dinero.
Velocidad y conversión: lo que muestran los datos
Los Core Web Vitals son las tres métricas con las que Google mide la experiencia real de uso de una página: velocidad de carga, respuesta a la interacción y estabilidad visual. Existen porque la experiencia de carga tiene un efecto directo y medible sobre quien compra.
El dato más citado — y legítimo — viene del estudio Milliseconds Make Millions, realizado por Deloitte a pedido de Google. Fueron 37 marcas de retail, turismo y lujo, y más de 30 millones de sesiones móviles analizadas. El resultado incomoda de lo pequeño que es el gatillo:
| Sector | Ganancia con solo 0,1s más rápido (móvil) |
|---|---|
| Retail | +8,4% de conversión, +9,2% en el ticket promedio |
| Turismo | +10,1% de conversión, +1,9% en el ticket promedio |
| Lujo | +40,1% en la progresión hacia “agregar al carrito” |
Léelo de nuevo: una décima de segundo. No un segundo, no cinco. La lentitud de tu sitio no necesita ser evidente para costar dinero — drena la conversión en silencio, un milisegundo a la vez.
Cuánto cuesta tu lentitud por mes
No necesitas el estudio de Deloitte para estimar tu caso. Necesitas tres números que ya tienes en el analytics y una cuenta de servilleta:
- Visitantes/mes en la página que importa (ej.: 40.000).
- Tasa de conversión actual (ej.: 2% → 800 conversiones).
- Valor promedio por conversión (ej.: $150 → $120.000/mes).
Ahora supón, de forma conservadora, que corregir la lentitud recupere 5% de la conversión — bien por debajo del 8,4% del retail en el estudio. Eso significa 40 conversiones más por mes, o $6.000 mensuales. $72.000 al año dejados sobre la mesa. Y ese es el escenario tímido.
El objetivo del modelo no es precisión de laboratorio — es sacar el rendimiento del terreno de lo “abstracto” y ponerlo en el de “esto paga el proyecto de optimización en dos semanas”. Cuando la conversación se vuelve número, la priorización cambia sola. Es la misma lógica que aplicamos al conectar producto e ingresos en rendimiento web y conversión: una decisión técnica justificada por dinero, no por gusto.
Las tres métricas que el usuario siente
Desde marzo de 2024, Google consolidó los Core Web Vitals en tres métricas — y cambió una de ellas. El antiguo FID salió; entró el INP, que mide la respuesta a la interacción de forma mucho más completa (anuncio oficial en web.dev). El trío actual, con las reglas de Google:
| Métrica | Qué mide | Bueno | Malo |
|---|---|---|---|
| LCP (Largest Contentful Paint) | Cuándo aparece el contenido principal | ≤ 2,5s | > 4,0s |
| INP (Interaction to Next Paint) | Qué tan rápido responde la página al clic/toque | ≤ 200ms | > 500ms |
| CLS (Cumulative Layout Shift) | Estabilidad — ¿el layout “salta”? | ≤ 0,1 | > 0,25 |
Fíjate en que cada una cubre un momento diferente de la frustración real: LCP es la espera para ver, INP es la espera para actuar, CLS es ese susto de hacer clic en el lugar equivocado porque el botón se movió. Optimizar el rendimiento es atacar esos tres fastidios — no perseguir un número único.
LCP: la espera para ver
Un LCP alto casi siempre tiene culpables conocidos: una imagen gigante sin compresión, un servidor lento en el primer byte, o una fuente/CSS que bloquea la renderización. Es la métrica más visible y, en general, la de mejor retorno para atacar primero en e-commerce y en landing pages.
INP: la espera para actuar
El INP es la métrica nueva y la más ligada a JavaScript pesado. Cuando haces clic en “agregar al carrito” y no pasa nada por medio segundo, es INP malo — el hilo principal está ocupado procesando script en vez de responderte. Los sitios con muchas bibliotecas y poco cuidado sufren aquí.
CLS: el layout que salta
El CLS es el más barato de corregir y el más descuidado. La causa número uno es una imagen o anuncio sin dimensión reservada: el contenido carga, empuja el resto hacia abajo, y el usuario toca en el lugar equivocado. Reservar espacio para el contenido multimedia resuelve la mayor parte.
Por qué la nota de PageSpeed engaña
Aquí está la trampa que hace que los equipos optimicen lo equivocado: la nota de PageSpeed Insights es un test de laboratorio. Simula un dispositivo y una red en un entorno controlado. Es útil para el diagnóstico, pero no es la experiencia de tus usuarios.
Los datos que de verdad importan son los de campo — el CrUX (Chrome UX Report), que mide usuarios reales, con celulares reales, en redes reales, en el percentil 75. Y es perfectamente posible tener:
- Nota 95 en el laboratorio y reprobar en los Core Web Vitals de campo, porque tus usuarios acceden desde un celular mediano en 4G, no desde el datacenter del test.
- Nota 70 y aprobar de sobra en el campo, porque la base de usuarios usa dispositivos y conexiones mejores que lo simulado.
La regla real se aplica al percentil 75 de los usuarios de verdad: la experiencia tiene que ser buena para la mayoría concreta que accede a tu sitio, no para el promedio ni para el laboratorio. Perseguir 100 en PageSpeed mientras el campo sigue en rojo es optimizar el panel, no el negocio.
Lo que realmente mueve la aguja en un stack real
Después de medir el campo y encontrar la métrica que falla, el retorno viene de un puñado de causas que se repiten en casi todo proyecto:
- Imágenes. El mayor peso de la web. Comprime, usa formatos modernos, dimensiona al tamaño mostrado y define ancho/alto para no generar CLS.
- JavaScript en exceso. Cada biblioteca “solo por conveniencia” cuesta INP. Menos script, o script cargado bajo demanda, responde más rápido al usuario.
- Fuentes que bloquean. Una fuente personalizada mal configurada traba la renderización y empeora el LCP. Cárgala con estrategia y define un fallback.
- Servidor lento en el primer byte. Caché, CDN y un backend que responde rápido cortan la base de todas las métricas.
- Reservar espacio para multimedia y anuncios. Corrige el CLS casi gratis.
El punto de disciplina: prioriza la página que genera ingresos. Home, página de producto y checkout primero. Optimizar una página institucional en la que nadie convierte mientras el checkout se arrastra es gastar esfuerzo lejos del dinero. Esa lógica de alcance es la misma que defendemos en MVP de cero a producción — resolver lo que mueve la aguja antes de pulir el resto.
Vale una advertencia sobre los atajos: el rendimiento construido con prisa, apilando un plugin de caché y un “optimizador mágico” sin entender la causa, suele cobrar la cuenta después. Es el mismo riesgo de subir código sin cuidado que describimos en vibe coding: no subas un proyecto de fin de semana — funciona en la prueba y se desmorona bajo tráfico real. Y cada capa extra que agregas para “acelerar” es una cosa más que puede romperse en producción; los riesgos de publicar apps en producción valen también para el stack de rendimiento. La ganancia sólida viene de atacar la causa — imagen, script, servidor — no de camuflar el síntoma.
¿Y el SEO en todo esto?
Sí, los Core Web Vitals son una señal de ranqueo de Google. Pero es honesto decir: no es la señal más fuerte. El contenido relevante y la autoridad pesan más. Si tu sitio es lento y tiene contenido débil, el rendimiento no salva el ranqueo.
El mayor retorno de la velocidad no está en el SEO — está en la conversión. Menos abandono en la espera, más páginas por sesión, un checkout que se completa en vez de trabarse. La ganancia de búsqueda es un bono agradable, no el motivo. Los equipos que invierten ese orden optimizan para el robot y se olvidan del humano que paga la cuenta. Vale cruzar esta lectura con el mantenimiento continuo de sitios que discutimos en mantenimiento WordPress continuo: el rendimiento no es un proyecto único, es higiene recurrente.
Un plan de ataque en cuatro pasos
Para salir de la teoría sin perderte:
- Mide el campo. Abre Search Console y CrUX. Descubre cuál de las tres métricas está en rojo para usuarios reales — no confíes solo en la nota del laboratorio.
- Calcula el costo. Corre el modelo de servilleta con tus números. Convierte la lentitud en dinero/mes para justificar la prioridad.
- Ataca la causa, en la página correcta. Empieza por la página que genera ingresos y por la causa dominante (casi siempre imagen o JavaScript).
- Vuelve a medir y monitorea. El rendimiento se degrada con el tiempo — cada plugin, script de marketing e imagen nueva erosiona la ganancia. Trátalo como un seguimiento continuo.
Si quieres transformar esto en resultado — del diagnóstico de campo a la corrección en la página que factura — es exactamente el tipo de trabajo que hacemos en desarrollo web. La regla nunca es la nota bonita: es la conversión que sube y la lentitud que deja de costar.
Preguntas frecuentes
¿La velocidad del sitio realmente afecta las ventas?
Sí, y hay datos de campo para probarlo. El estudio “Milliseconds Make Millions”, de Deloitte con Google, midió 37 marcas y más de 30 millones de sesiones: una mejora de apenas 0,1 segundos en móvil elevó la conversión en retail un 8,4% y en turismo un 10,1%. La velocidad no es vanidad técnica — es ingresos.
¿Qué son los Core Web Vitals?
Son tres métricas de Google que miden la experiencia real de uso: LCP (velocidad de carga del contenido principal), INP (respuesta a la interacción del usuario) y CLS (estabilidad visual del layout). Desde marzo de 2024, el INP reemplazó al antiguo FID. Se miden con usuarios reales, no en laboratorio.
¿Cuál es la diferencia entre la nota de PageSpeed y los datos de campo?
La nota de PageSpeed Insights viene de un test de laboratorio, en un entorno simulado. Los datos de campo (CrUX) vienen de usuarios reales en tu sitio, con dispositivos y redes de verdad. Es posible tener nota 90 en el laboratorio y fallar en los Core Web Vitals de campo. La experiencia real es lo que cuenta para la conversión y para la búsqueda.
¿Qué es un buen LCP, INP y CLS?
Según Google: un buen LCP es hasta 2,5 segundos; un buen INP es hasta 200 milisegundos; y un buen CLS es hasta 0,1. Por encima de eso hay franjas de “necesita mejorar” y “malo”. La regla se aplica al percentil 75 de tus usuarios reales — es decir, la experiencia tiene que ser buena para la mayoría, no solo en el promedio.
¿Mejorar el rendimiento ayuda en Google?
Ayuda, pero con un peso realista. Los Core Web Vitals son una señal de ranqueo, y no la más fuerte — el contenido y la relevancia pesan más. En la práctica, el mayor retorno del rendimiento viene de la conversión: menos abandono, más páginas por sesión y un checkout que se completa. La ganancia de SEO es un bono, no el motivo principal.
¿Por dónde empiezo a mejorar la velocidad de mi sitio?
Empieza midiendo los datos de campo reales (CrUX/Search Console) para saber qué métrica falla. Después ataca las causas más comunes: imágenes pesadas y sin dimensión definida, JavaScript en exceso y fuentes que traban la renderización. Prioriza la página que genera ingresos — home, producto o checkout — antes de optimizar el sitio entero.