Para superar los 90 puntos en Google Core Web Vitals con Magento hay que combinar tres cosas: la optimización de imágenes (pasar a formato WebP o AVIF), la minificación de JavaScript y CSS, y la reducción del tiempo de respuesta del servidor (TTFB). Estas tres áreas cubren la mayoría de los problemas técnicos que restan puntos. Según nuestra experiencia, la mayoría de los directivos espera milagros de una única intervención rápida, como activar la caché, pero un resultado superior a 90 solo se mantiene en el tiempo si las tres áreas se optimizan a la vez y de forma coordinada. En buena parte de los casos, las tiendas online con Magento se estancan entre 50 y 70 puntos porque se mejora un área mientras las otras dos quedan intactas, y eso limita todo su potencial. Este artículo ofrece pasos concretos y prácticos para que una tienda Magento alcance de verdad más de 90 puntos en Core Web Vitals, tanto en móvil como en escritorio.
Optimización de imágenes: el paso a WebP y AVIF
La optimización de imágenes es el área que aporta la mejora medible más rápida y con menos riesgo en la puntuación de Core Web Vitals, ya que las fotos de producto y los banners suelen representar la mayor parte del peso total de una página de catálogo en Magento. En nuestra experiencia, pasar de los formatos tradicionales JPEG o PNG a WebP o AVIF reduce por sí solo el tamaño de los archivos entre un 30 y un 50 % con la misma calidad visual, lo que mejora directamente el Largest Contentful Paint (LCP). En los casos que hemos analizado, las tiendas online que implantaron una conversión de formato automatizada para todas las imágenes subidas lograron cargas de páginas de categoría notablemente más rápidas, sobre todo en los listados que muestran muchos productos a la vez.
¿Qué ajustes concretos requiere la optimización de imágenes?
Una optimización de imágenes eficaz requiere la conversión automática a un formato moderno (WebP o AVIF), activar la carga diferida (lazy loading) para las imágenes situadas por debajo de la primera pantalla y un dimensionado responsive que sirva imágenes de distinto tamaño según el dispositivo. ¿Cuándo no basta con cambiar de formato? Cuando las imágenes, incluso ya convertidas, siguen siendo demasiado grandes para el espacio en el que se muestran: sin dimensionado responsive se siguen enviando al navegador archivos innecesariamente pesados, sobre todo en dispositivos móviles.
Minificación de JavaScript y CSS: menos carga que bloquea el renderizado
La minificación de JavaScript y CSS influye directamente en el Interaction to Next Paint (INP) y en el First Contentful Paint (FCP), porque los archivos de código sin comprimir e innecesariamente grandes ralentizan el procesamiento y el renderizado en el navegador. En muchos casos hemos comprobado que activar las opciones de minificación y agrupación (bundling) disponibles en la configuración nativa del panel de administración de Magento ya aporta una mejora apreciable, pero el verdadero salto llega al eliminar las reglas CSS y el código JavaScript que no se usan, que a menudo sobrecargan el sistema por la acumulación de módulos y extensiones.
¿Por qué no basta con activar la minificación integrada?
La minificación integrada no es suficiente por sí sola porque solo reduce el tamaño de los archivos existentes, pero no elimina el código sobrante y sin uso que dejan en el sistema los módulos de terceros o los desarrollos a medida obsoletos. ¿Para quién no sirve activar la minificación una sola vez y olvidarse? Para las tiendas online que instalan módulos nuevos con regularidad, porque cada extensión añade código nuevo, potencialmente sin optimizar, que hay que revisar periódicamente.
| Área de optimización | Métrica de Core Web Vitals afectada | Mejora típica |
| Optimización de imágenes (WebP/AVIF) | Largest Contentful Paint (LCP) | Reducción del tamaño de archivo del 30–50 % |
| Minificación de JS/CSS | Interaction to Next Paint (INP), FCP | Renderizado notablemente más rápido |
| Reducción del TTFB | Time to First Byte, indirectamente LCP | Mejora del orden de segundos |
| Implantación de la caché Varnish | Tiempo total de carga de la página | De segundos a milisegundos |
Reducción del tiempo de respuesta del servidor (TTFB): optimizar la capa base
Reducir el tiempo de respuesta del servidor, es decir, el Time to First Byte (TTFB), es fundamental, porque cualquier otra optimización, ya sea de imágenes o de JavaScript, solo surte efecto después de que el navegador reciba la primera respuesta del servidor. Según nuestra experiencia, la mayoría de los clientes consigue la mayor mejora de TTFB configurando correctamente la caché Varnish, ya que en las páginas cacheadas el servidor responde directamente desde la memoria, sin ejecutar PHP ni consultar la base de datos. Según los datos de un benchmark de rendimiento independiente, un Magento 2.4.9 estándar sin la optimización adecuada produce en móvil un LCP de 4,2–5,8 segundos, mientras que el umbral para obtener la calificación de «bueno» está por debajo de 2,5 segundos, lo que muestra claramente el peso de la base del lado del servidor en la puntuación final.
¿Qué factores influyen más en el TTFB de un sistema Magento?
En el TTFB influyen sobre todo la calidad de la infraestructura de hosting, que la versión de PHP esté actualizada, la optimización de las consultas a la base de datos y el tipo de backend de Full Page Cache (sistema de archivos integrado o Varnish), porque en conjunto determinan cuánto tarda el servidor en preparar y enviar la primera respuesta. ¿Conviene reducir el TTFB antes de optimizar imágenes y código? Sí, porque una capa base lenta en el servidor limita también la eficacia del resto de optimizaciones; por eso siempre es recomendable empezar el proceso de mejora de Core Web Vitals por el lado del servidor.
Cómo mantener una puntuación superior a 90 de forma sostenible
Para mantener de forma sostenible una puntuación de Core Web Vitals superior a 90 no basta con una única ronda de optimización puntual, porque la puntuación puede volver a caer con el tiempo si se incorporan módulos, imágenes o funcionalidades nuevas sin optimizar. En nuestra experiencia, la mayoría de las tiendas online que mantienen puntuaciones altas de forma duradera implantan auditorías de rendimiento periódicas que vuelven a comprobar las métricas de Core Web Vitals tras cada cambio relevante.
¿En qué orden conviene ejecutar el proceso completo de optimización?
Conviene empezar el proceso completo por la capa del servidor (caché Varnish, TTFB), continuar con la optimización de imágenes y terminar con la minificación de JavaScript y CSS y la eliminación del código sobrante, porque este orden garantiza que cada capa se construya sobre la mejor base posible. ¿Cuándo no es recomendable centrarse en una sola área? Cuando el objetivo es un resultado duradero superior a 90 puntos, porque las métricas de Core Web Vitals están relacionadas entre sí y un área descuidada puede limitar la puntuación global.
Para superar los 90 puntos en Core Web Vitals, conviene seguir estos pasos en orden:
- Configurar correctamente la caché Varnish y optimizar el TTFB del lado del servidor.
- Convertir automáticamente todas las imágenes de producto a WebP o AVIF y activar el lazy loading.
- Minificar y agrupar los archivos JavaScript y CSS, eliminando el código sobrante.
- Revisar los módulos instalados y retirar las extensiones que sobrecargan el sistema sin necesidad.
- Medir Core Web Vitals de forma periódica tras cada cambio relevante.
Antes de iniciar el proceso de optimización, conviene valorar también estos aspectos:
- La capacidad del mantenimiento de Magento y del entorno de servidor actuales para asumir los cambios necesarios.
- La posibilidad de incorporar una CDN para servir más rápido el contenido estático: imágenes, JS y CSS.
- El impacto de los módulos y desarrollos a medida existentes en el rendimiento actual.
- La diferencia entre los resultados medidos en móvil y en escritorio, y sus causas.
- La implantación de una monitorización periódica para conservar la puntuación a largo plazo.
Lazy loading y gestión del contenido de la primera pantalla
Implantar correctamente el lazy loading es crucial: aunque la carga diferida de las imágenes situadas por debajo de la primera pantalla mejora la velocidad de carga inicial, aplicarla a los elementos visibles de inmediato en la parte superior produce justo el efecto contrario y puede empeorar el Largest Contentful Paint. En nuestra experiencia, el error más habitual es que los desarrolladores apliquen una regla global de lazy loading a todas las imágenes, en lugar de distinguir entre el contenido visible en la vista inicial y el que queda por debajo. En los casos que hemos analizado, las tiendas online con mejores resultados de LCP fueron aquellas en las que el banner principal y las imágenes de las primeras filas de productos recibían prioridad explícita, mientras que el resto del contenido se cargaba con lazy loading.
¿Cómo identificar correctamente qué elementos pueden usar lazy loading?
Para identificarlos correctamente hay que determinar qué elementos aparecen en la vista inicial, sin desplazarse, en los tamaños de pantalla más habituales, porque esos elementos deben recibir prioridad en la carga, no lazy loading. ¿Cuándo no es recomendable una solución de lazy loading automática que lo abarque todo? Cuando en las páginas de categoría de la tienda el banner principal o los productos destacados aparecen en la vista inicial, porque en ellos el lazy loading empeora precisamente la métrica más importante, el LCP.
El impacto de los scripts de terceros en la puntuación de Core Web Vitals
Los scripts de terceros (herramientas de analítica, píxeles de marketing, widgets de chat) tienen un impacto a menudo subestimado, pero considerable, en la puntuación de Core Web Vitals, porque se cargan con independencia de nuestro propio trabajo de optimización y pueden aumentar mucho el tiempo de ejecución de JavaScript. En buena parte de los casos hemos visto que la puntuación de una tienda Magento por lo demás bien optimizada cae en picado en cuanto se añaden sin control entre 5 y 10 scripts distintos de marketing y analítica.
¿Cómo gestionar los scripts de terceros sin perjudicar la puntuación?
Para gestionar los scripts de terceros conviene usar una solución de gestión de etiquetas (por ejemplo, Google Tag Manager), que permite cargarlos de forma diferida y condicional, en lugar de que cada herramienta se cargue directamente y de inmediato en todas las páginas. ¿Conviene cargar todas las herramientas de marketing y analítica a la vez y de inmediato en todas las páginas? No, porque la mayoría de estos scripts no son críticos para la experiencia inicial del usuario y, con una carga diferida, su impacto negativo en las métricas de Core Web Vitals se reduce considerablemente.
Optimización de la carga de fuentes y reducción del Cumulative Layout Shift
La optimización de la carga de fuentes influye directamente en el Cumulative Layout Shift (CLS), porque mientras se cargan unas fuentes web mal gestionadas, el tamaño y la posición del texto pueden cambiar de golpe, lo que provoca desplazamientos visuales y empeora la experiencia de usuario. Según nuestra experiencia, la estrategia de carga de fuentes predeterminada de la mayoría de las tiendas Magento no tiene en cuenta este problema, y precisamente por eso el CLS se mantiene por encima del umbral deseado aunque la optimización de imágenes y código esté en orden.
¿Qué soluciones técnicas reducen los desplazamientos causados por la carga de fuentes?
Para reducir los desplazamientos causados por la carga de fuentes conviene usar la propiedad CSS font-display: swap o font-display: optional y precargar (preload) las fuentes críticas en la cabecera HTML, para que el navegador empiece a descargarlas cuanto antes. ¿Para quién no es buena idea insertar fuentes web directamente y sin pensarlo? Para las tiendas online que, por su identidad de marca, utilizan tipografías personalizadas en lugar de fuentes del sistema, porque en su caso una estrategia de carga incorrecta puede causar problemas de CLS especialmente graves a los visitantes con conexiones más lentas.
Qué orden de optimización es realmente el adecuado para alcanzar los 90 puntos
La opción realmente acertada nunca es centrarse en una única intervención vistosa, como convertir las imágenes, sino desarrollar la capa del servidor, la optimización de imágenes y la minificación de JavaScript/CSS de forma coordinada, en un orden consciente en el que cada paso se apoya en el anterior, porque las métricas de Core Web Vitals están estrechamente relacionadas entre sí. En nuestra experiencia, la mayoría de las tiendas Magento que mantienen de forma duradera más de 90 puntos empezaron por el TTFB del servidor y la configuración de la caché Varnish, ya que una capa base lenta limita también la eficacia de la optimización de imágenes y código; sobre esa base vinieron después el paso a WebP o AVIF y la eliminación del código sobrante. En buena parte de los casos, el riesgo mayor, y a la vez el que más se pasa por alto, son los scripts de marketing y analítica de terceros, porque pueden hundir la puntuación con independencia del trabajo de optimización propio si no se gestionan con una solución de gestión de etiquetas y carga diferida.
Según nuestra experiencia, la correcta gestión del lazy loading y de la carga de fuentes son pasos de ajuste fino sin los cuales el Largest Contentful Paint y el Cumulative Layout Shift no alcanzan el nivel deseado, aunque ya se hayan dado los pasos de optimización más importantes. ¿Para quién no sirve una ronda de optimización única y puntual? Para las tiendas online que incorporan con regularidad módulos, imágenes o funcionalidades nuevas, porque su puntuación caerá con el tiempo si no se implanta una auditoría de rendimiento periódica tras cada cambio relevante. La opción realmente acertada es, por tanto, una práctica de optimización estructurada por capas y mantenida de forma continua, que cubra todos los niveles, desde la base del servidor, pasando por las imágenes y el código, hasta la gestión de los scripts de terceros. Este enfoque garantiza que la tienda Magento no alcance más de 90 puntos en Core Web Vitals solo una vez, sino de forma duradera.
