Un sitio WordPress más rápido empieza por encontrar la capa lenta
Una página WordPress lenta puede repartir su tiempo entre varios lugares: descargar imágenes, esperar a PHP, consultar la base de datos o llamar a otro servicio. Instalar otro plugin de caché sin identificar la demora puede ocultar un problema y crear un segundo. Empiece con un recorrido repetible y un conjunto reducido de mediciones.
La conclusión práctica
Mida el recorrido lento real, distinga las respuestas en caché de las personalizadas, cambie una capa cada vez y confirme tanto la velocidad como la corrección antes de mantener una optimización.
Convierta «el sitio va lento» en una observación reproducible
Elija una página y describa con precisión el estado del visitante. Una primera visita a un artículo, un comprador que vuelve y abre un carrito y un administrador que guarda una entrada ponen a prueba partes distintas de WordPress. Anote la URL, si la persona ha iniciado sesión, la hora aproximada, el dispositivo y la red de acceso. Repita el mismo recorrido en lugar de comparar de memoria páginas no relacionadas. Mantenga los datos privados de la cuenta fuera de las capturas de pantalla y de los diagnósticos compartidos.
Separe la espera de la primera respuesta del trabajo realizado después de recibirla. Un navegador puede recibir el HTML rápidamente y aun así tardar varios segundos en descargar imágenes sobredimensionadas o ejecutar scripts de terceros. A la inversa, una página visualmente sencilla puede esperar a un trabajo lento del servidor. Anote juntos la duración de la respuesta, los bytes transferidos y las solicitudes fallidas. Una puntuación aislada es menos útil que saber qué solicitud retrasa la parte de la página que necesitan los visitantes.
| Observación | Primera capa que investigar | Comparación útil |
|---|---|---|
| El HTML llega tarde | PHP, base de datos o llamadas externas | La misma URL con el mismo estado de sesión |
| El HTML es rápido, la página sigue pesada | Imágenes, fuentes y scripts del navegador | Tamaño de transferencia y cascada de solicitudes del navegador |
| Solo los visitantes con sesión iniciada van lentos | Trabajo personalizado de la aplicación | Recorridos anónimo y con sesión iniciada por separado |
| Aparece una demora tras una actualización | Componente o configuración modificados | La versión registrada y una reversión controlada |
Sepa qué reutiliza realmente una caché
La caché de páginas puede reutilizar una respuesta generada en lugar de reconstruirla en cada solicitud. Resulta útil para contenido público que se ve igual para muchos visitantes. Necesita reglas deliberadas para páginas de inicio de sesión, carritos, pago, pantallas de cuenta y otras respuestas personalizadas. Una página rápida que muestra información errónea del cliente es una optimización fallida. Pruebe el comportamiento de la caché en sesiones de navegador distintas y confirme que las páginas privadas siguen el tratamiento previsto por la aplicación.
La caché de objetos reutiliza datos de la aplicación y es una capa distinta de la caché de una página completa. La caché del navegador determina qué puede reutilizar el visitante localmente. Una caché de distribución de contenido puede situarse en otro punto del recorrido de la solicitud. Dibuje las capas que existen realmente en su instalación, incluido su comportamiento de caducidad y purga. No dé por hecho que un panel de control, un plugin o un rango de alojamiento incluye un servicio de caché concreto salvo que su configuración disponible lo confirme.
Para un artículo público, compare la primera solicitud tras una purga con las posteriores. Una gran diferencia puede indicar que se reutiliza el trabajo de generación; no demuestra qué capa realizó la reutilización. Consulte los diagnósticos de caché o las cabeceras de respuesta pertinentes cuando estén disponibles. Para una tienda, pruebe por separado un cambio de precio de un producto y un carrito actualizado. La invalidación correcta importa tanto como un resultado de tiempo con la caché caliente.
Rastree el trabajo sin caché antes de añadir recursos
Revise los componentes implicados en el recorrido lento. Un tema puede desencadenar consultas repetidas, un plugin puede llamar a un endpoint remoto y una tarea programada puede competir con las solicitudes normales. Use diagnósticos adecuados a su entorno y retire los diagnósticos temporales tras la investigación. Prefiera una copia de staging para aislar componentes. Cambiar varios plugins en un sitio de producción con mucho tráfico dificulta la interpretación del resultado y puede alterar el contenido o los pedidos.
El trabajo de base de datos merece su propia investigación cuando las solicitudes no cacheadas siguen siendo lentas. Registre qué consultas son frecuentes o costosas y si la aplicación repite la misma búsqueda innecesariamente. Un cambio de índice, un resultado de consulta más pequeño o un comportamiento de plugin corregido pueden ayudar más que CPU adicional. Si la base de datos está esperando bloqueos, añadir trabajadores PHP puede aumentar la contención en lugar de aumentar el rendimiento útil. Interprete los recuentos de procesos junto con la duración de las respuestas y las solicitudes exitosas.
Los recursos de alojamiento siguen importando cuando las mediciones muestran una restricción real. Considere la memoria usada por la aplicación completa, el trabajo concurrente de PHP, la actividad de la base de datos y el crecimiento del almacenamiento. Las tarjetas de alojamiento web de HM Bastion describen límites de sitio web, almacenamiento y base de datos; no son una cifra publicada de compradores concurrentes garantizados. Si un proyecto necesita servicios personalizados o control del sistema operativo, compare un VPS usando sus recursos reales y la responsabilidad de administración que conlleva.
Mantenga un cambio solo tras comprobar todo el recorrido
Anote el cambio propuesto y el resultado que espera antes de aplicarlo. Por ejemplo, redimensionar imágenes públicas sobredimensionadas debería reducir los bytes transferidos sin cambiar el contenido del artículo. Excluir las páginas de cuenta de una caché de página debería preservar la privacidad aunque esas páginas sigan siendo más lentas que el contenido público. Conserve una copia de recuperación actual y sepa cómo revertir los cambios de configuración. Use las mismas condiciones de medición después del cambio para que la comparación siga siendo significativa.
- Compruebe una página pública tanto con caché vacía como con caché caliente.
- Compruebe el inicio y cierre de sesión, las páginas de cuenta, la búsqueda y cualquier carrito de compra.
- Confirme que los cambios de contenido se hacen visibles dentro del tiempo previsto.
- Compare los errores y las respuestas exitosas, así como la velocidad de la página.
- Registre la configuración, la versión del componente y el procedimiento de reversión.
Mantenga un breve registro de rendimiento tras la mejora inmediata. Anote el tiempo normal de generación de página, los recorridos pesados habituales y la capacidad libre observada durante los picos ordinarios. Revise esas observaciones tras un cambio de tema, una importación grande o una nueva campaña. El resultado útil es un sitio cuyo comportamiento usted entiende y puede mantener, en lugar de una colección de plugins superpuestos cuya velocidad aparente desaparece cuando un visitante inicia sesión.
