Quel est l'avantage d'héberger des ressources statiques sur un domaine distinct?

Je remarque que de nombreux sites hébergent leurs ressources sur un domaine distinct du site principal, par exemple StackExchange en utilisant sstatic.net, Barnes & Noble en utilisant imagesbn.com, etc.

Je comprends qu'il y a des avantages à placer vos ressources statiques sur un hôte séparé, éventuellement avec un serveur Web de fichiers statiques efficace comme nginx, libérant le serveur principal pour se concentrer sur la diffusion de contenu dynamique. De même, l'externalisation vers un CDN partagé comme cloudfront Akamai est logique.

Mais quel est l’avantage d’utiliser un domaine distinct autrement? Pourquoi sstatic.net au lieu de static.stackexchange.com?

Mise à jour : Plusieurs réponses manquent la question centrale. Je comprends qu'il y a un avantage à se diviser entre plusieurs hôtes - téléchargements parallèles, serveur Web plus mince, etc. Mais ce qui est plus difficile à comprendre, c'est pourquoi plusieurs domaines . Pourquoi sstatic.net plutôt que static.stackexchange.com en tant qu'hôte pour les ressources partagées? Jusqu'à présent, une seule réponse a répondu à cela.

De nombreux sites disposent d'un grand nombre de cookies, ces cookies ont pour but de prendre en charge une sorte d'état.

En plaçant les ressources statiques (sans état) sur un domaine complètement différent, vous pouvez réduire la taille des requêtes http. Dans certains cas, il y a tellement de cookies qu'une seule requête http prend deux paquets TCP pour être transmis. Donc, avoir un domaine séparé est l'un des moyens de réduire le nombre de paquets pour demander les différentes parties d'une page.

D'autres méthodes ayant le même objectif sont la fusion de nombreuses images en un seul sprite et la fusion de tout Javascript dans un seul fichier.

Outre l'utilisation de CDN, l'utilisation de domaines séparés pour les données statiques signifie également:

1. Vous pouvez utiliser un serveur Web léger qui ne doit pas charger tous les modules / extensions que votre serveur Web de contenu dynamique doit charger à chaque demande. Ne pas avoir à analyser chaque répertoire du chemin URI pour lire les fichiers .htaccess augmente également le nombre de requêtes simultanées que le serveur peut gérer.

2. L'ajout d'un sous-domaine supplémentaire signifie que vous augmentez le nombre de téléchargements parallèles que le navigateur peut effectuer.

3. S'il est correctement configuré (par exemple, votre site est hébergé sur www.example.comau lieu de example.com), vous pouvez également profiter d'un sous-domaine sans cookies, réduisant le trafic et les temps d'aller-retour.

Le seul inconvénient est que si vous utilisez des sessions SSL, vous avez besoin d'un certificat signé et d'une adresse IP statique distincte pour le ou les domaines supplémentaires. Mais les avantages l'emportent sur cet inconvénient mineur dans la plupart des cas.

Modifier:

Désolé, j'ai mal lu votre question. Si vous demandez pourquoi certaines personnes utilisent des SLD distincts, la parenthèse du # 3 répondra à cette question. C'est aussi expliqué sur sstatic.net :

Si votre domaine est www.example.org, vous pouvez héberger vos composants statiques sur static.example.org. Cependant, si vous avez déjà défini des cookies sur le domaine de premier niveau example.org par opposition à www.example.org, toutes les demandes adressées à static.example.org incluront ces cookies. Dans ce cas, vous pouvez acheter un tout nouveau domaine, y héberger vos composants statiques et conserver ce domaine sans cookie. Yahoo! utilise yimg.com, YouTube utilise ytimg.com, Amazon utilise images-amazon.com et ainsi de suite.

Mais incarné mentionne également un bon point sur l'utilisation d'un SLD générique distinct au lieu d'un sous-domaine d'un SLD existant lorsque vous exécutez un grand réseau de sites qui partagent certains actifs.

Enfin, comme le souligne Niels Basjes, une partie de la raison de l'élimination des cookies est de minimiser le nombre de paquets utilisés pour effectuer une demande. Je pense que les directives YSlow indiquent que la plupart des réseaux ont une taille de paquet maximale de 1500 octets, donc le garder sous 1500 octets réduirait la surcharge TCP. Cela démontre également un autre avantage d'utiliser sstatic.netau lieu de static.webmasters.stackexchange.com.

Lèse majesté a couvert les points principaux, mais pour développer davantage, j'ajouterais que le fait d'avoir un seul domaine pour tous les différents sites Stack Exchange signifie que quelqu'un qui les parcourra ne téléchargera qu'une seule fois le contenu statique tel que JavaScripts. Pour accéder au superutilisateur, par exemple, un utilisateur utilisera le contenu mis en cache car il provient du même endroit.

Il y a des informations plus utiles sur Yahoo et Google à ce sujet.

La raison principale est les cookies. Ce que Niels a suggéré dans sa réponse n'est qu'une conséquence mineure et non la vraie raison. Sans cookies, la taille de la demande est plus petite, ce qui permet d'économiser de la bande passante.

Cependant, la vraie différence vient du cache du navigateur. Comme le contenu est statique (c'est-à-dire qu'il ne change pas), les navigateurs peuvent le mettre en cache sur le disque dur local et éviter à chaque fois de charger le fichier depuis Internet. Au lieu du fichier entier, le serveur Web envoie simplement une réponse 304, ce qui signifie que le contenu n'a pas changé.

Lorsque le site utilise des cookies, les navigateurs considèrent que le contenu du fichier peut être différent pour différents utilisateurs, ils ne mettent donc pas ces fichiers en cache. Servir le fichier depuis un domaine sans cookie garantit que la mise en cache du navigateur fonctionne correctement.

C'est la raison principale car elle améliore les temps de chargement et réduit considérablement la bande passante.

Les navigateurs plus anciens sont limités à seulement deux téléchargements parallèles par nom d'hôte.

Le fractionnement des éléments d'une page Web sur plusieurs domaines est appelé partitionnement de domaine . Cela permet de télécharger plus de ressources en parallèle, ce qui réduit les temps de chargement des pages.

Le nombre optimal de domaines à répartir est de 2 à 4. Après 4 domaines, le temps de réponse se dégrade .