Core Web Vitals para Shopify: guía completa (2026)
Qué puedes controlar y qué no en Shopify, y cómo corregir el LCP, el INP y el CLS causados por el exceso de apps, temas pesados y scripts de terceros.
Compartir
Las tiendas de Shopify afrontan retos únicos con Core Web Vitals porque no puedes controlar el servidor, la CDN ni el JavaScript base que Shopify inyecta en cada página. Las mayores causas de fallo en CWV en Shopify son las apps (apps instaladas que inyectan JavaScript de forma global), imágenes hero sin optimizar, scripts de terceros (reseñas, widgets de chat, píxeles de seguimiento) y temas pesados con demasiadas funciones. Pese a todo, Shopify supera a WordPress en porcentaje de aprobados en CWV porque su infraestructura es rápida por defecto.
Última revisión por Arjen Karel en febrero de 2026

Shopify y Core Web Vitals: no controlas el servidor
Shopify es fundamentalmente distinto de WordPress o de sitios a medida a la hora de optimizar Core Web Vitals. En WordPress controlas todo: el servidor, la base de datos, la capa de caché y cada línea de código. En Shopify trabajas dentro de una plataforma gestionada donde ciertas cosas escapan por completo a tu control.
Según el Core Web Vitals Technology Report, Shopify supera a WordPress en la tasa de aprobados de CWV en móvil (alrededor del 65% frente al 44% a finales de 2025). Esto se debe a que la infraestructura de Shopify es excelente por defecto: servidores rápidos, una CDN global con Cloudflare, conversión automática de formatos de imagen y temas base ya optimizados. La plataforma resuelve bien la parte del servidor.
Los problemas surgen con lo que añaden los comerciantes: apps, scripts de terceros, modificaciones del tema, imágenes sobredimensionadas y una carga excesiva de fuentes. Ahí es donde las tiendas de Shopify suspenden Core Web Vitals. Y como el acceso al servidor y al código base es limitado, la estrategia de optimización debe ser diferente.
Core Web Vitals en Shopify en cifras
Shopify ocupa el segundo puesto general en el CrUX Technology Report en porcentaje de aprobados de Core Web Vitals, solo por detrás de Duda (una plataforma mucho menos utilizada). Estas son las cifras de CrUX y de estudios comparativos independientes:
| Métrica | Shopify (CrUX) | WordPress (CrUX) | Media web |
|---|---|---|---|
| Aprobados globales en CWV (móvil) | ~65% | 43,4% | 48% |
| INP bueno | 89,5% | 85,9% | ~87% |
| Mediana de LCP en móvil* | 2,26 s | ~3,4 s | ~2,9 s |
| Mediana de CLS* | 0,01 | ~0,08 | ~0,06 |
Fuentes: CrUX Technology Report (junio de 2025), análisis de CMS de SearchEngineJournal, estudio de 1.000 tiendas de Shero Commerce (noviembre de 2025). *Valores de la mediana del estudio de Shero, no el p75 de CrUX.
El estudio de Shero Commerce sobre 1.000 tiendas reales de Shopify reveló que solo el 48% aprueba las tres Core Web Vitals en móvil. Es una cifra inferior a la que muestra el CrUX Technology Report para Shopify en su conjunto, lo que sugiere que las tiendas presentes en CrUX (que requieren suficiente tráfico en Chrome) tienen un sesgo hacia tiendas más grandes y mejor optimizadas. La mediana de LCP en móvil de 2,26 segundos roza peligrosamente el umbral de "bueno" de 2,5 segundos: cualquier añadido menor (una app más o una imagen hero sin optimizar) puede hacer que una tienda pase de aprobar a suspender.
El CLS y el INP no son el problema. La mediana de CLS de Shopify de 0,01 es excelente, y la mediana de INP de 153 ms se sitúa con comodidad dentro del rango bueno. El LCP es el punto donde las tiendas de Shopify suspenden Core Web Vitals.
Los datos de usuarios reales de CoreDash en tiendas de Shopify confirman este patrón. Las tiendas que suspenden las CWV casi siempre fallan en el LCP. Las que cargan más de 8 scripts de apps de terceros presentan una mediana de LCP en móvil superior a 3,0 segundos. Las tiendas con 3 o menos scripts de apps mantienen una mediana de LCP por debajo de 2,0 segundos. En nuestros datos, la correlación entre el número de apps instaladas y el LCP es el factor predictivo más claro de fallo en CWV en Shopify.
Lo que no puedes controlar en Shopify
Antes de optimizar, comprende las limitaciones. En Shopify no puedes:
- Cambiar el servidor o el hosting. Shopify funciona en su propia infraestructura. No puedes migrar a un host más rápido, configurar caché a nivel de servidor ni ajustar parámetros de PHP. La ventaja: el TTFB de Shopify suele ser excelente (menos de 300 ms en la mayoría de regiones).
- Eliminar
content_for_header. Shopify inyecta JavaScript obligatorio en cada página a través de esta etiqueta Liquid. Incluye la analítica propia de Shopify, scripts del checkout y la infraestructura de carga de apps. No puedes eliminarlo, y posponerlo puede romper el checkout y el funcionamiento de las apps. - Controlar la CDN. Shopify utiliza Cloudflare como CDN. No puedes configurar reglas de caché, edge workers ni cabeceras personalizadas como harías en tu propia cuenta de Cloudflare.
- Acceder a la base de datos o al código del backend. El lenguaje de plantillas Liquid de Shopify se ejecuta en el servidor, pero no puedes optimizar consultas de base de datos ni el renderizado en servidor más allá de lo que permite Liquid.
Por tanto, toda la estrategia de optimización se centra en lo que sí puedes controlar: el código del tema, las apps instaladas, las imágenes, las fuentes y los scripts de terceros.
El principal problema de CWV en Shopify: el exceso de apps
Las apps instaladas son la causa principal de que las tiendas de Shopify suspendan Core Web Vitals. Cada app puede inyectar JavaScript y CSS en cada página de la tienda, incluso donde esa app no se usa. Una app de reseñas que se carga en la página de inicio. Un widget de recomendaciones de producto que se carga en la página de contacto. Un contador de cuenta atrás que se carga en cada página de producto sin que haya ninguna oferta activa.
Cómo inyectan código las apps
Las apps de Shopify inyectan código de varias formas, y esto importa al hacer limpieza:
- App Embeds (editor del tema): se pueden desactivar en el editor del tema, dentro de "App Embeds". Es el método más limpio y fácil de gestionar.
- Snippets del tema: algunas apps añaden código directamente a los archivos del tema durante la instalación. Desinstalar la app no siempre elimina este código. Conviene revisar manualmente
snippets/ysections/en busca de archivos sobrantes. - ScriptTag API: las apps pueden inyectar scripts por código sin tocar los archivos del tema. Se cargan a través del
content_for_headerde Shopify. Al desinstalar la app se eliminan, pero el script puede quedar en caché. - Cargadores de terceros: algunas apps cargan JavaScript externo desde su propia CDN, lo que genera búsquedas DNS y peticiones de red adicionales.

