Mejorar la velocidad de una tienda online sin quitar funciones

Cuando la velocidad de una tienda online empieza a preocupar, la primera propuesta suele ser recortar: quitar el chat y las reseñas, simplificar la ficha de producto y esperar a que la nota suba. A veces sube, y por el camino la tienda pierde cosas que ayudaban a vender. Muchas veces hay margen para cargar las mismas funciones en otro momento o solo en las páginas donde se usan. Aquí repasamos cómo medir y en qué orden atacar lo que más pesa.

Cómo medir la velocidad de una tienda online con datos reales

Google resume la experiencia de carga en las Core Web Vitals. LCP mide cuánto tarda en pintarse el elemento principal de la página, que en una ficha suele ser la foto del producto. INP mide cuánto tarda la página en reaccionar cuando el usuario hace algo, como elegir una talla o pulsar el botón de añadir al carrito; sustituyó a FID como métrica de respuesta en 2024. CLS mide cuánto se mueve el contenido mientras carga, ese salto que hace que pulses un enlace que no querías.

Google publica para cada métrica unos umbrales que clasifican las páginas como buenas, mejorables o malas. Consulta los vigentes en su documentación antes de fijar objetivos.

Datos de campo y datos de laboratorio

Los datos de campo salen de visitas reales con Chrome, agregadas durante varias semanas, y son los que ves en Search Console y en la parte superior de PageSpeed Insights cuando hay tráfico suficiente. Reflejan los móviles y las conexiones de tus clientes.

Los datos de laboratorio, como la nota de Lighthouse, vienen de una simulación con un dispositivo y una red concretos. Sirven para diagnosticar y comparar antes y después de un cambio, aunque la nota varía entre ejecuciones. Fija los objetivos con los datos de campo y usa el laboratorio para encontrar la causa.

Con poco tráfico puede que no haya datos de campo por URL, y te toca apoyarte en el laboratorio o en una herramienta que recoja métricas de tus propios visitantes.

Antes de tocar nada, anota:

• Métricas de campo por tipo de página: portada, categoría, ficha, carrito y checkout, en móvil y en escritorio.
• Varias mediciones de laboratorio de cada tipo de página, para ver el rango y no una cifra suelta.
• Tiempo de respuesta del servidor en páginas cacheadas y sin cachear.
• La lista de scripts que se cargan en la ficha de producto y quién pidió cada uno.

Imágenes: el peso más habitual en fichas y categorías

En una tienda con catálogo amplio, las imágenes suelen ser lo primero que aparece en el diagnóstico: fotos de varios miles de píxeles mostradas en una miniatura o carruseles de portada que descargan todas las diapositivas aunque el usuario solo vea la primera.

Lo que suele funcionar sin quitar ninguna imagen:

• Servir cada foto al tamaño en que se muestra, con varias resoluciones para que el navegador elija.
• Usar formatos modernos como WebP o AVIF. Shopify y muchas CDN los sirven según el navegador; en WooCommerce y PrestaShop depende del servidor o de la extensión que uses.
• Aplicar carga diferida a las imágenes que quedan por debajo de la primera pantalla.
• Dejar sin carga diferida la imagen principal de la ficha y darle prioridad alta, porque suele ser el elemento que mide el LCP.
• Declarar ancho y alto de cada imagen para que el diseño no salte al cargar.

El cuarto punto se olvida mucho: activar la carga diferida en todas las imágenes retrasa justo la que Google usa para medir la carga.

Scripts de terceros, apps y plugins: lo que carga cada uno

Chat, reseñas, píxeles de publicidad, mapas de calor, ventanas emergentes o avisos de pago aplazado: cada uno añade JavaScript que el navegador ejecuta en el mismo hilo que atiende los clics del usuario, y ahí se resiente el INP. El problema suele ser la suma de muchos en la ficha de producto.

Empieza por un inventario: qué script es, en qué páginas hace falta y quién del equipo lo usa. Es habitual encontrar código de apps desinstaladas hace meses que sigue en el tema.

Hay varias formas de conservar la función y reducir su coste:

• Cargar cada script solo donde se usa. El widget de reseñas hace falta en la ficha; en el carrito y el checkout sobra.
• Retrasar la carga hasta que el usuario lo necesita. Un chat puede mostrar un botón ligero y cargar el widget completo al pulsarlo.
• Revisar qué etiquetas de marketing pueden pasar a un gestor de etiquetas bien configurado o al etiquetado del lado del servidor.
• Sustituir una app pesada por una función a medida cuando solo se usa una parte pequeña de lo que ofrece.

