Shopify site speed: auditoría y arreglos reales

Dos informes de velocidad de la misma tienda, el mismo día, con números que no cuadran. Ninguno está roto. El informe de rendimiento web del admin de Shopify combina los datos de tu portada, tu página de producto más visitada y tu colección más visitada de los últimos 7 días y los recoge de visitantes con navegadores basados en Chromium y Firefox. Search Console tira de CrUX, que solo mide Chrome y solo a los usuarios que aceptaron compartir esos datos al instalar el navegador. Poblaciones distintas, ventanas distintas, resultados distintos.

Casi todas las auditorías de velocidad que me llegan empiezan mal. Alguien vio un número feo en el admin, se asustó, y la tienda lleva dos meses instalando apps de optimización para subirlo. Yo lo hago al revés: decido qué número manda, busco qué lo rompe, y termino casi siempre en el código que las apps han ido dejando dentro del tema. Esto es esa auditoría, con la línea marcada entre lo que cambias tú y lo que decide la plataforma.

En 30 segundos:

• El informe del admin y el de Search Console miden poblaciones de navegadores distintas, así que no van a coincidir.
• Google evalúa con datos de campo de CrUX en una ventana móvil de 28 días, no con una puntuación de laboratorio.
• Desinstalar una app no borra su código del tema. Lo dice la documentación de Shopify.
• Un LCP bueno son 2,5 segundos y un INP bueno son 200 milisegundos, en el percentil 75.
• El tiempo se gana quitando scripts, no añadiendo herramientas.

¿Sirve de algo la puntuación de velocidad del admin de Shopify?

Sirve como alarma, no como objetivo. La puntuación que ves en el admin sí está construida con datos reales: Shopify explica que el sistema usa datos de personas usuarias reales, Real User Metrics o RUM, de visitantes que usan navegadores basados en Chromium y Firefox. Eso es mucho mejor que una simulación. El problema es otro.

Ese conjunto de datos no es el que mira Google. Search Console dice de forma explícita que los datos del informe de Core Web Vitals proceden del informe CrUX, que recopila métricas anonimizadas de usuarios reales que visitan tu URL, lo que se llama datos de campo. CrUX es Chrome, con consentimiento previo, 28 días. El admin añade Firefox, Edge, Opera y Samsung Internet, y comprime la ventana a 7.

¿Eso hace inútil el informe del admin? En absoluto, y lo miro cada semana. Con 7 días de ventana detectas el martes una regresión que instalaste el lunes, cosa que CrUX no te contará hasta mucho más tarde. Lo que no puedes hacer es perseguir esa cifra como si fuera la nota de Google. No lo es. Si vienes de cero con las métricas, mi guía de Core Web Vitals en Shopify explica qué mide cada una.

¿Qué fuente de datos manda en cada decisión?

La regla que sigo es simple: CrUX decide si tienes un problema, el laboratorio decide cuál es. Las herramientas de laboratorio no dicen la verdad sobre tus usuarios, pero son las únicas que te enseñan la cascada de recursos con nombres y tamaños. El campo dice la verdad y no dice por qué.

Los umbrales son los mismos en todas las fuentes. Google indica que el LCP debe producirse dentro de los 2,5 segundos desde que la página empieza a cargar, que las páginas deberían tener un INP de 200 milisegundos o menos, y que todo se mide en el percentil 75 de las cargas, segmentado entre móvil y escritorio. Percentil 75 significa que el visitante mediano no cuenta. Cuenta el que va mal.

¿Por qué las apps son el mayor coste de velocidad de una tienda Shopify?

Porque su código sobrevive a la desinstalación. Shopify lo dice sin rodeos: desinstalar una aplicación no elimina su código del tema automáticamente, y la misma página pide que evalúes las apps instaladas y el código externo para comprobar que aportan valor suficiente como para compensar la pérdida de rendimiento.

Traducido a lo que me encuentro en una tienda de tres años: el script de un buscador de tallas retirado en 2024, dos widgets de reseñas porque alguien migró de proveedor sin limpiar, y un gestor de etiquetas con píxeles de la agencia anterior. Nada de eso figura en la lista de apps. Todo eso se ejecuta en cada carga.

