En mi caso, el plugin de caché que estoy usando es WPSuperCache, que guarda una copia estática de cada página generada por Wordpress, y la sirve directamente en próximas peticiones, siempre y cuando el usuario no esté registrado. Esto evita todas las peticiones contra la base de datos por parte de Wordpress. Además, opcionalmente, el plugin permite guardar las páginas estáticas con una estructura de directorios equivalente a la URL que las representa, y proporciona reescrituras de URL para llegar a dichas páginas directamente, evitando toda intervención por parte de Wordpress (y evitando, por lo tanto, la ejecución de código PHP en el servidor). Finalmente, además, te da la opción de guardar los archivos HTML comprimidos con GZip. Todas estas opciones aceleran notablemente la carga de la página, puesto que el único trabajo que debe realizarse es el del servidor web: encontrar la página html y servirla.

WPSuperCache, como la mayoría de plugins de caché, cuenta con un borrado automático de la caché cada cierto tiempo. Cada vez que se ejecuta esta tarea, las siguientes peticiones (si las hay ) a las distintas páginas del blog harán que se regenere la caché automáticamente.

Sin embargo, cuando tienes pocas visitas, no es buena idea hacer que la caché sea regenerada por los lectores. En ese caso, el mío , es probable que un lector obtenga una página no cacheada en vez de una que sí lo está. Una posiblidad es aumentar en gran medida el intervalo de borrado de la caché, pero en general es preferible tener una caché actualizada. La otra posiblidad es, además de borrar la caché, regenerarla automáticamente, de tal manera que todos los lectores del blog se beneficien de la caché del mismo.

En mi caso, he escrito un script que visita todos los enlaces de una página web basándose en el sitemap de la misma, siempre que este cumpla el protocolo descrito por Sitemaps.org. El código es el siguiente:

#!/bin/bash
# Visit all the links provided by a sitemap file.
# Diego Toharia - http://blog.deigote.com

