Le code Jquery doit-il entrer dans l'en-tête ou le pied de page?


Réponses:


189

Tous les scripts doivent être chargés en dernier

Dans presque tous les cas, il est préférable de placer toutes vos références de script à la fin de la page, juste avant </body>.

Si vous ne parvenez pas à le faire en raison de problèmes de création de modèles, etc., décorez vos balises de script avec l' deferattribut afin que le navigateur sache télécharger vos scripts après le téléchargement du HTML:

<script src="my.js" type="text/javascript" defer="defer"></script>

Cas de bord

Il existe cependant des cas extrêmes où vous pouvez rencontrer un scintillement de page ou d'autres artefacts lors du chargement de la page, qui peuvent généralement être résolus en plaçant simplement vos références de script jQuery dans la <head>balise sans l' deferattribut. Ces cas incluent l'interface utilisateur jQuery et d'autres addons tels que jCarousel ou Treeview qui modifient le DOM dans le cadre de leurs fonctionnalités.


Autres mises en garde

Certaines bibliothèques doivent être chargées avant le DOM ou CSS, comme les polyfills. Modernizr est l'une de ces bibliothèques qui doit être placée dans la balise head .


5
Eh bien, considérez ceci: themeforest.net/item/portfolious-professional-business-template/… . C'est un thème de site que j'ai récemment acheté et qui présente sur sa page d'accueil l'utilisation de jQuery avec jCarousel. Lorsque j'ai déplacé les blocs de script de la tête à la fin du fichier, j'ai remarqué que les images utilisées dans le carrousel seraient toutes affichées en même temps pendant le chargement de la page, alors que lorsque les fichiers de script étaient dans la tête, la page se chargerait plus facilement.
Chad Levy

5
Utilisez CSS pour définir l'état initial du contenu. CSS devrait aller dans la tête. Casser quelque chose pour faire fonctionner quelque chose d'autre n'est pas la solution. Si un visiteur doit attendre le chargement de jQuery et de tous les plugins associés avant de rendre un contenu, il se peut qu'il ne reste pas assez longtemps pour voir le contenu.
Duncan

9
ChadLevy a raison: il existe certaines conditions dans lesquelles les plugins jQuery fonctionnent mieux s'ils sont référencés dans le <head>. Si votre balisage dépend du plugin jQuery qui trie le contenu pour vous, cela n'a aucun sens de placer la référence du plugin en bas de la page, car vous allez obtenir un balisage funky dans votre page Web jusqu'à ce que les plugins se chargent. Les règles sont censées être suivies jusqu'à ce qu'elles ne fonctionnent plus, auquel cas les règles doivent être enfreintes.
Robert Harvey

2
@Duncan: Idéalement, ce serait le cas où vous pouvez contrôler toutes les dépendances. Le problème avec jQuery (plus spécifiquement des choses comme l'interface utilisateur jQuery et d'autres addons) est de par sa conception que vous ne pouvez pas avoir un contrôle complet sur leurs fonctionnalités, donc ajouter quelque chose comme des attributs de visibilité à un élément DOM afin qu'il se charge plus gracieusement pourrait ne pas être possible si un addon qui utilise cet élément ne prendra pas en compte ledit attribut. Parfois, il vaut mieux défier une simple convention que d'essayer de faire fonctionner une dépendance comme vous le souhaitez.
Chad Levy

2
@Stefan: Si vos plugins jQuery ne sont pas autorisés à manipuler le DOM, alors à quoi ça sert?
Robert Harvey

229

Placer les scripts en bas

Le problème causé par les scripts est qu'ils bloquent les téléchargements parallèles. La spécification HTTP / 1.1 suggère que les navigateurs ne téléchargent pas plus de deux composants en parallèle par nom d'hôte. Si vous diffusez vos images à partir de plusieurs noms d'hôte, vous pouvez obtenir plus de deux téléchargements en parallèle. Pendant le téléchargement d'un script, cependant, le navigateur ne lancera aucun autre téléchargement, même sur des noms d'hôte différents. Dans certaines situations, il n'est pas facile de déplacer les scripts vers le bas. Si, par exemple, le script utilise document.write pour insérer une partie du contenu de la page, il ne peut pas être déplacé plus bas dans la page. Il peut également y avoir des problèmes de portée. Dans de nombreux cas, il existe des moyens de contourner ces situations.

Une autre suggestion qui revient souvent est d'utiliser des scripts différés. L'attribut DEFER indique que le script ne contient pas document.write et indique aux navigateurs qu'ils peuvent continuer le rendu. Malheureusement, Firefox ne prend pas en charge l'attribut DEFER. Dans Internet Explorer, le script peut être différé, mais pas autant que souhaité. Si un script peut être différé, il peut également être déplacé vers le bas de la page. Cela accélérera le chargement de vos pages Web.

EDIT: Firefox prend en charge l'attribut DEFER depuis la version 3.6.

Sources:


