Por qué sus páginas de categoría en Magento 2 son lentas (y cómo arreglarlas)

Las páginas de categoría son donde la mayoría de las tiendas Magento pierden dinero en silencio. Están entre el tráfico de búsqueda y las páginas de producto, Google las indexa a fondo, y son estructuralmente la plantilla más cara que renderiza Magento: una sola petición puede cargar decenas de productos, calcular el precio de cada uno, construir un árbol de navegación por capas con recuentos y generar una rejilla de imágenes.

También son donde el rendimiento cacheado y sin cachear diverge más. Su página de categoría puede volver en 80 ms desde Varnish y tardar 2,8 segundos cuando se aplica un filtro. Como las páginas filtradas son exactamente las que visitan sus compradores más implicados, esa diferencia importa más que el número de cabecera.

Esto da por hecho que sus cimientos de rendimiento a nivel de sitio están en su sitio. Si el TTFB es malo en todas partes, arregle eso primero.

El problema de la navegación por capas

La navegación por capas es la mayor fuente individual de lentitud en las páginas de categoría, y empeora siguiendo un patrón concreto: va bien en una categoría de 200 productos, duele en una de 5.000 y es inutilizable en una de 50.000.

Los atributos filtrables no son gratis

Cada atributo marcado como «Use in Layered Navigation» añade trabajo a cada renderizado de página de categoría. Magento tiene que calcular las opciones disponibles y el recuento de productos de cada una, acotados al estado actual de los filtros.

Entre en su lista de atributos y audítela con honestidad. La mayoría de las tiendas ha acumulado filtros que nadie usa: un filtro con 400 opciones que produce un resultado por opción no ayuda a los compradores y le está costando en cada carga de página. Diez filtros bien elegidos ganan a cuarenta exhaustivos, en velocidad y en conversión.

Compruebe también por separado la opción «Use in Search Results Layered Navigation». Es un ajuste distinto y es fácil dejarlo activado en atributos que ya ha desactivado en otro sitio.

Las combinaciones de filtros hacen estallar su caché

Esta es la aritmética que pilla a la gente desprevenida. Una categoría con 8 filtros de una media de 6 opciones cada uno tiene, en principio, millones de combinaciones de URL alcanzables. Varnish cacheará encantado cada una de ellas, y expulsará todo lo demás para hacerles sitio.

Dos cosas que hacer al respecto:

• Limite la superficie rastreable. Use robots.txt y etiquetas canonical para que los buscadores no rastreen permutaciones de filtros, y configure su navegación por capas para poner noindex a las combinaciones de varios filtros. Es tanto una corrección de SEO como de rendimiento: el presupuesto de rastreo gastado en URLs de filtros es presupuesto de rastreo que no se gasta en productos.
• Vigile la tasa de expulsión de Varnish. Si n_lru_nuked en varnishstat sube de forma constante, su caché está dando vueltas y su hit rate en páginas reales es peor de lo que parece.

Considere una capa de motor de búsqueda dedicada

A partir de cierto tamaño de catálogo, calcular las facetas en MySQL deja de ser viable por mucho que se afine. La integración de Magento con OpenSearch lo resuelve razonablemente bien, pero si está en una extensión que todavía resuelve la navegación por capas a través de las tablas catalog_product_index_eav, ese es su cuello de botella, y ningún ajuste de índices arregla un desajuste arquitectónico.

Colecciones de producto hinchadas

Las colecciones de producto de Magento cargan más de lo que cree. Un listado por defecto carga todos los atributos del grupo catalog_listing, y cada extensión que toca la PLP tiende a añadir los suyos.

Lo concreto que hay que revisar:

Atributos marcados como «Used in Product Listing». Cada uno se une a la consulta de la colección con un join. Un atributo que solo se usa en la página de producto pero está marcado para el listado es sobrecarga pura, multiplicada por el tamaño de su página.

Extensiones que llaman a addAttributeToSelect('*'). Esto carga todos los atributos de todos los productos de la rejilla. Aparece en un número sorprendente de módulos de terceros. Busque en sus directorios vendor/ y app/code/: la solución suele ser cambiar una línea por una lista concreta de atributos.

Cálculo de precios. Los precios por nivel, las reglas de precio de catálogo y los precios por grupo de clientes añaden cálculo por producto. Si tiene reglas de precio complejas, el índice de precios está haciendo trabajo pesado y necesita estar sano. Compruebe que catalog_product_price está en Update by Schedule y realmente al día.

Productos por página. Una rejilla por defecto de 60 productos son 60 peticiones de imagen, 60 cálculos de precio y un DOM mucho más grande. Pruebe 24 o 36 contra sus datos reales de conversión: en nuestra experiencia, los compradores que quieren más resultados usan filtros, no páginas más largas.

