Où dois-je mettre les balises <script> dans le balisage HTML?

1488

Lors de l'incorporation de JavaScript dans un document HTML, où est l'endroit approprié pour placer les <script>balises et le JavaScript inclus? Je semble me rappeler que vous n'êtes pas censé les placer dans la <head>section, mais les placer au début de la <body>section est également mauvais, car le JavaScript devra être analysé avant que la page ne soit rendue complètement (ou quelque chose comme ça). Cela semble laisser la fin de la <body>section comme un endroit logique pour les <script>balises.

Alors, où est le bon endroit pour mettre les <script>balises?

(Cette question fait référence à cette question , dans laquelle il a été suggéré de déplacer les appels de fonction JavaScript des <a>balises aux <script>balises. J'utilise spécifiquement jQuery, mais des réponses plus générales sont également appropriées.)

javascript jquery html mipadi
la source
dans le cas où vous recherchez également une solution simple et que vous utilisez un générateur côté serveur comme Jekyll, je recommande plutôt d'inclure le script avec. tellement plus simple!
cregox

Réponses:

1864

Voici ce qui se passe lorsqu'un navigateur charge un site Web avec une <script>balise dessus:

  1. Récupérer la page HTML (par exemple index.html)
  2. Commencez à analyser le code HTML
  3. L'analyseur rencontre une <script>balise référençant un fichier de script externe.
  4. Le navigateur demande le fichier de script. Pendant ce temps, l'analyseur bloque et arrête l'analyse de l'autre HTML sur votre page.
  5. Après un certain temps, le script est téléchargé puis exécuté.
  6. L'analyseur continue d'analyser le reste du document HTML.

L'étape # 4 provoque une mauvaise expérience utilisateur. Votre site Web s'arrête essentiellement de charger jusqu'à ce que vous ayez téléchargé tous les scripts. S'il y a une chose que les utilisateurs détestent, c'est d'attendre qu'un site Web se charge.

Pourquoi cela arrive-t-il même?

Tout script peut insérer son propre HTML via document.write()ou d'autres manipulations DOM. Cela implique que l'analyseur doit attendre que le script ait été téléchargé et exécuté avant de pouvoir analyser en toute sécurité le reste du document. Après tout, le script pourrait pu insérer son propre code HTML dans le document.

Cependant, la plupart des développeurs JavaScript ne manipulent plus le DOM pendant le chargement du document. Au lieu de cela, ils attendent que le document soit chargé avant de le modifier. Par exemple:

<!-- index.html -->
<html>
    <head>
        <title>My Page</title>
        <script src="my-script.js"></script>
    </head>
    <body>
        <div id="user-greeting">Welcome back, user</div>
    </body>
</html>

Javascript:

// my-script.js
document.addEventListener("DOMContentLoaded", function() { 
    // this function runs when the DOM is ready, i.e. when the document has been parsed
    document.getElementById("user-greeting").textContent = "Welcome back, Bart";
});

Étant donné que votre navigateur ne sait pas que my-script.js ne va pas modifier le document tant qu'il n'a pas été téléchargé et exécuté, l'analyseur arrête l'analyse.

Recommandation désuète

L'ancienne approche pour résoudre ce problème était de mettre des <script>balises au bas de votre<body> , car cela garantit que l'analyseur n'est pas bloqué jusqu'à la fin.

Cette approche a son propre problème: le navigateur ne peut pas commencer à télécharger les scripts tant que le document entier n'est pas analysé. Pour les grands sites Web avec de grands scripts et feuilles de style, il est très important de pouvoir télécharger le script dès que possible pour les performances. Si votre site Web ne se charge pas dans les 2 secondes, les utilisateurs iront sur un autre site Web.

Dans une solution optimale, le navigateur commencerait à télécharger vos scripts dès que possible, tout en analysant le reste de votre document.

L'approche moderne

Aujourd'hui, les navigateurs prennent en charge le asyncetdefer attributs sur les scripts. Ces attributs indiquent au navigateur qu'il est sûr de continuer l'analyse pendant le téléchargement des scripts.

async

<script src="path/to/script1.js" async></script>
<script src="path/to/script2.js" async></script>

Les scripts avec l'attribut async sont exécutés de manière asynchrone. Cela signifie que le script est exécuté dès qu'il est téléchargé, sans bloquer le navigateur entre-temps.
Cela implique qu'il est possible de télécharger et d'exécuter le script 2 avant le script 1.

Selon http://caniuse.com/#feat=script-async , 97,78% de tous les navigateurs le soutiennent.

reporter

<script src="path/to/script1.js" defer></script>
<script src="path/to/script2.js" defer></script>

Les scripts avec l'attribut defer sont exécutés dans l'ordre (c'est-à-dire d'abord le script 1, puis le script 2). Cela ne bloque pas non plus le navigateur.

Contrairement aux scripts asynchrones, les scripts différés ne sont exécutés qu'après le chargement de l'intégralité du document.

Selon http://caniuse.com/#feat=script-defer , 97,79% de tous les navigateurs le soutiennent. 98,06% le soutiennent au moins partiellement.

Remarque importante sur la compatibilité du navigateur: dans certaines circonstances, IE <= 9 peut exécuter des scripts différés dans le désordre. Si vous devez prendre en charge ces navigateurs, veuillez d'abord lire ceci !

Conclusion

L'état actuel de la technique consiste à mettre des scripts dans la <head>balise et à utiliser le asyncoudefer attributs . Cela permet de télécharger vos scripts dès que possible sans bloquer votre navigateur.

La bonne chose est que votre site Web devrait toujours se charger correctement sur les 2% de navigateurs qui ne prennent pas en charge ces attributs tout en accélérant les 98% restants.

Bart
la source
63
Je suis surpris que personne n'ait cité l'explication de Google ... developers.google.com/speed/docs/insights/BlockingJS
Casey Falk
6
Je ne sais pas ce qui touche le DOM et ce qui ne le fait pas. Pouvez-vous clarifier? Est-il sûr de faire un chargement asynchrone sur quelque chose comme jquery.js?
Doug
7
@Doug Par exemple, document.writeopère sur le dom. La question n'est pas de savoir si un script manipule le dom, mais quand il le fait. Tant que toute manipulation dom se produit après le domreadydéclenchement de l'événement, vous êtes d'accord. jQuery est une bibliothèque, et en tant que telle ne manipule pas - ou ne devrait pas - le dom par lui-même.
Bart
24
Cette réponse est trompeuse. Les navigateurs modernes n'arrêtent pas d'analyser lorsqu'ils atteignent une balise de script synchrone qui peut affecter le HTML, ils arrêtent simplement le rendu / l'exécution et continuent d'analyser de manière optimiste pour commencer à télécharger d'autres ressources qui seront probablement demandées par la suite si aucun HTML n'est affecté.
Fabio Beltramini
40
Pourquoi les attributs asyncet deferne sont-ils utilisés nulle part? Je veux dire, j'ai vu beaucoup de sources HTML sur Internet, et je ne vois nulle part les attributs asyncet defer. ...?
john cj
239

Juste avant la balise de fermeture du corps, comme indiqué sur

http://developer.yahoo.com/performance/rules.html#js_bottom

Mettez les scripts au fond

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ôtes, vous pouvez obtenir plus de deux téléchargements en parallèle. Cependant, pendant le téléchargement d'un script, le navigateur ne démarre aucun autre téléchargement, même sur des noms d'hôtes différents.

Cammel
la source
7
D'accord avec le concept et son explication. Mais que se passe-t-il si l'utilisateur commence à jouer avec la page. Supposons que j'ai une liste déroulante AJAX qui commencera à se charger après que la page soit apparue à l'utilisateur mais pendant qu'elle se charge, l'utilisateur clique dessus! Et si un utilisateur «vraiment impatient» soumet le formulaire?
Hemant Tank
9
@Hermant Ancien commentaire mais vous pouvez faire l'astuce en désactivant les champs par défaut puis en les activant en utilisant JS lorsque le DOM est complètement chargé. C'est ce que Facebook semble faire de nos jours.
novato
2
Je viens de tester cela avec du chrome, pour vérifier si c'est toujours le même. C'est. Vous pouvez vérifier ici les différences de temps de chargement des pages de vos navigateurs. stevesouders.com/cuzillion
cypher
46
Si c'est la meilleure pratique, pourquoi le débordement de pile inclut-il toutes ses balises de script dans <head>? :-P
Philip
10
Dans certains cas, en particulier dans les sites lourds ajax, le chargement dans la tête peut en fait entraîner des temps de chargement plus rapides. Voir: encosia.com/dont-let-jquerys-document-ready-slow-you-down (notez que la fonction "live ()" est déconseillée dans jquery, mais l'article s'applique toujours avec le "on ()" ou " déléguer "). Le chargement dans <head> peut également être nécessaire pour garantir un comportement correct, comme indiqué par @Hermant. Enfin, modernizr.com/docs recommande de placer ses scripts dans <head> pour les raisons expliquées sur son site.
Nathan
77

Les balises de script non bloquantes peuvent être placées à peu près n'importe où:

<script src="script.js" async></script>
<script src="script.js" defer></script>
<script src="script.js" async defer></script>
  • async le script sera exécuté de manière asynchrone dès qu'il sera disponible
  • defer le script est exécuté lorsque le document a terminé l'analyse
  • async defer le script revient au comportement différé si l'async n'est pas pris en charge

Ces scripts seront exécutés de manière asynchrone / une fois le document prêt, ce qui signifie que vous ne pouvez pas faire ceci:

<script src="jquery.js" async></script>
<script>jQuery(something);</script>
<!--
  * might throw "jQuery is not defined" error
  * defer will not work either
-->

Ou ca:

<script src="document.write(something).js" async></script>
<!--
  * might issue "cannot write into document from an asynchronous script" warning
  * defer will not work either
-->

Ou ca:

<script src="jquery.js" async></script>
<script src="jQuery(something).js" async></script>
<!--
  * might throw "jQuery is not defined" error (no guarantee which script runs first)
  * defer will work in sane browsers
-->

Ou ca:

<script src="document.getElementById(header).js" async></script>
<div id="header"></div>
<!--
  * might not locate #header (script could fire before parser looks at the next line)
  * defer will work in sane browsers
-->

Cela dit, les scripts asynchrones offrent ces avantages:

  • Téléchargement parallèle des ressources : le
    navigateur peut télécharger des feuilles de style, des images et d'autres scripts en parallèle sans attendre le téléchargement et l'exécution d'un script.
  • Indépendance de l'ordre d'origine :
    vous pouvez placer les scripts à l'intérieur de la tête ou du corps sans vous soucier du blocage (utile si vous utilisez un CMS). L'ordre d'exécution compte toujours.

Il est possible de contourner les problèmes d'ordre d'exécution en utilisant des scripts externes qui prennent en charge les rappels. De nombreuses API JavaScript tierces prennent désormais en charge l'exécution non bloquante. Voici un exemple de chargement asynchrone de l'API Google Maps .

Salman A
la source
2
C'est la bonne réponse pour aujourd'hui - en utilisant cette approche, il est plus facile de garder vos widgets autonomes, pas besoin de faire preuve de <head>logique.
Daniel Sokolowski
1
Je suis confus pourquoi vous ne pouvez pas utiliser asyncou deferen incluant jQuery que vous indiquez dans votre deuxième bloc: <script src="jquery.js" async></script>. Pouvez-vous expliquer pourquoi? Je pensais que je devais avoir la balise async pour les performances - selon la réponse acceptée - afin que ma page puisse se charger même pendant que jQuery est toujours en cours de chargement]. Merci!
elbowlobstercowstand
3
@elbow 99% des fois <script src=jquery.js>est suivi de $(function(){ ... })blocs quelque part dans la page. Le chargement asynchrone ne garantit pas que jQuery sera chargé au moment où le navigateur essaie d'analyser ces blocs, donc il soulèvera $ n'est pas une erreur définie (vous ne pourrez pas obtenir l'erreur si jQuery a été chargé à partir du cache). J'ai répondu à une question sur le chargement de jQuery de manière asynchrone et la conservation $(function(){ ... }). Je vais voir si je pouvais le trouver, ou vous pouvez regarder cette question: stackoverflow.com/q/14811471/87015
Salman A
1
@SalmanA Merci! Oui, je tombe dans ce 99%. J'ai d'abord besoin de jquerylib pour charger, puis de mes .jsscripts restants . Lorsque je déclare asyncou defersur la jquerybalise lib script, mes .jsscripts ne fonctionnent pas. Je pensais $(function(){ ... })que ça protégeait - devinez pas. Solution actuelle: je n'ajoute pas deferou asyncsur le jqueryscript lib, mais j'ajoute asyncsur mes .jsscripts de suivi . Note: la raison pour laquelle je fais tout cela est de rendre Google Page Speed heureux. Merci encore pour l'aide! Tout autre conseil est le bienvenu. (Ou un lien vers votre réponse précédente). :)
elbowlobstercowstand
@elbow Voir stackoverflow.com/a/21013975/87015 , il ne vous donnera qu'une idée mais pas la solution complète. Vous pouvez plutôt rechercher «bibliothèques de chargeurs async jquery».
Salman A
38

Le conseil standard, promu par Yahoo! Équipe Performance exceptionnelle, est de mettre la<script> balises à la fin du corps du document afin qu'elles ne bloquent pas le rendu de la page.

Mais il existe des approches plus récentes qui offrent de meilleures performances, comme décrit dans cette réponse sur le temps de chargement du fichier JavaScript de Google Analytics:

Il y a quelques grandes diapositives de Steve Souders (expert en performances côté client) sur:

  • Différentes techniques pour charger des fichiers JavaScript externes en parallèle
  • leur effet sur le temps de chargement et le rendu des pages
  • quel type d'indicateurs "en cours" le navigateur affiche (par exemple "chargement" dans la barre d'état, curseur de la souris en sablier).