La documentación de temas es igual de directa: recomienda identificar y eliminar o diferir los scripts de apps que bloquean el análisis del HTML antes de que se renderice cualquier contenido, y auditar todo lo que se carga, quitando lo que no esté ganándose su coste. Ese “no se lo gana” es la parte difícil: cada app tiene dentro de la empresa alguien que la defiende.

Para separarlo duplico el tema, quito un bloque cada vez y mido. Nunca todos de golpe. Es lento y es la única forma de atribuir el ahorro. Si además arrastras problemas de plantilla, tengo un repaso de los errores SEO más comunes en Shopify que se solapa bastante con esta lista.

¿Qué problemas del tema puedes arreglar tú?

Los que afectan a cómo se descubre y se pinta la imagen principal, que en una ficha suele ser el elemento LCP. Las reglas de Shopify aquí son concretas y no hace falta ser desarrollador para aplicarlas.

• Nunca cargues la imagen LCP con lazy loading. Shopify avisa de que loading="lazy" en la imagen LCP la retrasa hasta que se completa el layout. Es el error más caro y el más fácil, porque el ajuste se suele aplicar en bloque a todo el tema.
• Usa <img> en lugar de fondos CSS para el héroe, así el escáner de precarga lo descubre pronto.
• Aplica fetchpriority="high" a la imagen LCP para señalar su importancia antes de que el navegador termine el layout.
• Pon siempre width y height, o usa image_tag, que los añade solo, y genera las URLs con image_url en vez de construir a mano las del CDN.

Después vienen los bloqueos de renderizado. La misma página señala que las hojas de estilo y los scripts que bloquean el renderizado dentro del <head> son el motivo habitual de que el LCP llegue tarde, y recomienda cargar de forma síncrona solo el CSS crítico de la ventana inicial. No se trata de diferirlo todo, sino de decidir qué entra en la primera pantalla.

Y luego está Liquid, donde se esconde el tiempo de servidor. Shopify pide eliminar los patrones O(n²), incluidos los bucles anidados y el acceso a metafields dentro de bucles, que hacen crecer el tiempo de renderizado de forma cuadrática, y mantener la paginación por debajo de 25.000 objetos. En una colección grande, un bucle anidado mal puesto pesa más que todas tus imágenes juntas. Para el detalle escribí sobre Liquid aplicado a SEO y sobre optimización de imágenes en Shopify, con el código concreto.

¿En qué orden hago la auditoría de velocidad?

Siempre igual, y siempre empezando por medir antes de tocar. El orden no es estético: cada paso descarta hipótesis para el siguiente, y saltárselos te lleva a optimizar algo que no era el problema.

1. Anota el estado de partida en las dos fuentes de campo. Admin y Search Console, mismo día, captura incluida. Sin línea base no hay auditoría, hay opiniones.
2. Separa por plantilla. Portada, colección y ficha tienen problemas distintos y casi nunca comparten culpable. Un LCP malo solo en producto apunta a la galería.
3. Identifica el elemento LCP real en la plantilla que peor va, con la pestaña de rendimiento del navegador. No lo supongas. En media docena de tiendas no era la imagen que todos daban por hecha.
4. Lista todo lo que se ejecuta antes de esa pintura: scripts en el <head>, bloques de app embebidos, contenedores del gestor de etiquetas, fuentes personalizadas.
5. Cruza esa lista con las apps instaladas. Lo que se ejecuta sin corresponder a ninguna app activa es residuo de una desinstalación, y es el trabajo con mejor relación entre esfuerzo y resultado de toda la auditoría.
6. Duplica el tema y quita un elemento cada vez, midiendo en laboratorio tras cada cambio.
7. Revisa las reglas de imagen: lazy loading fuera del héroe, fetchpriority en la LCP, dimensiones declaradas, image_url en todos lados.
8. Busca bucles anidados y accesos a metafields dentro de bucles en las secciones que rendericen listados largos.
9. Publica y espera. CrUX se mueve en 28 días, así que la confirmación no llega en 48 horas por mucho que la quieras.

El paso 9 es el que peor se lleva. Se hace el trabajo, se mira Search Console al día siguiente, no se mueve nada, y alguien concluye que no sirvió. Para eso está el informe del admin.

