Optimizando un poco WordPress 3.0

Ahora que me las tengo que ver con WordPress 3.0 en serio, toca hacer un pequeño "tutorial" sobre lo que estoy haciendo y, claro, un poco de historia.

Un poco de historia personal

Llevo más de 4 años y medio en la red con SigT lo cual no me da ningún tipo de autoridad pero si un buen filón de anécdotas y si no fuera por mi misantropía ligera (no confundir con misoginia) también me hubiera dado para llenar una agenda de contactos del tamaño de "El código Da Vinci" o tocho similar...

En este tiempo siempre he estado en Dreamhost. A finales del 2005 muchos blogs importantes estaban también en dicho hosting y empezaron a aparecer problemas de exceso de CPU a mansalva. ¿El motivo? El uso de PHP como CGI. En su día Ricardo Galli lo explicó y la mayoría se paso a mod_php que era lo suyo.

En el 2007 Dreamhost eliminó la opción por defecto dado que eso impedía que los que usaban muchísimos recursos apareciesen en los reportes (por lo visto dependían de CGI). ¿Y a día de hoy? PHP4 ya ni es recomendado, mod_php sólo está disponible para sus "Private Servers" y la opción por defecto es PHP5 con FastCGI.

Mientras tanto, salvo problemas puntuales, yo he seguido usando WordPress+Dreamhost sin problemas. Supongo que es más que nada porque yo siempre he antepuesto dos cosas para mis sitios: diseños minimalistas (incluso "cutres" a veces) y el máximo de optimización posible.

Con WordPress 3.0 el consumo de CPU se ha reducido (respecto a la serie 2.9.x) pero el tamaño y el posible consumo de memoria al escalar (a medida que un sitio aumenta en plugins, comentarios a procesar por cada entrada, etcétera) se dispara y aunque no es demasiado alto sigue siendo bastante mayor de lo que era en la rama 2.0.x.

Cómo optimizar WordPress 3.0

1. Desactiva las revisiones y el autosave. Al crear o editar una entrada es, sin duda, una de las cosas que más puede aumentar el consumo. Mientras hacía pruebas en local, cada vez que saltaba el "autosave" o se creaba una revisión temporal la gráfica con el consumo de CPU que tiene incorporado el IceWM se disparaba. No es que sea tan exagerado en producción (un LAMP recién instalado no es ni de lejos lo que se dice optimizado) pero ahí está.

   Si realmente no lo necesitas como es mi caso (las revisiones me dan dolor de cabeza e incluso a veces me ha aparecido una antigua en lugar de la actual mientras que el "autosave" es útil si te peta el navegador a medio texto pero a mi el Firefox me saca el texto de nuevo al reiniciar) lo mejor es desactivarlo. Personalmente prefiero usar este plugin para ello.

2. Aumenta el máximo de memoria usable. Muchos hablan visto el error "Allowed Memory Size Exhausted" al realizar alguna tarea en WordPress 3.0 debido a que sobrepasan el máximo de memoria usable por defecto (32MB) en alguna operación.

   Para ello lo más fácil es editar el wp-config y añadir un nuevo rango:

    :::php
    define('WP_MEMORY_LIMIT', '64M');
   

   O incluso el PHP.ini si se tiene acceso:

    :::text
    memory_limit = 64M;
   

   Si tu hosting no permite modificar este valor y no da solución. Toca hacer maletas o rezar para que la próxima versión de WordPress use menos recursos (cosa que llevan prometiendo tiempo y a veces dan pasos hacía adelante y a veces hacía atrás).

3. Los obvios: menos plugins y sistema de cache. WP-Cache está desactualizado así que actualmente prefiero recomendar WP-SuperCache. Y tener el número de plugins imprescindibles ayuda. De la misma forma podemos añadir el siguiente código al final del todo de la página:

    :::php
    <?php echo "<!-- Memoria usada: " . memory_get_usage() . "bytes -->"; ?>
   

   E ir mirando como aumenta/disminuye a medida que activas/desactivas plugins. Si ves que un plugin aumenta considerablemente el consumo --más de 512KB (524.288 bytes) y eso ya es para mí una cantidad exagerada-- busca en la red si más gente tiene problemas o si hay una alternativa que consuma menos. De media cuando una página consuma más del rango 5-7MB empieza a ser alto.

