Mejorar el rendimiento de un WordPress es un trabajo en orden: primero se mide, después se ataca el servidor, luego la caché, después las imágenes y el código, y al final la base de datos. Saltarse el orden es lo que hace que la gente instale cinco plugins de optimización y termine con una web más lenta que antes. Esta guía va por ese orden, con los umbrales concretos que debes buscar en cada paso.
Paso 0: medir antes de tocar nada
Sin una medición de partida no sabrás si lo que haces mejora o empeora. Y hay dos tipos de datos que no son intercambiables: los de laboratorio (PageSpeed Insights, Lighthouse), que simulan una carga en condiciones fijas, y los de campo, que son los que Google recoge de usuarios reales de Chrome y los que cuentan para las Core Web Vitals.
Las tres métricas que importan y sus umbrales:
| Métrica | Qué mide | Bien | Mal |
|---|---|---|---|
| LCP | Cuándo se pinta el elemento principal | ≤ 2,5 s | > 4 s |
| INP | Cuánto tarda la web en responder a una interacción | ≤ 200 ms | > 500 ms |
| CLS | Cuánto se mueve el contenido mientras carga | ≤ 0,1 | > 0,25 |
| TTFB | Respuesta del servidor (no es Core Web Vital, pero manda sobre el LCP) | ≤ 300 ms | > 800 ms |
Para una foto rápida usa nuestro analizador de velocidad web, que te da el TTFB y el desglose de carga sin instalar nada, y contrasta con PageSpeed Insights para ver los datos de campo. Guarda una captura del antes: te va a hacer falta.
Mide siempre en móvil y con la caché de página desactivada en una primera pasada. La caché tapa problemas reales del servidor y te hará creer que todo está bien hasta que un usuario entre a una URL no cacheada.
El servidor: PHP-FPM, versión de PHP y OPcache
Aquí está la mayor parte del TTFB. Tres ajustes que casi nadie revisa:
Versión de PHP
Actualizar de PHP 7.4 a una versión 8.x moderna suele recortar el tiempo de ejecución de forma muy notable, y es gratis. Comprueba antes la compatibilidad de tema y plugins en un entorno de pruebas; los plugins abandonados son los que dan problemas.
OPcache
OPcache guarda el bytecode compilado de PHP en memoria para no recompilar en cada petición. Debería estar activo siempre. Con muchos plugins conviene subir opcache.memory_consumption a 256 MB y opcache.max_accelerated_files a 20.000, porque WordPress con veinte plugins supera fácil los diez mil ficheros y, si se llena, OPcache deja de cachear.
PHP-FPM: el número de hijos
PHP-FPM mantiene un grupo de procesos listos para atender peticiones. Si hay pocos, las peticiones hacen cola y el TTFB se dispara en picos; si hay demasiados, te quedas sin memoria. El cálculo aproximado: divide la RAM disponible entre el consumo medio de un proceso PHP (entre 60 y 120 MB en WordPress con plugins). Y ojo con pm = ondemand con un idle_timeout muy corto: en hostings compartidos provoca picos de varios segundos porque cada visita tiene que levantar un proceso nuevo.
Si tu plan de hosting no te deja tocar nada de esto, ya sabes cuál es el techo. En un VPS para WordPress estos parámetros se ajustan al proyecto; te explicamos cómo detectar el momento del cambio en esta guía sobre cuándo migrar a VPS.
Caché: las cuatro capas
«Instalar un plugin de caché» no es una capa, son varias y hacen cosas distintas:
- Caché de página: guarda el HTML ya generado. Es la que más impacto tiene. Un plugin como WP Rocket, LiteSpeed Cache o el propio NGINX FastCGI Cache.
- Caché de objetos persistente: Redis o Memcached guardan en memoria los resultados de consultas repetidas. Decisiva en WooCommerce y en el escritorio, que no se cachean como página.
- Caché de navegador: cabeceras
Cache-Controlpara que el visitante recurrente no vuelva a descargar CSS, JS e imágenes. - CDN: sirve los archivos estáticos desde el nodo más cercano. Útil si tienes público fuera de tu región; irrelevante si todos tus clientes están en Málaga y el servidor está en Madrid.
Regla de oro: un solo plugin de caché. Dos compitiendo generan conflictos difíciles de diagnosticar. Y excluye siempre del cacheo el carrito, la finalización de compra, el área de cliente y cualquier página con contenido personalizado.
Imágenes: donde está el LCP de casi todas las webs
En la mayoría de las webs que revisamos, el elemento que marca el LCP es una imagen de cabecera. Y suele ser un JPEG de 2.500 píxeles de ancho pesando 1,8 MB para mostrarse a 390 píxeles en un móvil. El orden de ataque:
- Redimensiona en origen. Ninguna imagen debería subirse con más ancho del que se va a mostrar en el layout más grande, con un margen para pantallas retina.
- Convierte a WebP o AVIF. WebP recorta habitualmente entre un 25 y un 35 % frente a JPEG con calidad equivalente; AVIF va más allá pero comprime más lento.
- Carga diferida por debajo del pliegue, y nunca en la imagen del LCP: si aplicas lazy load a la imagen de cabecera, empeoras la métrica.
- Declara ancho y alto en cada imagen. Es lo que evita que el contenido salte mientras carga y arruine el CLS.
- Precarga la imagen del LCP con
<link rel="preload">para que el navegador la pida antes de terminar de leer el CSS.
Un detalle que se pasa por alto: los sliders de cabecera. Cargan tres o cuatro imágenes grandes de las que el usuario ve una, arrastran una librería de JavaScript y empeoran LCP e INP a la vez. Casi siempre se pueden sustituir por una sola imagen.
CSS y JavaScript: menos, no comprimido
Minificar y combinar ayuda poco si el problema es que cargas 40 recursos. Lo que sí mueve la aguja es cargar solo lo necesario en cada página: los constructores visuales y muchos plugins encolan sus estilos y scripts en todo el sitio aunque solo se usen en una página. Con Asset CleanUp o Perfmatters puedes desactivarlos selectivamente por URL.
Después, el resto: difiere el JavaScript no crítico, retrasa la carga de scripts de terceros hasta la primera interacción (chats, mapas, píxeles de publicidad) y usa font-display: swap con las tipografías alojadas en tu propio dominio. Las fuentes externas añaden una conexión más y suelen bloquear el pintado.
Los scripts de terceros son también los principales responsables de un INP malo, porque ocupan el hilo principal justo cuando el usuario intenta pulsar algo.
Base de datos: la limpieza que nadie hace
Una base de datos hinchada no se nota en la portada cacheada, pero castiga cada petición no cacheada. Revisa esto:
- Opciones autocargadas. La tabla
wp_optionscarga en cada petición todo lo marcado como autoload. Si eso pesa más de 1 MB, tienes un problema. Suelen ser restos de plugins desinstalados. - Transitorios caducados que nunca se limpian.
- Revisiones de entradas. Limita con
define('WP_POST_REVISIONS', 5);en wp-config.php. - Tablas huérfanas de plugins que ya no usas, y metadatos sin entrada asociada.
- Tablas sin índices en instalaciones con WooCommerce y muchos pedidos: ahí una consulta mal indexada puede costar segundos.
Haz siempre una copia de seguridad antes de limpiar. Y no uses plugins que prometen «optimizar» borrando sin decirte qué borran.
Plugins que lastran (y cómo demostrarlo)
No es cuestión de cantidad sino de qué hace cada uno. Los sospechosos habituales: constructores visuales pesados, plugins de estadísticas que escriben en la base de datos en cada visita, buscadores en tiempo real, sliders, chats en vivo cargados desde el primer milisegundo y plugins de seguridad que analizan cada petición.
Para no discutir de oídas, instala Query Monitor en un entorno de pruebas: te dice qué consultas se ejecutan, cuánto tardan y qué plugin las lanza. Es la diferencia entre sospechar y saber. Si un plugin de estadísticas consume el 40 % del tiempo de generación, sustitúyelo por analítica del lado del cliente y recuperas ese tiempo entero.
El orden de ataque, resumido
- Mide en móvil y anota LCP, INP, CLS y TTFB.
- Actualiza PHP, comprueba OPcache y revisa la configuración de PHP-FPM.
- Deja un único plugin de caché de página bien configurado y añade caché de objetos si hay tienda.
- Arregla las imágenes, empezando por la del LCP.
- Descarga los CSS y JS que no se usan en cada página y aplaza los terceros.
- Limpia la base de datos y las opciones autocargadas.
- Sustituye los plugins que Query Monitor señale.
- Vuelve a medir y compara con la captura del principio.
Si has hecho los ocho pasos y el TTFB sigue por encima de 600 ms, el límite es el hardware o el plan de alojamiento. Ese es el momento de plantearse un cambio, no antes.
¿Prefieres que lo hagamos nosotros?
En LaudeMMedia optimizamos WordPress y administramos servidores desde hace más de 25 años. Auditamos, priorizamos por impacto real y te enseñamos el antes y el después con números. Empieza analizando tu web con el analizador de velocidad web y, si el problema es el servidor, mira nuestro VPS WordPress administrado. También puedes llamarnos al +34 910 059 091.
Preguntas frecuentes
¿Qué es un buen tiempo de carga para una web WordPress?
En Core Web Vitals el objetivo es un LCP igual o inferior a 2,5 segundos en móvil, un INP por debajo de 200 ms y un CLS por debajo de 0,1. Como referencia de servidor, un TTFB por debajo de 300 ms es bueno y por encima de 800 ms indica un cuello de botella en el alojamiento o en el código.
¿Cuántos plugins son demasiados en WordPress?
No hay un número. Veinte plugins ligeros y bien programados pueden rendir mejor que cinco pesados. Lo que importa es cuántas consultas lanza cada uno y si carga sus recursos en todo el sitio o solo donde hace falta. Query Monitor te da esa respuesta en minutos y evita discusiones basadas en intuiciones.
¿WebP mejora de verdad el rendimiento?
Sí. Frente a un JPEG de calidad equivalente, WebP suele recortar entre un 25 y un 35 % del peso, y en webs con muchas fotografías eso se traduce directamente en un LCP mejor. AVIF comprime aún más, aunque tarda más en generarse. Antes de convertir formatos, redimensiona: una imagen de 2.500 píxeles sigue sobrando aunque sea WebP.
¿Necesito un VPS para que mi WordPress vaya rápido?
Solo si el servidor es el límite. Optimiza primero caché, imágenes, base de datos y plugins, y vuelve a medir. Si con la web ya afinada el TTFB sigue alto, o tu panel registra topes de CPU, entonces el hosting compartido se te ha quedado corto y un VPS administrado sí resolverá el problema.
Deja una respuesta