Position de l'appel d'un script jquery

Version imprimable

Bonjour,
J'appelle la librairie jquery en fin de fichier, je place derrière mes script javascripts personnels puis vient la balise </body> ; cela respecte les recommandations qu'on peut lire sur ce sujet et donc ça ressemble à cela :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 <!doctype html> <html> <head> <title>Titre de la page</title> <link rel="stylesheet" type="text/css" href="styles.css"> </head> <body> ... <script src="http://ajax.googleapis.com/ajax/libs/jquery/1/jquery.min.js"></script> <script src="mon_script.js"></script> </body> </html>
Cela dit, ça me pose un problème et c'est pourquoi je vous sollicite :
J'ai un système de fichiers en PHP avec "index.php" et plein d'autres fichiers. Quand on clic sur un lien ou qu'on soumet un formulaire, c'est systématiquement "index.php" qui est sollicité et selon la valeur du GET ou du POST, un appel de tel ou tel fichier php est fait (avec include("tot.php") par exemple).
Tout marche bien, si ce n'est que cette structure (ou façon de faire) impose que tous mes scripts javascript soient présents, même s'ils ne sont pas utiles ; ceci est du au fait que leur position est APRES l'appel de la librairie. Conséquence : le flux HTML retourné par le serveur contient du code inutile (pas bon pour la BP, le temps de chargement, etc.)
Une solution possible je pense serait de mettre l'appel JQ en haut, avant </head> par exemple, mais je quitte les recommandations évoquées plus haut ; du coup, je ne l'ai pas fait et je préfère recueillir préalablement vos expertises.
J'espère être clair et si vous avez une solution, je suis bien sur preneur.
Par avance merci.
Gilles

06/09/2015, 01h26
SylvainPV
Le positionnement des balises <script> est un sujet plus complexe qui n'y paraît. Il y a cette entrée de la FAQ : http://javascript.developpez.com/faq...positionScript ; sur laquelle j'ai moi-même contribué, mais je pense qu'elle pourrait quand même être plus étoffée. Je vais essayer d'expliquer ça clairement.

Plus un script est déclaré haut dans la page, plus vite le navigateur lancera la requête pour le télécharger ; car on n'attend pas que tout le document soit chargé, le HTML est interprété progressivement à mesure qu'il est reçu par le navigateur. C'est la même chose pour les feuilles CSS et pour toute autre ressource de la page. Bien sûr, la différence est significative uniquement si on a de gros documents, des pages HTML de plusieurs centaines de Ko. Si on regarde comment le Web a évolué, aujourd'hui le HTML est généralement bien plus léger que le reste (gros frameworks JS, CSS à rallonge, images haute définition etc...). Autrement dit, cette question du positionnement des balises <script> est pas si importante que ça. Il y a certainement des choses plus importantes en matière de performances à mettre en place sur un site web... comme charger tes pages en AJAX voire charger uniquement les données en JSON et confier le templating à JavaScript plutôt qu'à PHP. Non seulement c'est plus rapide car plus léger sur le réseau, mais ça ouvre la voie à d'autres innovations comme la compensation de latence ou même l'usage offline !

Enfin bref, s'il faut quand même répondre à la question du positionnement des balises <script>, voilà la théorie :
1. les ressources importantes, c'est-à-dire celles que tu as envie d'avoir avant même que le document n'ait fini d'être téléchargé, doivent être idéalement placées en <head>. C'est pour ça qu'on met les feuilles de style en <head>, pour avoir le document "décoré" tout de suite et pas que l'utilisateur voit un texte noir et blanc dégueu jusqu'à ce que le chargement de la page soit fini.
2. exception à la 1ère règle:
  
  Citation:
  
  un script étant susceptible de modifier le contenu de la page, il est nécessaire de bloquer l'interprétation de la page pendant le chargement et l'exécution des scripts ; placer les scripts dans le <head> réduit ainsi la vitesse d'affichage de la page ;
  
  ; on doit ce comportement notamment à document.write qui peut changer le document avant-même que celui ait fini d'être chargé. Fichu document.write, si seulement on pouvait s'en débarrasser... Attention, précision importante, ce qui est bloqué est seulement l'interprétation du HTML, pas son téléchargement qui continue en tâche de fond. Tous les navigateurs modernes savent très bien gérer ça maintenant, donc le temps de chargement total de la page est quasiment inchangé. En revanche, le délai d'attente avant que l'utilisateur commence à voir un bout de contenu de page est lui plus long, car conditionné par le chargement et l'exécution des scripts en <head>.