orip
la source
25

Si vous utilisez JQuery, placez le javascript où vous le trouvez le mieux et utilisez $(document).ready() pour vous assurer que les choses sont chargées correctement avant d'exécuter des fonctions.

Sur une note latérale: j'aime toutes mes balises de script dans la <head>section car cela semble être l'endroit le plus propre.

Andrew Hare
la source
14
dans la tête ... euh? <header>?
Dan Lugg
7
Notez que l'utilisation $(document).ready()ne signifie pas que vous pouvez placer votre JavaScript où vous le souhaitez - vous devez toujours le placer après l' <script src=".../jquery.min.js">endroit où vous incluez jQuery, de sorte qu'il $existe.
Rory O'Kane
2
Il n'est pas optimal de mettre des balises de script dans la section <head> - cela retardera l'affichage de la partie visible de la page jusqu'au chargement des scripts.
CyberMonk
Non, @Dan, un headerélément fait partie du contenu du document HTML et doit apparaître une ou plusieurs fois dans la balise head de l' bodyélément . The pour les métadonnées et les données de non-contenu du document. C'est, de nos jours, avec deferet asyncun endroit idéal pour les balises de script. headerles éléments ne doivent contenir que des informations décrivant la section du document qui le suit.
ProfK
1
@ProfK, Dan faisait référence à la question originale non modifiée lorsqu'il a posté cela il y a plus de 4 ans. Comme vous pouvez le voir, la question a été modifiée un an plus tard.
kojow7
18

