Cómo saber si su tienda Magento es lenta de verdad

Todo el que trabaja en una tienda tiene una teoría sobre por qué va lenta. Es el hosting. Es el tema. Es esa extensión que alguien instaló en 2021. Las teorías suelen ser sinceras y con frecuencia equivocadas, y ninguna se puede zanjar discutiendo, porque «lento» no es una medida.

Cuatro números lo zanjan. Este artículo trata de cómo obtenerlos, cómo leerlos y qué es lo que no pueden decirle.

Los cuatro números

TTFB — tiempo hasta el primer byte. Cuánto tarda el servidor en empezar a responder. El umbral de Google para «bueno» es 800 ms. Este es el que marca el techo: si el HTML no empieza a llegar hasta pasados dos segundos, nada de lo que haga el navegador después puede producir una página rápida.

LCP — largest contentful paint. Cuándo termina de renderizarse el elemento más grande en pantalla, que es más o menos el momento en que una persona diría que la página apareció. Bueno es 2,5 segundos o menos. Entre 2,5 y 4 necesita trabajo. Por encima de 4 está suspendiendo.

INP — interaction to next paint. Cuánto tarda la página en responder cuando alguien hace clic o escribe. Bueno es 200 ms o menos. Este es el que delata el JavaScript pesado, y es el que la mayoría de las tiendas nunca ha mirado.

CLS — cumulative layout shift. Cuánto se mueve la página mientras carga. Bueno es 0,1 o menos. Normalmente lo causan imágenes sin dimensiones, banners inyectados tarde o un cambio de fuente que redimensiona todo.

Tres de ellos —LCP, INP y CLS— son los Core Web Vitals con los que Google posiciona. El TTFB no es uno de ellos, y es el que decide si los otros tres son alcanzables.

Datos de campo, no una puntuación de Lighthouse

Dos personas pueden mirar la misma tienda, medirla con honestidad y no estar de acuerdo en nada, porque midieron cosas distintas.

Lighthouse es una prueba de laboratorio. Una página, una conexión simulada, un visitante anónimo que llega por primera vez, en un navegador recién abierto. Es una herramienta de diagnóstico, y buena.

Los datos de campo son lo que les pasó a personas reales. Google los recoge en CrUX —el Chrome User Experience Report— a partir de usuarios reales de Chrome en dispositivos reales, y son lo que muestra Search Console y lo que usa el posicionamiento.

Los dos discrepan constantemente, y cuando lo hacen, los datos de campo tienen razón. Los visitantes reales llegan a páginas que no estaban en la full-page cache. Algunos tienen la sesión iniciada, lo que se salta la caché por completo. Otros van en un Android de hace cuatro años, en un tren. Lighthouse nunca ve nada de eso.

Así que: PageSpeed Insights, sobre su dominio real. La mitad superior de esa página son datos de campo, si su tienda tiene tráfico suficiente para tenerlos. La mitad inferior es una ejecución nueva de Lighthouse. Lea la mitad superior para saber si tiene un problema, y la inferior para averiguar cuál es.

Si PageSpeed dice que no hay datos de campo para su URL, la tienda no recibe suficiente tráfico de Chrome para que CrUX informe sobre ella. No es un fallo: solo significa que está trabajando con números de laboratorio, y que debería probar usted mismo los caminos lentos con más cuidado.

Mida las páginas correctas

Casi todas las conversaciones sobre rendimiento empiezan por la portada, y la portada es la página menos útil del sitio para medir.

Es la página que ya está optimizada, porque es la que todo el mundo mira. Suele ser más sencilla que el resto de la tienda. Y la mayoría de los visitantes nunca la ve: llegan desde un buscador a un producto o a una categoría.

Mida estas, en móvil, por separado:

• Una página de categoría, idealmente una profunda, con navegación por capas y unos cientos de productos detrás.
• Una página de producto, idealmente un configurable con muchas opciones.
• La página de resultados de búsqueda, si una parte significativa de su tráfico usa el buscador.