LCP en una rejilla de imágenes

Las páginas de listado de productos tienen un perfil de LCP poco habitual: el elemento más grande suele ser una de las primeras imágenes de producto, o un banner de categoría. Las dos cosas tienen arreglo.

Precargue la imagen correcta. Identifique el elemento LCP en el panel Performance de Chrome DevTools sobre una página de categoría real —no la portada— y precárguelo con fetchpriority="high".

No cargue en diferido los productos por encima del pliegue. La mayoría de los temas aplican loading="lazy" a todas las imágenes de producto de la rejilla, incluida la primera fila. El navegador entonces quita prioridad justo a la imagen que determina su LCP. Ponga las primeras 3-6 imágenes (según su rejilla) en loading="eager" y cargue el resto en diferido.

Sirva imágenes con el tamaño adecuado. Una miniatura de rejilla que se muestra a 280 px no debería ser un original de 1200 px reducido con CSS. El view.xml de Magento controla el tamaño de las imágenes por tema: asegúrese de que la entrada category_page_grid coincide con lo que su CSS renderiza de verdad, y genere un srcset responsivo para que el móvil no esté descargando recursos de escritorio.

Reserve el espacio. width y height explícitos en cada imagen de producto, más una relación de aspecto fija en el contenedor de la tarjeta. Las rejillas sin dimensiones reservadas son el fallo de CLS más habitual que vemos en las PLP, y se acumula: cada fila que se desplaza empuja todo lo que hay debajo.

Paginación, scroll infinito y el intercambio que nadie menciona

El scroll infinito convierte bien en algunos catálogos y es un lastre real de SEO y rendimiento en otros. La versión honesta:

• Añade JavaScript a una página que ya tiene de sobra, y los manejadores de scroll perjudican el INP si no están bien limitados.
• El rastreador de Google no hace scroll. Los productos que solo se alcanzan por scroll infinito pueden quedarse sin indexar salvo que también exponga URLs paginadas.
• Rompe el botón de volver atrás salvo que se implemente con cuidado, y eso es un coste real de conversión.

Si lo usa, impleméntelo como mejora progresiva sobre URLs paginadas reales con semántica rel="next"/rel="prev", mantenga pequeña la carga inicial y asegúrese de que un comprador que baja hasta el producto 200 y entra en él puede volver a donde estaba.

La ordenación y el índice que nadie revisa

«Ordenar por precio» y «Ordenar por posición» rinden de forma muy distinta. La ordenación por posición lee de catalog_category_product_index, que debería ser rápida, salvo que ese índice esté desactualizado o la categoría tenga un número enorme de productos con posiciones asignadas a mano.

La ordenación por precio golpea el índice de precios con el ámbito del grupo de clientes. Si tiene muchos grupos de clientes y muchos sitios web, ese índice crece deprisa. Conviene comprobar el número real de filas de catalog_product_index_price; en instalaciones multitienda con muchos grupos puede alcanzar un tamaño en el que ordenar se convierte en un problema de consulta real.

Además: cada opción de ordenación que expone multiplica su espacio de URLs cacheables. Tres opciones de ordenación sobre sus combinaciones de filtros son tres veces las entradas de Varnish.

Una secuencia de auditoría práctica

Al trabajar sobre una PLP lenta, este es más o menos el orden que encuentra los problemas más rápido:

1. Compare el tiempo de respuesta cacheado y sin cachear de una URL filtrada. Esa diferencia es el tamaño real de su problema.
2. Active el profiler integrado de Magento o use Blackfire en una petición filtrada sin cachear y mire el número de consultas. Cualquier cosa por encima de unos cientos de consultas por renderizado de página es una señal de alarma.
3. Audite los atributos filtrables y las marcas «Used in Product Listing». Suele ser la mejora significativa más rápida.
4. Busque addAttributeToSelect('*').
5. Arregle la capa de imágenes: cargue la primera fila con avidez, corrija los tamaños de view.xml, añada dimensiones.
6. Vuelva a tomar la línea base con datos de campo a las dos semanas.

Las páginas de categoría recompensan este trabajo más que la mayoría de las plantillas, porque las mejoras se acumulan: una consulta de colección más ligera hace más rápido el camino sin cachear, lo que hace menos costosos los fallos de caché, lo que hace menos arriesgada su estrategia de filtros.

Emyrix hace profiling de rendimiento y trabajo de Core Web Vitals en Magento para comerciantes y agencias, incluidas las decisiones de arquitectura de catálogo que hay detrás de las páginas de listado lentas. Si sus páginas de categoría son el punto débil, hablemos.