Obtenir le nombre de requêtes simultanées par navigateur
J'essaie de déterminer s'il serait utile de répartir les demandes d'images sur plusieurs sous-domaines. [Cet article] (lien cassé) par exemple dit:
La plupart des navigateurs ne peuvent faire que deux requêtes à la fois, de sorte que le navigateur demandera deux fichiers, les téléchargera et passera ensuite aux deux suivants. Plus une page nécessite de requêtes HTTP ou de composants séparés pour s'afficher correctement, plus l'Utilisateur devra attendre longtemps.
Quand ils disent la plupart , quels navigateurs en particulier? Est-ce que ce nombre est lié au nombre de xmlhttprequests simultanés, par cette question?
2 réponses
Il y a beaucoup de choses à considérer ici. Dans la plupart des situations, Je ne choisirais qu'un domaine/sous-domaine sans cookie pour héberger vos images telles que static.mywebsite.com. et idéalement, les fichiers statiques devraient être hébergés par un CDN, mais c'est une autre histoire.
Tout d'abord, IE7 n'a permis que deux connexions simultanées par hôte. Mais la plupart des navigateurs permettent aujourd'hui plus que cela. IE8 permet 6 connexions simultanées, Chrome permet 6 et Firefox permet 8.
Donc, si votre page web n'a que 6 les images, par exemple, il serait vraiment inutile de diffuser vos images sur plusieurs sous-domaines.
Disons que vous avez 24 images sur une page. Eh bien, peu de choses dans la vie sont libres et il y a une telle chose comme la mort par parallélisation. Si vous hébergez vos images dans 4 sous-domaines différents, cela signifie que chaque image pourrait théoriquement être téléchargée en parallèle. Cependant, cela signifie également qu'il y a 3 recherches DNS supplémentaires impliquées. Et une recherche DNS pourrait être 100 ms, 150 ms, ou parfois plus. Ce retard supplémentaire pourrait facilement compenser tout avantage des téléchargements parallèles. Vous pouvez voir des exemples réels de ceci en testant des sites avec http://www.webpagetest.org/
Bien sûr, la meilleure solution est d'utiliser des sprites CSS lorsque cela est possible pour réduire le nombre de requêtes. Je parle de cela et de la surcharge inhérente à chaque requête dans Cet article et celui-ci.
Mise à JOUR
Il y a un article intéressant de Steve Souders sur le sujet des domaines sharding...
La plupart des dix meilleurs sites Web des États-Unis font du partage de domaines. YouTube utilise i1.ytimg.com, i2.ytimg.com, i3.ytimg.com, et i4.ytimg.com. vivre Utilisations de recherche ts1.images.live.com, ts2.images.live.com, ts3.images.live.com, et ts4.images.live.com. ces deux sites sont sharding à travers quatre domaines. Quel est le nombre optimal? Yahoo! publié une étude qui recommande sharding à travers au moins deux, mais non plus de quatre domaines. Au-dessus de quatre, la performance se dégrade réellement.
Http://www.stevesouders.com/blog/2009/05/12/sharding-dominant-domains/
Notez cependant que cela a été écrit en 2009. Et en 2011, il a posté un commentaire...
Puisque les nouveaux navigateurs ouvrent plus de connexions par domaine, c'est probablement mieux vaut réviser le nombre vers le bas. Je pense que 2 est un bon compromis, mais c'est juste une intuition. Ce serait génial si une propriété de production fonctionnait test pour déterminer le nombre optimal.
Vous devez également garder à l'esprit que la grande raison pour laquelle il est même nécessaire pour les grands sites comme Yahoo et Amazon à faire domaine sharding est que leurs sites sont si dynamiques. Les images sont attachées à des produits ou des histoires qui sont affichés dynamiquement. Il n'est donc pas possible pour eux d'utiliser des sprites CSS aussi agressivement que ce serait optimal.
Un site comme StackOverflow, cependant, est léger sur ce genre d'images et ils ont réduit le nombre de demandes tellement qu'ils n'ont pas besoin de faire de la fragmentation. Un grand pas vers ce qui se passe est leur utilisation de ce sprites.Image png...
Http://cdn.sstatic.net/Sites/stackoverflow/img/sprites.png?v=5
Mise à jour #2
Steve Souders a posté une autre mise à jour sur le partage de domaine. Il répète une grande partie de ce que j'ai déjà mentionné. Mais la chose qui se démarquait était SPDY et comment cela devrait affecter votre décision.
Peut-être l'argument le plus fort contre le sharding de domaine est que c'est inutile dans le monde de SPDY (ainsi que HTTP 2.0). Effectivement, le sharding de domaine blesse probablement les performances sous SPDY. SPDY prend en charge requêtes simultanées (envoyer tous les en-têtes de requête au début) ainsi que demande de priorisation. Le partage entre plusieurs domaines diminue ces avantages. SPDY est pris en charge par Chrome, Firefox, Opera et IE 11. Si votre trafic est dominé par ces navigateurs, vous pouvez ignorer le domaine la fragmentation.
Mise à jour # 3 (février 2018)
Comme Dean l'a mentionné dans les commentaires ci-dessous, les sprites CSS ne vous achètent pas vraiment maintenant avec HTTP/2 pris en charge dans les navigateurs modernes. Mais vous devez obtenir un certificat SSL, configurer votre site pour qu'il fonctionne avec HTTPS et vous assurer que votre serveur web est configuré pour HTTP/2. Soit cela, soit utilisez un CDN qui a déjà tout cela mis en place pour vous. Une fois que vous avez fait tout cela, vous pouvez probablement ignorer les deux sprites CSS et domaine de la fragmentation.
Google chrome a :6, Safari a: 5, mozilla firefox a: 8 requête get simultanée maximale au même domaine.