¿Por qué mi minicarrito de WooCommerce deja de mostrarse cuando activo Remove Unused CSS?

Optimiza la tienda, el informe de PageSpeed mejora, y unas horas después un cliente le escribe: el icono del carrito no hace nada. Pasa el cursor sobre él y no se abre nada. O se abre vacío, o sin ningún estilo. Usted nunca tocó el carrito. Activó una optimización de CSS. Entonces, ¿qué ha pasado?

El minicarrito es el pequeño icono del carrito en su cabecera, normalmente con un contador de artículos, y el panel que se abre al pasar el cursor o tocarlo, donde se muestra lo que hay en la cesta. Ese panel es la parte que se rompe, y hay dos motivos por los que se rompe, a menudo juntos.

Qué es en realidad un minicarrito (y por qué es frágil)

Al cargar la página, el panel no está pensado para verse. Permanece oculto: display:none, o opacity:0 con visibility:hidden, o desplazado fuera de la pantalla. No se muestra nada hasta que se interactúa.

Dos cosas hacen que aparezca. El CSS contiene su estado oculto y su estado abierto, las reglas que lo cambian a visible y posicionan el panel. El JavaScript es quien hace el cambio: al pasar el cursor o tocar, añade una clase que activa el panel, o bien construye e inyecta el contenido del carrito al vuelo. En WooCommerce esa construcción suele correr a cargo de wc-cart-fragments.js, el script que mantiene sincronizados el minicarrito y el contador de artículos mediante AJAX.

Quite el CSS adecuado, o impida que se ejecute el script adecuado, y el panel nunca aparece. Ambas cosas ocurren cuando se optimiza sin decirle a la herramienta que deje el carrito en paz.

Causa 1: el CSS está oculto, así que se elimina

Un proceso de used-CSS o remove-unused-CSS conserva los estilos de lo que es visible al renderizar la página, y descarta el resto. El panel de su minicarrito está oculto en ese momento, así que la herramienta decide que sus estilos son peso muerto y los elimina.

Como resultado, se rompen dos cosas. La regla que hacía aparecer el panel al abrirse desaparece, así que pasar el cursor no produce nada visible. O bien desaparece el propio estilo del panel, y entonces se abre sin estilos: una lista desnuda sin posicionamiento ni fondo, desbordándose por la página.

Es el mismo mecanismo que elimina un menú móvil oculto o una superposición de búsqueda. La explicación completa, y la solución que perdura, está en nuestra guía sobre cómo el critical CSS rompe menús y superposiciones.

Key infos

El panel está oculto al cargar, así que un proceso de used-CSS considera inútiles sus estilos y los elimina.
Se pierde el estado abierto (no aparece nada) o el estilo del panel (se abre roto).
Misma causa que un menú móvil o una superposición de búsqueda eliminados.

Causa 2: el JavaScript nunca se dispara

Incluso con los estilos intactos, el panel necesita su script para abrirse. Si se retrasa o difiere el JavaScript, el script que añade la clase de apertura, o el que construye el carrito, puede que no esté disponible cuando el visitante pasa el cursor.

En WooCommerce el sospechoso habitual es wc-cart-fragments.js, además del script del tema o del carrito lateral que gestiona el hover, además de jQuery por debajo de ambos. Retrase la cadena y el contador deja de actualizarse, o el panel se queda vacío, o el icono simplemente no responde.

Diferir el JavaScript merece la pena, pero la interacción del carrito tiene que seguir funcionando. El método, excluir toda la cadena de dependencias por fragmento de URL con una guarda para que tolere cargarse pronto, es el mismo que soluciona un menú hamburguesa de doble toque, descrito en la guía del menú hamburguesa.

Una advertencia: no desactive wc-cart-fragments.js para ahorrarse la solicitud AJAX. Esa solicitud tiene un coste real en cada página, y puede limitar dónde se ejecuta, pero eliminarla mata un minicarrito en vivo. Exclúyalo del retraso, no lo elimine.

Key infos

El panel necesita un script para abrirse; un retraso de JS puede impedir que ese script se ejecute a tiempo.
En WooCommerce suele ser wc-cart-fragments.js más el script del tema o del carrito lateral más jQuery.
Excluya cart fragments del retraso, nunca lo elimine, o el carrito en vivo deja de actualizarse.

Diagnostíquelo en 30 segundos

Desactive la opción de used-CSS un momento. Si el minicarrito vuelve a funcionar, el CSS es el culpable. Vuelva a activarla y vaya directo a la safelist.

