Después de tener que modificar el código de wordpress, el tema y los plugins varias veces por culpa de las actualizaciones, he decidido empezar de cero y usar plugins para hacer el trabajo que antes hacía manualmente.

Las herramientas que he usado para medir el rendimiento son:

• Site Performance (SP): Los tiempos de este sitio son espectaculares. Debe ser que ambos extremos están conectados por fibra óptica y que deben realizar muy pocos saltos.
• Web Page Test (WPT): Este sitio permite realizar la simulación desde distintos sitios y con distintas conexiones y nevegadores. En mi caso elegí una adsl con el IE8 en Dulles, VA.
• YSlow: Estos son los datos que da el YSlow instalado en el Firefox de mi casa, donde tengo una adsl.

Los pasos que he seguido esta vez los he sacado principalmente del blog Noupe, aunque adaptado a la salida de Wordpress 2.8.

Además, esta vez he ido apuntando todos los datos en cada una de las modificaciones para poder controlar en cuanto afecta al rendimiento cada uno de los cambios. Los datos los he dejado disponibles en esta página (y en bruto).

A parte de subir 23 puntos en la puntuación de YSlow, hemos reducido el tiempo medio de descarga a la mitad, la mayor parte gracias al control de la cache mediante las cabeceras.  En los datos en bruto se puede ver como activar la compresión en el servidor hace más por reducir la cantidad a descargar (175Kb menos) que el tiempo de descarga. Podéis ver la configuración de apache aquí.

WP Super Cache y WP Widget Cache sólo mejoran en algo el tiempo de acceso, pero en cambio si mejoran mucho el tiempo que el servidor dedica en generar la página.

He tenido que dejar para una segunda entrada, dos plugins que creo que podrían mejorar aún más el rendimiento: WP PHP Speedy y cSprites, el problema es que no he conseguido hacerlos funcionar.  Tendré que instalar XDebug y ver si puedo arreglarlos, ya que sus respectivos autores están en paradero desconocido.

Gracias a esta herramienta hemos reducido el tamaño de los ficheros a descargar en 30Kb, y por tanto arañamos unos milisegundos al tiempo total, sobretodo con la caché vacía que era el apartado que menos había mejorado (e incluso empeorado durante un paso). YSlow nos da un aprobado alto con una puntuación de 90, ya queda poco para terminar el trabajo.

Para solucionar el problema rápidamente he modificado el fichero ‘gzip-header-css.php’ que venía incluido en el tema K2 que uso, y lo he dejado así:

Lo que he hecho ha sido quitar la parte que indicaba el Content-Type, para poder indicar CSS y JS en función de lo que vaya a necesitar, y cambiar la forma de calcular la fecha de Expires para usar un método más intuitivo.

Añadiendo el include de este fichero a las tres peticiones que faltaban, conseguimos una A en estos dos test y una puntuación de 88 en el total, que ya empieza a estar bastante bien. La media del tiempo de carga con la caché vacía ha subido casi un segundo quedándose en unos 7 segundos, pero la media usando la caché ha bajado casi un segundo hasta llegar a los 3 segundos. De momento no hemos mejorado apenas, pero quedan dos puntos que nos pueden ayudar bastante: minificar el código Javascript y pasar la carga de los ficheros .js al final del documento.

Normalmente el uso de estas redes está reservado para grandes corporaciones que pueden pagarlas, pero nosotros vamos a apoyarnos en la infraestructura de Google para descargar a nuestro pobre servidor de atender estas peticiones, y de paso permitir que el navegador descargue en paralelo los ficheros, ya que al estar en dominios distintos no estará limitado por el número máximo de descargas simultaneas.

Lo primero que vamos a hacer es usar el API de Google para cargar las librerías Javascript que usa el blog. En este apunte encontraréis una explicación detallada de las ventajas de usar este API. Si usamos wordpress, este plugin nos hará todo el trabajo sucio.

Después tenemos que añadir a la configuración de YSlow el dominio ‘ajax.googleapis.com‘ para que nos reconozca lo que descarga desde esa dirección como perteneciente a nuestra CDN. El como hacerlo lo podemos ver en su FAQ.

El siguiente paso es pasar todo el contenido estático a otra CDN. Para ello vamos a hacer un poco de trampa y usar el servicio de Google App Engine para montarnos una CDN. Con la información de esta entrada monté lo básico y pasé todo lo que pude a la página de Google Apps, pero me mosqueaba que siempre se recargaban las imágenes, los css y los js, y con Firebug vi que Google no respondía a las peticiones If-Modified-Since y siempre devolvía el contenido como nuevo. Al fichero de la aplicación hay que añadirle la linea ‘default_expiration: “365d”‘ para que la fecha de expiración se de en un año por defecto.

En esta otra entrada continúan el trabajo de la anterior pero añadiendo el control de la cache del navegador y así evitar enviar los datos con cada petición.Como en el anterior apartado, deberemos añadir el dominio que creemos a la configuración de YSlow para que nos lo tenga en cuenta.

Después de este cambio los tiempos de carga no han variado apenas, pero hemos descargado bastante nuestro servidor principal, con lo que en caso de necesitar atender a muchas peticiones lo tendrá más fácil. Además, los servidores de Google comprimen de forma automática los ficheros de texto (css y js) por lo que ahorramos en ancho de banda.

La puntuación que nos da YSlow ha subido hasta 80, no sólo por usar la CDN sino porque al utilizarla hemos mejorado otros puntos como añadir la cabecera de Expires, comprimir el contenido o configurar los ETags (estos no son compatibles con las CDNs por lo que todo lo que se descarga de una no necesita tener esa cabecera).