L'approche moderne en 2019 utilise des scripts de type module ES6 .

<script type="module" src="..."></script>

Par défaut, les modules sont chargés de manière asynchrone et différés. c'est-à-dire que vous pouvez les placer n'importe où et ils se chargeront en parallèle et s'exécuteront à la fin du chargement de la page.

Les différences entre un script et un module sont décrites ici:

https://stackoverflow.com/a/53821485/731548

L'exécution d'un module par rapport à un script est décrite ici:

https://developers.google.com/web/fundamentals/primers/modules#defer

Le support est montré ici:

https://caniuse.com/#feat=es6-module

cquezel
la source
belle info à ajouter à la base de connaissances
Sagar
1
Juste une note que cela ne fonctionnera pas si vous essayez simplement des choses sur votre système de fichiers local sans serveur. Au moins sur Chrome, vous obtenez une erreur d'origine croisée en essayant de charger les js à partir du HTML, même s'ils ont tous deux la même origine, votre système de fichiers.
hippietrail
11

XHTML ne sera pas validé si le script est ailleurs que dans l'élément head. il se trouve que cela peut être partout.

Vous pouvez différer l'exécution avec quelque chose comme jQuery, donc peu importe où il est placé (sauf pour un petit coup de performance pendant l'analyse).

Allain Lalonde
la source
1
XHTML validera avec des balises de script dans le corps, à la fois strictes et transitoires. Les balises de style ne peuvent cependant être que dans la tête.
I.devries
11 
<script src="myjs.js"></script>
</body>