Móvil primero, porque ahí es donde los números son peores y donde suele estar la mayoría del tráfico. Una tienda que va bien en escritorio y suspende en móvil está suspendiendo.

El camino que nadie prueba

Un cliente con sesión iniciada y artículos en el carrito se salta la full-page cache. Cada petición que hace es una petición real a Magento: bootstrap completo, layout completo, consultas reales a la base de datos. En muchas tiendas este camino es varias veces más lento que el cacheado, y es el camino que recorre cada cliente que vuelve.

Compruébelo a mano. Inicie sesión, añada algo al carrito y cronometre una página de categoría en el panel de red del navegador. Compárela con la misma página en una ventana privada. Si la diferencia es grande, su caché está haciendo más trabajo del que pensaba y sus clientes reales están recibiendo la versión lenta.

Lo mismo vale para el checkout, que no se puede cachear en absoluto.

Qué le dicen los números

Una vez que los tiene, acotan bastante la búsqueda.

El TTFB es alto, todo lo demás es proporcional. El problema está en el servidor y el frontend es inocente. Mire primero la full-page cache: no si Varnish está instalado, sino cuál es realmente el hit rate. Una tienda con Varnish a un 40 % de aciertos es una tienda en la que la mayoría de los visitantes recibe el camino lento de todos modos. Después: consultas lentas a la base de datos, una extensión haciendo trabajo en cada petición, workers de PHP agotados en horas punta, o un hosting que simplemente se queda corto.

El TTFB está bien, el LCP está mal. El servidor responde rápido y el navegador tarda mucho en hacer algo con la respuesta. CSS y JavaScript que bloquean el renderizado, una imagen principal sin optimizar, fuentes que impiden pintar el texto, o un tema que envía varios megabytes.

El INP está mal. Demasiado JavaScript ejecutándose en el hilo principal. Con frecuencia es un script de terceros —un widget de chat, un contenedor de tag manager, una herramienta de personalización— y con frecuencia uno que nadie recuerda haber añadido.

El CLS está mal. Algo carga tarde y empuja el contenido. Imágenes sin ancho y alto, un banner de cookies insertado después de pintar, un cambio de fuente.

Los números están bien y aun así se siente lenta. Entonces mida el camino con sesión iniciada y el checkout, porque ahí es donde no ha mirado.

Lo que no se ve desde fuera

La mayoría de estas investigaciones empiezan desde fuera de la tienda, así que los límites de esa vista importan.

Desde fuera puede medir tiempos de respuesta, leer cabeceras de caché, consultar datos de campo y, a menudo, deducir la versión de Magento. Lo que no puede ver es la razón: el log de consultas lentas, el hit rate de la caché, si el cron está corriendo, si los indexers están en el modo correcto, cuántos workers de PHP hay, o cuál de las cuarenta extensiones instaladas añade 300 ms a cada página.

No es una diferencia pequeña. Es la diferencia entre saber que una tienda es lenta y saber qué hacer al respecto, y es la razón por la que «compre más hosting» es una respuesta equivocada tan habitual y tan cara. Si el cuello de botella es la base de datos, más workers de PHP lo empeoran: hacen cola contra el mismo recurso saturado.

Y después

Apunte los números con la fecha. CrUX es una ventana móvil de 28 días, así que una corrección desplegada hoy no se verá del todo hasta dentro de un mes, y querrá saber cómo estaba antes.

Luego trabaje en orden: primero el servidor, porque marca el techo, y el frontend al final, porque nunca puede correr más que un backend lento. El checklist de rendimiento para Magento 2 es esa lista en orden, con los comandos para verificar cada punto.

Si los números dicen que hay un problema y no puede ver la causa desde donde está —que es el resultado habitual—, para eso existe exactamente el diagnóstico gratuito de su tienda. Una persona lee su tienda, y usted recibe lo que encontramos.