La velocidad de carga vende porque cada segundo de espera destruye conversiones antes de que el visitante vea su oferta. Google midió que el 53% de las visitas móviles se abandona cuando el sitio tarda más de 3 segundos, y Deloitte documentó que mejorar apenas 0,1 segundos sube las conversiones un 8,4% en comercio minorista.
No es un problema de estética ni de gusto: es un problema de caja. Un sitio lento pierde el mismo tráfico que usted paga en pauta, arrastra el posicionamiento y encarece cada lead. Abajo están las cifras públicas que lo demuestran, las métricas exactas que Google mide hoy (LCP, INP y CLS) con sus umbrales, las causas reales de lentitud y un plan de mejora ordenado por impacto.
Qué pierde exactamente por cada segundo de más
La relación entre tiempo de carga y abandono no es lineal: se dispara. El estudio de Google y SOASTA The State of Online Retail Performance (2017) cuantificó cuánto crece la probabilidad de rebote a medida que la página se demora, y los números siguen siendo la referencia de la industria.
| Tiempo de carga | Aumento en probabilidad de rebote | Fuente |
|---|---|---|
| De 1 a 3 segundos | +32% | Google / SOASTA, 2017 |
| De 1 a 5 segundos | +90% | Google / SOASTA, 2017 |
| De 1 a 6 segundos | +106% | Google / SOASTA, 2017 |
| De 1 a 10 segundos | +123% | Google / SOASTA, 2017 |
El efecto contrario también está medido. Deloitte, en Milliseconds Make Millions (2020), analizó 37 marcas y encontró que una mejora de 0,1 segundos en velocidad móvil elevó las conversiones un 8,4% en retail y un 10,1% en viajes, además de subir el valor promedio del pedido un 9,2%. Akamai reportó que cada 100 milisegundos de retraso reducía la tasa de conversión cerca de un 7%, y Amazon documentó desde 2006 que 100 milisegundos adicionales de latencia le costaban aproximadamente el 1% de las ventas.
Traducido a un negocio colombiano: si su sitio recibe 5.000 visitas al mes, convierte al 2% y cada cliente deja $400.000 COP de margen, son 100 clientes y $40.000.000 COP. Recortar un segundo de carga y subir la conversión al 2,4% —una mejora conservadora frente a los estudios anteriores— agrega $8.000.000 COP mensuales sin comprar una sola visita adicional.
Las métricas que importan hoy: LCP, INP y CLS
Google ya no evalúa “cuánto tarda la página”, sino tres señales concretas de experiencia llamadas Core Web Vitals. Se miden en el percentil 75 de las visitas reales: no basta con que le cargue rápido a usted en su oficina con fibra óptica; debe cargar rápido para 3 de cada 4 usuarios.
| Métrica | Qué mide | Bueno | Necesita mejorar | Deficiente |
|---|---|---|---|---|
| LCP (Largest Contentful Paint) | Cuándo aparece el elemento principal (imagen o titular) | Menos de 2,5 s | 2,5 s – 4,0 s | Más de 4,0 s |
| INP (Interaction to Next Paint) | Cuánto tarda la página en responder a un clic o toque | Menos de 200 ms | 200 ms – 500 ms | Más de 500 ms |
| CLS (Cumulative Layout Shift) | Estabilidad visual: cuánto “salta” el contenido | Menos de 0,1 | 0,1 – 0,25 | Más de 0,25 |
El cambio importante es INP, que el 12 de marzo de 2024 reemplazó oficialmente a FID (First Input Delay) como métrica estable. FID solo medía el retraso de la primera interacción; INP evalúa la latencia de todas las interacciones de la sesión y reporta prácticamente la peor. Es una vara mucho más exigente y castiga los sitios cargados de JavaScript que parecían aprobados con FID. El detalle técnico de esta transición y cómo diagnosticarla lo desarrollo en la guía de Core Web Vitals e INP.
Un punto que suele malinterpretarse: los Core Web Vitals son un factor de ranking real pero de desempate. No van a poner primero un contenido mediocre, pero sí deciden entre dos páginas de calidad parecida. Su efecto más fuerte y más inmediato es sobre la conversión, no sobre la posición.
Causas más comunes de lentitud en los sitios colombianos
En la mayoría de los sitios que se revisan en Colombia, la lentitud no tiene una causa exótica: se repiten cinco, casi siempre juntas. Vale la pena recordar el contexto: buena parte del tráfico llega desde celulares con redes móviles variables, así que el sitio se debe diseñar para el peor escenario, no para el mejor.
Imágenes sin optimizar
Es la causa número uno y la más fácil de corregir. Subir la foto tal como sale de la cámara o del banco de imágenes significa cargar archivos de 3 a 8 MB donde bastarían 80 a 150 KB. El arreglo es servir WebP o AVIF, redimensionar al tamaño real de visualización, usar srcset para móvil y aplicar loading="lazy" a todo lo que esté bajo el pliegue, nunca a la imagen principal. Al hacerlo aproveche y ordene el texto alternativo: es la misma operación que describo en SEO en imágenes.
Hosting barato y compartido
El hosting de $10.000 COP al mes reparte CPU y memoria entre cientos de sitios. Cuando el vecino tiene un pico de tráfico, su sitio se arrastra, y eso se ve directo en el TTFB (Time To First Byte): si el servidor tarda más de 600 ms en responder el primer byte, ninguna optimización de imágenes lo va a salvar. Sume que muchos planes económicos tienen el servidor físico fuera de la región, lo que agrega latencia en cada petición.
Plugins acumulados y temas pesados
Un WordPress con 40 plugins carga decenas de archivos CSS y JS en todas las páginas, aunque el plugin solo se use en una. Los constructores visuales pesados agravan el problema al generar marcado inflado. WordPress no es lento por naturaleza —sus ventajas para empresas siguen siendo reales—, pero exige disciplina: cada plugin instalado “por si acaso” es deuda de rendimiento.
Fuentes web mal cargadas
Cargar cuatro familias tipográficas con seis pesos cada una desde un servidor externo bloquea el renderizado y provoca el clásico texto invisible durante la carga. La solución es autoalojar las fuentes, limitarse a dos familias, usar font-display: swap y precargar solo la que aparece en el primer pantallazo.
Scripts de terceros
Chats, mapas embebidos, píxeles de publicidad, banners de cookies, ventanas emergentes, mapas de calor, reseñas y widgets sociales. Cada uno abre conexiones a dominios externos y ejecuta JavaScript en el hilo principal, que es exactamente lo que castiga el INP. Es el rubro donde más se subestima el costo: es común encontrar sitios donde los terceros pesan más que todo el sitio propio.
Tabla de diagnóstico: causa, impacto y solución
Este cuadro sirve como checklist de auditoría. La columna de impacto indica qué métrica se degrada primero y los costos son rangos de referencia del mercado colombiano, no tarifas fijas.
| Causa | Métrica que golpea | Solución | Costo de referencia |
|---|---|---|---|
| Imágenes de varios MB | LCP y consumo de datos | Conversión a WebP/AVIF, srcset, lazy loading | $300.000 – $900.000 COP (una vez) |
| Hosting compartido saturado | TTFB y LCP | Migrar a cloud, VPS o WordPress gestionado | $80.000 – $350.000 COP al mes |
| Sin caché ni CDN | LCP y TTFB en regiones lejanas | Caché de página en servidor + CDN | Desde plan gratuito de CDN |
| Exceso de plugins | INP y peso total | Auditoría, desinstalar y cargar CSS/JS por página | $500.000 – $1.500.000 COP |
| Fuentes externas bloqueantes | LCP y estabilidad del texto | Autoalojar, font-display: swap, precarga | $200.000 – $500.000 COP |
| Scripts de terceros | INP | Diferir, cargar bajo interacción, eliminar los inútiles | $400.000 – $1.200.000 COP |
| Imágenes y anuncios sin dimensiones | CLS | Declarar width y height, reservar espacio | $150.000 – $400.000 COP |
| Tema o constructor pesado | Todas | Rediseño sobre base liviana | Desde $3.500.000 COP |
Cómo medir bien: datos de campo vs. datos de laboratorio
Aquí es donde casi todo el mundo se equivoca: el puntaje de PageSpeed Insights no es su Core Web Vitals. Existen dos tipos de datos y solo uno cuenta para Google.
- Datos de campo (field data): vienen del CrUX (Chrome UX Report), es decir, de usuarios reales de Chrome, con sus dispositivos y sus redes, en una ventana móvil de 28 días. Es lo que Google usa para evaluar el sitio y lo que ve en el informe de Core Web Vitals de Search Console.
- Datos de laboratorio (lab data): los genera Lighthouse simulando un dispositivo y una conexión. Sirven para diagnosticar y reproducir problemas, pero varían entre ejecuciones y no representan a sus usuarios.
Reglas prácticas para no perder el tiempo:
- Mida siempre en móvil: concentra la mayoría del tráfico y es el escenario más duro.
- Evalúe plantillas, no una sola URL: home, categoría, ficha de producto o servicio y un artículo del blog. Cada una falla por algo distinto.
- Corra Lighthouse en ventana de incógnito y sin extensiones; si no, mide sus extensiones.
- Espere 28 días tras un cambio antes de juzgar el dato de campo: esa es la ventana de CrUX.
- Priorice con el informe de Core Web Vitals de Search Console, que agrupa URL por volumen de tráfico.
El INP tiene un matiz extra: no se detecta bien en laboratorio porque depende de interacciones reales. Para diagnosticarlo hay que reproducir en el sitio en vivo lo que hacen los usuarios —abrir el menú, filtrar, enviar el formulario— y observar el hilo principal.
Plan de mejora priorizado en cuatro fases
El orden importa: hacer primero lo caro y complejo es la forma más común de gastar presupuesto sin mover la aguja. Este es el orden por relación impacto/esfuerzo.
Fase 1 — Ganancias inmediatas (semana 1). Comprimir y convertir todas las imágenes a WebP, declarar width y height en cada imagen, activar caché de página y compresión Gzip o Brotli, y conectar un CDN. Suele ser el 60% de la mejora con el 10% del esfuerzo.
Fase 2 — Limpieza (semanas 2 y 3). Auditar plugins y eliminar los que no se usen; cargar CSS y JS solo donde se necesiten; autoalojar fuentes y reducirlas a dos familias; diferir o eliminar scripts de terceros prescindibles. Aquí es donde mejora el INP.
Fase 3 — Infraestructura (mes 2). Si el TTFB sigue por encima de 600 ms después de las fases anteriores, el problema es el servidor: migrar a un hosting con recursos garantizados y, si aplica, activar caché a nivel de objeto y base de datos.
Fase 4 — Arquitectura (cuando nada más funcione). Si el tema o el constructor visual son el cuello de botella, ninguna optimización superficial lo arregla. Ahí toca reconstruir sobre una base liviana, y conviene revisar antes las señales de que su web necesita rediseño. Un sitio bien construido nace rápido: el rendimiento se diseña, no se parcha, que es la lógica de trabajar diseño web y SEO integrados.
La velocidad también decide cuánto paga en publicidad
Si invierte en pauta, la lentitud le cobra dos veces. La primera es obvia: paga el clic y el usuario se va antes de ver la oferta. La segunda es silenciosa: la experiencia de la página de destino es uno de los tres componentes del Nivel de Calidad en Google Ads, junto con el CTR esperado y la relevancia del anuncio. Un Nivel de Calidad bajo se traduce en un CPC más alto por la misma posición.
Es decir, la misma campaña, con el mismo anuncio y la misma puja, cuesta más cara si la landing es lenta. Optimizar velocidad es de las pocas acciones que bajan el costo por adquisición sin tocar el presupuesto, y el efecto se acumula con el orgánico.
Errores comunes al optimizar velocidad
- Perseguir el 100 en PageSpeed. Es un puntaje de laboratorio. Un 85 en móvil con LCP de 1,9 s en campo vale más que un 98 sintético.
- Instalar tres plugins de caché a la vez. Se pisan entre ellos y el sitio queda más lento, o directamente roto.
- Aplicar
lazy loadinga la imagen principal. Retrasa justo el elemento que define el LCP: el efecto es contrario al buscado. - Optimizar solo la home. El tráfico orgánico entra por artículos y páginas internas, que suelen ser las peores.
- Comprimir imágenes al punto de destruirlas. Una foto de producto borrosa cuesta más ventas de las que salva el ahorro de peso.
Tener una web rápida es una forma de respetar el tiempo de quien está considerando comprarle. Empiece midiendo: abra PageSpeed Insights, revise el dato de campo en móvil de sus cuatro plantillas principales y contraste con el informe de Core Web Vitals en Search Console. Si los números están en rojo, es una fuga de dinero que ya está ocurriendo.
Si prefiere partir de una base construida para ser rápida desde el primer día, conozca mi servicio de diseño de páginas web —incluye optimización de Core Web Vitals desde el lanzamiento— o escríbame desde contacto con la URL de su sitio.