la balise de script doit toujours être utilisée avant la fermeture du corps ou en bas du fichier HTML .

vous pouvez ensuite voir le contenu de la page avant de charger le fichier js .

cochez cela si besoin: http://stevesouders.com/hpws/rule-js-bottom.php

AmanKumar
la source
2
Cela a en fait répondu à la question. Je me demandais que presque tous les exemples publiés n'avaient jamais donné le contexte visuel approprié de la "fin de la page"
Ken Ingram
1
Cette réponse est très trompeuse et probablement fausse. Les articles dans Google et dans MDN suggèrent que JS synchrone (ce qui est le cas ici) bloque toujours la construction et l'analyse DOM, ce qui entraînera un retard de premier rendu. Par conséquent, vous ne pouvez pas voir le contenu de la page jusqu'à ce que le fichier JS soit récupéré et ait terminé son exécution, quel que soit l'endroit où vous placez votre fichier JS dans le document HTML tant qu'il est synchrone
Lingaraju EV
Il fait également référence à des points soulevés en 2009 et qui ne sont plus pertinents.
toxaq
7

La réponse conventionnelle (et largement acceptée) est "en bas", car alors tout le DOM aura été chargé avant que quoi que ce soit puisse commencer à s'exécuter.

Il existe des dissidents, pour diverses raisons, à commencer par la pratique disponible pour commencer intentionnellement l'exécution avec un événement de chargement de page.

