La velocidad de una tienda suele ser un problema de arquitectura

Comprimir imágenes es donde se detiene el trabajo de velocidad en casi todas las tiendas. Debería ser donde empieza, y debería tomar una tarde. Todo lo caro de una tienda Shopify lenta es una decisión que alguien tomó sobre arquitectura: cuántas apps inyectan un script, cuántas secciones renderiza la home, sobre qué le pide recorrer la plantilla de colección a Liquid, y qué terceros pueden bloquear el primer pintado. Nada de eso se arregla con un mejor formato de imagen.

Esto es una postura, así que la digo claro. El peso de las imágenes es el problema más barato que tienes, y se lleva toda la atención porque es el único que una herramienta te nombra sola. Los costos que deciden si una página de producto se siente rápida no son archivos. Son decisiones, y alguien tiene que estar dispuesto a revertirlas.

Qué te compra de verdad comprimir imágenes

Bytes reales, y vale la pena hacerlo. Sirve tamaños responsivos, deja que el CDN de imágenes de Shopify haga el redimensionado, usa formatos modernos, fija width y height explícitos para que el layout no salte, y carga en diferido todo lo que está bajo la línea de flotación mientras cargas de inmediato la imagen que es el elemento más grande en pantalla. Esa última parte es la que casi todas las tiendas hacen al revés: poner la imagen del hero en lazy load es una forma de empeorar el Largest Contentful Paint sintiendo que optimizaste algo.

Haz todo eso y habrás quitado peso de la red. Lo que no tocaste es el tiempo: el intervalo entre que el navegador tiene tu HTML y que la página se puede usar. Ese intervalo es sobre todo ejecución de scripts y peticiones bloqueantes, y le da igual qué tan pequeños sean tus JPEG.

Los costos que sí están en la página

Scripts que no escribiste tú

Cada app que toca la tienda añade algo: una etiqueta de script, una theme app extension, un pixel, o un bloque incrustado que se trae su propio bundle. Individualmente cada uno es pequeño, y cada proveedor te dirá que es asíncrono. En conjunto son el mayor bloque de trabajo en el hilo principal de la mayoría de las tiendas, y asíncrono no significa gratis: significa que el parser no se bloquea mientras el archivo descarga. Se ejecuta igual, y compite con todo lo demás por el mismo hilo único.

El número que vale la pena anotar no son milisegundos. Es la cuenta. ¿Con cuántos orígenes de terceros distintos habla una página de producto? Cuéntalos en tu propia tienda; el número casi siempre es más alto de lo que el equipo supone. El ejercicio que produce más velocidad por hora de trabajo no es afinar; es abrir la lista de apps y preguntar, para cada una, qué hace y si alguien notaría que no está. Desinstalar una app que se dejó de usar hace dos temporadas vale más que una semana de micro-optimización, y muchas veces es la única intervención que mueve los datos de campo.

Cuidado con la desinstalación. Quitar una app no siempre quita su script tag ni sus ediciones al tema, y una tienda puede cargar el fantasma de tres apps que nadie tiene instaladas desde el año pasado. Busca el dominio del proveedor después de cada eliminación.

Los pocos que sí bloquean el render

Un puñado de cosas bloquea de verdad el primer pintado en vez de solo competir por el hilo: un script síncrono en el head, una hoja de estilos de un origen externo, una webfont sin estrategia de fallback, un banner de consentimiento que condiciona el render, y un snippet de test A/B instalado como lo recomiendan — síncrono, arriba, para que la página no muestre el control antes de aplicar la variante.

Ese último es un intercambio deliberado, no un error: pagas tiempo de primer pintado para evitar un parpadeo. Es la decisión correcta mientras corre un experimento y la equivocada como accesorio permanente en una tienda que no prueba nada. Si haces experimentación en serio, el snippet se gana su costo durante una prueba y conviene reconsiderarlo entre una y otra.

La home que renderiza todo

Las secciones son lo mejor de los temas modernos de Shopify y lo más fácil de abusar. Un comerciante que puede añadir una sección va a añadir secciones, y una home que empezó con cinco termina con dieciocho: tres carruseles, dos videos incrustados, un widget de reseñas, un feed social, un contador y un slider de nueve colecciones.

Cada una es marcado renderizado en el servidor, recursos pedidos en el cliente, y a menudo un componente de JavaScript que se inicializa al cargar aunque nadie haga scroll hasta ahí. La home además es la página que más se mide y la que menos suele ser donde ocurre una compra, que es por lo que acumula peso que nadie defiende.

