La investigación de una capa de caché oculta: optimización de rendimiento para Thomas Fragoso
Un proyecto de Core Web Vitals para un tatuador que atiende en Málaga terminó convirtiéndose en una búsqueda de una capa de caché Varnish que nadie sabía que existía — y que ocultaba la mejora de rendimiento real ya implementada.
El problema
Thomas Fragoso es tatuador y atiende en Málaga, España — su sitio necesitaba mejores Core Web Vitals para el público europeo, sin cambiar de servidor (Cloudways, con un datacenter en EE. UU., ya era una decisión cerrada del cliente). Punto de partida: rendimiento móvil de 56/100, LCP crítico de 19,8 segundos en la página `/espanol/`, la landing principal para la captación de leads.
Lo que no podía romperse
WP Rocket, GTM y Facebook Pixel ya estaban activos y alimentando los anuncios del cliente — la regla del proyecto era optimizar, nunca eliminar. El formulario de captación para la lista de espera era la conversión principal y debía sobrevivir a cada cambio, probado después de cada etapa.
Las mejoras sin depender de una licencia
Imagen del LCP comprimida de 627KB a 80KB. Feed de Instagram diferido mediante IntersectionObserver, cargando solo cuando la sección entra en pantalla. Caché de objetos Redis instalada. Base de datos limpiada de 1.171 revisiones y 28 transients. Como la licencia de WP Rocket de la cuenta anterior había expirado, un Critical CSS manual mediante un mu-plugin propio resolvió el CSS bloqueante sin depender de un plugin de pago — 100% reversible.
La investigación
Cuando el cliente compró su propia licencia de WP Rocket y la función oficial Remove Unused CSS se ejecutó por primera vez, falló en silencio — y el sitio volvió a servir CSS bloqueante, como si todo el trabajo anterior hubiera desaparecido. La causa no estaba en WP Rocket, ni en Redis, ni en Cloudflare: era una capa de caché Varnish del propio Cloudways, nunca purgada durante este proyecto, que servía una versión antigua y rota de la página. Se localizó accediendo directamente a la IP del servidor (evitando Cloudflare) y se confirmó mediante `varnishadm` — resuelta sin necesitar acceso root.
Resultado
Después de purgar Varnish: el LCP móvil bajó de 19,8s al rango de 13–14s en las mediciones oficiales de PageSpeed Insights, y en escritorio el LCP pasó de 1,4s a 1,9s, dentro del margen de ruido — una medición manual con GTmetrix (metodología paralela, sin el throttling agresivo de PSI) registró un 98% de rendimiento y un LCP de 838ms en `/espanol/`. El formulario de captación, GTM y Facebook Pixel se confirmaron intactos en cada etapa.