Porque el hosting solo decide el primer tramo de la carga, y ese tramo es corto. Tu servidor puede responder en 300 milisegundos y aun así tu web tardar 6 segundos: los otros 5,7 los pones tú, con lo que el navegador tiene que descargar, leer y ejecutar después.

Es como culpar al camión de reparto cuando el problema es que enviaste 40 cajas.

Lo que mide realmente tu hosting: el TTFB

TTFB significa time to first byte: cuánto tarda el servidor en empezar a contestar. Es lo único que un hosting mejor arregla de forma directa.

Usa 0,8 segundos como corte de trabajo: por debajo de ahí, el servidor no es lo que te está frenando. Si el tuyo está ahí y tu web sigue tardando 5 segundos, cambiar de hosting no te va a devolver ni medio segundo. Vas a pagar más por el mismo problema.

Cómo verlo, gratis y en dos minutos:

1. Entra en PageSpeed Insights y pega la URL de tu página de producto (no la de inicio: mide la página a la que apuntan tus anuncios, que es la que ve quien llega pagando).
2. Elige la pestaña Móvil.
3. Baja hasta el desglose de diagnósticos y busca «Reduce el tiempo de respuesta inicial del servidor». Ahí está tu TTFB.

Si ese número es bajo y la nota sigue en rojo, el resto de este artículo es tu artículo.

Las tres fugas que sí frenan tu tienda

1. Imágenes que pesan diez veces lo que deberían

En tiendas de skincare y belleza pesa especialmente: la foto es el argumento de venta, se sube a la máxima calidad posible y nadie quiere tocarla.

El problema no es la foto: es que subes un JPG de 3000 px y 2,4 MB para mostrarlo en un cuadro de 400 px. El navegador descarga los 2,4 MB completos y después lo encoge. En una 4G real eso son segundos, no décimas.

Qué hacer, concreto:

• Exporta las fotos en WebP o AVIF. Pesan bastante menos que un JPG a calidad similar y los soportan todos los navegadores actuales.
• Ninguna imagen de producto debería pasar de 200 KB. Las de banner, de 300 KB.
• Pon loading="lazy" en todo lo que esté por debajo del primer pantallazo, y fetchpriority="high" solo en la imagen principal.
• En WooCommerce/WordPress: ShortPixel o Imagify convierten el histórico entero. En Shopify el CDN ya sirve WebP, pero no encoge el original: lo que subes pesado sigue pesando.

2. Scripts de terceros que nadie audita

Cada píxel, cada chat, cada barra de reseñas y cada pop-up de descuento es un archivo JavaScript de otro dominio. El navegador tiene que ir a buscarlo, descargarlo y ejecutarlo. Si ese servidor va lento ese día, tu web va lenta ese día.

La lista suele parecerse a esto: píxel de Meta, Google Ads, GA4, Hotjar, un widget de chat, una app de reseñas, una de cuenta atrás y dos que instaló un freelancer que ya no responde.

Ábrelo tú: F12 en Chrome → pestaña Network → recarga → ordena por Size. Todo lo que no sea de tu dominio y pese más de 100 KB tiene que justificar su existencia.

3. La plantilla que carga la web de otro

Los temas multiuso (los de Envato, los constructores tipo Elementor) traen sliders, animaciones, iconos y cuatro librerías para que cualquier negocio pueda montar cualquier web. Tú usas el 10% y descargas el 100%.

Señal clara: si tu HTML carga más de 15 archivos CSS y JS distintos antes de mostrar el primer producto, el tema es el problema. Se ve en la misma pestaña Network, filtrando por CSS y JS.

Dónde se van los segundos

Los rangos son órdenes de magnitud para que sepas dónde mirar, no una medición de tu web. La tuya la mides en PageSpeed Insights.

Los tres umbrales de Google que importan

Google publica los suyos en Search Central, donde confirma que las Core Web Vitals, junto con otros aspectos de la experiencia en la página, «se corresponde con lo que nuestros sistemas de posicionamiento principales buscan recompensar». Los umbrales, tal y como los define web.dev, se evalúan en el percentil 75 de las cargas de página:

