La mayoría de los problemas de rendimiento de WordPress se atribuyen al entorno de alojamiento, que a veces es el diagnóstico correcto. Sin embargo, las dependencias de terceros también dan la misma señal de alarma, aunque están fuera del control del proveedor de alojamiento.
Las pasarelas de pago que se quedan sin tiempo de espera, las APIs de envío que no responden y los scripts de analíticas lentos son fallos ante los que solo puedes intentar minimizar los daños. Sin embargo, esto depende de tu infraestructura de alojamiento y de lo que puedas hacer a nivel de aplicación para mantener tu sitio en funcionamiento cuando fallan las dependencias.
¿Por qué las dependencias de terceros provocan fallos en cadena en WordPress?
Un sitio moderno de WordPress rara vez funciona de forma aislada. Por ejemplo, piensa en los elementos de los que depende el proceso de pago de WooCommerce en un momento dado:
- Las pasarelas de pago se encargan de procesar la transacción.
- Las APIs de envíos calculan las tarifas en tiempo real.
- Los servicios fiscales se encargan del cumplimiento normativo.
Otros sitios pueden cargar un rastreador de analíticas, un script de sincronización de CRM, un widget de chat en tiempo real y muchas otras dependencias, cada una alojada en un servidor externo diferente.
Cuando alguno de estos elementos se ralentiza o deja de responder, el efecto no se limita a esa funcionalidad concreta. Al contrario, se extiende por toda la capa de ejecución de PHP y provoca un problema que puede afectar a todo el sitio web. Esto se debe a que, cuando WordPress muestra una página que necesita una respuesta de una API externa, un hilo queda en espera hasta que se completa la solicitud.
Por lo tanto, una pasarela de pago que se bloquea tras 30 segundos ocupa un hilo durante todo ese tiempo y no puede procesar nada más mientras tanto. Si varios visitantes acceden a ese proceso de pago lento a la vez, varios hilos pueden retrasar la carga de las páginas en toda la cadena. Con el alojamiento compartido, los sitios comparten un conjunto de hilos.
La brecha de visibilidad: problemas de rendimiento internos frente a externos
Por eso, no hacen falta muchos tiempos de espera simultáneos para agotar por completo un pool compartido. Cuando eso ocurre, la API externa agota el tiempo de espera y los visitantes que quedan reciben errores relacionados con el tiempo de espera, como el 502 o el 504, mientras esperan a que se libere un hilo.
Sin embargo, un error 504 se ve exactamente igual, independientemente de su origen. En este tipo de respuestas de error, lo habitual es analizar primero las métricas de la CPU, la memoria y la infraestructura. Puede parecer que el problema está en el alojamiento, aunque la causa real sea una dependencia externa.
Cómo la arquitectura de contenedores de Kinsta limita el impacto de los fallos de terceros
Kinsta ejecuta cada sitio de WordPress en su propio contenedor aislado, lo que determina el «alcance del impacto» cuando falla un servicio externo.
Cada contenedor tiene su propio conjunto dedicado de hilos PHP al que no pueden acceder otros sitios de la plataforma. Esto significa que el agotamiento de hilos PHP se limita a tu contenedor sin afectar a otros sitios de la misma infraestructura. Además, cuando las llamadas a APIs externas ocupan todos los hilos PHP de tu contenedor, las solicitudes entrantes se ponen en cola dentro de Nginx y PHP-FPM en lugar de devolver errores inmediatamente.
En la práctica, una interrupción en la pasarela de pago que dejaría fuera de servicio todos los sitios de un servidor compartido solo afecta a tu contenedor en Kinsta. El grupo de hilos dentro de tu contenedor se ve sometido a una gran carga, pero los sitios vecinos siguen funcionando con total normalidad.
Los límites de tiempo de espera de las solicitudes evitan bloqueos indefinidos
Si no se controla, un hilo de PHP podría mantener una conexión con una API externa que falla durante un periodo prolongado. Para evitarlo, Kinsta establece max_execution_time en un valor predeterminado de 300 segundos, lo que limita el tiempo que un script de PHP puede ejecutarse activamente.
Hay un tiempo de espera HTTP independiente que determina cuándo se interrumpe la conexión entre el navegador y el servidor y se devuelve un error 504 al visitante; en Kinsta, este tiempo de espera se activa tras 180 segundos.
En conjunto, estos límites hacen que, desde el punto de vista del visitante, el peor de los casos tenga un endpoint definido. Sin embargo, ninguno de estos límites por sí solo interrumpe de forma fiable una llamada a la API saliente bloqueada. En Linux, el temporizador de ejecución de PHP no cuenta el tiempo dedicado a esperar operaciones de flujo, que es precisamente lo que ocurre con una solicitud HTTP saliente a través de la API HTTP de WordPress.
Un hilo bloqueado por la respuesta de una pasarela de pago apenas acumula tiempo de ejecución desde el punto de vista de PHP, por lo que el límite de 300 segundos ofrece menos protección de lo que podría parecer. Por eso, establecer tiempos de espera explícitos dentro de los plugins mediante http_request_timeout es la forma más fiable de poner fin a una llamada externa bloqueada a nivel de la aplicación.
Cuando una solicitud agota el tiempo de espera, el hilo se libera y el contenedor inicia un proceso de recuperación que suele durar un par de minutos.
Cómo usar Kinsta APM para diferenciar los cuellos de botella del alojamiento de los de terceros
La herramienta APM de Kinsta recopila datos con marca de tiempo sobre los procesos PHP, las consultas MySQL y las llamadas HTTP externas. Es la mejor forma de monitorizar la diferencia de rendimiento entre tu alojamiento y las dependencias de terceros.
Activa el APM desde la sección APM en MyKinsta y, a continuación, elige un intervalo de monitorización entre las cuatro opciones predefinidas, que van de dos a 24 horas. Como el APM de Kinsta consume recursos adicionales del servidor, lo mejor es activarlo cuando sospeches que se está produciendo un problema o que este se puede reproducir.
Una vez que el APM esté en funcionamiento, podrás consultar diversos cuadros, gráficos y visualizaciones repartidos en cuatro secciones: Transacciones, WordPress, Base de datos y Externo. Esta última es clave para entender dónde se producen los cuellos de botella.
Cómo usar la pantalla Externo en Kinsta APM
La pestaña Externo muestra todas las solicitudes HTTP externas que realiza tu sitio, incluidas las llamadas iniciadas por plugins y temas para el procesamiento de pagos, el cálculo de gastos de envío, las integraciones con CRM y las herramientas de analítica. Cada entrada muestra la duración total, máxima y media, junto con la frecuencia de solicitudes por minuto.
Por ejemplo, si una API de pago aparece al principio de la lista, con una duración máxima de varios segundos, eso indica claramente que la pasarela es la causa del problema.
Seguimiento de transacciones
Al hacer clic en la URL de una solicitud en la pestaña Externo, se abre una lista de ejemplos de transacciones. Al seleccionar un ejemplo concreto, se abre la línea de tiempo del seguimiento de la transacción, que muestra un desglose completo de todos los procesos que se han producido, cada uno de ellos representado como un intervalo de tiempo.
Los intervalos que consumen más del 5 % del tiempo total de la transacción aparecen en naranja; los que consumen más del 25 % aparecen en rojo.
Las trazas te ayudan a priorizar qué dependencias optimizar o sustituir primero. Por ejemplo, si una llamada HTTP externa a una API de pagos ocupa cinco segundos de una transacción de 5.5 segundos, la infraestructura de hosting gestionó todo lo demás en solo medio segundo
Para usar el APM de Kinsta cuando creas que hay un problema, el proceso es el siguiente:
- Activa la monitorización APM y selecciona un intervalo de tiempo que abarque el periodo en el que se produjo el problema.
- Reproduce el problema si no se está produciendo en este momento (o espera a que la herramienta recopile datos en tiempo real).
- Deja que se acumulen los datos, luego abre la pestaña Externo, haz clic en cualquier solicitud externa para abrir el seguimiento de la transacción y comprueba la duración de los intervalos.
Si las llamadas HTTP externas aparecen al principio de los resultados y su duración representa la mayor parte del tiempo de la transacción, ya tienes la información que necesitas para empezar a solucionar el problema.
Estrategias operativas para gestionar las dependencias de terceros
El aislamiento de contenedores limita los daños causados por fallos externos, pero también influye la forma en que cargas y llamas a los servicios externos. Incluso si cuentas con un alojamiento bien diseñado, las dependencias de terceros requieren una gestión proactiva a nivel de aplicación.
Patrones de carga asíncrona para scripts no críticos
WordPress carga los scripts de forma sincrónica por defecto, lo que significa que un script situado en el encabezado del documento impide que el navegador muestre el contenido hasta que termine de descargarse y ejecutarse. En el caso de los scripts de analítica, las herramientas de mapas de calor y la automatización de marketing, esto implica que un servidor externo lento retrasa la carga de toda tu página.
Lo que hay que tener en cuenta aquí es que cargar mediante sync y async da resultados diferentes cuando un servidor externo va lento:
- La carga sincrónica (con bloqueo) detiene el análisis del HTML hasta que el script se descargue y se ejecute. Si el servidor externo está saturado, tu página se queda a la espera.
- La carga asíncrona permite que el navegador siga analizando el HTML y mostrando el contenido mientras el script se carga en segundo plano. Si el servidor externo es lento, tu página se muestra de todos modos.
WordPress tiene compatibilidad nativa con las estrategias de carga async y defer a través de wp_enqueue_script(). Ambas evitan que los scripts no esenciales bloqueen la visualización de la página, pero se comportan de forma diferente: defer ejecuta los scripts en orden (por lo que es ideal para scripts con dependencias), mientras que async ejecuta los scripts tan pronto como se cargan, sin importar el orden.
Usar async es ideal para rastreadores independientes en los que el orden de ejecución no importa.
add_action( 'wp_enqueue_scripts', function() {
// Analytics — deferred so it doesn't block the critical path.
wp_enqueue_script(
'google-analytics',
'https://www.googletagmanager.com/gtag/js?id=G-XXXXXXXX',
[],
null,
[ 'strategy' => 'defer', 'in_footer' => false ]
);
// Marketing script — async because execution order doesn't matter.
wp_enqueue_script(
'hotjar',
'https://static.hotjar.com/c/hotjar-XXXXXX.js',
[],
null,
[ 'strategy' => 'async', 'in_footer' => false ]
);
} );Sin embargo, los scripts críticos para el proceso de pago suelen requerir un comportamiento de carga más cuidadoso que las etiquetas de analítica o marketing, y es posible que algunas integraciones de pago deban permanecer bloqueadas o ordenadas para evitar que se interrumpa el proceso de pago. En resumen, los scripts no críticos que pueden fallar sin que la página deje de funcionar se marcan como async o defer; los scripts que el usuario necesita para completar una transacción no.
Configuración del tiempo de espera para llamadas a API externas
El valor predeterminado de max_execution_time de Kinsta es lo suficientemente largo para operaciones complejas, pero demasiado largo como para tener a un usuario esperando. Por eso, un plugin que realice llamadas a API externas debería establecer su propio límite de tiempo de espera en lugar de recurrir al límite a nivel del servidor.
WordPress establece por defecto un tiempo de espera HTTP de 5 segundos para las solicitudes externas, si un plugin o un filtro lo modifican. Si un plugin necesita un límite diferente, WordPress ofrece un filtro para ello: http_request_timeout. Se ejecuta antes de que se realice una solicitud y acepta tanto el valor actual del tiempo de espera como la URL de destino, por lo que puedes establecer límites diferentes para distintos servicios:
add_filter( 'http_request_timeout', function( $timeout, $url ) {
if ( str_contains( $url, 'api.example.com' ) ) {
return 10; // Don't wait longer than 10 seconds.
}
return $timeout;
}, 10, 2 );Este tipo de límite hace que un servicio que falla devuelva rápidamente un error al usuario, en lugar de ocupar un hilo de PHP. Mantener los tiempos de espera a nivel de plugin muy por debajo del límite del servidor es lo que evita que una sola API lenta consuma un hilo durante un tiempo excesivo.
Sin embargo, aumentar los valores de tiempo de espera no soluciona la lentitud de las APIs, sino que evita fallos prematuros cuando un servicio funciona pero está bajo carga. Lo mejor es establecer un tiempo de espera corto que falle rápidamente y pase a un plan de contingencia (fallbacks).
Planes de contingencia y degradación controlada
Los planes de contingencia (Fallbacks) mantienen tu sitio operativo cuando se producen fallos externos, en lugar de mostrar un mensaje de error. Este patrón utiliza los transitorios de WordPress para almacenar en la caché las respuestas correctas de la API y, a continuación, muestra los datos almacenados cuando falla una llamada en tiempo real.
Aquí tienes un ejemplo:
function get_shipping_rates_with_fallback( $package ) {
$cache_key = 'live_shipping_rates_' . md5( serialize( $package ) );
$backup_key = 'backup_shipping_rates_' . md5( serialize( $package ) );
// Return fresh cached rates if they're available.
$cached = get_transient( $cache_key );
if ( $cached !== false ) {
return $cached;
}
// Attempt the live API call with a short timeout.
$response = wp_remote_post( 'https://api.example.com/rates', [
'timeout' => 8,
'body' => [
'destination' => $package['destination'],
'weight' => $package['contents_weight'],
],
] );
// On success: cache the result and update the longer-lived backup.
if ( ! is_wp_error( $response ) && wp_remote_retrieve_response_code( $response ) === 200 ) {
$rates = json_decode( wp_remote_retrieve_body( $response ), true );
set_transient( $cache_key, $rates, HOUR_IN_SECONDS );
set_transient( $backup_key, $rates, DAY_IN_SECONDS );
return $rates;
}
// On failure: serve stale backup rates rather than an error.
$backup = get_transient( $backup_key );
if ( $backup !== false ) {
return $backup;
}
// No cached data at all: return a flat-rate fallback.
return [
[ 'id' => 'fallback_flat', 'label' => 'Standard Shipping', 'cost' => 9.99 ],
];
}El caché temporal de una hora se encarga del almacenamiento en caché habitual para evitar llamadas innecesarias a la API. El caché temporal de 24 horas solo se actualiza cuando la API activa devuelve una respuesta correcta, lo que permite que tu sitio web recurra a la respuesta correcta más reciente. Cuando la API deja de funcionar, tu sitio web muestra las tarifas de envío de ayer en lugar de mostrar un error.
La degradación controlada mantiene en funcionamiento tus funciones básicas incluso cuando los servicios externos no están disponibles. Funciona mejor junto con una infraestructura de alojamiento que limite los fallos al nivel del contenedor, de modo que un problema en una dependencia no acabe consumiendo recursos.
Tu alojamiento debería ofrecerte algo más que velocidad para tu sitio
Los fallos de terceros son algo habitual cuando se gestiona un sitio de WordPress con dependencias en el mundo real. Lo que sí puedes controlar es en qué medida tu sitio se ve afectado por ellos, lo cual depende de cómo responda tu entorno de alojamiento.
El uso de una infraestructura que incorpore aislamiento de contenedores, un grupo de hilos PHP dedicado, límites de tiempo de espera integrados y monitorización de aplicaciones te permite distinguir entre un problema de alojamiento y un problema de dependencias.
Si estás listo para ver cómo la infraestructura de Kinsta gestiona esto para tus sitios de WordPress, echa un vistazo a los planes de alojamiento de Kinsta. También puedes hablar con el equipo para ver cómo Kinsta puede ayudarte con tu configuración específica.
