Evaluación inicial sin contraseñas Presupuesto antes de intervenir Especialista responsable de principio a fin

Css Javascript Browser

Eliminar CSS no usado rompe el menú móvil: cómo repararlo

Repara un menú móvil de WordPress roto al eliminar CSS no usado, localiza selectores dinámicos y limita las exclusiones sin desactivar la optimización.

La versión de escritorio sigue viéndose bien después de optimizar el CSS, pero en el móvil el menú se abre sin posición, permanece invisible o tapa la página de forma incorrecta. Es probable que la herramienta analizara únicamente el estado inicial cerrado y eliminara selectores que solo se utilizan cuando JavaScript añade una clase.

Primero hay que recuperar una navegación fiable y después reducir la excepción. No tiene sentido obtener una hoja de estilos más pequeña si una parte de los visitantes ya no puede recorrer la web.

Confirmar que la eliminación de CSS causa el fallo

En staging, o mediante el parámetro seguro de omisión de la herramienta, desactiva únicamente la función de CSS no usado. Mantén sin cambios la caché y los ajustes de JavaScript. Repite la prueba como visitante desconectado y con el mismo ancho de pantalla.

Si el menú vuelve a funcionar, compara el CSS original con el optimizado. Si continúa roto, investiga JavaScript retrasado, una actualización del tema o recursos generados que hayan quedado obsoletos.

Anota si el botón adopta su estado abierto y si el elemento del menú cambia de clase o atributo ARIA. Esa diferencia separa un problema visual de uno funcional.

Capturar los selectores dinámicos

Abre el menú e inspecciona qué cambia en el DOM. Un tema puede añadir estados como estos:

<body class="menu-open">
  <nav class="site-menu is-active" aria-hidden="false">

Los estilos necesarios podrían ser:

.menu-open {
  overflow: hidden;
}

.site-menu.is-active {
  opacity: 1;
  visibility: visible;
  transform: translateX(0);
}

Un rastreador automático que nunca pulsa el botón no ve esos estados. También puede omitir submenús anidados, estilos de foco y el control de cierre.

Revisar las media queries

La regla necesaria quizá exista solo por debajo de un breakpoint. Compara el CSS exactamente en el ancho donde aparece el fallo y prueba alrededor del límite: por ejemplo, 767, 768 y 769 píxeles.

No incluyas en la lista segura únicamente .is-active si el diseño también depende de clases padre, pseudoelementos o reglas dentro de @media. Conserva el grupo completo más pequeño que permita usar la interacción correctamente.

Comprueba igualmente la orientación horizontal y el zoom del navegador, porque pueden activar la navegación móvil en una pantalla físicamente ancha.

Conservar patrones estables

Utiliza la exclusión o lista segura documentada por el optimizador para los selectores confirmados. Es preferible conservar un prefijo estable como .site-menu que una clase con hash generada por un constructor y susceptible de cambiar al regenerar los recursos.

No uses patrones generales como cualquier clase que contenga active: podrían retener gran parte de la hoja original. Tampoco basta con recuperar una sola regla visible si siguen ausentes los estados de foco o de submenú.

Documenta por qué se conserva cada selector. Así una limpieza futura no repetirá el mismo incidente.

Separar el CSS del tiempo de ejecución de JavaScript

La eliminación de CSS y el retraso de JavaScript suelen activarse juntos. Es posible que el estilo esté presente, pero que el controlador del clic todavía no se haya ejecutado.

Busca errores en la consola y observa si al pulsar cambian aria-expanded o las clases del menú. Si solo funciona después de hacer scroll, el bloqueo procede probablemente de JavaScript retrasado, no de CSS ausente.

Cambia una función cada vez. Excluir simultáneamente el script y el CSS impide saber qué reparación era realmente necesaria.

Regenerar y verificar en el orden correcto

Tras ajustar la lista segura, regenera el CSS utilizado, purga la página afectada y después la caché de CDN. Un constructor visual también puede necesitar regenerar sus archivos CSS. Evita borrar directorios de caché manualmente en producción: usa los controles admitidos y confirma que la URL nueva devuelve el archivo correcto.

Prueba en una sesión limpia, sin la barra de administración. Confirma que el menú abre y cierra con ratón y teclado, muestra el estado expandido correcto, conserva un foco visible, permite usar submenús, bloquea el scroll de fondo cuando corresponde y devuelve el foco de forma lógica al cerrar.

Revisa la cabecera en la portada, una entrada, la página de servicio y el checkout si comparten navegación. Si los nombres de clase son variables, existen varias plantillas de cabecera o el CSS cambia según la caché, conviene realizar una reparación técnica: el resultado debe sobrevivir a la siguiente regeneración, no limitarse a verse bien en una captura.

ANTES DE ENVIAR LA SOLICITUD

Preguntas frecuentes.

¿Pedís contraseñas en el formulario?+

No. El formulario público nunca solicita accesos. Los datos seguros se piden únicamente después de aprobar el alcance y el presupuesto.

¿Quién revisa la incidencia?+

La solicitud llega a Jordi Ensenyat, fundador de Code Barcelona y especialista WordPress con más de 15 años de experiencia.

¿Se cambia algo antes del presupuesto?+

No. Primero se revisan los síntomas visibles y se define el alcance. La intervención empieza tras la aprobación y con una vía de vuelta preparada.

¿Trabajáis con webs en inglés y fuera de España?+

Sí. WP Repair atiende incidencias WordPress y WooCommerce en inglés y español, con servicio remoto.

Evaluar mi incidencia