Imagina una ficha con un widget de reseñas que trae su propia librería, sus fuentes y sus estilos para enseñar cinco estrellas y un contador. La nota media se puede pintar desde el servidor junto al resto de la ficha, y el listado completo de opiniones cargarse cuando el usuario baja hasta esa sección. En Shopify, este tipo de cambio suele resolverse con funcionalidades a medida que reemplazan la parte que usas de una app.

Ojo con retrasar scripts de medición: si el píxel de conversión se carga tarde, las campañas pueden dejar de atribuir ventas. Prueba esos cambios con quien gestiona las campañas.

Tema y front: CSS, fuentes y JavaScript propio

Muchos temas comerciales incluyen sliders, animaciones y secciones que la tienda no usa, y cargan su CSS y su JavaScript en todas las páginas. Revisa qué partes se usan de verdad y si el resto se puede dejar de cargar. Cambiar de tema parece la solución rápida, pero si después se instalan las mismas apps, la tienda acaba en un punto parecido.

Con las fuentes pasa algo parecido: varias familias con muchos pesos suponen muchas descargas antes de que el texto se vea bien. Reducir variantes y precargar la principal suele notarse sin cambiar el aspecto de la tienda.

El JavaScript propio también cuenta. Un filtro de categoría que recalcula toda la página en el navegador con cada clic, o un selector de variantes que reconstruye la ficha entera, empeora el INP aunque la carga inicial sea rápida. Si vendes productos personalizables, en la guía sobre el configurador de producto explicamos cómo evitar que las reglas de compatibilidad bloqueen la página.

Servidor, consultas lentas y caché

En Shopify el alojamiento lo gestiona la plataforma, así que el margen está sobre todo en el tema y las apps. En WooCommerce y PrestaShop el servidor y la base de datos son tu responsabilidad, y un tiempo de respuesta alto retrasa todo lo demás.

Las causas que más vemos son consultas lentas en búsquedas y filtros por atributos, tablas de registros que crecen sin que nadie las limpie, versiones antiguas de PHP e importaciones de stock programadas en plena hora de tráfico. Activar el registro de consultas lentas durante unos días suele señalar dónde mirar.

La caché tiene sus propias reglas en una tienda:

• La caché de página completa sirve para portada, categorías y fichas, pero no para carrito, checkout ni área de cliente.
• Si hay precios por cliente o grupo, la caché debe distinguirlos para no enseñar a un particular el precio de un distribuidor.
• El stock y el precio que muestra una página cacheada tienen que refrescarse cuando cambian, o venderás con datos viejos.
• Una caché de objetos en memoria ayuda a las páginas que no se pueden cachear enteras.

En qué orden mejorar la velocidad de una tienda online

El orden importa porque algunos cambios esconden el efecto de otros. Una secuencia que suele funcionar:

• Si el tiempo de respuesta del servidor es alto, empieza por ahí. Con un servidor lento, optimizar el front se nota poco.
• Después, imágenes sobredimensionadas y scripts huérfanos de apps que ya no están. Son cambios de poco riesgo que afectan a muchas páginas.
• Luego, scripts de terceros por tipo de página, empezando por la ficha y la categoría, que es donde más se navega.
• Al final, el tema y el JavaScript propio, que es lo que más horas cuesta y más pruebas necesita.

Haz un cambio cada vez y mide antes y después en laboratorio. Los datos de campo tardan semanas en reflejar una mejora, así que apunta la fecha de cada cambio. Después de cada despliegue, prueba un pedido completo en un móvil de gama media, que se parece más al de tus clientes que el portátil del equipo.

Qué preparar antes de pedir una optimización

Con esto delante, la valoración parte de tu tienda real:

• Acceso a Search Console y a la analítica.
• Lista de apps, plugins o módulos activos y quién usa cada uno.
• Las páginas que más venden y las que reciben tráfico de pago.
• Las funciones que no se pueden tocar, como el configurador, las reseñas o el pago aplazado.
• Un entorno de pruebas o la posibilidad de crear una copia de la tienda.
• Si usas WooCommerce o PrestaShop, datos del alojamiento y acceso a los registros del servidor.

Si quieres que revisemos tu caso, en optimización ecommerce explicamos cómo trabajamos la carga sin quitar funciones. Si además sospechas que la lentitud es solo uno de varios problemas, una auditoría técnica ecommerce ordena todo por prioridad antes de tocar código.