Por qué tu sitio carga lento y qué te puede costar

Un sitio carga lento casi siempre por una de tres razones: imágenes más pesadas de lo necesario, demasiado código de terceros (plugins, scripts, constructores visuales) o un servidor que tarda en responder. Lo que te cuesta no tiene una cifra honesta que valga para todos los negocios. Hay casos documentados de empresas grandes y hay una forma sencilla de medirlo en el tuyo. Aquí van las dos cosas, y una medición de nuestro propio sitio con sus límites.

Qué significa «lento» según Google

Google resume la experiencia de una página en tres indicadores llamados Core Web Vitals. Cada uno mide una cosa que tu cliente nota sin saber su nombre:

• LCP: qué tan pronto aparece el contenido principal. Se considera bueno si ocurre dentro de los primeros 2.5 segundos de la carga.
• INP: qué tan rápido responde la página cuando tocas algo. Es bueno con 200 milisegundos o menos.
• CLS: cuánto se mueve el contenido sin avisar mientras cargas. Es bueno con 0.1 o menos.

La recomendación de Google es evaluar el percentil 75 de las visitas, es decir, que tres de cada cuatro visitas cumplan el umbral y no solo la visita perfecta. Y al medir conviene separar dos tipos de dato: el de laboratorio, que es una prueba simulada con un dispositivo y una red fijos y sirve para encontrar problemas, y el de campo, que viene de usuarios reales con sus teléfonos y sus señales. Google advierte que pueden diferir.

Las tres causas más comunes

1. Imágenes que pesan de más

El Web Almanac 2025 de HTTP Archive, que analiza millones de sitios, encontró que las imágenes son lo que más bytes aporta a una página, por delante del JavaScript y las fuentes. En la página de inicio mediana de un teléfono, unos 911 KB eran imágenes, contra 632 KB de JavaScript. Las guías de web.dev para mejorar el LCP piden servir cada imagen en el tamaño que de verdad se muestra, usar formatos modernos como AVIF o WebP, comprimirla, y nunca cargar de forma diferida la imagen principal de la página, porque eso retrasa justo lo que el visitante espera ver.

2. Código de terceros acumulado

Para los gestores de contenido que se amplían con extensiones, el mismo Web Almanac dice que el peso de las páginas depende menos del núcleo y más del efecto acumulado de temas, plugins y constructores visuales; estos últimos suelen generar más código CSS y JavaScript. Ojo con no sacar conclusiones simplistas: el estudio también dice que, en WordPress, la variación de rendimiento viene más de la configuración que del núcleo. En móvil, en 2025, pasó los Core Web Vitals el 45 % de los sitios de WordPress y el 74 % de los de Wix. Esa diferencia es un promedio, no el destino de tu sitio.

Algo parecido vimos en uno de nuestros propios sitios antes de migrarlo: el plugin de formularios cargaba su hoja de estilos y su JavaScript en páginas que no tenían ni un solo formulario. Código que se descarga, se ejecuta y no hace nada por nadie. Lo contamos completo en el caso de la migración.

3. Un servidor que tarda en contestar

Antes de que el navegador pueda dibujar nada, el servidor tiene que responder. A ese tiempo se le llama TTFB, y web.dev lo considera bueno con 0.8 segundos o menos y malo por encima de 1.8. En su guía del LCP, web.dev da como orientación que alrededor del 40 % del tiempo total se va en esa espera. Si tu sitio arma cada página desde cero en cada visita con una base de datos, o está en un hosting saturado, ahí se pierde tiempo que ninguna optimización de imágenes recupera.

Cuánto te cuesta: lo que sí se sabe

El caso mejor documentado que encontramos es el de Vodafone, publicado en web.dev. Probaron dos versiones de una página de ventas con tráfico de anuncios repartido por mitades. La optimizada para Web Vitals tuvo un LCP 31 % mejor en datos de campo y, frente a la otra, un 8 % más de ventas, una mejora de 15 % en la tasa de interesados por visita y de 11 % en la de carrito por visita. Cada página recibía alrededor de 100 mil clics y 34 mil visitas al día.

Es un resultado real, pero de una empresa enorme con mucho tráfico pagado. No se traslada tal cual a una clínica o a un despacho, y lo ponemos aquí como prueba de que la velocidad puede mover ventas, no como cifra para tu caso.

Sobre Google Search, la documentación oficial dice que los Core Web Vitals se usan en sus sistemas de clasificación, pero que buenos puntajes no garantizan aparecer arriba y que la relevancia del contenido manda: puede mostrar contenido relevante aunque la experiencia de la página sea mala. Una página lenta no es un castigo seguro, y una rápida no es un premio asegurado.

Qué puedes hacer esta semana

• Mide tres veces tu página de inicio en PageSpeed Insights y anota los números con la fecha. Una sola corrida engaña.
• Revisa tus imágenes más grandes. Si una foto de fondo pesa varios megas, ahí empieza el trabajo.
• Haz una lista de plugins y scripts que cargan en tu página y quita los que no uses.
• Pregunta a tu proveedor por el TTFB de tu sitio y si hay caché. Si no sabe responder, es información.
• Vuelve a medir y compara el número de mensajes por visita, no solo el puntaje.

En Byte and Brand los sitios se publican como archivos ya armados, sin plugins que actualizar, y las fotos se preparan para que no pesen. Si estás comparando contra Wix o WordPress, la comparación completa está en otro artículo.

En resumen

Las causas más comunes son imágenes pesadas, código de terceros acumulado y un servidor lento. El costo en clientes no tiene una cifra universal: hay casos de empresas grandes, pero el tuyo se mide comparando mensajes por visita. Mide antes de gastar y desconfía de quien te prometa un puntaje perfecto.