dkretz
la source
6

Le meilleur endroit pour mettre une <script>balise est avant de fermer la </body>balise , donc le téléchargement et son exécution ne bloquent pas le navigateur pour analyser le html dans le document,

Le chargement externe des fichiers js a également ses propres avantages, car il sera mis en cache par les navigateurs et peut accélérer les temps de chargement des pages , il sépare le code HTML et JavaScript et aide à mieux gérer la base de code .

mais les navigateurs modernes prennent également en charge d'autres moyens optimaux comme asyncet deferpour charger des javascriptfichiers externes .

Async et Defer

Normalement, l'exécution des pages HTML commence ligne par ligne. Lorsqu'un élément JavaScript externe est rencontré, l'analyse HTML est arrêtée jusqu'à ce qu'un JavaScript soit téléchargé et prêt à être exécuté. Cette exécution de page normale peut être modifiée à l'aide de deferet d' asyncattribut.

Defer

Lorsqu'un attribut de report est utilisé, JavaScript est téléchargé parallèlement à l'analyse HTML mais ne sera exécuté qu'après l'analyse complète du HTML.

<script src="/local-js-path/myScript.js" defer></script>

Async

Lorsque l'attribut async est utilisé, JavaScript est téléchargé dès que le script est rencontré et après le téléchargement, il sera exécuté de manière asynchrone (parallèlement) avec l'analyse HTML.