Cómo auditar las apps
Así audito el impacto de las apps de Shopify en el rendimiento:
- Pasa la página de inicio, una página de producto, una de colección y la del carrito por PageSpeed Insights. Anota las puntuaciones de LCP, INP y CLS.
- Abre Chrome DevTools y ve a la pestaña Coverage. Recarga la página y revisa el porcentaje de JavaScript no utilizado. En tiendas Shopify sobrecargadas, entre el 60% y el 80% del JavaScript que se carga no se usa en esa página.
- Revisa la pestaña Network filtrando por JavaScript. Ordena por tamaño. Identifica qué scripts provienen de apps y cuáles del tema. La columna "Initiator" indica qué cargó cada script.
- Desactiva las apps una a una (o desmarca sus App Embeds) y vuelve a medir. Analiza el impacto individual de cada app en el INP y el LCP.
- Decide para cada app: ¿aporta suficiente valor de negocio frente a su coste en rendimiento? ¿Se puede sustituir por una alternativa más ligera? ¿Es posible cargarla solo en tipos de página específicos?

Los datos de CoreDash en proyectos de optimización en Shopify muestran el impacto habitual de limpiar apps: eliminar un único script innecesario de un widget de reseñas mejoró la mediana de INP en 45 ms en una tienda. Quitar tres apps que no se usaban (una herramienta de popups ya desactivada, un programa de fidelización y un widget de chat en desuso) redujo en 380 KB el JavaScript total de la página y mejoró el LCP en móvil en 1,1 segundos. Toda app que ya no uses activamente está ralentizando la tienda para nada. Elimínala.
Cómo optimizar el LCP en Shopify
En tiendas de Shopify, el elemento de LCP es casi siempre la imagen del banner hero en la página de inicio, la imagen destacada del producto en las páginas de producto o el banner de la colección en las páginas de colección. La CDN de Shopify entrega imágenes en formato WebP automáticamente, lo que ayuda. Pero hay varias optimizaciones que debes gestionar tú mismo.
Precargar la imagen hero
El filtro Liquid image_tag de Shopify incluye el parámetro preload. Al configurarlo en true, Shopify envía desde el servidor una cabecera HTTP Link con rel=preload. El navegador la recibe antes de empezar a procesar el HTML, lo que supone la señal de precarga más temprana posible. Además, incluye automáticamente imagesrcset e imagesizes a partir de la etiqueta, con lo que la precarga responsive funciona correctamente sin riesgo de discrepancias en la URL.
Combina esto con fetchpriority: 'high' en la etiqueta <img> y loading: 'eager' para anular el lazy loading que Shopify aplica por defecto a las secciones situadas fuera de la pantalla inicial. En la imagen hero se hace así:
{{ section.settings.hero_image | image_url: width: 1200 | image_tag:
preload: true,
fetchpriority: 'high',
loading: 'eager',
sizes: '100vw'
}} Esa sola línea te proporciona: precarga mediante cabecera HTTP (lo antes posible), fetchpriority="high" en la etiqueta <img>, carga inmediata (eager) en lugar de lazy loading, atributos width y height automáticos (evitando el CLS) y generación automática de srcset. Aplica siempre fetchpriority="high" en la imagen hero, incluso si no usas precarga.
Si el tema usa una imagen de fondo en CSS para el hero
Algunos temas de Shopify muestran el banner hero como un background-image en CSS en lugar de una etiqueta <img>. Esto es un antipatrón para el LCP. Pierdes fetchpriority, pierdes el srcset automático, pierdes la precarga por cabecera HTTP de Shopify y el navegador no puede empezar a descargar la imagen hasta que descarga y procesa el archivo CSS.
La solución correcta es convertir el fondo CSS en una etiqueta <img> para poder usar image_tag adecuadamente. Implica modificar el código del tema, pero es lo adecuado.
Si no puedes modificar la plantilla bajo ningún concepto, puedes añadir una sugerencia de precarga manual en theme.liquid:
{%- if template == 'index' -%}
<link rel="preload" as="image" href="{{ section.settings.hero_image | image_url: width: 1200 }}">
{%- endif -%} Atención: la URL de la precarga debe coincidir exactamente con la URL del CSS, incluida la marca de versión ?v= de Shopify y el parámetro &width=. Si difieren aunque sea en un solo parámetro, el navegador descargará la imagen dos veces, empeorando el rendimiento en lugar de mejorarlo.
Para consultar la estrategia completa de precarga de imágenes de LCP, consulta cómo precargar la imagen de LCP.
No uses lazy loading en la pantalla inicial
Muchos temas de Shopify aplican loading="lazy" a todas las imágenes, incluida la hero. Esto le indica al navegador que reste prioridad a la imagen más importante de la página. Asegúrate de que el tema excluya del lazy loading las imágenes situadas en la pantalla inicial. En temas modernos que usan el filtro image_tag de Shopify, utiliza loading: 'eager' en las imágenes hero.
Optimiza el tamaño de las imágenes
La CDN de Shopify puede redimensionar imágenes al vuelo mediante parámetros en la URL, pero las plantillas Liquid deben solicitar el tamaño adecuado. No cargues una imagen de 2000 px de ancho cuando solo se muestra a 800 px. Usa el marcado de imágenes responsive de Shopify con los atributos srcset y sizes correctos. Consulta nuestra guía sobre cómo optimizar imágenes.

