Question Où dois-je mettre des balises


Réponses:


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

  1. Récupérez la page HTML (par exemple, index.html)
  2. Commencez l'analyse du code HTML
  3. L'analyseur rencontre un <script> tag 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 code HTML sur votre page.
  5. Après un certain temps, le script est téléchargé et ensuite exécuté.
  6. L'analyseur continue l'analyse du reste du document HTML.

L'étape 4 provoque une mauvaise expérience utilisateur. Votre site web arrête 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 l'attente d'un site Web à charger.

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 le reste du document en toute sécurité. Après tout, le script pourrait ont inséré son propre HTML dans le document.

Cependant, la plupart des développeurs JavaScript ne manipulent plus le DOM tandis que le document est en cours de chargement. Au lieu de cela, ils attendent que le document ait été chargé avant de le modifier. Par exemple:

<!-- index.html -->
<html>
    <head>
        <title>My Page</title>
        <script type="text/javascript" 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";
});

Parce 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 <script> des étiquettes 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 sites plus importants avec de grands scripts et feuilles de style, pouvoir télécharger le script le plus tôt possible est très important pour la performance. Si votre site ne se charge pas dans les 2 secondes, les gens iront sur un autre site.

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 supportent async et defer attributs sur les scripts. Ces attributs indiquent au navigateur qu'il est prudent de poursuivre l'analyse pendant le téléchargement des scripts.

async

<script type="text/javascript" src="path/to/script1.js" async></script>
<script type="text/javascript" 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 que le script 2 soit téléchargé et exécuté avant le script 1.

Selon http://caniuse.com/#feat=script-async, 94,57% de tous les navigateurs supportent ceci.

reporter

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

Les scripts avec l'attribut defer sont exécutés dans l'ordre (c'est-à-dire le premier 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 que le document entier a été chargé.

Selon http://caniuse.com/#feat=script-defer, 94,59% de tous les navigateurs supportent ceci. 94,92% le supportent au moins partiellement.

Une note 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 supporter ces navigateurs, veuillez lire ce premier!

Conclusion

L'état de l'art actuel est de mettre des scripts dans le <head> marquer et utiliser le async ou defer les 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 encore charger correctement sur les 6% des navigateurs qui ne supportent pas ces attributs tout en accélérant l'autre 94%.


1464
2018-06-05 21:20



Juste avant l'étiquette de corps de fermeture, comme indiqué sur

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

Mettre 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. Pendant le téléchargement d'un script, le navigateur ne lance aucun autre téléchargement, même sur des noms d'hôtes différents.


218
2018-01-12 18:18



Les tags de script non bloquants peuvent être placés n'importe où:

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

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

<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 qu'un script soit téléchargé et exécuté.
  • Indépendance des commandes:
    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 quand même.

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 charger l'API Google Maps de manière asynchrone.


56
2018-02-06 11:19



Le conseil standard, promu par Yahoo! Équipe de performance exceptionnelle, est de mettre le <script> balises à la fin du corps du document afin qu'ils 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 à propos du temps de chargement du fichier JavaScript Google Analytics:

Il y a quelques bonnes diapositives par Steve Souders (expert de la performance 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 de la page
  • quel type d'indicateurs "en cours" le navigateur affiche (par exemple "chargement" dans la barre d'état, curseur de souris sablier).

36
2018-01-12 23:37



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

Sur une note de côté: j'aime tous mes tags de script dans le <head> section car cela semble être l'endroit le plus propre.


19
2018-01-12 18:18



XHTML ne Validera pas si le script est ailleurs que dans l'élément head. s'avère qu'il peut être partout.

Vous pouvez différer l'exécution avec quelque chose comme jQuery, peu importe où il est placé (à l'exception d'un petit hit de performance lors de l'analyse).


8
2018-01-12 18:22



<script src="myjs.js"></script>
</body>

tag de script doit être utilisé toujours avant corps à proximité ou Bottom en HTML fichier.

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

vérifiez ceci si besoin: http://stevesouders.com/hpws/rule-js-bottom.php


8
2017-07-16 11:16



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

Il existe des dissidents, pour diverses raisons, en commençant par la pratique disponible pour commencer intentionnellement l'exécution avec un événement page onload.


5
2018-01-12 18:18



En fonction du script et de son utilisation, le mieux possible (en termes de chargement de la page et de temps de rendu) consiste à ne pas utiliser de balise <script> classique, mais à 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 est restituée, ce qui n'a pas d'impact sur 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, voir le post Couplage de scripts asynchrones par Steve Souders (créateur de YSlow mais maintenant chez Google).


0
2018-01-12 21:06



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

Ou la meilleure chose (si ce n'est pas un problème) est que vous pouvez faire une boîte de chargement modale, placez votre javascript au 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 incorrect.


0
2017-11-18 04:41