Optimización WEB (Aumento de velocidad de descarga)
Es lamentable, lo sé, pero desde que puse en marcha este blog no he dedicado mucho tiempo a mejorar el rendimiento del mismo. Pero, y como dice el dicho, “Más vale tarde que nunca”, por lo que aquí va mí Optimización WEB.
Antes de nada, ¿Para qué actualizar?
Esta pregunta tiene 2 respuestas obvias:
- Mejorar la experiencia de usuario en cuanto a la carga de información.
- Mejorar la carga de los sistemas de búsqueda (Google, Bing, Yahoo, etc..) que valorarán mejor aquellas WEB que sean más rápidas y que ofrezcan información de mejor calidad. Esto redunda en el posicionamiento WEB, por lo que se podría tener una mejor posición en los resultados de búsqueda.
Aumento de velocidad
Tras analizar mi WEB en la herramienta de Google para tiempos de carga “PageSpeed Tools”, se presentan varios fallos a corregir.
Habilitar compresión
Cuando un cliente (por ejemplo, un navegador web o una araña de búsqueda) hace una petición a nuestra WEB, se produce un intercambio de información. El objetivo de la compresión es la de reducir lo máximo posible el volumen de información que viaja por la WEB.
Pensad que cada carácter ocupa 8 bits de información y que por norma general una WEB incluye, además del texto, un volumen muy alto de datos en los que se incluyen las imágenes, los estilos, los ficheros de ejecución de código (JS), etc.
Por otro lado, el cada vez mayor incremento de dispositivos móviles y la consecuente tarificación por datos, hace casi obligatorio que nuestra WEB reduzca al máximo la cantidad de datos a enviar. Obviamente pensando en los usuarios que verían reducida la cuota de consumo mensual si vistan constantemente página no optimizadas.
¿Y cómo conseguimos la compresión de nuestra WEB?
Existen varias formas de realizar esta acción, y dependerá del grado de control que tengamos en nuestros servidor, alojamiento o servicio.
La mejor opción (en mi opinión) es realizar la compresión a nivel de servidor WEB. Si tenemos acceso a nuestro servidor tendremos que definir una serie de reglas que modificarán el comportamiento del software devolviendo los resultados comprimidos.
Apache:
El primer paso será averiguar si disponemos de los módulos necesarios para realizar la compresión. Que decir que esta operación se debería realizar sobre un terminal (yo utilizo la aplicación putty). El comando para ver los módulos cargados es:
httpd -t -D DUMP_MODULES
El módulo que nos interesa es “deflate_module” que en mi caso no estaba presente. ¿Cómo lo solucioné?, quizás lo hice de la forma más complicada posible ya que con una actualización del sistema “apt-get update” hubiera sido suficiente, pero en mi servidor no tengo esta posibilidad. Lo que he hecho ha sido compilar el apache incluyendo este módulo.
- Aprovechando la situación he descargado la última versión de apache en su hilo 2.2 (en este caso el 2.2.31).
wget http://apache.rediris.es//httpd/httpd-2.2.31.tar.gz
- Descomprimimos el fichero
tar -xzvf httpd-2.2.31.tar.gz
- Y lo configuramos para que incluya el módulo necesario
./configure --enable-mods-shared=all --enable-logio --enable-deflate --with-z=/usr/local
- Ahora lo compilamos
make
- Y lo instalamos
make install
- Por último, comprobamos que la versión está correctamente instalada
httpd -v
Ahora procedemos a configurar el apache, para lo cual modificamos el fichero httpd.conf que se encuentra en la carpeta conf dentro de la instalación de nuestro apache (en mi caso se encuentra en la carpeta /usr/local/apache2).
La configuración la copiamos directamente del manual de apache:
<IfModule mod_deflate.c>
SetOutputFilter DEFLATE
<IfModule mod_setenvif.c>
BrowserMatch ^Mozilla/4 gzip-only-text/html
BrowserMatch ^Mozilla/4\.0[678] no-gzip
BrowserMatch \bMSI[E] !no-gzip !gzip-only-text/html
SetEnvIfNoCase Request_URI .(?:gif|jpe?g|png)$ no-gzip dont-vary
</IfModule>
<IfModule mod_headers.c>
Header append Vary User-Agent env=!dont-vary
</IfModule>
</IfModule>
Por último, no deberemos olvidarnos de reiniciar nuestro servidor WEB.
/etc/init.d/httpd restart
.htaccess
Lo anterior solo es válido si disponemos de acceso a nuestro servidor como administradores, pero ¿Qué ocurre si esto no es posible?
Una opción es la de modificar el fichero .htaccess, el cual se encuentra en la carpeta raíz de nuestro proyecto y que se utiliza para redefinir el comportamiento de las solicitudes WEB.
Para ello, simplemente hemos de añadir las siguientes líneas y subirlas por FTP a nuestro servidor.
AddOutputFilterByType DEFLATE text/xml
AddOutputFilterByType DEFLATE text/css
AddOutputFilterByType DEFLATE text/javascript
AddOutputFilterByType DEFLATE application/javascript
AddOutputFilterByType DEFLATE application/x-javascript
AddOutputFilterByType DEFLATE application/xml
AddOutputFilterByType DEFLATE application/xhtml+xml
AddOutputFilterByType DEFLATE application/rss+xml
Resultados
Para comprobar el progreso de nuestras configuraciones, podremos utilizar la funcionalidad de desarrollo que incluyen la mayoría de navegadores WEB. Esta se activa pulsando la tecla F12. En nuestro caso nos centraremos en el apartado de RED.
En la siguiente imagen se puede apreciar varios detalles importantes:
- En nuestra solicitud (Hecha con un navegador Mozilla Firefox) se indica que se aceptan compresiones mediante gzip y deflate.
- El servidor NO envía comprimida la información lo que repercute en 53.1KB y en un total de 1.68s (UN SEGUNDO) de procesamiento de página.
Tras la configuración vemos que ya se devuelve la información comprimida en formato gzip y que el tamaño se ha reducido a 13,00KB.
Cache de Cliente
La Cache consiste en el guardado y posterior utilización de información por parte de los sistemas Informáticos. En el caso de la cache de cliente o de navegador, consiste en que estas aplicaciones (los navegadores) almacenan en disco toda la información que descargamos. Por norma general estos recursos (páginas, imágenes, ficheros CSS, etc.) son enviados por los servidores con ciertos metadatos que informan al navegador si deben ser cacheados y durante cuánto tiempo. Si el navegador hace caso del servidor y almacena los recursos, en sucesivas peticiones de nuestra WEB no será necesaria su descarga y por tanto la presentación para el usuario será mucho más rápida.
Según las indicaciones de la herramienta de Google, la opción más adecuada para cachear el contenido es mediante el valor de “Expires” para indicar el final del cacheo y “Last-Modified” para indicar que fecha de modificación tiene el recurso o “ETag” que será un valor único del recurso. Con estos datos el sistema determinará si la información almacenada en disco está vigente y por tanto puede ser utilizada o por el contrario ha de ser nuevamente solicitado al servidor WEB.
Como se puede apreciar en la siguiente imagen, los recursos que devuelve nuestro servidor WEB no incluyen la opción Expires lo que intuyo es interpretado por el servidor como recurso no cacheable o caduco.
Para saber si un recurso está cacheado en nuestro sistema, el resultado no debería ser “200 OK” sino un “304”.
Comprobando la configuración
El primer paso, al igual que hicimos con la configuración de la compresión es ver si disponemos del módulo de Apache. Ejecutando nuevamente el comando “httpd -t -D DUMP_MODULES” veo que no tengo el módulo “expires_module” por lo que vuelvo a compilar el apache añadiendo dicho módulo en la configuración:
./configure --enable-deflate --with-z=/usr/local --enable-expires
Y compilamos e instalamos “make” y “make install”
Una vez instalada procedemos a realizar las configuraciones adecuadas.
Apcache y .htaccess
En apache volveremos a editar el fichero “http.conf” o “.htaccess” añadiendo las siguientes líneas:
<ifModule mod_expires.c>
ExpiresActive On
ExpiresDefault "access plus 604800 seconds"
ExpiresByType image/x-icon "access plus 2592000 seconds" # o 30 days
ExpiresByType image/jpeg "access plus 2592000 seconds" # o 30 days
ExpiresByType image/png "access plus 2592000 seconds" # o 30 days
ExpiresByType image/gif "access plus 2592000 seconds" # o 30 days
ExpiresByType application/x-shockwave-flash "access plus 2592000 seconds" # o 30 days
ExpiresByType text/css "access plus 604800 seconds" # o 7 days
ExpiresByType text/javascript "access plus 604800 seconds"
ExpiresByType application/javascript "access plus 604800 seconds"
ExpiresByType application/x-javascript "access plus 604800 seconds"
ExpiresByType text/html "access plus 600 seconds" # o 10 minutes
ExpiresByType application/xhtml+xml "access plus 600 seconds" # o 10 minutes
</ifModule>
En este punto ya tenemos activada tanto las fechas de expiración como las de última modificación.
Ojo, si seguís recibiendo un 200 en vuestro WordPress, aseguraros de que no estéis validados. En el caso de estar identificados el propio WordPress envía el meta “pragma: no-cache” lo que básicamente indica a nuestro navegador que no debe cachear la página. Esto lo hace para que veamos todos los cambios que estamos realizando en nuestro blog de la forma más real posible.
Por cierto, ¿sabéis que con la combinación de teclas Ctrl+F5 podéis solicitar a vuestro navegador que se salte la cache y cargue el contenido real del servidor? Esto es muy útil cuando estamos programando páginas.
Con estos cambios hemos conseguido pasar de un estado Rojo a uno Ámbar en la herramienta de PageSpeed, lo que seguro dará sus frutos en el posicionamiento de nuestra WEB.
