Optimización de velocidad WordPress

El problema

Un sitio web lento es plata que se pierde y en el caso de WordPress, un sitio WordPress lento suele tener un rendimiento paupérrimo. Cada segundo extra de carga en móvil baja notablemente la conversión, y desde que Core Web Vitals es señal de ranking (SEO), también baja el tráfico. Notar los problemas de velocidad es algo interesante, lo normal siempre es simplemente revisar números (PageSpeed) o “cuánto me demora” en cargar en el teléfono o PC y esto si bien no es erróneo, no toma en cuenta la experiencia de usuario (secciones que se mueven, mala visualización) que suelen acompañar los problemas de carga y además los problemas de velocidad de carga suelen tener dos trampas:

La primera: la causa casi nunca es la que se presume. La respuesta típica es instalar un plugin de caché con la configuración por defecto y esperar que “arregle solo” y asumir que el problema mayor es el servidor / hosting. Solo atacar con un plugin de caché realmente no genera un gran impacto y suele provocar muchos problemas de visualización cuando el problema real está en otra parte: render bloqueante, imágenes pesadas, fonts externas o la base de datos saturada. Sin diagnóstico real (qué bloquea el LCP, qué script dispara el INP, qué CSS es crítico por template), cualquier optimización es más cercana a adivinar.

La segunda trampa es perseguir el 100 de PageSpeed como si fuese el objetivo. No lo es. El número solo sirve cuando hay un objetivo de negocio detrás que lo justifique: vender más, recibir más consultas, rankear mejor. Optimizar correctamente se hace por un objetivo y requiere una visión global más amplia que un número.

Core Web Vitals

Desde que Core Web Vitals es señal de ranking de Google e influye en tu posicionamiento (SEO), la velocidad dejó de ser solo experiencia de usuario y el LCP, INP y CLS medidos en producción impactan directamente en tu web y negocio.

Mido y reporto en móvil porque es donde Google evalúa el sitio y donde más se nota la lentitud usualmente, en escritorio se mide y mejora también.

Qué hago

• Medición antes y después: cada URL que optimizo se mide mínimo 3 veces en producción bajo las mismas condiciones y te informo la media. Una sola corrida de PageSpeed varía demasiado y engaña tanto para bien como para mal.
• Critical CSS por template: extracción con pipeline propio (home, categoría, producto) y personalizado, no uso un plugin genérico de “optimización automática”.
• Eliminación de CSS/JS bloqueante identificado midiendo la carga real en navegadores de escritorio y móvil y optimizado para no romper ninguna funcionalidad básica ni elemento visual de la web.
• Imágenes optimizadas: conversión a AVIF/WebP con fallback, lazy loading correcto, dimensiones explícitas para evitar layout shift.
• Fonts self-hosted con preload, eliminando el bloqueo de fuentes externas (Google Fonts u otras) sobre el render inicial.
• Minificación y compresión Brotli a nivel servidor: configuración quirúrgica, no plugin de caché genérico.
• Staging antes de producción: backups completos y cambios incrementales con validación en cada paso.

Si solo necesitas velocidad para WordPress: WP Rápido es mi servicio de optimización de velocidad de carga específico a WordPress: el plan depende del tamaño del sitio y de los problemas que aparezcan al medirlo. Si en cambio la velocidad es parte de un trabajo más amplio o el sitio pide algo a medida (una tienda con miles de productos, un tema hecho en casa, un servidor que hay que reconfigurar), en ese caso tomo ese proyecto por acá. Si tu caso cabe en WP Rápido te lo digo en el diagnóstico y seguimos por ahí.

Lo que queda fuera: si lo que el sitio necesita es rehacerse de cero entonces ya no hablamos de un proceso de optimización sino que hablamos de desarrollo WordPress. Te comunicaré oportunamente si este es tu caso en lugar de forzar parches u optimizaciones sobre una base que realmente no da para más. El diagnóstico es importante para esto y es importante mencionar también que no necesariamente WordPress es la solución a tus necesidades y también podría ser un trabajo de diseño web.

Caso real

Este caso es la prueba de que lo que importa no es el número sino lo que cambia detrás. El caso de rescate más duro del portfolio es 2eme, un sitio de servicios WordPress que pasó de 45 a 94 de PageSpeed móvil, con la home bajando de 13,3s a 2,3s de LCP y la peor página de 28,2s a 2,2s, medido con medianas de mínimo 3 corridas para no reportar ruido.

En PMK Autopartes bajé el LCP de móvil de 11,0s a 6,14s (-44%) con mi pipeline propio de Critical CSS por template y en Comercial Moya, −92% en la respuesta del servidor (2,60s a 0,20s) tras dar con la causa raíz (bots saturando PHP-FPM) más el upgrade de PHP 7.4 a 8.2, con el sitio nuevo levantado en staging aislado, sin cortar producción.

Tres rescates publicados con tres problemas distintos (LCP fuera de control, CSS bloqueante, servidor saturado) y el mismo método: medir en serio, dar con la causa raíz y verificar que la mejora se sostenga. Un sitio que carga rápido no es un logro de vanidad: la lentitud en móvil cuesta ventas y bajar estos números es dejar de perderlas.

La velocidad además se sostiene: un sitio optimizado que nadie mantiene vuelve a degradarse con cada plugin y actualización. Para eso existe el plan de mantención mensual.