Performance

Performance de WordPress enterprise que aguanta el tráfico real

La velocidad es una propiedad de cómo está construido el sitio, no un plugin que se agrega después. Trabajamos el tema, las consultas, el pipeline de assets y la capa de caché para que los Core Web Vitals sigan en verde mucho después de la semana del lanzamiento.

Qué construimos

Siete lugares donde la performance de WordPress se gana o se pierde

Los sitios enterprise rara vez son lentos por un solo motivo. Son lentos porque siete decisiones se tomaron cada una por separado. Estas son las que tomamos de forma deliberada.

Marcado liviano y un render path sin bloqueos

HTML semántico sin anidar contenedores decorativos, y bloques construidos para que nada en el camino crítico demore el primer render. El marcado que generan los page builders es la causa más común de un sitio enterprise lento en WordPress, y no hay capa de caché que lo deshaga.

Disciplina en la carga de scripts y estilos

Los assets se encolan con async o defer donde el grafo de dependencias lo permite, y nada que no sea esencial se carga de forma global. Evitamos jQuery salvo que alguna dependencia lo exija. El bundling pasa por Vite con Tailwind JIT, así el CSS que se publica es el CSS que la página usa.

Consultas a la base de datos que escalan con el contenido

WP_Query se afina en lugar de darse por buena, se eliminan las consultas repetidas y el trabajo pesado queda fuera de pre_get_posts. La consulta que anda bien con 500 posts es la que falla con 50.000.

Entrega de imágenes y tipografías sin saltos de layout

Las imágenes se comprimen en origen y se sirven en WebP o AVIF donde el hosting y el navegador lo soportan, con width y height explícitos para que nada salte mientras la página se pinta. Las tipografías se precargan cuando hace falta, con font-display en swap.

Peso de terceros limitado a lo que se lo gana

Las librerías de JavaScript se agregan con cuentagotas y no por costumbre, porque cada dependencia es peso que el navegador paga en cada visita. Las imágenes por debajo de la primera pantalla se cargan de forma diferida, así el ancho de banda inicial va a lo que el lector ya está viendo.

Caché y CDN acordes a tu hosting

WordPress VIP te da CDN y caché de página completa, Kinsta suma caché a nivel servidor, Ymir es serverless detrás de un CDN de borde y DigitalOcean con Trellis cachea en el servidor. Configuramos según la plataforma en vez de instalar el mismo plugin en todos lados.

Números que el desarrollo tiene que cumplir

Se valida contra umbrales, no contra impresiones: LCP por debajo de 2,5 segundos, CLS por debajo de 0,1 y TBT por debajo de 300 milisegundos, medidos en mobile y con la conexión limitada, porque así es como llega la mayor parte del tráfico.

Evidencia

Qué logró el marcado liviano en una plataforma de ciberseguridad

ThreatModeler, una empresa enterprise de modelado de amenazas, corría sobre Elementor. El page builder inflaba los tiempos de carga y hundía los Core Web Vitals. Reconstruimos el frontend con marcado liviano de Gutenberg. Resultados medidos en su plataforma:

40%+

de mejora en la performance del sitio tras reemplazar el marcado del page builder por Gutenberg liviano

En cada release

los Core Web Vitals siguen en verde desde la migración, no solo el día del lanzamiento

3x

más rápido el ciclo de campañas, porque el sistema de bloques liviano es el que edita marketing

Cómo trabajamos

Tres fases, porque una auditoría no es una solución

Una auditoría te dice qué está lento hoy. Estas fases evitan que vuelva a estarlo dentro de dos trimestres.

Desarrollo

Las restricciones de performance se aplican mientras se escribe el código. Los scripts no esenciales nunca se cargan de forma global, los bloques salen sin assets que bloqueen el render, y el diseño se optimiza antes de llegar al navegador: sin elementos innecesarios en el archivo de Figma y con las imágenes comprimidas desde el original.

QA antes de salir a producción

Query Monitor corre en desarrollo y staging para exponer lo que un puntaje sintético esconde: consultas lentas o repetidas a la base de datos, estilos que cargan donde no se usan, hooks con alto tiempo de ejecución y problemas en AJAX, la REST API y los transients. Después validamos en PageSpeed Insights, GTmetrix y WebPageTest.

Después del lanzamiento

Los Core Web Vitals se revisan en Search Console con datos de campo reales, las acciones correctivas se documentan en vez de recordarse, y Lighthouse CI puede frenar cada pull request para que una regresión se detecte en la revisión y no la descubran tus usuarios.

Lo que los equipos enterprise nos preguntan sobre performance en WordPress

Vale la pena leerlo aunque nunca nos contrates.

Lecturas relacionadas

Seguí leyendo sobre performance en WordPress

Práctica de optimización, herramientas de monitoreo y qué cambia cuando el tráfico escala.

El siguiente paso

Pedí una auditoría de performance de WordPress

Medimos LCP, CLS y TBT en mobile, revisamos tu configuración de caché y CDN contra la plataforma en la que corrés, y te decimos qué está frenando al sitio. Los hallazgos son tuyos en cualquier caso.

Pedir una auditoría de performance Hablar con un ingeniero de WordPress