Debuggeando WordPress, Elementor y un bug de Safari Mobile que nos hizo perder más de 10 horas

El problema

Durante el desarrollo del sitio de GUX nos encontramos con un problema crítico:
la página principal tardaba más de 40 segundos en cargar únicamente en Safari Mobile.

• En Android: funcionaba perfecto
• En desktop: sin problemas
• En Safari iOS: prácticamente inutilizable

La pantalla quedaba en blanco durante largos segundos, sin errores claros en consola.

El stack y las primeras sospechas

El sitio estaba construido con:

• WordPress
• Elementor
• Plugins de cache y optimización
• Efectos visuales modernos (gradientes, blur, animaciones)

Hicimos todo lo típico:

• Desactivar plugins uno por uno
• Revisar Lighthouse
• Limpiar cachés
• Cambiar hosting
• Buscar JavaScript bloqueante

Nada explicaba por qué solo Safari Mobile se comportaba tan mal.

Aislar el problema: WordPress limpio en AWS

Cuando ya no quedaban hipótesis claras, tomamos una decisión más radical.

Levantamos una nueva instancia en AWS, completamente limpia, y migramos el sitio parte por parte:

1. WordPress recién instalado
2. Sin plugins
3. Sin Elementor
4. Tema mínimo
5. Contenido agregado progresivamente

El objetivo era simple:
detectar exactamente en qué punto Safari Mobile dejaba de renderizar correctamente.

El descubrimiento

Con WordPress limpio:

• El sitio cargaba instantáneamente
• Safari Mobile no mostraba ningún problema

Pero al llegar al home, el bug reaparecía.

Y no solo ahí.

Nos dimos cuenta de que:

• El home usaba un fondo con gradientes y blur
• Otras secciones reutilizaban el mismo patrón visual
• Al activar ese diseño, Safari volvía a tardar más de 40 segundos

Ahí dejamos de culpar a plugins y empezamos a mirar CSS puro.

El verdadero culpable: un gradiente con blur

Este era el código responsable:

    .header-section-principal::before,
    .header-section-principal::after {
      content: '';
      position: absolute;
      border-radius: 9999px;
      background-color: #125c8c;
      z-index: 0;
    }
 
    .header-section-principal::before {
      width: 640px;
      height: 640px;
      bottom: 0;
      left: -400px;
      opacity: 0.5;
    }
 
    .header-section-principal::after {
      width: 720px;
      height: 720px;
      top: -200px;
      right: -200px;
      filter: blur(200px);
      opacity: 0.1;
    }
 
    .header-section-principal {
      background-color: rgba(2, 8, 23, 1);
    }

En Safari Mobile, la combinación de:

• pseudo-elementos gigantes
• filter: blur(200px)
• elementos fuera del viewport
• DOM inflado por Elementor

provocaba un bloqueo total del renderizado inicial.

Safari intentaba rasterizar y difuminar todo antes de pintar la primera frame.

El resultado

• Más de 40 segundos de carga
• Pantalla completamente en blanco
• Sin errores evidentes
• Página aparentemente “rota”

Al eliminar el blur o reemplazar el gradiente por una imagen optimizada:

• El tiempo de carga bajó a menos de 2 segundos
• Safari Mobile volvió a ser usable
• El diseño se mantuvo consistente

Lecciones aprendidas

1. Safari Mobile no renderiza como Chrome
2. Los gradientes con blur son extremadamente costosos
3. WordPress y Elementor amplifican problemas de render
4. El CSS puede romper una web tanto como el JavaScript
5. Migrar a un entorno limpio es la forma más rápida de encontrar la verdad

Conclusión

Este problema no se resolvió con prompts ni con magia.

Se resolvió con:

• aislamiento
• migraciones controladas
• pruebas sistemáticas
• entendiendo cómo renderiza Safari

A veces el problema no es WordPress.
No es Elementor.
No es el hosting.

Es un gradiente.
Con blur.
En Safari Mobile.

Debuggear performance es entender cómo piensa el navegador, no solo correr Lighthouse.