Dominios libres de cookies para servir contenidos
Publicado el Saturday 16 de January del 2010 @ 15:41 por Armonth.
- 5
- 0
Comentar
Entre tanta entrada se me hace difícil creer que no haya tratado este punto de forma más detallada (lo rocé recientemente en una entrada sobre Page Speed). El de usar dominios libres de cookies para servir contenidos tal como recomienda Yahoo.
¿Qué es eso? Pues literalmente lo que dice: un dominio (o subdominio) habilitado para servir contenidos sin cookies. Cuando en un sitio www.nuestrodominio.tld utilizamos una cookie no sólo la almacenamos en nuestro navegador para mantener la sesión.
Si el navegador hace una petición a un contenido que no sea la propia web (contenido estático como imágenes, ficheros CSS, etcétera) aparte de la petición (HTTP GET) también enviará la cookie que ya tiene almacenada. Lo cual es malo de cara a optimizar una página lo máximo posible ya que esa cookie, en ese entorno, no le sirve para nada al servidor.
Un navegador puede consumir unos pocos bytes en enviar la petición GET a un fichero html. Un par de kilobytes a lo sumo si además envía la cookie. Pero si además de eso en tu página web contienes 5 imágenes el navegador hará otros 5 envíos “GET+cookie”.
Una página con un fichero CSS, un fichero Javascript y 10 imágenes hace en total 13 peticiones GET. Si envía la cookie sólo para el HTML/PHP de la web asumiendo el ejemplo anterior serían 2kB de tráfico + unos pocos bytes por los 12 GET restantes hacía el servidor. Si envía la cookie para los 13 GET el tráfico se dispara a 26kB. Aunque los números sean menores (el tamaño de las cookies varía) no deja de ser tráfico de red inútil.
En casa del herrero, cuchillo de palo
Al entrar en SigT, si no se cachea los contenidos esta es la información de solicitud hecha por una imagen (el logotipo):
Encabezados de la Solicitud
Host sigt.net
User-Agent Mozilla/5.0 (X11; U; Linux i686; es-ES; rv:1.9.0.14) Gecko/2009091010 Iceweasel/2.0.0.3; (Debian-3.0.6-1)
Accept image/png,image/*;q=0.8,*/*;q=0.5
Accept-Language es_es,es-es;q=0.8,es;q=0.6,en;q=0.4,en-us;q=0.2
Accept-Encoding gzip,deflate
Accept-Charset ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive 300
Connection keep-alive
Referer http://sigt.net/
Cookie dbx-postmeta=grabit=0-,1-,2+,3-,4-,5+,6+&advancedstuff=0+,1+,2-; comment_author_CENSURADO=Armonth; comment_author_email_CENSURADO=;
Pragma no-cache
Cache-Control no-cache
Es decir, una cookie mínima de 560 bytes o lo que es lo mismo unos 5.8kB de tráfico extra por cada visitante que tenga una cookie de SigT previamente sin contar otros recursos (imágenes que no sean parte del diseño).
Solución
La forma más sencilla es crear un subdominio y usarlo para almacenar todo el contenido estático (ficheros CSS, imágenes, ficheros JavaScript, etcétera). Traduzco de la entrada de Yahoo:
Si tu dominio es www.example.org puedes almacenar los componentes estáticos en static.example.org. Sin embargo si ya tienes cookies en el dominio de nivel superior “example.org” en lugar de usar www.example.org entonces todas las peticiones a static.example.org incluirán estas cookies. En este caso puedes adquirir un dominio totalmente nuevo para alojar esos componentes y mantenerlo libre de cookies. Yahoo! usa yimg.com, YouTube usa ytimg.com, Amazon usa images-amazon.com y así.
Otro beneficio de alojar componentes estáticos en un dominio libre de cookies es que algunos proxies pueden negarse a guardar en cache componentes que han sido pedidos junto a cookies. En una nota relacionada si te preguntas si usar example.org o www.example.org para tu página, considera el impacto de las cookies. Omitir las www te deja sin opción salvo fijar las cookies a *.example.org así que, por razones de rendimiento, es mejor usar el subdominio con www. y escribir las cookies a ese subdominio.
Y este es, sin embargo, el único motivo que conozco para preferir dominios con www en lugar de sin ellos.
Un ejemplo sangrante: imageshack
En GNU/Linux navego con la opción “preguntar siempre” de las cookies. Recientemente en imageshack deben haber “tocado” algo porque de un par de semanas para aquí todos los subdominios usados para enviar imágenes (los “imgXXX”) envían cookies y, aparte de la molestia de que te pregunten por 20 cookies de golpe, imaginaos un sitio del tamaño de imageshack y el tráfico extra que deben estar generando.
Cada vez que entro en una ficha de algún Anime o película con las típicas 8-9 imágenes de ejemplo si estas están almacenadas en esta compañía el resultado es el envío de una docena de cookies. Si sirven millones de imágenes al día… tendrán millones de kB de tráfico gastado extra por un despiste.
Relacionadas
- Cuando es el mejor momento de mandar la cookie. Entrada de opinión sobre las distintos momentos de mandar una cookie y las pegas que genera.
- Trasteando con Page Speed.
5 Comentarios
-
Jorge:
hola muy interesante lo que comentas pero tengo dos preguntas.
¿merece la pena por 6KB más de tráfico? ¿cuanto te ahorrarias con el cambio?
-
Alejandro:
Hola, muy interesante la nota.
Casualmente leí hace poco lo mismo a partir de analizar mi web con el plugin pagespeed (que por cierto me parece genial, al igual que el yslow).
Sin embargo me gustaría aclarar/consultar un tema: en la nota decís que “aparte de la petición (HTTP GET) también enviará la cookie que ya tiene almacenada.”. Según entiendo, en realidad no es aparte sino que las cookies viajan como parte del encabezado de la petición. No te genera nuevas peticiones. Esto tendría otro impacto porque por regla los navegadores tienen un límite en la cantidad de peticiones simultáneas a un dominio (que si mal no recuerdo es de 2).
Por último me gustaría acotar que:
1- La mayoría de los sitios suele guardar más de una cookie, por lo que el impacto agregado de todas las peticiones a un sitio de mucho tráfico puede ser notorio.2- Es difícil implementar esta topología de sitio en algunos frameworks Web. Por ejemplo, yo trabajo con WebSphere Portal (de IBM) que tiene muy integrado la gestión de contenidos estáticos como imágenes y css. No es imposible, pero hay que romper buena parte de la arquitectura “base” para lograrlo.
Saludos.
-
InKiLiNo:
El artículo me ha parecido muy interesante, pero no acabo de ver como ponerlo en práctica :(
Ya que ultimamente te veo inspirado en tus posts, podrías currarte uno de como implementar esto ;)