Le JavaScript référencé dans la section head doit-il être servi à partir du même nom d'hôte que le document principal?
12
J'avais l'impression que pour les meilleures performances, Javascript devrait être traité comme du contenu statique et servi à partir d'un domaine sans cookies avec des fichiers CSS, des images, etc.
Pour JavaScript référencé en tête du document et nécessaire au démarrage de la page, il doit être servi à partir du même nom d'hôte que le document principal. Étant donné que la plupart des navigateurs bloquent les autres téléchargements et le rendu jusqu'à ce que tous les fichiers JavaScript aient été téléchargés, analysés et exécutés, il est préférable d'éviter le risque d'une recherche DNS supplémentaire à ce stade du traitement.
Alors maintenant, je suis en conflit. Je ne sais pas trop ce que signifie "nécessaire pour le démarrage d'une page".
J'ai généralement deux références JavaScript, JQuery servie depuis ajax.googleapis.com et un fichier master.js qui contient principalement des gestionnaires d'événements dans la fonction $ (document) .ready (). Est-ce nécessaire pour le démarrage de la page?
Compte tenu des options disponibles (ajax.googleapis.com, domaine sans cookies statique, nom d'hôte d'origine) où mon JavaScript doit-il être servi?
Alors maintenant, je suis en conflit. Je ne sais pas trop ce que signifie "nécessaire pour le démarrage d'une page".
Cela dépend beaucoup du fonctionnement de votre site. Fondamentalement, c'est le JavaScript qui doit être exécuté avant que quelqu'un puisse utiliser la page Web.
Par exemple, si vous allez sur http://www.weather.com/ , vous pouvez voir que les gens raffinés ont décidé d'utiliser de la magie JavaScript pour fournir un indice pour le formulaire de recherche météo. C'est-à-dire que les mots Enter Zip, City or Place (e.g. Disney World)apparaissent dans le champ de saisie de texte. Malheureusement, il y a un léger retard lors du chargement de la page, du moins de mon côté. Donc, si la page est suffisamment lente à charger et que vous êtes assez rapide pour commencer à taper la saisie de texte avant l'exécution de JavaScript - ce qui n'est pas un tronçon - votre entrée peut être foutue par le JavaScript qui place aveuglément cet indice texte dans la zone de saisie.
Certes, cela pourrait être évité en vérifiant d'abord la saisie de l'utilisateur dans la zone de texte ou en abandonnant simplement cette technique anachronique. Cependant, cela ne servirait pas de très bon exemple.
Compte tenu des options disponibles (ajax.googleapis.com, domaine sans cookies statique, nom d'hôte d'origine) où mon JavaScript doit-il être servi?
Cela ne peut pas vraiment être répondu sans savoir ce que fait votre JavaScript. En outre, comme l'indique bpeterson76, cela dépend de la situation spécifique de votre site. C'est-à-dire quelle est la taille de la page? dans quelle mesure votre hôte répond-il à la demande? combien de fichiers CSS, d'images, etc. charge-t-il? combien de ressources externes charge-t-il?
Selon votre situation spécifique, cela peut être une optimisation prématurée.
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 today Personnellement, 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
George Marian
1
Google gère un énorme réseau de contenu distribué dans le monde entier qui rapproche le contenu de l'utilisateur que n'importe quel serveur que vous utilisez probablement (pensez à Akami, mais appartenant à Google). Donc, du point de vue de la vitesse, il va de soi que Google va envoyer votre fichier à l'utilisateur plus rapidement que votre serveur local ... à moins qu'ils ne soient très proches de votre serveur personnel.
Cette question a fait le tour de Stackoverflow, et la réponse ci-dessus semble toujours être le consensus. Mais d'un point de vue réaliste, les gains réalisés en hébergeant l'un contre l'autre vont être assez minimes à long terme. Vous obtiendrez de bien meilleurs avantages de la réduction, de l'optimisation et de la réduction des demandes http globales que vous examinerez où les choses sont physiquement situées. Dans les situations où cela commence à avoir de l'importance (j'ai fait un travail où une page se chargeait 1,5+ million de fois / jour, donc une amélioration de 5k signifiait 5 gigas d'économies de bande passante), il y a généralement une équipe de décideurs qui sont chargés d'examiner ces décisions.
Personnellement, j'héberge habituellement chez Google pour la seule raison qu'ils vont me donner la copie la plus à jour de ce que je recherche.
Où hébergez-vous votre JavaScript personnalisé? Domaine sans cookie statique ou nom d'hôte d'origine?
James Lawruk
Honnêtement, en dehors de (principalement) Jquery en ligne, il n'y a vraiment pas beaucoup de choses qui ne peuvent pas être liées dynamiquement. J'ai tendance à garder le vaudou au minimum, en utilisant (principalement) Jquery et l'interface utilisateur Jquery, à l'exception peut-être du plugin Datatables. Je suis un grand partisan du concept de Keep it simple (stupid) et je ne mettrai pas de code s'il n'est pas rétrocompatible, ce qui exclut beaucoup d'options. Comme je l'ai dit ci-dessus, mettre un fichier sur un domaine sans cookies n'est pas si grave.
bpeterson76
1
Une chose importante à retenir est que les navigateurs ont des limites sur le nombre de ressources qui seront téléchargées simultanément à partir du même domaine, généralement entre 2 et 6 selon le navigateur. L'utilisation d'un domaine différent permet au navigateur de télécharger plus de choses simultanément depuis votre domaine.
Donc, la meilleure solution est d'utiliser un CDN populaire comme ajax.googleapis.com car de cette façon, il n'y a pas de cookies. L'utilisateur a probablement déjà effectué la recherche DNS et peut même avoir mis en cache la ressource. Les CDN sont optimisés pour la vitesse et ont probablement un serveur proche de votre utilisateur.
Si un CDN n'est pas une option, si vous avez beaucoup de cookies ou avez beaucoup de ressources à télécharger (images, etc.), utilisez un domaine sans cookie (il suffit de faire une recherche DNS une fois de toute façon).
Si vous avez peu de ressources (un seul fichier javascript personnalisé) et peu de cookies (juste un petit identifiant de session) hébergés dans le même domaine.
Bien que les réponses ci-dessus aient disséqué la plupart de votre question, je contribuerai sur "nécessaire pour le démarrage de la page". Je traduis ceci en: ce script est-il essentiel à l'utilisation du site Web? Par expérience, la réponse est généralement non. Cependant, les cas où je voudrais:
Validation de formulaire
Une navigation basée sur JavaScript (pas idéale de toute façon)
Si la mise en page dépend de JavaScript
Si JavaScript ou une bibliothèque (comme jQuery) est utilisé pour les modifications DOM critiques
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. +1Google gère un énorme réseau de contenu distribué dans le monde entier qui rapproche le contenu de l'utilisateur que n'importe quel serveur que vous utilisez probablement (pensez à Akami, mais appartenant à Google). Donc, du point de vue de la vitesse, il va de soi que Google va envoyer votre fichier à l'utilisateur plus rapidement que votre serveur local ... à moins qu'ils ne soient très proches de votre serveur personnel.
Cette question a fait le tour de Stackoverflow, et la réponse ci-dessus semble toujours être le consensus. Mais d'un point de vue réaliste, les gains réalisés en hébergeant l'un contre l'autre vont être assez minimes à long terme. Vous obtiendrez de bien meilleurs avantages de la réduction, de l'optimisation et de la réduction des demandes http globales que vous examinerez où les choses sont physiquement situées. Dans les situations où cela commence à avoir de l'importance (j'ai fait un travail où une page se chargeait 1,5+ million de fois / jour, donc une amélioration de 5k signifiait 5 gigas d'économies de bande passante), il y a généralement une équipe de décideurs qui sont chargés d'examiner ces décisions.
Personnellement, j'héberge habituellement chez Google pour la seule raison qu'ils vont me donner la copie la plus à jour de ce que je recherche.
la source
Une chose importante à retenir est que les navigateurs ont des limites sur le nombre de ressources qui seront téléchargées simultanément à partir du même domaine, généralement entre 2 et 6 selon le navigateur. L'utilisation d'un domaine différent permet au navigateur de télécharger plus de choses simultanément depuis votre domaine.
Donc, la meilleure solution est d'utiliser un CDN populaire comme ajax.googleapis.com car de cette façon, il n'y a pas de cookies. L'utilisateur a probablement déjà effectué la recherche DNS et peut même avoir mis en cache la ressource. Les CDN sont optimisés pour la vitesse et ont probablement un serveur proche de votre utilisateur.
Si un CDN n'est pas une option, si vous avez beaucoup de cookies ou avez beaucoup de ressources à télécharger (images, etc.), utilisez un domaine sans cookie (il suffit de faire une recherche DNS une fois de toute façon).
Si vous avez peu de ressources (un seul fichier javascript personnalisé) et peu de cookies (juste un petit identifiant de session) hébergés dans le même domaine.
Bonnes ressources:
http://www.phpied.com/free-falling-waterfalls/
http://www.stevesouders.com/blog/2009/04/27/loading-scripts-without-blocking/
http://developer.yahoo.com/performance/rules.html
la source
Bien que les réponses ci-dessus aient disséqué la plupart de votre question, je contribuerai sur "nécessaire pour le démarrage de la page". Je traduis ceci en: ce script est-il essentiel à l'utilisation du site Web? Par expérience, la réponse est généralement non. Cependant, les cas où je voudrais:
Et les directives de performance YSlow de Yahoo pour référence.
la source