4. Plantillas con menos llamadas: codifica a mano. Si se cambia de sitio luego es un engorro, pero se puede crear una copia de tu plantilla actual y cambiar todas las llamadas para obtener urls, por ejemplo si `` devuelve www.tusitio.com pues quita el código y pon directamente www.tusitio.com. Eso incluye desactivar los widgets.

   Esto también puede aplicarse para reducir plugins: ¿tienes un plugin tipo "socializar" que incluye botones para enviar tu sitio a 5-6 redes sociales? Lo primero preguntate si necesitas los 5-6 o sólo los tienes por un par... y lo segundo leete el código para insertar (manualmente) los enlaces en la plantilla. Muchos de estos plugins no son más que código que inserta un par de enlaces en el loop + una serie de opciones en el Dashboard que seguramente tocarás una vez y nunca más...

5. Limita el número de RSS que se muestran en el Dashboard. Por defecto en el Dashboard se muestran un par de feeds de noticias que sin tocar código no se pueden eliminar: "WordPress Blog" y "WordPress News". Hasta hace poco (estaba pendiente de arreglarlo, no sé si lo hicieron al final) los feeds que ahí se mostraban aumentaban considerablemente la memoria usada.

   Actualmente este consejo puede ser poco útil, pero si no te interesan estos feeds dale al botón "Configurar" que sale a la derecha de WordPress Blog/News y limita el número de entradas mostrada (2 y 5 respectivamente por defecto) a "1".

6. (Semi-avanzado) desactivar partes del código. Desactivar partes del código tiene dos efectos: no tener que cargarlos y que si una parte de WordPress la usa... pete. Básicamente es el mismo consejo que ya dí en septiembre del 2007 que era coger el wp-settings.php y comentar el fichero deprecated.php para que no se cargue.

   Con la diferencia que ahora ya ronda los 76kB de código (en lugar de 17kB) de llamadas antiguas. Si tienes una plantilla actualizada y los plugins también lo están, es casi imposible que se use alguna de esas funciones: un montón de ellas corresponden a funciones usadas en la versión 0.71 y que se consideran deprecated desde WordPress 2.0/2.1.

   Deberían hacer el código más modular para poder desactivar grandes partes de código sin tener problemas, yo eliminaría las etiquetas, widgets, las funciones de xmlrpc y envío de entradas desde otros sitios y demás código que no me sirve... una pena.

7. Paso definitivo: Really Static. Ya he hablado antes de Really Static pero ahora puedo decir que, si no necesitas que el sitio sea dinámico (y un sitio orientado al contenido normalmente no lo necesita) puede ser la hostia.

   Con el he podido separar en otro proyecto el back-end (el CMS en sí) del front-end y comunicarse ambos sólo para la inserción de comentarios. Tiempos de carga inferiores a 1seg para el contenido de media, en realidad si sólo se carga el HTML porque el resto de objetos (CSS, imágenes, etcétera) están cacheadas podemos hablar de incluso 500ms (0.5seg... contando que desde mi localización al servidor hay 200ms de latencia).

   Con las desventajas de que "la gente ve" un sitio estático pero con sus ventajas. ¿Meto la pata y destrozo la instalación de WordPress? Aquí no ha pasado nada, nadie se ha enterado, no tengo que ir contra-reloj para solucionarlo y que la menor cantidad de gente se entere "de mi pifia". ¿Se cae el servidor MySQL o falla PHP? De nuevo la gente ni se entera... a no ser que pete directamente el servidor Apache. De cuatro o cinco puntos (por software) que pueden provocar que un sitio sea inaccesible eliminas de un plumazo cuatro de ellos.

   Eso por no hablar de la opción de restringir el acceso al front-end o directamente meterlo en otro sitio. Te quitas de un plumazo todos los posibles problemas de seguridad (actuales o futuros) de WordPress.