Pourquoi les grands sites hébergent-ils leurs images / CSS sur des domaines externes?
Pourquoi des sites comme Facebook, Twitter et Google hébergent-ils leurs images et leurs CSS sur des domaines externes tels que:
- Facebook:
static.ak.fbcdn.net - Twitter:
a0.twimg.com - Google:
ssl.gstatic.com
Question (s):
- Est-ce que la performance? Ou la sécurité?
@toomanyairmiles est partiellement correct - le but de cette technique est d'autoriser les connexions parallèles du navigateur Web au serveur. Les navigateurs Web doivent autoriser un minimum (---) de deux connexions simultanées à un seul hôte, mais de nombreux nouveaux navigateurs peuvent en gérer jusqu'à 60. Quoi qu'il en soit, les connexions simultanées simultanées entre le navigateur et le (s) serveur (s) Web ) est un goulot d'étranglement majeur en termes de vitesse.
De ressource de Google :
La spécification HTTP 1.1 (section 8.1.4) stipule que les navigateurs doivent autoriser au plus deux connexions simultanées par nom d'hôte (bien que les navigateurs récents autorisent plus que cela: voir Browserscope pour une liste). Si un document HTML contient des références à plus de ressources (CSS, JavaScript, images, etc.) que le maximum autorisé sur un hôte, le navigateur émet des demandes pour ce nombre de ressources et met le reste en file d'attente. Dès que certaines des demandes sont terminées, le navigateur émet des demandes pour le prochain nombre de ressources de la file d'attente. Il répète le processus jusqu'à ce qu'il ait téléchargé toutes les ressources. En d'autres termes, si une page référence plus de X ressources externes à partir d'un seul hôte, où X est le nombre maximal de connexions autorisées par hôte, le navigateur doit les télécharger séquentiellement, X à la fois, générant 1 RTT pour chaque X ressource. Le temps total aller-retour est N/X, N étant le nombre de ressources à extraire d'un hôte. Par exemple, si un navigateur autorise 4 connexions simultanées par nom d'hôte et qu'une page fait référence à 100 ressources sur le même domaine, un RTT lui sera facturé, pour un total de 4 ressources, et une durée totale de téléchargement de 25 RTT.
Donc, le moyen de contourner cela est de "partager" les demandes vers différents domaines, ou hôtes:
Encore une fois, à partir de la même ressource Google:
Équilibrez les ressources parallélisables entre les noms d'hôte. Les demandes relatives à la plupart des ressources statiques, y compris les images, CSS et autres objets binaires, peuvent être parallélisées. Équilibrez autant que possible les demandes adressées à tous ces objets entre les noms d'hôte. Si ce n'est pas possible, essayez de vous assurer qu'aucun hôte ne dessert plus de 50% de plus que la moyenne de tous les hôtes. Ainsi, par exemple, si vous avez 40 ressources et 4 hôtes, chaque hôte devrait servir idéalement 10 ressources; dans le pire des cas, aucun hôte ne devrait en desservir plus de 15. Si vous disposez de 100 ressources et de 4 hôtes, chaque hôte doit en desservir 25; aucun hôte ne devrait servir plus de 38 personnes.
Mais, il y a encore une pièce du puzzle. Chaque demande est normalement accompagnée de ses propres frais généraux, généralement sous la forme de cookies. Les éléments statiques tels que les images, CSS et JavaScript n'ont pas besoin de transmettre de données de cookie. Par conséquent, les servant à partir de (sous) domaines sans cookies peut accélérer les allers-retours:
Le contenu statique, tel que les images, les fichiers JS et CSS, n'a pas besoin d'être accompagné de cookies, car il n'y a aucune interaction de l'utilisateur avec ces ressources. Vous pouvez réduire la latence des demandes en servant des ressources statiques à partir d'un domaine qui ne sert pas de cookies. Cette technique est particulièrement utile pour les pages référençant de gros volumes de contenu statique rarement mis en cache, telles que les vignettes d'image souvent modifiées ou les archives d'images accédées peu fréquemment. Nous recommandons cette technique pour toute page contenant plus de 5 ressources statiques. (Pour les pages qui desservent moins de ressources, le coût de la configuration d'un domaine supplémentaire ne vaut pas la peine.)
Pour réserver un domaine sans cookie au service de contenu statique, enregistrez un nouveau nom de domaine et configurez votre base de données DNS avec un enregistrement CNAME qui pointe le nouveau domaine vers votre enregistrement de domaine A existant. Configurez votre serveur Web pour qu'il serve les ressources statiques du nouveau domaine et n'autorisez aucun cookie à être placé nulle part sur ce domaine. Dans vos pages Web, référencez le nom de domaine dans les URL des ressources statiques.
Auparavant, les navigateurs Web ne pouvaient télécharger que deux éléments à la fois (maintenant 6 ou plus), le téléchargement de ressources de différents domaines est donc plus rapide qu'un seul domaine. Cela s'applique à tout, des images aux javascripts.
De nombreuses entreprises utilisent également un CDN , un outil qui garantit à l'utilisateur final que ses données sont stockées sur un serveur géographiquement proche d'eux, ce qui augmente également les performances du site en réduisant le temps d'aller-retour pour les demandes de ressources.
Les sites volumineux déplacent leur contenu statique (images, fichiers JS et CSS) vers un réseau de distribution de contenu (Content Delivery Network) ou un réseau de diffusion de contenu (CDN), car le déploiement de votre contenu sur plusieurs serveurs géographiquement dispersés accélérera votre chargement de la page du point de vue de l'utilisateur.
Comme le CDN a un nom de domaine différent, il fournit également avantages de partage de domaine .
La restriction de 2 éléments n'est plus un problème. Bien que ce soit une recommandation de la spécification HTTP, tous les navigateurs modernes autorisent au moins 6 connexions simultanées .