Actualización: La semana que viene dejará de estar disponible el feed normal de wordpress.

Para ayudarnos vamos a utilizar YSlow, un plugin para FireBug (si, un plugin para un plugin). Este plugin comprueba si se cumplen las reglas que diseñaron en el grupo de Exceptional Performance de Yahoo!

Si le indicamos que analice la portada del blog, nos da una puntuación (usando el sistema anglosajón) de F (34), un suspenso como un camión.

La primera regla en la que suspendemos (con una F) es en la de realizar pocas peticiones HTTP, ya que para cargar la página hacen falta 10 ficheros JS, 6 CSS y 28 imágenes. De los 10 JS, 6 pertenecen al tema de wordpress que uso y los otros 4 a plugins. Intentar unificar los ficheros de distintos plugins sería una locura, pero los que pertenecen al tema vamos a reunirlos en 1 para reducir casi a la mitad el número total.

Después vamos a usar la técnica de Sprites CSS (vía el generador automático) para unificar todas las imágenes que usan tanto el tema K2/Vader como el plugin de Compártelo, para pasar de 28 imágenes descargadas a 6. Como beneficio añadido tenemos que podemos optimizar los PNGs y pasar de 20,7Kb en imágenes a 6,9Kb. lo cual nunca viene mal.

Ya que no resultaba muy complicada también eliminamos la llamada a un css cuya única función era cargar la el css principal en php.

Tras todos estos pasos, hemos reducido las peticiones a 6 JS, 5 CSS y 6 imágenes. Ahora obtenemos una C en este apartado e incrementamos la puntuación total en 14 puntos. Para obtener un sobresaliente en esta apartado tendríamos que reescribir partes fundamentales de Wordpress, del Tema y los plugins.

Por ejemplo, se me ocurre que el motor de Wordpress podría tener un par de funciones con las que los plugins y temas puedan indicarle que ficheros JavaScript y CSS quieren usar respectivamente, y este los uniera en uno solo para enviárselo al navegador. De esta forma tendríamos siempre una sola petición JS y otra CSS independientemente de cuantos plugins tuviéramos instalados. Estos envíos podrían estar comprimidos y su compresión sería mayor que la de cada uno de los elementos por separado.

Actualización: A sugerencia de mi amigo Juan, voy a ir poniendo los tiempos que se ganan con cada modificación para poder ver como afectan al tiempo total cada uno de ellos. Pero también tengo que decir que los tiempos en si mismos son bastante difíciles de medir, ya que el blog está en un servidor en el que también hay un juego online, y la carga que este impone al servidor hace variar mucho los tiempos. Por eso voy a intentar medir el tiempo desde el mismo sitio y a las mismas horas para intentar que los parámetros de la medición sean lo más parecidos posibles.

Los resultados son un poco raros, ya que el tiempo de carga con la caché vacía ha aumentado en casi 1 segundo (probablemente debido a que ahora en la portada se cargan imágenes más grandes debido a los Sprites CSS); pero una vez los datos están en caché el tiempo medio ha bajado en casi medio segundo. Habrá que esperar a tener más resultados para comparar.

Para los que seáis tan impacientes como yo, aquí os lo dejo para descargar.

Para solucionar esto hace poco encontré una referencia a una barra de herramientas de accesibilidad hecha por la gente de WAVE. La diferencia es que todo el trabajo lo hace dentro del navegador con la información que esté mostrando en ese momento.

Una vez instalada veremos algo como esto:

Para utilizarla sólo tendremos que ir a la página que queramos y darle a ‘Errors, Features, and Alerts’ y generará el informe de los fallos de accesibilidad dentro de la página en la que estemos. Como ejemplo vamos a ver como queda la página de mi estantería en aNobii con los fallos superpuestos:

Nada más empezar, vemos que la página contiene unos cuantos errores desde el punto de vista de la accesibilidad. Cómo por ejemplo, los dos primeros iconos de arriba a la derecha nos indican que hay una imagen sin texto ‘alt’ y que el input de búsqueda no tiene una etiqueta asignada respectivamente.

Para volver a tener la página como estaba sólo tenemos que pulsar en ‘Reset Page’. Con esta herramienta no tenemos excusa para dedicarle un poco de tiempo a hacer accesibles nuestras páginas.

Esta es la lista de plugins que he instalado:

• aNobii: aNobii es una red social de libros bastante activa.
• Compartelo: No habrá nadie que no haya visto este plugin en acción.
• Embedded Tag: Permite hacer referencia a los tags dentro de los post.
• Google Analycator: Estadísticas de Google Analitics por javascript para no sobrecargar la bdd del blog.
• Inline Tag: Editar los tags vía Ajax.
• Quoter: Para citar los comentarios sin recargar.
• Related Post: Para tener la lista de post relacionados.
• Tag Managing: Más opciones para editar los tags de WP.
• Twitter Tools: Para ver los twitts y twittear automáticamente al postear.
• WP Super Cache: Para intentar mitigar un poco la lentitud del servidor, aunque también le estoy echando un vistazo a Viper Cache.

Editado: Tanto hablar de los plugins y se me olvida el más importante:

• K2: Que se encarga de darle un aire más moderno a WordPress, y uno de sus temas:
• Vader2: Porque me gustó mucho los colores estilo sable luz.

¿Conocéis algún otro plugin interesante?

Espero seguir blogeando en breve, hasta entonces ¡Comentad!