La règle «tout ce qui est requis avant que la page ne commence à s'afficher doit provenir du même serveur» s'applique généralement à votreserveurs ou autres ressources plus petites - situations où cette recherche DNS peut prendre une fraction notable d'une seconde (qui peut s'additionner rapidement si vos objets sont éparpillés sur de nombreux domaines). Avec des ressources publiques communes comme le cache Google de jQuery et d'autres bibliothèques, il y a de fortes chances que le navigateur de votre visiteur ait déjà effectué cette recherche DNS aujourd'hui (car d'autres sites référencent le contenu de ce service) et a probablement le fichier en cache aussi, donc non le transfert doit être effectué (ou si une demande est faite, il peut simplement récupérer une réponse courte "304 - non modifiée"). Même si un téléchargement complet est nécessaire pour l'objet, le réseau de diffusion de contenu de Google sera plus rapide pour la plupart des utilisateurs que votre opération à plus petite échelle.
Une règle connexe: les objets qui ne sont pas requis pour le bon fonctionnement de la page (comme le voit l'utilisateur) doivent être mentionnés le plus tard possible dans la réponse HTTP principale. Par exemple, des choses comme les scripts requis pour les services de publicité / statistiques (c'est-à-dire Google Analytics et ses semblables) - donnez à l'utilisateur votre contenu le plus rapidement possible, puis chargez les éléments d'arrière-plan qui ne vous intéressent vraiment. J'ai bloqué quelques services d'annonces / statistiques (en les mappant sur 127.0.0.1 dans mon fichier d'hôtes) car ils sont souvent trop lents et les sites qui s'y réfèrent tôt me donnent juste une page vierge pendant que les scripts sont attendus à la place de faire référence à eux tard pour que je puisse lire le contenu pour lequel je suis là pendant que les autres trucs traînent en arrière-plan.
L'utilité d'un domaine sans cookie pour le contenu statique est une question d'échelle. Si tout ce que vous avez est un identifiant de session de 10 octets dans les cookies et dix mille visiteurs par jour demandant ~ 20 objets statiques par visite, vous économisez seulement ~ 118 Mo de bande passante par mois (20 * 20 * 10000 * 31/1024/1024). Si, d'autre part, votre site conserve un ou deux kilo-octets de contenu dans les cookies, la différence peut être beaucoup plus importante, surtout si l'un de vos utilisateurs accède au site via des connexions lentes (par exemple, GPRS via le partage de connexion avec un mobile ou un (connexion wifi surpeuplée dans une zone à forte interférence) ou si vous obtenez des millions de visites par jour.
Pour résumer, pour les scripts qui doivent être chargés avant que la page puisse rendre mes préférences, ce serait:
- ajax.googleapis.com, ou similaire
- nom d'hôte d'origine de la page d'appel
- domaine statique sans cookie
Pour les ressources qui ne sont pas essentielles pour le rendu de page initial, faites-y référence le plus tard possible et inversez la liste de préférences ci-dessus (bien que la différence entre le nom d'hôte d'origine et le domaine sans cookie ne soit probablement pas significative, sauf si vous opérez à grande échelle). ).
With common public resources ... there is a good chance that your visitor's browser has already done that DNS lookup todayPersonnellement, je ne me sentirais pas à l'aise de me fier à cela pour mon site. Je voudrais que ce soit aussi rapide que raisonnablement possible dans autant de situations que possible. Quoi qu'il en soit, vous faites de bons arguments. +1