Cómo optimizar el INP en Shopify
Los fallos de INP en Shopify se deben casi en su totalidad a JavaScript que bloquea el main thread. La inyección de content_for_header propia de Shopify ya añade una base de JavaScript que no puedes eliminar. Todo lo que añadas encima agrava el problema.
Retrasa los scripts de terceros no críticos
Los widgets de chat (Tidio, Zendesk, Intercom), las apps de reseñas (Judge.me, Yotpo, Loox), las herramientas de personalización (popups de Klaviyo, Privy) y la analítica (Google Analytics, Facebook Pixel, Hotjar) no deberían cargarse durante el renderizado inicial de la página. El método adecuado es requestIdleCallback: el navegador carga estos scripts únicamente cuando el main thread está inactivo, normalmente unos segundos después de que la página se ha renderizado.
No uses el aplazamiento basado en interacción (cargar scripts con el primer scroll, clic o toque). Si un usuario pulsa un botón y el sitio responde cargando 500 KB de JavaScript de terceros en ese mismo evento, el main thread se bloquea y esa interacción se lleva una puntuación pésima de INP. El objetivo de posponer scripts es mantener el main thread libre para las interacciones del usuario, no competir con ellas.
Sustituye el atributo src por data-src en los scripts no críticos y restablécelo cuando el navegador esté inactivo:
<script>
(window.requestIdleCallback || function(cb) { setTimeout(cb, 1); })(function() {
document.querySelectorAll('script[data-src]').forEach(function(s) {
s.src = s.dataset.src;
});
});
</script> El fallback con setTimeout da cobertura a Safari, que no admite requestIdleCallback. A diferencia de requestIdleCallback, no espera a una ventana de inactividad real. Pero aun así fragmenta el main thread y los scripts inyectados dinámicamente esquivan el preload scanner de todos modos, lo que en la práctica lo convierte en un fallback suficiente.
Para ver más estrategias para posponer JavaScript, consulta 14 métodos para posponer JavaScript.
Reduce el JavaScript del tema
Los temas de Online Store 2.0 de Shopify (como Dawn) están diseñados para ser ligeros, pero muchos temas de terceros añaden JavaScript pesado para megamenús, sliders de producto, modales de vista rápida y animaciones. Audita el JavaScript del tema usando la pestaña Coverage de Chrome DevTools. Si el tema carga más de 200 KB de JavaScript, busca funciones que puedas desactivar o reemplazar con alternativas en CSS.
Cómo optimizar el CLS en Shopify
El Cumulative Layout Shift en tiendas de Shopify suele deberse a tres cosas: imágenes sin dimensiones, intercambio de fuentes (font swapping) y contenido inyectado dinámicamente por apps.
Define las dimensiones de imagen en las plantillas Liquid
Revisa las plantillas Liquid en busca de etiquetas <img> sin los atributos width y height. El filtro image_tag de Shopify puede generarlos de forma automática:
{{ product.featured_image |
image_tag: widths: '200,400,800', sizes: '(max-width: 768px) 100vw, 50vw' }} Esto genera imágenes responsive con las dimensiones correctas, evitando cambios de diseño a medida que se cargan las imágenes.
Reserva espacio para el contenido dinámico
Las incrustaciones de apps que inyectan estrellas de valoración, sellos de confianza, contadores de cuenta atrás o barras de anuncios tras cargar la página provocan CLS. Reserva espacio para cada elemento dinámico con min-height en CSS para que el contenido circundante no se mueva cuando aparezca el elemento. Esto es especialmente importante en elementos que se inyectan por encima del contenido existente.
Optimiza la carga de fuentes
Si el tema de Shopify carga fuentes web personalizadas, asegúrate de que usen font-display: swap con una fuente de fallback bien ajustada. Precarga los archivos de fuentes principales para reducir el tiempo que tarda el texto en mostrarse con la fuente correcta. Carga solo los grosores y estilos que realmente uses. Consulta nuestra guía sobre optimización de fuentes.
Elección del tema de Shopify y rendimiento
La elección del tema establece la base de rendimiento de la tienda. El proyecto ThemeVitals monitoriza datos reales de CrUX para temas de Shopify. Conclusiones clave:
- Dawn (el tema gratuito predeterminado de Shopify) ofrece sistemáticamente un buen rendimiento en Core Web Vitals porque se desarrolló con el rendimiento como prioridad.
- Los temas con muchas secciones, animaciones y funciones integradas (megamenús, vista rápida de producto, carritos AJAX desplegables) tienden a tener más JavaScript y peor INP.
- Los temas de Online Store 2.0 son generalmente más rápidos que los temas heredados porque utilizan la arquitectura moderna de secciones y de carga de recursos de Shopify.
Si vas a elegir un tema nuevo, revisa sus datos de CrUX en ThemeVitals antes de comprarlo. La optimización de rendimiento más económica es empezar con un tema rápido.
Lo que Shopify hace bien por defecto
Shopify hace muchas cosas bien de serie:
- Infraestructura rápida: los servidores de Shopify y la CDN de Cloudflare ofrecen un TTFB sistemáticamente bajo en todo el mundo.
- WebP automático: la CDN de Shopify convierte imágenes a formato WebP de forma automática cuando el navegador lo admite.
- HTTP/2 y Brotli: activados por defecto en todas las tiendas de Shopify.
- CDN de imágenes con redimensionamiento al vuelo: puedes solicitar cualquier imagen a cualquier ancho mediante parámetros en la URL.
- Indicaciones de preconnect: Shopify añade indicaciones de preconnect para los dominios de su CDN automáticamente.
Estas opciones predeterminadas son la razón por la que el rendimiento base de Shopify es bueno. Tu trabajo consiste en no anular estas ventajas acumulando apps y scripts en exceso.
Cómo monitorizar tu tienda Shopify
El panel de administración de Shopify incluye una "Puntuación de velocidad", pero es una métrica simplificada basada en Lighthouse que no representa tus Core Web Vitals reales. Para una monitorización real del rendimiento:
- Google Search Console: revisa el informe de Core Web Vitals para consultar field data de toda la tienda
- CoreDash: instala el snippet ligero de RUM (una línea de código en theme.liquid) para obtener datos de Core Web Vitals en tiempo real desglosados por tipo de página, dispositivo y país
- PageSpeed Insights: analiza URLs individuales de producto, colección y página de inicio para obtener datos de diagnóstico