3. contre-exception à la règle numéro 2 : les attributs async et defer apparus avec HTML5 sur la balise <script> permettent de mieux gérer ce comportement de blocage du parser HTML, et donc d'avoir les gains de la règle 1 sans les pertes de la règle 2.
Vous suivez toujours ? Bon, un petit récapitulatif ferait du bien j'imagine :
- si vous devez supporter des navigateurs non compatibles HTML5, avez des pages HTML assez grosses et que votre site ne repose pas sur JavaScript pour fonctionner, mettez vos scripts avant la fermeture du </body>
- si vous devez supporter des navigateurs non compatibles HTML5, avez des scripts assez lourds et importants pour faire fonctionner le site, mettez vos scripts dans le <head>
- si vous supportez uniquement les navigateurs compatibles HTML5, mettez tous vos scripts dans <head> et :
  - Si le script dépend ou est requiert par d'autres scripts, ou s'il doit travailler sur le DOM une fois chargé, ajoutez l'attribut defer.
  - Si le script est indépendant et fonctionnera peu importe quand il est interprété, ajoutez l'attribut async. (exemple: monitoring, statistiques, pub...)
Dans le cas des scripts utilisant jQuery, je pense que la principale raison pour laquelle on met leurs balises <script> juste avant la fermeture du </body>, c'est qu'on est sûrs que le DOM ( le modèle document constitué par le HTML qui précède) a été interprété et on peut donc utiliser les sélecteurs jQuery sans problème. Mais ce n'est pas une obligation, on peut très bien mettre le script en <head> et utiliser $(document).ready (https://api.jquery.com/ready/) pour savoir quand le DOM est prêt.

TL;DR: si vous ne devez retenir qu'une seule option à appliquer en toutes circonstances, mettre tous les <script> dans <head> avec l'attribut defer est le meilleur compromis à toutes les situations exposées précédemment.

Autres liens explicatifs :
https://developer.mozilla.org/fr/doc...Element/script
http://www.growingwiththeweb.com/201...ttributes.html
06/09/2015, 12h49
Watilin

+1 Sylvain. J'aurais parlé des attributs async et defer si tu ne l'avais pas fait.

Je pense qu'il est temps que quelqu'un prenne la responsabilité de faire une annonce de fin de vie pour document.write :P Quelqu'un m'entend ? Mozilla ? Google ? … Apple peut-être ? :aie:
06/09/2015, 12h49
GillesV

Merci pour cette réponse détaillée.

Si je pars sur ceci :

Citation:

si vous ne devez retenir qu'une seule option à appliquer en toutes circonstances, mettre tous les <script> dans <head> avec l'attribut defer est le meilleur compromis à toutes les situations exposées précédemment.

et si j'ai bien compris, alors puisque je dois mettre mon appel de librairie JQ AVANT mes <script>, cet appel JQ sera donc aussi dans le <head>.

Ensuite, selon que mes js jouent ou pas sur le DOM, alors je leur met un attribut ou un autre (defer ou async).
06/09/2015, 17h53
SylvainPV

Exact, l'attribut defer garantit l'ordre d'exécution des scripts donc tu peux mettre tous tes scripts dans l'ordre dans <head>, jQuery en premier.
08/09/2015, 20h57
GillesV

Merci à tous pour vos précisions.