La salud del sitio es una de esas funcionalidades de WordPress que parece inofensiva hasta que miras lo que hace por dentro.

Por si no lo sabías, ejecuta un cron semanal con docenas de comprobaciones, pinta un widget en el escritorio con sus propias consultas, y cada vez que entras en Herramientas → Salud del sitio dispara una tanda de peticiones a api.wordpress.org y al propio servidor para verificar loopback, HTTPS y unas cuantas cosas más.

¿A que ni lo imaginabas?

En una web con hosting decente no vas a notarlo, pero en un hosting compartido justito o en un servidor que va al límite igual lo notas ¿o no te has fijado lo que tarda en cargar el widget de salud del sitio del escritorio a veces o lo que tarda en cargar la herramienta?

A veces puedes notar que la semana que le toca ejecutarse deja el admin lento durante unos segundos, que el widget del escritorio ralentiza la entrada al escritorio cada vez que accedes, y no te olvides de las consultas al servidor y la telemetría a WordPress.org.

Pues bien, hoy toca meterle mano y optimizar – también – la herramienta de salud del sitio de WordPress. Aquí te cuento cómo bajarle el volumen sin renunciar a su utilidad, que ni se te ocurra cuestionarla, es imprescindible.

Índice de contenidos

Qué hace Salud del sitio en la trastienda

Hay tres cosas ejecutándose en momentos distintos:

El cron wp_site_health_scheduled_check, que se lanza una vez por semana y ejecuta todos los tests (loopback, HTTPS, versión de PHP, versión de MySQL, comunicación con WordPress.org, etc.).
El widget estado de salud del sitio del escritorio, que consulta un transient y, si no existe, lanza las comprobaciones al vuelo.
Los tests asíncronos que se disparan vía API REST cuando abres la pantalla de salud del sitio.

Los tres se pueden intervenir por separado, y lo ideal es tocar solo lo que esté molestando.

Quitar el cron semanal

Si quieres desactivar la comprobación programada añade esto a un mu-plugin:

/* Quitar la comprobación semanal de salud del sitio */
function ayudawp_remove_site_health_cron() {
    $timestamp = wp_next_scheduled( 'wp_site_health_scheduled_check' );
    if ( $timestamp ) {
        wp_unschedule_event( $timestamp, 'wp_site_health_scheduled_check' );
    }
}
add_action( 'init', 'ayudawp_remove_site_health_cron' );

Con eso el cron deja de reprogramarse y te ahorras la tanda semanal de comprobaciones, que incluye varias llamadas HTTP externas. Si algún día quieres volver, comenta las líneas o desinstala el snippet y WordPress lo reprograma solo.

Mientras tanto, por supuesto, la herramienta sigue funcionando, solo tienes que visitar su página para que funcione normalmente.

Quitar el widget del escritorio

El widget del escritorio es el que más lata da en el día a día porque lo ves cada vez que entras al admin, pero es que tarda siempre algo, a veces mucho. Para eliminarlo…

/* Quitar el widget de escritorio de salud del sitio */
function ayudawp_remove_site_health_widget() {
    remove_meta_box( 'dashboard_site_health', 'dashboard', 'normal' );
}
add_action( 'wp_dashboard_setup', 'ayudawp_remove_site_health_widget' );

Sigues pudiendo entrar a Herramientas → Salud del sitio cuando te haga falta, pero dejas de cargarlo al escritorio sin pedirlo.

Quitar tests concretos que dan guerra

A veces no quieres matar salud del sitio entera, solo los tests que marcan falsos positivos en tu hosting.

Los dos clásicos son la comprobación de loopback (que falla en entornos con Basic Auth o cortafuegos que bloquean peticiones internas) y la de HTTPS. Con el filtro site_status_tests los quitas uno a uno:

/* Quitar tests específicos de salud del sitio */
function ayudawp_remove_site_health_tests( $tests ) {
    unset( $tests['async']['loopback_requests'] );
    unset( $tests['async']['https_status'] );
    unset( $tests['direct']['available_updates_disk_space'] );
    return $tests;
}
add_filter( 'site_status_tests', 'ayudawp_remove_site_health_tests' );

Los tests async son los que lanzan llamadas HTTP, así que cada uno que quites baja el coste de abrir la pantalla de salud del sitio. Los direct se ejecutan en el mismo hilo.

Cuándo merece la pena meterle mano

Si tu hosting va sobrado no toques nada. Tener el chequeo activo es útil para detectar versiones de PHP obsoletas o problemas de correo antes de que alguien se queje.

En cambio, sí merece la pena intervenir cuando:

El admin va lento y Query Monitor te señala el widget o los endpoints site-health como culpables.
Tienes avisos en rojo de loopback o HTTPS que son falsos positivos del hosting y no puedes arreglarlos.
Estás preparando un pico de tráfico y quieres desactivar todo el cron no crítico durante unos días.

Y si esto te ha interesado, échale un ojo también a los trucos de optimización de admin que tengo publicados en la categoría de WPO del blog, que van en la misma línea de ganar rendimiento con snippets pequeños que hacen cosas grandes.