WordPress es un gran CMS, no me cansaré de decirlo, ya que lo uso desde 2006 y la verdad es que pocos problemas me ha dado; pero cada vez más las configuraciones e instalaciones se complican, los sitios web crecen de tráfico y la configuración básica ya no es suficiente.
En las últimas semanas he hablado de algunos desastres con WordPress, de la creación de estáticos para WordPress, algunos trucos con el .htaccess… y hoy quiero comentar un par de plugins que creo que son bastante interesantes de cara a tener en cuenta pequeñas mejoras de rendimiento.
El primero más que para analizar el rendimiento es para aumentarlo. Hoy en día por defecto WordPress viene configurado para que se cree un histórico de todas las entradas, actualizaciones y demás de forma infinita, por lo que se pueden generar hasta decenas de copias de una entrada antes de ser publicada. la verdad es que si activas el auto-guardado (por ejemplo cada 2 minutos -120 segundos-) creo que es más que suficiente y pocos necesitamos tener el historial. Para ello lo mejor es configurar esto en el wp-config.php:
define('WP_POST_REVISIONS', false);
define('AUTOSAVE_INTERVAL',120);
Una vez tengamos esto configurado deberíamos hacer una pequeña limpieza de la base de datos para aligerarla un poco (o mucho) con el plugin Better Delete Revision que aliviará un poco las consultas.
Pero no quería hablar de esto, sino de analizar las consultas a la base de datos. Y es que estos días atrás, como ya comenté en la entrada de los desastres de WordPress, me he encontrado con una instalación que me ha traído de cabeza algunas semanas. Durante un día completo desactivamos plugins, cambiamos la plantilla (aunque los responsables de la web la volvían a activar, de ahí el no haber encontrado el error)… total, que hace unos días me instalé un interesante plugin llamado Debug Queries que básicamente lo que hace es añadir al pie de página la lista de todas las consultas a la base de datos. En una plantilla sencilla (por ejemplo la Twenty Eleven) se hacen entre 20 y 40 consultas aproximadamente (dependiendo en muchos casos de los plugins instalados). El sitio que estaba monitorizando tenía más de 1800 consultas en todas las páginas. Al final, hice la misma prueba con el diseño por defecto y me volvió a dar las 30 habituales, manteniendo todos los plugins activos. Esto me hizo pensar que el fallo estaba en la plantilla, y que debía ser algo que estaba en todas las páginas (así que se reducía todo a que probablemente fuera la cabecera, el pie o la barra lateral).
Analizando la cabecera me di cuenta de que se hacían muchas consultas a cosas que siempre van a devolver los mismos resultados, como son las direcciones URL de las plantillas, del propio sitio web, etc… lo puse a pelo y me quedé tan ancho; lo mismo hice con el pie de página. Pero esto no era y la desesperación aumentaba. En la barra lateral había muchas zonas de código HTML comentados, y ahí estaba el error, que casi por inercia obviaba esas zonas «que no se ejecutan»… pero no me fijaba en el código PHP de ellas. Sí, allí estaba.
El sitio es colaborativo y tiene abierto el registro para cualquier usuario, a los que ofrecen sistemas de puntuaciones por participar, entre otras cosas. Pues allí estaba la función wp_list_authors listando los 900 y pico de usuarios en un menú desplegable que, en la web, no se veía. Como tenemos un sistema de reducción de código con WP Minify el sistema elimina toda la parte «comentada» del HTML, así que aunque miraba y miraba en el código fuente no se veía absolutamente nada extraño. Y es que aunque hay 900 usuarios, por cada uno de ellos se ejecutan dos consultas, una que pide la información de la tabla usuarios (ID por ID) y luego la que solicita todos los metadatos de dicho usuario… en definitiva: 900 por 2 te dan las 1.800 consultas que se estaban ejecutando y que no servían para absolutamente nada.
Lo más curioso de todo es que la propia página de código de WordPress incluye una sección llamada Testing WordPress Performance en la que da algunas explicaciones sobre cómo controlar el rendimiento del propio sistema en la que básicamente se trata el tema de Xdebug para controlar el PHP y de MySQLnd para analizar el MySQL.
Llevo años optimizando WordPress, pero siempre hay algún sitio web que no deja de sorprenderme.
Deja una respuesta