¿Qué parte no vas a poder arreglar?

Bastante más de la que te gustaría, y saberlo ahorra semanas. El renderizado de Liquid ocurre en los servidores de Shopify, la entrega de imágenes la hace su CDN, y el checkout no vive en tu tema. Puedes escribir Liquid más barato. No puedes cambiar dónde se ejecuta. La recomendación de mantener la paginación bajo 25.000 objetos es un límite de plataforma disfrazado de buena práctica.

También hay scripts que no vas a poder quitar por motivos que no son técnicos: el píxel de un canal que el cliente factura, la herramienta de accesibilidad que exige legal, el chat que atención al cliente usa a diario. Ahí queda negociar cuándo se cargan, no si se cargan, sacándolos de la ruta crítica del primer pintado.

Mi criterio para cerrar una auditoría: si el LCP está bajo el umbral en las plantillas que traen dinero y el INP no se dispara al abrir el selector de variantes, he terminado. Perseguir décimas rinde más en otro sitio, normalmente en la experiencia de compra en móvil, que es un problema de conversión y no de milisegundos. Lo trato aparte en CRO móvil para ecommerce.

Preguntas frecuentes

¿Por qué mi puntuación en el admin de Shopify no coincide con PageSpeed Insights?

Porque no miden lo mismo. El admin usa datos reales de navegadores Chromium y Firefox de los últimos 7 días. El bloque de campo de PageSpeed Insights usa CrUX, que solo cubre Chrome y solo a usuarios que dieron su consentimiento, en una ventana de 28 días. Con muestras y periodos distintos, la coincidencia exacta sería sospechosa.

¿Qué umbrales tengo que alcanzar en Core Web Vitals?

LCP dentro de 2,5 segundos, INP de 200 milisegundos o menos y CLS por debajo de 0,1. Todo se evalúa en el percentil 75 de las cargas de página, segmentado entre móvil y escritorio. Shopify añade una lectura práctica de lo mismo: al menos el 75 % de tus cargas deben obtener puntuación buena en las tres métricas para que un buscador considere bueno tu rendimiento.

¿Sirven las apps de optimización de velocidad del App Store?

Depende de lo que haya debajo, pero mi respuesta por defecto es que no empieces por ahí. Una app más es un script más en cada carga, y el problema que intentas resolver suele ser exactamente ese. Limpia primero el residuo de apps antiguas y arregla las reglas de imagen. Si después sigue habiendo margen, evalúa herramientas.

¿Cuánto tarda en notarse una mejora de velocidad?

En laboratorio, inmediatamente. En Search Console, semanas, porque CrUX trabaja con una ventana móvil de 28 días y necesita acumular cargas nuevas suficientes. El informe del admin, con sus 7 días, es el que antes te confirma que vas bien. No decidas nada con un solo día de datos, en ninguna de las dos fuentes.

¿Un tema de pago resuelve el problema de velocidad?

No siempre, y en la mayoría de los casos solo resuelve el punto de partida. Un tema bien construido da mejor arranque, pero el deterioro llega después, con las apps, los píxeles y las secciones que se acumulan durante dos años. He visto temas de pago con peor LCP que temas gratuitos limpios. El mantenimiento pesa más que la compra.

La velocidad se gana quitando, no añadiendo

Después de bastantes auditorías, mi conclusión es poco emocionante: casi todo el tiempo recuperable ya estaba dentro de la tienda, en forma de código que alguien instaló y nadie retiró. No hay técnica avanzada en eso. Hay inventario, paciencia y ganas de discutir con quien defiende una app que nadie usa desde hace un año.

Lo otro que aprendí a la fuerza: no optimices contra un número que no es el que te evalúa. El informe del admin es un buen detector de humo porque reacciona en días. El de Search Console refleja lo que Google ve, con su muestra de Chrome y sus 28 días. Confundirlos lleva a celebrar mejoras que no existen. Si el resto del trabajo técnico también está pendiente, la guía de SEO para Shopify ordena por dónde seguir.

Si quieres que mire tu tienda y te diga qué se puede quitar sin romper nada, reserva 30 minutos de consultoría.