4
J'ai vu des conseils modernes indiquant que les scripts doivent être placés en haut. Placer les scripts en bas permet aux images et autres contenus dans le corps de la page d'être chargés en parallèle, mais entraîne effectivement le chargement ultérieur des scripts de la page - tout le corps HTML doit être téléchargé avant que le navigateur ne sache. les URL de script à charger. La plupart des gens font référence au guide Yahoo, qui n'est plus précis - Firefox respecte en effet les attributs différés sur les scripts. Le report en haut entraînera un chargement de page plus rapide si vous le mesurez.
ShadowChaser

Puis-je voir des statistiques sur les vitesses de chargement des pages avec cette méthode?
Gabriel Alack

1
Firefox prend en charge l'attribut DEFER depuis la version 3.6. Source: w3schools.com/tags/att_script_defer.asp
Nikita 웃

1
Mise à jour: depuis le début / la mi-2016, tous les navigateurs modernes ont augmenté le nombre de connexions par nom d'hôte à au moins 6.
Night Owl

32

Chargez uniquement jQuery lui-même dans la tête, via CDN bien sûr.

Pourquoi? Dans certains scénarios, vous pouvez inclure un modèle partiel (par exemple, un extrait du formulaire de connexion ajax) avec du code dépendant de jQuery intégré; si jQuery est chargé en bas de page, vous obtenez une erreur "$ is not defined", bien.

Il existe bien sûr des moyens de contourner ce problème (comme ne pas intégrer de JS et ajouter à un bundle js load-at-bottom), mais pourquoi perdre la liberté des js chargés paresseusement, de pouvoir placer le code dépendant de jQuery où vous le souhaitez ? Le moteur Javascript ne se soucie pas de l'emplacement du code dans le DOM tant que les dépendances (comme jQuery en cours de chargement) sont satisfaites.

Pour vos fichiers js communs / partagés, oui, placez-les avant </body>, mais pour les exceptions, où il est vraiment logique, du point de vue de la maintenance de l'application, de coller un extrait de code dépendant de jQuery ou une référence de fichier à ce point dans le html, faites-le.

Il n'y a pas de hit de performance chargeant jquery dans la tête; quel navigateur sur la planète n'a pas déjà le fichier jQuery CDN dans le cache?

Beaucoup de bruit pour rien, colle jQuery dans la tête et laisse règne ta liberté js.


1
beaucoup de navigateurs ne le font pas; environ 2% est le chiffre le plus élevé que j'ai lu, lorsque vous prenez en compte la version et que la mise en cache des faits est basée sur des noms de ressources exacts, donc jquery1.4.2 n'est pas la même chose que jquery1.7, ou 1.9.1 ou .. .
Toni Leigh

Parmi ceux-ci 2%, disons, la moitié partira avant le chargement de la page pour la première fois. De cette façon, vous perdez 1%des visiteurs, mais vous économisez potentiellement beaucoup de temps de développement et de problèmes. Voyez si cela a du sens avec votre modèle d'entreprise ...
osa

13

Nimbuz fournit une très bonne explication du problème en cause, mais je pense que la réponse finale dépend de votre page: qu'est-ce qui est plus important pour l'utilisateur d'avoir plus tôt - des scripts ou des images?

Il y a des pages qui n'ont pas de sens sans les images, mais qui n'ont que des scripts mineurs et non essentiels. Dans ce cas, il est logique de placer les scripts en bas, afin que l'utilisateur puisse voir les images plus tôt et commencer à donner un sens à la page. D'autres pages reposent sur des scripts pour fonctionner. Dans ce cas, il est préférable d'avoir une page de travail sans images qu'une page non fonctionnelle avec des images, il est donc logique de placer les scripts en haut.

Une autre chose à considérer est que les scripts sont généralement plus petits que les images. Bien sûr, il s'agit d'une généralisation et vous devez voir si cela s'applique à votre page. Si c'est le cas, pour moi, c'est un argument pour les mettre en premier en règle générale (c'est-à-dire à moins qu'il n'y ait une bonne raison de faire autrement), car ils ne retarderont pas les images autant que les images retarderaient les scripts. Enfin, il est juste beaucoup plus facile d'avoir un script en haut, car vous n'avez pas à vous soucier de savoir s'ils sont encore chargés lorsque vous devez les utiliser.

En résumé, j'ai tendance à mettre les scripts en haut par défaut et je ne considère que s'il vaut la peine de les déplacer vers le bas une fois la page terminée. C'est une optimisation - et je ne veux pas le faire prématurément.


Vous m'avez eu jusqu'à ce que vous tiriez sur l'argument d'optimisation prématurée. C'est juste une autre règle que les gens suivent dogmatiquement sans en comprendre pleinement les implications.
Robert Harvey

6
Eh bien, je ne peux pas tous les gagner! Je suis convaincu que je comprends ses implications. :)
EMP