Monitoriza tras cada instalación de apps, actualización del tema y lanzamiento de campañas estacionales. Las regresiones de rendimiento en Shopify casi siempre se deben a algo que se añadió hace poco.
Los datos de monitorización de CoreDash indican que la causa más habitual de regresión en las CWV en Shopify es la instalación de una app nueva que inyecta JavaScript de forma global. De media, una app nueva de Shopify añade entre 50 KB y 150 KB de JavaScript a la carga de cada página. Para una tienda que se encuentra justo en el límite del LCP (de 2,3 a 2,5 segundos), una sola app puede empujarla al suspenso. La segunda causa más común son los cambios estacionales: banners de campañas de Black Friday, popups festivos y contadores de promociones que se añaden para una campaña de rebajas y luego se quedan olvidados.

¿Necesitas una web más rápida?
Soy Arjen y llevo 17 años arreglando webs lentas. Si te encuentras con problemas que no puedes resolver por tu cuenta, envíame tu URL y hablamos.
Envíame tu URL
¿Por qué no funciona nuestro fix?
A veces la CDN sigue sirviendo el HTML antiguo, o el fix se metió en la plantilla de desktop y el móvil usa otra. Envíame tu URL y el problema, y te respondo con varias opciones. Primero reviso tus field data, luego dedicamos una hora a tu web, y en menos de un día tienes mis notas por escrito. 350 € sin IVA.
Envíame tu URL¿No tienes desarrollador para hacer el fix? Hago el trabajo yo mismo, en una copia de tu web.
Preguntas frecuentes sobre Core Web Vitals en Shopify
¿Influye el hosting de Shopify en Core Web Vitals?
El hosting de Shopify juega a tu favor. La plataforma funciona sobre servidores rápidos con una CDN global de Cloudflare, lo que proporciona un Time to First Byte sistemáticamente bajo (por lo general, inferior a 300 ms). A diferencia de WordPress, donde el hosting suele ser el principal cuello de botella, en Shopify la infraestructura es sólida por defecto. Los retos con Core Web Vitals provienen de lo que añades encima: apps, scripts de terceros y modificaciones del tema.
¿Cuántas apps de Shopify son demasiadas para Core Web Vitals?
No hay un número fijo, porque el impacto depende de cómo inyecte su código cada app. Una sola app de reseñas mal desarrollada puede perjudicar más el rendimiento que diez apps ligeras de utilidades. La pregunta clave es: ¿cuánto JavaScript añade cada app a cada página? Audita las apps desactivándolas una a una y midiendo el impacto en INP y LCP en PageSpeed Insights. Elimina las que ya no uses y revisa los archivos del tema para borrar código huérfano de apps desinstaladas anteriormente.
¿Es posible conseguir buenas Core Web Vitals en Shopify sin un desarrollador?
Se pueden lograr mejoras notables sin necesidad de un desarrollador: elige un tema enfocado en el rendimiento como Dawn, elimina las apps que no uses, comprime las imágenes de producto antes de subirlas, limita el número de fuentes web y desactiva funciones superfluas del tema como animaciones y sliders. Sin embargo, las optimizaciones avanzadas como modificar plantillas Liquid, posponer scripts de terceros o implementar sugerencias de precarga suelen requerir experiencia en desarrollo o a un especialista en rendimiento de Shopify.
¿Por qué difiere la Puntuación de velocidad de Shopify de Core Web Vitals?
La Puntuación de velocidad en el panel de administración de Shopify se basa en lab data de Lighthouse a partir de una única visita simulada. Las Core Web Vitals en Google Search Console utilizan field data de usuarios reales de Chrome durante una ventana móvil de 28 días. Estas cifras pueden diferir notablemente porque los usuarios reales disponen de dispositivos, velocidades de red y patrones de interacción distintos a los de la simulación de Lighthouse. De cara al SEO, prioriza siempre el informe de Core Web Vitals de Search Console por encima de la Puntuación de velocidad de Shopify.