Sin duda alguna una de las formas de reducir la cantidad de tráfico no-útil en un sitio es utilizando sistemas de caché. Gracias a esto, y de varias formas, podremos reducir la cantidad de peticiones contra el servidor si el usuario utiliza navegadores mínimamente nuevos.
Además, el hecho de separar los sitios/contenidos estáticos de los dinámicos también nos permitirá hacer muchas mejoras en cuanto al uso de tecnologías adecuadas para cada uno de los casos.
DOMAIN SHARDING
Categoría: Conectividad, CSS, Imágenes, JavaScript, Servidor
Por norma general no podemos invertir mucho dinero en proyectos con un CDN (del que luego hablaré) por lo que si queremos jugar con la paralelización de peticiones podemos utilizar el llamado Domain Sharding. Este sistema básicamente lo que permite es montar un sistema de subdominios para realizar varias peticiones aleatorias y en paralelo al mismo servidor estático.
Básicamente se trata de tener un servidor de archivos estáticos (imágenes, JavaScript, hojas de estilo…) y que, de una forma más o menos ordenada y mediante subdominios, podamos hacer muchas peticiones.
La forma normal sería hacer estas peticiones:
- www.dominio.ext/estilos.css
- www.dominio.ext/scripts.js
- www.dominio.ext/imagen1.png
- www.dominio.ext/imagen2.png
- www.dominio.ext/imagen3.png
- www.dominio.ext/imagen4.png
- www.dominio.ext/imagen5.png
- www.dominio.ext/imagen6.png
- www.dominio.ext/imagen7.png
Haciendo esto, encontramos una situación que, haciendo las peticiones en este orden, la imagen1.png no se cargaría hasta que el JavaScript se haya acabado de cargar, y como los navegadores suelen venir configurados para hacer 3-4 peticiones en paralelo, la imagen 4 no se empezaría a cargar hasta que no se hubieran cargado los ficheros anteriores.
Si creamos distintos subdominios que apunten al mismo lugar, tendríamos algo así:
- www.dominio.ext/estilos.css
- www.dominio.ext/scripts.js
- ww1.dominio.ext/imagen1.png
- ww1.dominio.ext/imagen2.png
- ww1.dominio.ext/imagen3.png
- ww2.dominio.ext/imagen4.png
- ww2.dominio.ext/imagen5.png
- ww2.dominio.ext/imagen6.png
- ww1.dominio.ext/imagen7.png
De esta forma, se mejorará sensiblemente la velocidad de carga de los distintos ficheros. Hay que tener en cuenta también que no es bueno crear más de 3-4 subdominios distintos, y que cada uno de ellos se debe llamar al menos 3-4 ocasiones para que sea realmente óptima la situación.
NOTA: En estos casos se genera una probabilidad muy elevada de generar contenidos duplicados, ya que los www, ww1 y ww2 acaban llamando a los mismos ficheros, por lo que es recomendable que, en caso de querer dejar indexar estos contenidos, sólo se deje hacerlo con el www pero no con el ww1 o ww2.
DISTRIBUCIÓN GEOGRÁFICA DE CONTENIDOS ESTÁTICOS (CDN)
Categoría: Conectividad, CSS, Imágenes, JavaScript, Servidor
Otra de las formas de mejorar la velocidad de conexión es la suma del Domain Sharding con la geolocalización de contenidos, que es lo que se consigue utilizando un CDN. Básicamente es lo mismo que el Domain Sharding, pero, aparte de tenerlo en una máquina en un país concreto, el sistema se replica automáticamente en centros de datos repartidos por el mundo. De esta forma y automáticamente, tú siempre enlazas a la misma dirección (estatico.dominio.ext) y el sistema hace una redirección al contenido que ha de descargarse.
Este sistema es muy recomendable sobre todo en sitios muy internacionales, ya que el tráfico trasatlántico está muy saturado y provoca lentitud en las comunicaciones, por lo que si tenemos los contenidos en Europa y Estados Unidos haremos que en esas dos zonas la descarga sea más rápida.
El uso de CDN no está recomendado en sitios pequeños ya que puede ser una inversión cara que no tiene mucho sentido, pero sí que lo tiene en sitios con cierto tamaño o que tenga una proyección internacional.
Hay muchos sitios grandes de Internet que utilizan sus propios CDN, como por ejemplo Google y su gstatic.com, Yahoo! con su yimg.com o Youtube con su ytimg.com.
Entre los servicios más habituales tenemos el Amazon CloudFront, Akamai o Windows Azure CDN.
CABECERAS CON CONTROL DE CACHÉ Y EXPIRACIÓN
Categoría: CSS, Imágenes, JavaScript, Servidor
Cachear contenidos web es bastante sencillo siempre y cuando se traten de páginas en HTML, ya que tenemos algunas metaetiquetas que permiten indicar la fecha de caducidad de la página; pero cuando se trata de otros contenidos, la única forma de indicar cuándo caducan dichos contenidos es a través del propio servidor web.
La función básica de la caché es que un usuario no se vuelva a descargar muchas veces un mismo contenido que no cambia. Para esto debemos indicarle al servidor los contenidos (normalmente las extensiones) de los ficheros y el tiempo que queremos que estén cacheados.
Para ello podemos usar dos sistemas: el de avisar la cantidad de tiempo que el archivo ha de mantenerse en caché (normalmente en segundos) o la fecha concreta hasta la que hay que almacenar dicha información.
En el caso de Apache lo habitual es indicar un tiempo desde la fecha de acceso o de modificación, de forma que podremos incluir algo de este estilo en el fichero de configuración general o en el particular del dominio. Existen varias formas de indicarlo, gracias al Mod_Expires.
<FilesMatch "\.(ico|gif|jpg|png|flv|pdf|mp3|js|css|xml)$">
Header set Cache-Control "max-age=2592000"
</FilesMatch>
En el caso de querer activarlo en IIS, podemos hacer lo siguiente:
- Entrar en las propiedades del dominio.
- Pulsar en la pestaña de Cabeceras HTTP
- Seleccionar la opción de Caducidad de los contenidos.
- Seleccionar el tipo de caducidad (inmediata, después de o hasta) y completar con la información correspondiente.
Hay que tener en cuenta que si cambiamos frecuentemente los archivos (como puede pasar con los CSS o los JS) es interesante plantearse el versionado de los ficheros, porque una vez un usuario lo ha leído, aunque lo sobrescribamos el sistema no dejará recuperar la nueva versión y es muy probable que el sitio se vea con errores o deformaciones de diseño.
CACHÉ EN CONTENIDOS DINÁMICOS
Categoría: Contenidos, Servidor
Aunque en el caso anterior os comentaba principalmente el cachear los contenidos el máximo tiempo posible, puede darse la necesidad de querer cachear los contenidos dinámicos. Por ejemplo, si tenemos un sitio que sabemos que va a recibir un pico elevado de tráfico, podemos limitar la actualización de las páginas a los usuarios durante unos pocos minutos, a sabiendas que puede darse el caso de que van a recargar las páginas muchas veces. Otro caso es el de un fichero que redirija a otro lugar, caso también que, habitualmente si depende de un parámetro, mandará siempre a ese otro lugar, podemos cachear la información.
El funcionamiento es muy similar al código anterior del Apache, y un ejemplo en PHP podría ser el siguiente:
// segundos*minutos*horas*días
$caducidad = 60*60*24*7;
header("Pragma: public");
header("Cache-Control: maxage=".$expires);
header('Expires : '.gmdate('D, d M Y H:i:s', time()+$expires).' GMT');
Gracias a este sistema que se puede replicar a otros lenguajes de programación, estamos informando de la cantidad máxima de segundos por los que se ha de cachear, además de la fecha de caducidad del contenido.
USAR “CACHE CONTROL: PUBLIC” PARA CACHEAR CONEXIONES SEGURAS “HTTPS”
Categoría: Contenidos, Servidor
Un tipo concreto de peticiones que por defecto no se cachean nunca son las conexiones seguras (https://…) ya que, como su nombre indica, son seguras y por lo tanto no deben almacenarse en ningún lugar. Pero aunque eso es así, en muchas ocasiones nos encontramos con que una web segura tiene una parte pública que puede cachearse sin problema. Un ejemplo muy claro sería la web de un banco que por defecto sea segura, pero tiene una zona navegable pública (para todos) y otra zona bajo usuario y contraseña. La primera zona, la pública, podría cachearse sin problema ya que no implica ninguna brecha de seguridad para el usuario tenerla en su propia máquina o al servidor ofrecer una copia prealmacenada.
El funcionamiento de este sistema es igual que el de los anteriores, pero hay que indicar de una forma expresa el código “public” para que pueda servirse de esta manera.
<FilesMatch "\.(ico|pdf|flv|jpg|jpeg|png|gif|js|css|swf)$">
Header set Cache-Control "public"
Header set Expires "Thu, 15 Apr 2010 20:00:00 GMT"
</FilesMatch>
EN APACHE USAR MOD_CACHE, MOD_DISK_CACHE, MOD_MEM_CACHE, MOD_FILE_CACHE Y HTCACHECLEAN
Categoría: Servidor
En el caso de utilizar servidores Apache para servidor contenidos existen distintos módulos muy útiles a la hora de prestar cachés, sobre todo del propio servidor que ayudan a la entrega más rápida de los contenidos.
- Mod_Cache: implementa el RFC 2616 que permite cachear los contenidos en local o a través de un proxy.
- Mod_Disk_Cache: permite que la caché se almacene en el disco local.
- Mod_Mem_Cache: permite que la caché se almacene en la memoria de una mejor forma.
- Mod_File_Cache: mejora del sistema de acceso a la caché de disco.
- Htcacheclean: es un programa que permite optimizar la caché limpiándola y manteniéndola.