El arreglo es estructural, no ingenioso. Las secciones bajo la línea de flotación no deberían inicializar su JavaScript hasta estar cerca del viewport. Los carruseles no deberían existir por triplicado. Un feed social incrustado es un iframe de tercero con su propio framework adentro. Esto es trabajo de tema normal, no una disciplina especializada, y es donde viven las mayores ganancias.

Liquid que recorre todo el catálogo

Este no aparece en el navegador en absoluto, porque ocurre antes de enviar la respuesta. Un bucle de productos que recorre cada variante y cada opción dentro de ella, una lectura de metafield hecha una vez por iteración, un megamenú que resuelve todos los hijos de todos los enlaces en cada petición: cada uno de esos es tiempo de servidor, el tiempo de servidor es time to first byte, y el time to first byte es el piso debajo de cualquier otra métrica de la página.

Una plantilla lenta normalmente renderiza bien, así que el modo de fallo no es un error: es una plantilla que cuesta varias veces lo que su hermana en cada petición, y nadie lo nota porque la cascada del navegador se ve idéntica salvo por una primera barra larga. Mide el time to first byte por plantilla — home, colección, producto, carrito — y trata una plantilla lenta como un problema de consultas, no de front-end.

Una buena puntuación de laboratorio no es una página de producto rápida

Las herramientas de laboratorio corren una URL, en un dispositivo simulado, desde una ubicación, sin cookies y sin carrito. Tus visitantes llegan a una página de producto, en hardware real con veinte pestañas abiertas, muchas veces con el carrito lleno, desde un anuncio cuyos parámetros de tracking activan otro camino de código.

Que la portada puntúe bien mientras las páginas de producto puntúan mal es lo esperable, porque la página de producto carga el widget de reseñas, el selector de variantes, el bloque de upsell y el pixel que dispara al verse. Las herramientas de laboratorio tampoco pueden ver la latencia de interacción de una persona real tocando un swatch de variante. Eso aparece en datos de campo como Interaction to Next Paint, y es la métrica que más seguido contradice una buena puntuación de laboratorio.

Usa las herramientas de laboratorio como depurador, nunca como marcador. Te dicen qué pasó en una ejecución y son excelentes para eso. No te dicen si tu tienda es rápida.

Qué medir de verdad

Cuatro cosas, en este orden.

• Core Web Vitals de campo, segmentados por plantilla. Un solo número para todo el sitio esconde que la página de producto es la lenta. Separa home, colección, producto y carrito, y separa móvil de escritorio.
• Cuenta de peticiones y de orígenes de terceros, por plantilla. Las cuentas son estables, fáciles de comparar en el tiempo, y se traducen directo a una decisión que alguien puede tomar: quitar la app, o dejarla y decir por qué.
• Time to first byte por plantilla. El problema de Liquid es invisible en cualquier otra métrica, y mueve el piso de todas.
• Interaction to Next Paint en la página de producto. En concreto sobre el selector de variantes y el botón de añadir al carrito, porque son las interacciones que cargan el dinero.

Fíjate en lo que no está en esa lista: una puntuación. Una puntuación comprime varias cosas sin relación en un número que se mueve por razones sobre las que no puedes actuar. Esto lo hacemos como optimización de rendimiento, y el entregable siempre es una lista de eliminaciones y reescrituras, no una captura de un círculo verde.

Segmenta las cuatro por fuente de tráfico antes de atribuirte cualquier movimiento. El social de pago llega en dispositivos de gama más baja que la búsqueda orgánica, así que mover presupuesto entre canales mueve las métricas de campo por su cuenta.

La conclusión incómoda

Casi todas las tiendas podrían ser más rápidas borrando cosas. No refactorizando, no adoptando un framework, no pasándose a headless: quitando cuatro apps, cortando la home a la mitad, y arreglando una plantilla de colección que recorre el catálogo. Ese trabajo no luce, no produce ningún artefacto para una presentación, y casi siempre es la respuesta correcta.

Y no, irse a headless no es una estrategia de velocidad. Es otra arquitectura con otro conjunto de costos, y una tienda a medida cargando los mismos scripts de terceros es la misma página lenta con un mejor pipeline de build. El problema eran los scripts. El build nunca fue el problema.

Las tiendas genuinamente rápidas no son las que mejor comprimieron sus imágenes. Son aquellas donde alguien dijo que no las veces suficientes como para que no quedara mucho por cargar.