# Verify parameter
if [[ $# -ne 1 ]] ; then
    echo "Error: first parameter (sitemap URL) missing"
    echo "Usage: `basename $0` "
    exit 1
fi

url=$1
links=`wget -q -O - http://blog.deigote.com/sitemap.xml | awk '{ print $1 }' | grep "^http" | awk 'BEGIN { FS=">" } { print $2 }' | awk 'BEGIN { FS="<" } { print $1 }'`

for i in $links ; do
	echo "Visiting " $i
	wget -q -O - $i > /dev/null
done

Seguro que hay formas más elegantes de hacerlo, pero awk es tan potente que es difícil resistirse a usarlo . Lo he llamado visit_site_by_sitemap, original que es uno .

Una vez tenemos el script, lo más fácil es programar una tarea del cron que cada cierto tiempo (preferiblemente, en franjas horarias con el menor tráfico posible) borre la caché y ejecute el script pasándole como parámetro la URL del sitemap. Por cierto que, en mi caso, el sitemap lo genera el plugin Google Sitemap Generator. El mandato para la regla en mi caso sería algo como:

cd path/al/blog/wp-content ; find cache -type f -name '*.html' -exec rm {} \; -o -name '*.gz' -exec rm {} \; ; ~/bin/visit_site_by_sitemap http://blog.deigote.com/sitemap.xml

La idea es borrar todos los ficheros html y gz generados por la caché y regenerar la misma visitando todos los enlaces proporcionados por el sitemap del blog.

Podemos hacer un par de pruebas que, sin ser demasiado científicas, nos dan una idea del beneficio que obtenemos. La primera sería ejecutar en local el script dos veces, previo borrado de la caché. La primera visitaría todos los enlaces sin disponer de caché, mientras que la segunda lo haría usando la caché.

$ cd path/al/blog/wp-content
$ find cache -type f -name '*.html' -exec rm {} \; -o -name '*.gz' -exec rm {} \;
$ time ~/bin/visit_site_by_sitemap http://blog.deigote.com/sitemap.xml
Visiting  http://blog.deigote.com/
...
real    4m12.102s
$ time ~/bin/visit_site_by_sitemap http://blog.deigote.com/sitemap.xml
Visiting  http://blog.deigote.com/
...
real	0m7.759s

Podemos ver que los resultados son espectaculares. De 4 minutos hemos pasado a 7 segundos. Sin embargo, estamos probando el caso óptimo, en el que la latencia es mínima y la velocidad de conexión con el servidor web es máxima, lo que hacen que la capacidad de proceso sea el único parámetro que influye en los resultados.

Si ejecutamos esta misma prueba en una máquina externa y situada en España, la misma desde la que estoy escribiendo, obtenemos unos resultados bien distintos: casi trece minutos (12m45) frente a casi 9 (8m44s).

Sin embargo, esto es culpa de la lamentable latencia y velocidad de conexión que Dreamhost tiene en España, ya que ejecutando la prueba en una máquina situada en USA (y de otro servicio de hosting distinto), se obtienen 3 minutos (3m02s) frente a 22 segundos, resultados más parecidos a la ejecución en local. Tendré que pensar seriamente en cambiar de hosting .

La otra prueba que se puede hacer es algo más realista: medir el tiempo de descarga de una única página, que es lo que hace un usuario cualquiera (no creo que tenga ningún lector tan fan como para visitarse todas las entradas del blog una detrás de otra ). En mi caso, he usado un navegador Firefox con la caché deshabilitada y con la extensión Firebug instalada, usando la pestaña Red de dicha extensión para medir el tiempo de carga del HTML de la página de inicio. He realizado varias pruebas con la caché vacía y con la caché llena y he obtenido de media unos 2.5 segundos frente a medio segundo respectivamente, lo cual no está mal. Sin embargo, el resto de elementos de la página (malditos emoticonos ) ralentiza la carga total de la misma en gran medida, aunque eso es otra historia .

Gracias a Álvaro por su inestimable ayuda a la hora de lanzar el juego de pruebas en un servidor externo a españa.

Sin embargo, es muy probable que la entrada en la que se anuncia el nuevo blog, la cual está en el nuevo blog ( ). ¿Cómo es posible que si la URL ha cambiado los enlaces para el feed sigan siendo válidos? O una de dos: o mis lectores son muy poco observadores o pasotas, o tengo muy pocos lectores (yo pienso que es una mezcla de los dos )

Volviendo a la pregunta anterior, la respuesta es haber usado un simple URL rewriting gracias al módulo mod_rewrite de Apache. Gracias a este módulo, es posible reescribir una URL cuando esta llega al servidor web, cambiando las cabeceras de la petición, y redirigiéndola a donde corresponde tras realizar el cambio.

En mi caso, he necesitado las siguientes reglas para el dominio deigote.com:

RewriteRule ^blog$ http://blog.deigote.com [L]
RewriteRule ^blog/(.*) http://blog.deigote.com/$1 [L]

La primera de ellas sirve para cuando la URL entrante es http://deigote.com/blog (sin un slash o barra del siete al final). La segunda sirve para el resto de URLs que comiencen por http://deigote.com/blog. Seguro que algún lector (la esperanza es lo último que se pierde ) está pensando que ambas reglas se podrían fusionar en una como la siguiente:

RewriteRule ^blog(.*) http://blog.deigote.com$1 [L]

Es decir, eliminando los slash en la segunda regla para que englobe también el primer caso. El problema de hacer esto es que una URL del tipo http://deigote.com/blogstats sería redirigida a http://blog.deigote.comstats. Por ello, es mejor proteger todas las URLs con un slash al final y añadir una regla para el único caso en que no hace falta poner dicha barra (aunque quizá algún lector me corrija en este punto dándome una solución para unificar ambas reglas ).

De esta manera, todos los enlaces anteriores, ya sean los del feed, entradas, comentarios, etcétera… siguen funcionando correctamente .

PD: Si, tampoco es algo tan increible como para hacer una entrada tan larga, pero bueno, a mi me ha costado lo mío .