Pourquoi des sites comme Facebook, Twitter et Google hébergent-ils leurs images et leurs CSS sur des domaines externes tels que:
static.ak.fbcdn.neta0.twimg.comssl.gstatic.comDes questions):
Réponses:
@toomanyairmiles est partiellement correct - cette technique a pour but de permettre des connexions parallèles du navigateur Web au serveur. Les navigateurs Web doivent autoriser au moins 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 ou les serveurs Web constituent un goulot d'étranglement majeur.
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 obtenir une liste). Si un document HTML contient des références à plus de ressources (par exemple, 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 ressource X. 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, il encourra 1 RTT pour 4 ressources et un temps de téléchargement total 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ôtes. Les demandes pour 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 cela 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, si vous les fournissez à partir de (sous) domaines sans cookie, les allers-retours peuvent être plus rapides:
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 afin de servir du 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 installé ailleurs 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 permet à l'utilisateur final de récupérer ses données sur un serveur géographiquement proche de lui, ce qui augmente également les performances du site en réduisant le temps 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 le chargement de vos pages du point de vue de l'utilisateur.
Comme le CDN a un nom de domaine différent, il offre également des avantages en matière 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 .
Ceci est toujours nécessaire pour les cookies indésirables envoyés à l'en-tête lors de l'utilisation d'un nom de domaine externe. Aucun cookie n'est défini, ce qui rend le chargement du contenu beaucoup plus rapide.
Donc oui, il est toujours nécessaire pour la vitesse.