Si los estilos están claramente ahí pero el panel sigue sin abrirse, observe la pestaña Network: pase el cursor sobre el icono y compruebe si wc-cart-fragments.js y el script del tema se cargan y se ejecutan. Si se disparan tarde, o no se disparan en absoluto, el retraso es el culpable.

Y compruebe tanto móvil como escritorio. Muchos motores mantienen una versión optimizada distinta por dispositivo, así que un carrito que funciona en escritorio puede seguir roto en móvil.

Las excepciones que hay que añadir

Conservar el CSS (safelist). Proteja los selectores del minicarrito frente a la poda. Los habituales en WooCommerce:

el widget principal: .widget_shopping_cart, .widget_shopping_cart_content, .woocommerce-mini-cart, .mini_cart_item, .cart_list, .cart-contents
el carrito de bloques, si lo usa: .wc-block-mini-cart y sus elementos hijos
el estado abierto, que es lo que más importa: la clase que sea que active la visibilidad del panel en su sitio (a menudo .active, .is-open, .open, .show)
el contenedor de su tema o del plugin de carrito lateral, que tendrá que identificar directamente en la página

Una safelist depende del plugin y de la configuración, así que se desactualiza con el tiempo. La versión que sobrevive a una regeneración consiste en poner en línea el estado oculto y el estilo completo del estado abierto en un bloque al que se le indica al optimizador que no toque, colocado después de wp_head(). Ese método está en la guía de critical CSS.

Conservar el JS (exclusiones). Saque los scripts del carrito del retraso, como una cadena:

wc-cart-fragments.js, el que construye y actualiza el minicarrito
jQuery y jQuery Migrate, del que depende
el script de su tema o del plugin de carrito lateral que gestiona el hover o la alternancia

Localícelos por un fragmento único de su URL, no por el handle interno, y asegúrese de que el script excluido tolera cargarse pronto. Excluya toda la cadena junta, o obtendrá el resultado “excluido pero muerto”: el carrito figura como excluido y aun así no funciona.

Key infos

Incluya en la safelist los selectores del minicarrito, y sobre todo la clase que abre el panel.
Mejor aún, ponga en línea los estilos ocultos y abiertos en un bloque no optimizable, para que sobreviva a una regeneración.
Mantenga la cadena de JS fuera del retraso: cart fragments, jQuery y el script del tema o del carrito lateral, por URL.

Una nota para quienes construyen temas y plugins

Si usted construye el carrito, puede convertir todo esto en una excepción de una sola línea. Dele al componente una única clase de espacio de nombres, por ejemplo minicart, y encierre bajo ella todas las reglas: el estado oculto, el estado abierto y cada elemento hijo.

CSS

.minicart              { opacity: 0; visibility: hidden; }
.minicart.is-open      { opacity: 1; visibility: visible; }
.minicart .item        { /* ... */ }
.minicart .count       { /* ... */ }

Ahora todo el componente está en la safelist con un único token, .minicart, y ningún optimizador puede desmontarlo. Disperse esos mismos estilos entre selectores genéricos como .cart-item o .flyout.open y cada uno necesitará su propia entrada en la safelist, lo que se rompe la primera vez que alguien se olvida de una. Esto ayuda a cualquier optimizador, no solo a Mantys.

Con Mantys Core

Mantys Core puede gestionar toda su capa de rendimiento, caché incluida, o convivir con la configuración que ya tiene. En una tienda, el minicarrito es exactamente el tipo de elemento que está diseñado para proteger.

respeta los bloques que usted marca como no optimizables, así que los estilos ocultos y abiertos del carrito sobreviven;
mantiene las excepciones de JavaScript declaradas por fragmento de URL con una guarda de estado, así que cart fragments y el script del hover siguen funcionando mientras el resto se retrasa;
regenera el CSS página por página, así que las plantillas de su tienda no se recortan como si fueran una landing page normal;
y gestiona móvil y escritorio por separado, así que un carrito que funciona en uno no está roto en el otro.

Su tienda sigue funcionando mientras se reduce el peso, sin tener que estar pendiente de una safelist.

En resumen

El minicarrito está oculto hasta que alguien pasa el cursor sobre él, así que un proceso de used-CSS elimina sus estilos y un retraso de JS impide que se abra.
La causa uno es CSS: el panel oculto se considera inútil y se elimina. La causa dos es JS: el script que abre o construye el carrito nunca se ejecuta.
Solucione el CSS con una safelist, o mejor, con un bloque en línea no optimizable para los estilos ocultos y abiertos.
Solucione el JS excluyendo toda la cadena, cart fragments más jQuery más el script del tema, del retraso, y no elimine nunca cart fragments.
Si usted construye el tema, ponga el carrito bajo una única clase de espacio de nombres para que la excepción sea una sola línea.