¿Por qué los sitios grandes alojan sus imágenes / CSS en dominios externos?

¿Por qué los sitios como Facebook, Twitter y Google alojan sus imágenes y CSS en dominios externos como:

• Facebook: static.ak.fbcdn.net
• Gorjeo: a0.twimg.com
• Google: ssl.gstatic.com

Pregunta (s):

• ¿Es el rendimiento? o seguridad?

@toomanyairmiles es parcialmente correcto: el propósito de esta técnica es permitir conexiones paralelas desde el navegador web al servidor. Los navegadores web deben permitir un mínimo de dos conexiones simultáneas a un solo host, pero muchos navegadores nuevos pueden administrar hasta 60. Independientemente, las conexiones simultáneas simultáneas entre el navegador y los servidores web son un importante cuello de botella de velocidad.

Del recurso de Google :

La especificación HTTP 1.1 (sección 8.1.4) establece que los navegadores deben permitir como máximo dos conexiones concurrentes por nombre de host (aunque los navegadores más nuevos permiten más que eso: consulte Browserscope para obtener una lista). Si un documento HTML contiene referencias a más recursos (por ejemplo, CSS, JavaScript, imágenes, etc.) que el máximo permitido en un host, el navegador emite solicitudes para ese número de recursos y pone en cola el resto. Tan pronto como finalicen algunas de las solicitudes, el navegador emite solicitudes para la siguiente cantidad de recursos en la cola. Repite el proceso hasta que haya descargado todos los recursos. En otras palabras, si una página hace referencia a más de X recursos externos de un solo host, donde X es la cantidad máxima de conexiones permitidas por host, el navegador debe descargarlas secuencialmente, X a la vez, incurriendo en 1 RTT por cada X recursos. El tiempo total de ida y vuelta es N / X, donde N es el número de recursos para obtener de un host. Por ejemplo, si un navegador permite 4 conexiones concurrentes por nombre de host, y una página hace referencia a 100 recursos en el mismo dominio, incurrirá en 1 RTT por cada 4 recursos, y un tiempo de descarga total de 25 RTT.

Entonces, la forma de evitar esto es "fragmentar" las solicitudes a diferentes dominios o hosts:

Nuevamente, desde el mismo recurso de Google:

Equilibre los recursos paralelizables entre los nombres de host. Las solicitudes de la mayoría de los recursos estáticos, incluidas imágenes, CSS y otros objetos binarios, se pueden paralelizar. Balancee las solicitudes a todos estos objetos tanto como sea posible a través de los nombres de host. Si eso no es posible, como regla general, intente asegurarse de que ningún host sirva más del 50% más que el promedio en todos los hosts. Entonces, por ejemplo, si tiene 40 recursos y 4 hosts, cada host debería servir idealmente 10 recursos; en el peor de los casos, ningún host debería servir a más de 15. Si tiene 100 recursos y 4 hosts, cada host debe servir a 25 recursos; Ningún anfitrión debe servir a más de 38.

Pero, hay una pieza más en el rompecabezas. Cada solicitud normalmente viene con sus propios gastos generales, normalmente en forma de cookies. Los elementos estáticos como imágenes, CSS y JavaScript no necesitan transmitir datos de cookies, por lo que servirlos desde (sub) dominios sin cookies puede dar como resultado viajes de ida y vuelta más rápidos:

El contenido estático, como imágenes, archivos JS y CSS, no necesita estar acompañado de cookies, ya que no hay interacción del usuario con estos recursos. Puede disminuir la latencia de la solicitud al servir recursos estáticos de un dominio que no sirve cookies. Esta técnica es especialmente útil para páginas que hacen referencia a grandes volúmenes de contenido estático que rara vez se almacena en caché, como las miniaturas de imágenes que cambian con frecuencia o los archivos de imágenes a los que se accede con poca frecuencia. Recomendamos esta técnica para cualquier página que sirva más de 5 recursos estáticos. (Para las páginas que sirven menos recursos que esto, no vale la pena el costo de configurar un dominio adicional).

Para reservar un dominio sin cookies para servir contenido estático, registre un nuevo nombre de dominio y configure su base de datos DNS con un registro CNAME que señale el nuevo dominio a su registro de dominio A existente. Configure su servidor web para servir recursos estáticos del nuevo dominio y no permita que se establezcan cookies en ningún lugar de este dominio. En sus páginas web, haga referencia al nombre de dominio en las URL de los recursos estáticos.

En el pasado, los navegadores web solo podían descargar dos elementos a la vez (ahora 6 o más), por lo que descargar recursos de varios dominios es más rápido que un solo dominio. Esto se aplica a todo, desde imágenes hasta javascripts.

Muchas compañías también usan una CDN , una herramienta que garantiza que el usuario final obtenga sus datos de un servidor que está geográficamente cerca de ellos, lo que también aumenta el rendimiento del sitio al reducir el tiempo de ida y vuelta para las solicitudes de recursos.

Los sitios grandes mueven su contenido estático (imágenes, archivos JS y CSS) a una red de entrega de contenido o CDN, ya que la implementación de su contenido en múltiples servidores dispersos geográficamente hará que sus páginas se carguen más rápido desde la perspectiva del usuario.

Como el CDN tiene un nombre de dominio diferente, también proporciona beneficios de fragmentación de dominio .

La restricción de 2 elementos ya no es un problema. Si bien es una recomendación de la especificación HTTP, todos los navegadores modernos permiten al menos 6 conexiones simultáneas .

Esto todavía es necesario para las cookies no deseadas que se envían al encabezado mientras se usa un nombre de dominio externo que no tiene ninguna cookie establecida, por lo que es mucho más rápido cargar contenido.

Entonces sí, todavía es necesario para fines de velocidad.