Wordpress, el CMS que uso para gestionar mi blog, dispone de varios plugins para acelerar su carga mediante cachés, algo muy necesario en general, y más si, como yo, eres usuario de un servicio de hosting barato.
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.
