¿Cuál es la ventaja de alojar recursos estáticos en un dominio separado?


24

Noto que muchos sitios alojan sus recursos en un dominio separado del sitio principal, por ejemplo, StackExchange usando sstatic.net, Barnes & Noble usando imagesbn.com, etc.

Entiendo que hay beneficios al colocar sus recursos estáticos en un host separado, posiblemente con un servidor web de archivos estáticos eficiente como nginx, liberando el servidor principal para enfocarse en servir contenido dinámico. Del mismo modo, la externalización a un CDN compartido como Akamai frente a la nube es lógico.

Sin embargo, ¿cuál es el beneficio de usar un dominio separado? ¿Por qué sstatic.net en lugar de static.stackexchange.com?

Actualización : varias respuestas pierden la pregunta central. Entiendo que es beneficioso dividir entre varios hosts: descargas paralelas, un servidor web más delgado, etc. Pero lo que es más difícil de entender es por qué múltiples dominios . ¿Por qué sstatic.net en lugar de static.stackexchange.com como host de recursos compartidos? Hasta ahora, solo una respuesta ha abordado eso.

Respuestas:


22

Muchos sitios tienen bastantes cookies establecidas, estas cookies tienen el propósito de admitir algún tipo de estado.

Al poner los recursos estáticos (sin estado) en un dominio completamente diferente, puede reducir el tamaño de las solicitudes http. En algunos casos, hay tantas cookies que una sola solicitud http requiere la transmisión de dos paquetes TCP. Por lo tanto, tener un dominio separado es una de las formas de reducir la cantidad de paquetes para solicitar las diferentes partes de una página.

Otros métodos con el mismo objetivo son fusionar muchas imágenes en un solo sprite y fusionar todo Javascript en un solo archivo.


23

Además del uso de CDN, el uso de dominios separados para datos estáticos también significa:

  1. Puede usar un servidor web liviano que no tenga que cargar todos los módulos / extensiones que su servidor web de contenido dinámico debe cargar en cada solicitud. No tener que escanear cada directorio en la ruta URI para leer archivos .htaccess también aumenta el número de solicitudes simultáneas que el servidor puede manejar.

  2. Agregar un subdominio adicional significa que aumenta el número de descargas paralelas que el navegador puede realizar.

  3. Si está configurado correctamente (por ejemplo, su sitio está alojado en www.example.comlugar de example.com), también puede aprovechar un subdominio sin cookies, lo que reduce el tráfico y los tiempos de ida y vuelta.

El único inconveniente es que, si está utilizando sesiones SSL, necesita un certificado firmado e IP estática separada para los dominios adicionales. Pero los beneficios superan este inconveniente menor en la mayoría de los casos.

Editar:

Lo siento, leí mal tu pregunta. Si se pregunta por qué algunas personas usan SLD por separado, eso sería respondido por el paréntesis en el n. ° 3. También se explica en sstatic.net :

Si su dominio es www.example.org, puede alojar sus componentes estáticos en static.example.org. Sin embargo, si ya ha configurado cookies en el dominio de nivel superior example.org en lugar de www.example.org, entonces todas las solicitudes a static.example.org incluirán esas cookies. En este caso, puede comprar un dominio completamente nuevo, alojar allí sus componentes estáticos y mantener este dominio libre de cookies. Yahoo! usa yimg.com, YouTube usa ytimg.com, Amazon usa images-amazon.com y así sucesivamente.

Pero encarnado también menciona un buen punto sobre el uso de un SLD genérico separado en lugar de un subdominio de un SLD existente cuando está ejecutando una gran red de sitios que comparten ciertos activos.

Por último, como señala Niels Basjes, parte de la razón para eliminar las cookies es minimizar la cantidad de paquetes utilizados para realizar una solicitud. Creo que las pautas de YSlow establecen que la mayoría de las redes tienen un tamaño de paquete máximo de 1500 bytes, por lo que mantenerlo por debajo de 1500 bytes reduciría la sobrecarga de TCP. Esto también demuestra otra ventaja de usar en sstatic.netlugar de static.webmasters.stackexchange.com.


¿Por qué necesitarías una ip separada?
Mihalis Bagos

2
Porque el cifrado se aplica tradicionalmente antes de enviar el nombre de dominio. SNI , que alivia esto, todavía no es universalmente compatible: excluiría IE en XP.
phihag

@Mihalis: solo para agregar al comentario de phihag, también estaría excluyendo Windows Mobile 6.5 y anteriores, Android 2.xy anteriores, Blackberry Browser, Safari en XP ... La lista completa de software compatible / no compatible se puede encontrar aquí : en.wikipedia.org/wiki/Server_Name_Indication#No_support
Lèse majesté

3
No estoy preguntando por qué usar múltiples subdominios, eso tiene sentido para mí. Estoy preguntando por dominios completos separados. ¿Por qué sstatic.net en lugar de static.stackexchange.com?
Michael Ekstrand

5

Lèse majesté cubrió los puntos principales, pero para ampliar aún más, agregaría que tener un solo dominio para todos los diversos sitios de Stack Exchange significa que alguien que los navegue solo descargará contenido estático como JavaScripts una vez. Al ir a Superusuario, por ejemplo, un usuario usará el contenido en caché, ya que es del mismo lugar.

Hay más información útil sobre Yahoo y Google sobre esto.


5

La razón principal son las cookies. Lo que Niels sugirió en su respuesta es solo una consecuencia menor, y no la razón real. Sin cookies, el tamaño de la solicitud es menor, por lo que está ahorrando algo de ancho de banda.

Sin embargo, la verdadera diferencia proviene de la memoria caché del navegador. Dado que el contenido es estático (es decir, no cambia), los navegadores pueden almacenarlo en caché en el disco duro local y evitar cargar el archivo desde Internet cada vez. En lugar de todo el archivo, el servidor web solo envía una respuesta 304, lo que significa que el contenido no ha cambiado.

Cuando el sitio usa cookies, los navegadores consideran que el contenido del archivo puede ser diferente para diferentes usuarios, por lo que no almacenan en caché esos archivos. Servir el archivo desde un dominio sin cookies garantiza que el almacenamiento en caché del navegador funcione correctamente.

Esta es la razón principal, ya que mejora los tiempos de carga y reduce significativamente el ancho de banda.


Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.