Existe toda una industria de contenido en torno a la optimización de WordPress. «10 plugins para acelerar tu sitio», «5 trucos secretos para que tu sitio vuele», «el plugin de caché definitivo». La mayoría es ruido.
Después de optimizar decenas de sitios WordPress, lo que he aprendido es que la mayoría de los problemas de rendimiento provienen de 3 fuentes. Y que la mayoría de los «trucos» que se leen por internet o no suponen una diferencia medible, o son directamente contraproducentes.
Los Core Web Vitals que importan en 2026
Google cambió los Core Web Vitals en 2024. Hoy, los tres que cuentan son:
- LCP (Largest Contentful Paint): tiempo hasta que aparece el elemento visible más grande. Objetivo: menos de 2,5 segundos
- INP (Interaction to Next Paint): tiempo de respuesta a las interacciones del usuario. Objetivo: menos de 200 ms
- CLS (Cumulative Layout Shift): estabilidad visual durante la carga. Objetivo: menos de 0,1
INP reemplazó a FID en marzo de 2024 y es significativamente más exigente. Muchos sitios que tenían FID en verde ahora tienen INP en rojo.
Importante: Google mide los Core Web Vitals con datos de usuarios reales (CrUX), no con pruebas sintéticas. Tu PageSpeed Insights puede mostrar 95 en pruebas de laboratorio, pero si los usuarios reales tienen dispositivos lentos y conexiones 4G, su experiencia es la que cuenta.
Los 3 problemas que resuelven la mayoría de los casos
1. Alojamiento inadecuado
Este es, con diferencia, el problema más subestimado. Un sitio WordPress en un alojamiento compartido barato de 3 €/mes nunca tendrá buen rendimiento, independientemente de lo que hagas en el código.
Para un sitio profesional, el mínimo decente es un alojamiento gestionado con PHP 8.2+, MySQL 8 o MariaDB 10.6+, Redis o Memcached para la caché de objetos, HTTP/3 y soporte nativo de caché a nivel de servidor. Esto suele costar entre 15 y 40 € al mes y marca una diferencia drástica.
Para proyectos más exigentes, VPS o servidor dedicado con LiteSpeed, Nginx con caché FastCGI, o stacks especializados (Cloudways, Kinsta, WP Engine).
2. Imágenes sin optimizar
En casi todos los sitios que audito, las imágenes representan entre el 60 y el 80 % del peso total de la página. Y habitualmente, muchas imágenes se sirven en el formato incorrecto, con el tamaño incorrecto o sin lazy loading adecuado.
En 2026, el estándar mínimo es:
- Formato WebP o AVIF (nunca JPEG o PNG para fotografía web)
- Imágenes responsive con
srcsetysizescorrectos - Lazy loading nativo con
loading="lazy"(excepto el LCP, que debe sereager) - Compresión agresiva: una calidad de 75-85 es visualmente indistinguible en fotografía
- Dimensiones correctas en el código para evitar CLS
3. Demasiados plugins
Regla general: cada plugin activo añade entre 50 ms y 300 ms al tiempo de carga, según lo que haga y lo bien que esté desarrollado. Un sitio con más de 40 plugins es físicamente incapaz de tener buen rendimiento.
Mi regla personal en proyectos a medida: máximo 15 plugins, cada uno con una función clara y justificada. Las funcionalidades sencillas (sliders, acordeones, formularios básicos, compartir en redes sociales) deben implementarse en el tema, no mediante plugins.
Por qué los plugins de caché no son suficientes
Mucha gente instala WP Rocket o W3 Total Cache y cree que su problema de rendimiento está resuelto. No es así.
Los plugins de caché resuelven un problema concreto: evitar que WordPress genere la página dinámicamente en cada petición. Esto es útil, pero no ayuda con el LCP causado por imágenes mal optimizadas, el INP causado por JavaScript pesado, ni el CLS provocado por la falta de dimensiones en los elementos multimedia.
La caché es parte de la solución. No es la solución.
Rendimiento y accesibilidad: dos caras de la misma moneda
Un punto que rara vez se comenta: la optimización del rendimiento y la accesibilidad van de la mano. Un sitio rápido con una estructura semántica limpia, lazy loading correcto y JavaScript no bloqueante es también un sitio más accesible para usuarios con tecnologías de asistencia.
Para proyectos que requieren conformidad con WCAG 2.1 AA (cada vez más obligatoria en sectores públicos y regulados), la optimización del rendimiento debe plantearse junto a la accesibilidad desde el inicio. Es posible obtener puntuaciones altas en ambos aspectos, pero requiere disciplina desde la arquitectura inicial del tema.
El checklist que uso antes de entregar cualquier proyecto
- Alojamiento con PHP 8.2+, MySQL 8+, HTTP/3
- Caché de objetos activa (Redis o Memcached)
- Caché de página a nivel de servidor (LiteSpeed, Nginx FastCGI) o plugin dedicado
- Imágenes en WebP/AVIF, con srcset y dimensiones explícitas
- Fuentes con
font-display: swapy preload de la fuente principal - CSS crítico en línea, el resto con
media="print" onload - JavaScript no crítico con
defero carga condicional - Sin plugins redundantes o duplicados
- HTTPS con HSTS activo
- Compresión Brotli o Gzip
- CDN para activos estáticos (Cloudflare como mínimo)
- Core Web Vitals en verde en PageSpeed Insights y CrUX
- Puntuación de accesibilidad acorde a los requisitos del proyecto
Herramientas que uso para medir
- PageSpeed Insights: datos de laboratorio + datos de usuarios reales (CrUX)
- WebPageTest: análisis detallado por petición, filmstrip visual
- Chrome DevTools Lighthouse: auditoría local
- Google Search Console: Core Web Vitals en usuarios reales, por URL
- GTmetrix: panel histórico y comparativas
- Query Monitor (plugin): identificar consultas lentas y hooks pesados
Conclusión: el rendimiento no es magia, es disciplina
Los sitios rápidos no se construyen con plugins mágicos ni trucos secretos. Se construyen prestando atención al detalle en cada decisión: elección del alojamiento, arquitectura del tema, disciplina en el uso de plugins, optimización de los medios y pruebas continuas.
Si tu sitio es lento y quieres un diagnóstico técnico, puedo realizar una auditoría de rendimiento. Recibirás un informe con los problemas identificados, las prioridades y el impacto estimado de cada optimización.
