WordPress Performance Análisis

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.

10 comentarios en “WordPress Performance Análisis”

  1. He ejecutado el plugin que comentas y me daba 48 consultas. Ahora lo he dejado en 32 consultas. Un tercera parte menos y eso que tengo una plantilla bastante modificada y personalizada.

    Gracias por el dato

    Saludos!

  2. pues el otro día tu web estuvo caída bastantes horas, estabas realizando cambios entiendo, no?

  3. Yo diría incluso que el 99% de los casos en los que una instalación de WP tiene problemas de rendimiento es debido al theme.

    He visto auténticas barbaridades en cuanto a consumo, y no sólo en themes gratuitos (como se podría esperar), también en themes a medida y por los que los clientes se han dejado un buen presupuesto.

    En mi opinión esto es debido casi siempre a que el desarrollador del theme tiene poco o ningún conocimiento de las funciones y herramientas específicas se WordPress, y lo desarrolla tirando de PHP+MySQL estándar.

    Por cierto… aún sigo esperando esa documento que ibas a publicar sobre cómo debería ser el plugin SEO perfecto… ;)

  4. Cada vez que escucho a alguien decir que word reas es un cms se me pone la carne de gallina. Y si encima dices que da pocos problemas .. Se nota que no manejas grandes instalaciones.

    Donde se ha visto que tengas que crear tablas y tablas cada vez que hagas alguna extensión ¿ donde se ha visto que la cantidad de Plugins facilite tanto que el sistema sea hackeable¿ habéis visto alguna bbdd de un conjunto de blogs un par de años después de empezar ?

    Wordpres es un dolor de cabeza para un gestor de sistemas, eso si, para un desarrollador o para alguien que quiera hacer lo mínimo esta bien . En eso no le quitare mérito .

    cada vez que actualizo sufro, cada vez que me llega un Mail de las listas de bugs de wordpress sufro, cada vez que see corrompe una tabla sufro, cada vez que hago un backup sufro … Sufro continuamente. Así que me permitiréis que discrepe sobremanera. Esta muy lejos de ser un cms bueno.
    Dicho con todos mi respetos para otros muchos usos

Deja un comentario