Para acelerar WordPress, primero identifica qué está lento. Una respuesta tardía del servidor, una imagen principal pesada y un checkout lento necesitan soluciones distintas. Estos cinco pasos te ayudarán a medir una referencia, actualizar con cuidado, investigar procesos costosos, mejorar la entrega y comprobar el resultado.
El objetivo es que el sitio cargue y responda bien para sus visitantes. Una puntuación de velocidad es una pista de diagnóstico que debes considerar junto al funcionamiento de formularios, compras y navegación.
- Medir antes de cambiar
- Actualizar WordPress y elegir una versión de PHP compatible
- Localizar plugins, consultas y tareas costosas
- Mejorar caché, imágenes y recursos
- Repetir las pruebas y observar usuarios reales
1. Mide el rendimiento antes de cambiar nada
Elige páginas representativas: inicio, una entrada y una página importante de servicio o producto. Anota la URL, el dispositivo, la ubicación de prueba cuando esté disponible, la fecha y si has iniciado sesión. Repite varias veces en las mismas condiciones y conserva un resultado típico, no solo el más rápido.
PageSpeed Insights ofrece diagnósticos de laboratorio y, cuando hay muestras suficientes, datos de usuarios reales de Chrome. El laboratorio ayuda a investigar cambios de inmediato. Los datos reales cubren los 28 días anteriores; revisa si corresponden a la URL o a todo el sitio. La ausencia de datos indica falta de muestras, no un resultado aprobado. Consulta la explicación de Google.
Las tres Core Web Vitals miden carga, respuesta y estabilidad visual. Sus umbrales se evalúan en el percentil 75 de visitas reales, por separado en móvil y escritorio:
| Métrica | Qué mide | Umbral bueno |
|---|---|---|
| Largest Contentful Paint (LCP) | Cuándo aparece el contenido visible principal | 2,5 segundos o menos |
| Interaction to Next Paint (INP) | Rapidez de la respuesta visual a las interacciones | 200 milisegundos o menos |
| Cumulative Layout Shift (CLS) | Desplazamientos inesperados del contenido | 0,1 o menos |
Utiliza el informe para decidir por dónde empezar:
- Espera larga hasta recibir el documento: revisa redirecciones, caché de página, trabajo de la aplicación y respuesta del alojamiento. TTFB es útil, aunque no es una Core Web Vital.
- El contenido principal aparece tarde: identifica el elemento LCP y busca imágenes grandes, fuentes tardías o recursos que bloqueen la presentación.
- Los clics o la escritura responden lentamente: investiga tareas largas de JavaScript y scripts externos durante esa interacción.
- El diseño se mueve: comprueba dimensiones de imágenes, cambios de fuentes y elementos insertados después de empezar a dibujar la página.
- Solo está lento el panel, la cuenta o el checkout: mide ese proceso por separado. Una página de inicio rápida desde caché no demuestra que las solicitudes dinámicas también lo sean.
2. Actualiza WordPress y utiliza PHP con soporte
Mantén WordPress, temas y plugins actualizados mediante cambios controlados. Crea una copia de seguridad, confirma cómo restaurarla y prueba primero los cambios que puedan afectar funciones importantes. Revisa las notas de versión y los requisitos de compatibilidad.
Una actualización puede corregir problemas de rendimiento o cambiar el comportamiento. Mide el resultado en lugar de asumir que siempre mejorará la velocidad. Atiende las correcciones de seguridad manteniendo una vía de recuperación.
Utiliza Salud del sitio como inventario y sistema de avisos
Abre Herramientas → Salud del sitio. Las pantallas de Estado e Información ayudan a detectar advertencias y registrar la configuración. Consulta al proveedor cuando las recomendaciones afecten al servidor. Esta herramienta no es una prueba de velocidad ni detecta todos los problemas.
Elige una rama de PHP con soporte y comprueba la compatibilidad
Utiliza una versión con soporte compatible con WordPress, el tema, los plugins y el código propio. Prefiere soporte activo cuando todo el conjunto esté preparado. La página de requisitos de WordPress de referencia recomienda PHP 8.3 o superior; eso no garantiza que cada extensión admita todas las versiones nuevas.
Con fecha de referencia 27 de septiembre de 2026, PHP 8.2 recibía solo correcciones de seguridad hasta el 31 de diciembre de 2026. PHP 8.3 también estaba en esa fase, mientras 8.4 y 8.5 tenían soporte activo. Consulta la tabla vigente de PHP al planificar la actualización.
- Revisa la compatibilidad de WordPress, el tema, los plugins esenciales y el código propio.
- Prueba la versión propuesta en un entorno de pruebas, incluidos formularios, acceso, checkout y tareas programadas.
- Revisa errores y avisos de funciones obsoletas en los registros de PHP. Un aviso señala código que necesita atención, pero no demuestra por sí solo lentitud.
- Confirma extensiones y ajustes con el proveedor, publica el cambio probado y repite la medición inicial.
Revisa PHP sin vaciar .htaccess
La ubicación de los ajustes depende de cómo se ejecute PHP. Las directivas en .htaccess pueden ser válidas con PHP como módulo de Apache. Los archivos .user.ini corresponden a CGI/FastCGI. Algunos proveedores ofrecen controles propios.
Apache documenta un costo de procesamiento de .htaccess, pero quitar unas directivas no demuestra una mejora medible ni elimina esas consultas. No borres reglas solo por estar fuera del bloque estándar de WordPress: pueden gestionar redirecciones, accesos o configuración del alojamiento.
Consulta qué método corresponde, guarda una copia y modifica solo ajustes que comprendas. Comprueba los valores efectivos y el funcionamiento después. Aumentar memoria o tiempos máximos no sustituye a investigar el trabajo costoso.
3. Localiza plugins, consultas y tareas costosas
No existe una cantidad universal de plugins «segura». Importa lo que hace cada uno: consultas, solicitudes externas, recursos públicos y tareas programadas. Una sola función pesada puede influir más que varias utilidades pequeñas. Quitar un plugin sin uso es razonable, pero no prueba una mejora de velocidad.
Haz un inventario y busca funciones duplicadas. Query Monitor ayuda a examinar consultas lentas, errores PHP y solicitudes HTTP. Para problemas bajo carga, consulta al proveedor sobre análisis de la aplicación y recursos. Las solicitudes de diagnóstico con sesión iniciada pueden comportarse de forma distinta a las visitas desde caché.
- Reproduce la acción lenta y guarda el diagnóstico inicial.
- En pruebas, desactiva una función sospechosa por vez, respetando sus dependencias y las necesidades del negocio.
- Repite la acción y compara tiempos, errores y comportamiento. Reactiva lo que no haya demostrado ser la causa.
- Si la evidencia apunta a la base de datos, revisa tareas, registros crecientes, opciones de carga automática y consultas repetidas. Identifica quién utiliza los datos antes de borrarlos.
Crea una copia antes de limpiar la base de datos. Una tabla o una opción desconocida no necesariamente está sin uso; eliminar información activa puede romper funciones. El diagnóstico y la recuperación deben preceder a cualquier herramienta de limpieza.
4. Mejora la caché, las imágenes y los recursos
Adapta la caché al tipo de solicitud
La caché de página completa sirve HTML reutilizable sin generarlo para cada visita. Una caché persistente de objetos reduce consultas de datos en solicitudes dinámicas, pero no reemplaza la caché de página. Revisa qué ofrece el alojamiento y comprueba aciertos, exclusiones y actualización del contenido. La guía de caché de WordPress explica estas capas.
Las páginas personalizadas necesitan otro tratamiento. En WooCommerce, excluye carrito, checkout y cuenta de la caché compartida y respeta las sesiones. Sigue las indicaciones de WooCommerce y prueba con sesiones separadas. Nuestra guía de rendimiento de WooCommerce amplía estos puntos.
Una CDN acerca los recursos almacenados a los visitantes, pero no corrige automáticamente consultas lentas ni llamadas a servicios externos. Investiga las respuestas sin caché con tiempos y datos de CPU, memoria, disco o límites de procesos antes de contratar un plan mayor.
Prioriza lo que los visitantes ven y utilizan
- Imágenes: ajusta dimensiones, comprime y reserva su espacio visual. Aplica carga diferida a imágenes adecuadas fuera de la primera pantalla, pero evita hacerlo con la imagen responsable del LCP. La guía de Google sobre LCP explica la importancia del descubrimiento y la prioridad de carga.
- JavaScript y CSS: elimina funciones y etiquetas realmente innecesarias. Prueba cada cambio de carga diferida: los ajustes agresivos pueden afectar menús, formularios, consentimiento y checkout.
- Fuentes: revisa las familias y los grosores descargados por página y comprueba el resultado en móvil.
- Contenido incrustado: considera cargar videos u otros elementos pesados desde una vista previa cuando el usuario los necesite, manteniendo su acceso.
5. Repite las pruebas y observa usuarios reales
Después de cada cambio significativo, repite las mismas URLs y condiciones. Guarda un registro breve con cambios, mediciones y ajustes revertidos. Distingue entre caché fría y caliente.
- Revisa las páginas afectadas en móvil y escritorio, incluida la navegación.
- Prueba formularios, acceso y búsqueda. En tiendas, utiliza pedidos de prueba controlados y comprueba cuenta y carrito.
- Revisa errores del navegador y PHP, y verifica analítica y consentimiento cuando corresponda.
- Limpia las cachés afectadas y confirma que se entrega el contenido actualizado.
- Revisa las métricas reales a medida que se acumula tráfico. La ventana móvil de 28 días de PageSpeed Insights seguirá incluyendo visitas anteriores al cambio durante un tiempo.
Mantén el sitio estable para observar resultados. Prioriza mejoras repetibles en páginas y recorridos importantes antes que una puntuación perfecta en una sola prueba.
¿Necesitas ayuda para identificar el problema?
Nuestro servicio de optimización de WordPress parte de los problemas de tu sitio y de las prioridades acordadas. Consulta el alcance y los siguientes pasos en la página del servicio.