<script src="/local-js-path/myScript.js" async></script>

Quand utiliser quels attributs

  • Si votre script est indépendant des autres scripts et est modulaire, utilisez async.
  • Si vous chargez script1 et script2 avec async, les deux s'exécuteront
    parallèlement à l'analyse HTML, dès qu'ils seront téléchargés
    et disponibles.
  • Si votre script dépend d'un autre script, utilisez-le deferpour les deux:
  • Lorsque script1 et script2 sont chargés dans cet ordre avec defer, alors script1 est garanti de s'exécuter en premier,
  • Ensuite, script2 s'exécutera après l'exécution complète de script1.
  • Doit le faire si script2 dépend de script1.
  • Si votre script est suffisamment petit et dépend d'un autre script de type, asyncutilisez votre script sans attribut et placez-le au-dessus de tous les asyncscripts.

référence: knowledgehills.com

Haritsinh Gohil
la source
3

Cela dépend, si vous chargez un script qui est nécessaire pour styliser votre page / en utilisant des actions dans votre page (comme un clic sur un bouton), vous feriez mieux de le placer en haut. Si votre style est 100% CSS et que vous avez toutes les options de secours pour les actions de bouton, vous pouvez le placer en bas.

Ou la meilleure chose (si ce n'est pas un problème) est que vous pouvez créer une boîte de chargement modal, placez votre javascript en bas de votre page et faites-le disparaître lorsque la dernière ligne de votre script est chargée. De cette façon, vous pouvez éviter aux utilisateurs d'utiliser des actions dans votre page avant le chargement des scripts. Et évitez également le style inapproprié.

ahmedmzl
la source
3

L'inclusion de scripts à la fin est principalement utilisée lorsque le contenu / les styles du site Web doivent être affichés en premier.

inclure les scripts dans la tête charge les scripts tôt et peut être utilisé avant le chargement de l'ensemble du site web.

si les scripts sont enfin entrés, la validation n'aura lieu qu'après le chargement de l'ensemble des styles et du design, ce qui n'est pas apprécié pour les sites Web réactifs.

Sanjeev S
la source
2

Selon le script et son utilisation, le mieux possible (en termes de chargement de page et de temps de rendu) peut être de ne pas utiliser une balise <script> conventionnelle en soi, mais de déclencher dynamiquement le chargement du script de manière asynchrone.

Il existe différentes techniques, mais la plus simple consiste à utiliser document.createElement ("script") lorsque l'événement window.onload est déclenché. Ensuite, le script est chargé en premier lorsque la page elle-même est restituée, n'affectant ainsi pas le temps que l'utilisateur doit attendre pour que la page apparaisse.

Cela nécessite naturellement que le script lui-même ne soit pas nécessaire pour le rendu de la page.

Pour plus d'informations, consultez le post Coupling async scripts de Steve Souders (créateur de YSlow mais maintenant chez Google).

stpe
la source
2

  • Si vous vous souciez toujours beaucoup du support et des performances dans IE <10, il est préférable de TOUJOURS faire de vos balises de script les dernières balises de votre corps HTML. De cette façon, vous êtes certain que le reste du DOM a été chargé et vous ne bloquerez pas et ne rendrez pas.

  • Si vous ne vous souciez plus trop d'IE <10, vous voudrez peut-être mettre vos scripts dans la tête de votre document et les utiliser deferpour vous assurer qu'ils ne s'exécutent qu'après le chargement de votre DOM ( <script type="text/javascript" src="path/to/script1.js" defer></script>). Si vous voulez toujours que votre code fonctionne dans IE <10, n'oubliez pas de mettre votre code dans un window.onloadmême, cependant!


la source
Dans la réponse acceptée, on parle de «recommandation désuète». Si vous le pensez toujours, vous devriez probablement produire une référence pour le soutenir.
dakab
1

Le script bloque le chargement du DOM jusqu'à ce qu'il soit chargé et exécuté.

Si vous placez des scripts à la fin de <body>tous les DOM, vous avez la possibilité de charger et de rendre (la page "s'affichera" plus rapidement). <script>aura accès à tous ces éléments DOM.

En revanche, le placer après le <body>début ou au-dessus exécutera le script (où il n'y a toujours pas d'éléments DOM).

Vous incluez jQuery, ce qui signifie que vous pouvez le placer où vous le souhaitez et l'utiliser .ready ()

Szymon Toda
la source
1

Je pense que cela dépend de l'exécution de la page Web. Si la page que vous souhaitez afficher ne peut pas s'afficher correctement sans charger d'abord JavaScript, vous devez d'abord inclure le fichier JavaScript. Mais si vous pouvez afficher / rendre une page Web sans télécharger initialement le fichier JavaScript, vous devez mettre le code JavaScript au bas de la page. Parce qu'il émulera un chargement de page rapide, et du point de vue d'un utilisateur, il semblerait que cette page se charge plus rapidement.

Amit Mhaske
la source
1

Vous pouvez placer la plupart des <script>références à la fin de <body>,
mais s'il y a des composants actifs sur votre page qui utilisent des scripts externes,
alors leur dépendance (fichiers js) devrait précéder (idéalement dans la balise head).

Tech AG
la source
1

Avant la fin de la balise body afin d'empêcher et de bloquer l'interface utilisateur.

Anoop Gupta
la source
-1

À la fin du document HTML

Pour qu'il n'effectue pas le chargement du document HTML dans le navigateur au moment de l'exécution.

Mr_Blue
la source
-1

Le meilleur endroit pour écrire votre JavaScriptcode est à la fin du document après ou juste avant la </body>balise pour charger le document en premier, puis exécuter le code js.

<script> ... your code here ... </script>
</body>

Et si vous écrivez JQueryce qui suit peut être dans le document principal et il s'exécutera après le chargement du document:

<script>
$(document).ready(function(){
   //your code here...
});
</script>
nada diaa
la source
ça jetteSyntaxError
Raz
Votre réponse n'était pas fausse, mais avait vraiment besoin d'être mise à jour.
Paul Carlton
-2

Il est plus logique pour moi d'inclure le script après le HTML. Parce que la plupart du temps, j'ai besoin que le Dom se charge avant d'exécuter mon script. Je pourrais le mettre dans la balise head mais je n'aime pas tous les frais généraux de l'écouteur de chargement de documents. Je veux que mon code soit court, doux et facile à lire.

J'ai entendu dire que les anciennes versions de safari étaient quarky lors de l'ajout de votre script en dehors de la balise head, mais je dis qui s'en soucie. Je ne connais personne qui utilise cette vieille merde.

Bonne question d'ailleurs.

zachdyer
la source
-6

Vous pouvez placer où vous voulez les scripts et l'un n'est pas meilleur qu'une autre pratique.

la situation est la suivante:

La page se charge linéairement, "de haut en bas", donc si vous mettez le script dans la tête s'assure qu'il commence à se charger avant tout, maintenant, si vous le mettez à l'intérieur du corps mélangé avec le code peut provoquer des chargements de page d'une manière inesthétique.

identifier les bonnes pratiques ne dépend pas de l'endroit où.

pour vous soutenir, je mentionnerai ce qui suit:

vous pouvez placer:

et la page se chargera linéairement

la page est chargée de manière asynchrone avec d'autres contenus

le contenu de la page se chargera avant et après la fin du chargement les scripts sont chargés

la bonne pratique serait ici, quand mettra en œuvre chacun?

J'espère avoir été utile, quoi que ce soit, répondez-moi à ce problème.

Juan Miguel
la source