Je ne suis pas sûr que vous ayez à vous inquiéter si vos scripts se sont chargés. Le rendu des blocs jusqu'à ce qu'un script soit chargé, c'est le sujet principal de cette discussion. Donc, tant que vous n'appelez rien avant de le charger, tout va bien. Et en plus, c'est à cela que servent les rappels et vous ne devriez pas vraiment intégrer grand-chose d'autre dans votre page. Si je comprends bien, les images ne se bloquent pas (elles se chargent en parallèle) et en fait le DOM peut être prêt et vos scripts s'exécutent avant que les images ne soient complètement chargées. Cela n'a pas de sens de mettre les scripts en premier juste pour éviter qu'ils ne soient bloqués.
Duncan

4
Étant donné que le consensus général est de placer les scripts en bas, ne serait-il pas préférable de le faire par défaut et de les déplacer uniquement vers le haut si vous rencontrez des problèmes? Cela semble étrange de faire les choses à l'envers. Parfois, il est préférable de faire la chose optimale s'il n'y a pas de différence dans l'effort dépensé :)
Duncan

@Duncan, oui c'était mon approche. J'ai mis les plugins en bas, et quand j'avais des problèmes, je les mettais en haut, et cela a résolu les problèmes.
Robert Harvey le

6

La plupart du code jquery s'exécute lorsque le document est prêt, ce qui ne se produit pas avant la fin de la page de toute façon. De plus, le rendu de la page peut être retardé par l'analyse / l'exécution javascript, il est donc recommandé de placer tous les javascript en bas de la page.


5

La pratique standard est de mettre tous vos scripts au bas de la page, mais j'utilise ASP.NET MVC avec un certain nombre de plugins jQuery, et je trouve que tout fonctionne mieux si je mets mes scripts jQuery dans la <head>section du master page.

Dans mon cas, il y a des artefacts qui se produisent lorsque la page est chargée, si les scripts sont au bas de la page. J'utilise le plugin jQuery TreeView, et si les scripts ne sont pas chargés au début, l'arbre sera rendu sans les classes CSS nécessaires imposées par le plugin. Donc, vous obtenez ce désordre drôle lorsque la page se charge pour la première fois, suivi du rendu approprié de TreeView. Très mauvais. Mettre les plugins jQuery dans la <head>section de la page maître élimine ce problème.


Les intranets ne sont pas soumis aux mêmes conditions qu'Internet, de sorte que le délai de chargement est probablement moins perceptible. Cependant, il est toujours conseillé de suivre les règles.
Duncan

non, mettre les identificateurs / styles CSS dans le balisage (au lieu d'attendre que jQuery le fasse sur DOM prêt) résout le problème.
Dan Beam

1
@Dan Beam: l'arborescence est remplie à partir d'une table de base de données, et les styles de l'arborescence sont définis par le plugin Treeview en fonction du contenu de la table, donc non, cela ne fonctionnera pas.
Robert Harvey

1
Pourquoi ferais-je cela alors que je peux simplement mettre le script Treeview Plugin non modifié en haut de la page, et cela fonctionnera très bien? Cela n'a aucun sens, Dan.
Robert Harvey

1
Salutations Robert, j'utilise également ASP.NETMVC avec des formulaires en partiels. Il est logique de garder le javascript dans le partiel car les nouveaux champs se voient réaffecter leurs fonctionnalités à chaque fois que le partiel est exécuté (par exemple pour la validation). Je n'ai rencontré des problèmes que lors de la tentative d'utilisation @Html.Action, ce qui écrit dynamiquement un résultat dans la sortie, car mon partial donne un $ is undefinedsens, je dois plutôt utiliser .load ('@ Url.Action') pour charger le partiel. Mais cela donne un fouc en raison de la demande supplémentaire. En fonction de votre entrée, je vais simplement déplacer jquery au-dessus de RenderBody () dans ma page maître
Malkin

4

Bien que presque tous les sites Web placent toujours Jquery et d'autres javascript sur header: D, vérifiez même stackoverflow.com.

Je vous suggère également de mettre l'étiquette avant fin du corps. Vous pouvez vérifier le temps de chargement après avoir placé sur l'un ou l'autre des endroits. La balise de script suspendra votre page Web pour se charger davantage.

et après avoir placé javascript sur le pied de page, vous pouvez obtenir une apparence inhabituelle de votre page Web jusqu'à ce qu'elle charge javascript, alors placez css sur votre section d'en-tête.


2
Mais vous pouvez obtenir la même chose en utilisant defer sur le script. w3schools.com/tags/att_script_defer.asp
Jack Tuck

2

Juste avant </body>est le meilleur endroit selon Yahoo Developer Network de meilleures pratiques pour accélérer votre site Web ce lien , il est logique.

La meilleure chose à faire est de tester par vous-même.


0

Pour moi, jQuery est un peu spécial. Peut-être une exception à la norme. Il y a tellement d'autres scripts qui en dépendent, il est donc très important qu'il se charge tôt afin que les autres scripts qui viennent plus tard fonctionnent comme prévu. Comme quelqu'un d'autre l'a souligné, même cette page charge jQuery dans la section head.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.