@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.