• LCP (lo que tarda en dibujarse el elemento más grande, casi siempre tu foto de producto): bueno por debajo de 2,5 s.
• CLS (cuánto salta el contenido mientras carga): bueno por debajo de 0,1.
• INP (cuánto tarda en responder cuando alguien toca un botón): bueno por debajo de 200 ms.

El que se te va a estar rompiendo es el LCP, y casi siempre por la imagen principal. El CLS se rompe cuando las imágenes no llevan width y height declarados y el texto salta cuando cargan: el cliente va a pulsar «Añadir al carrito» y le baila el botón.

No hacen falta saltos enormes para que se note en caja. El retailer Farfetch midió que su tasa de conversión bajaba de media un 1,3% por cada 100 ms más de LCP. En Milliseconds Make Millions, el estudio que Deloitte y 55 hicieron por encargo de Google sobre más de 30 millones de sesiones en 37 marcas europeas y americanas, 0,1 segundos de mejora en velocidad móvil se asociaron a un 8,4% más de conversión en retail. Y en Agrofy, un marketplace argentino, mejorar el LCP un 70% hizo que el abandono durante la carga de las fichas de producto cayera un 76%, del 3,8% al 0,9%.

Con el INP pasa lo mismo: redBus lo mejoró un 72% arreglando cómo gestionaba el estado de la página y registró un 7% más de ventas.

La lectura práctica es simple. Si tu web tarda 5 segundos, una parte de lo que pagas en pauta se te va antes de que nadie vea un producto.

Qué hacer el lunes por la mañana

Una hora, en este orden. No saltes pasos: el orden está puesto por relación entre esfuerzo y segundos recuperados.

1. Mide primero. PageSpeed Insights, pestaña Móvil, sobre tu página de producto más vendida. Guarda una captura con la nota y el LCP: es tu punto de partida.
2. Busca el TTFB en los diagnósticos. Si está por debajo de 0,8 s, deja el hosting en paz y sigue.
3. Mira qué elemento marca tu LCP. PageSpeed te lo dice con nombre y apellido. Si es una imagen, ábrela en una pestaña y mira lo que pesa.
4. Comprime las 20 imágenes de tus 20 productos más vendidos. WebP, máximo 200 KB. Con eso ya suele bajar el LCP de forma visible.
5. Lista los scripts externos en la pestaña Network y quita los que no puedas justificar en una frase. El chat que nadie contesta y el pop-up de una promo de 2024 se van hoy.
6. Vuelve a medir. Misma página, mismo día, misma pestaña Móvil. Si el LCP no se movió, el problema es el tema y ahí ya toca decidir si se limpia o se rehace.

Si al llegar al paso 6 la conclusión es que el tema no tiene arreglo razonable, rehacer la plantilla suele salir mejor que seguir parcheándola: un tema hecho solo para tu catálogo carga las librerías que usas y ninguna más, y ese peso que dejas de servir es exactamente el que hoy se te está yendo en el LCP.

Preguntas frecuentes

¿El hosting influye en la velocidad de mi web?

Sí, pero solo en la primera parte: el tiempo que tarda el servidor en responder (TTFB). Ese tramo se cuenta en décimas de segundo. Los otros segundos los pone tu web, no el servidor.

¿Cómo sé si el problema es mi hosting o mi web?

Abre PageSpeed Insights y mira el dato de «Tiempo hasta el primer byte». Si está por debajo de 0,8 segundos, trabaja con la idea de que el hosting no es tu cuello de botella y busca el problema en imágenes, scripts o plantilla.

¿Qué es el LCP y cuánto debería marcar?

Es el tiempo que tarda en dibujarse el elemento más grande de la pantalla, normalmente la foto principal. Google lo documenta en Search Central: bueno por debajo de 2,5 segundos, medido en el percentil 75 de las cargas.

Fuentes

• Google Search Central — Comprender las Core Web Vitals y los resultados de la Búsqueda
• Google / web.dev — Métricas web esenciales (Web Vitals)
• Google / web.dev — Farfetch, conversión y Core Web Vitals
• Deloitte y 55 por encargo de Google — Milliseconds Make Millions
• Google / web.dev — Agrofy Market, LCP y abandono de carga
• Google / web.dev — redBus, optimizar INP aumentó las ventas un 7%