Quand devrais-je utiliser le Javascript en ligne par rapport au Javascript externe?

https://stackoverflow.com/questions/138884

02-07-2019
|

Question

J'aimerais savoir quand inclure des scripts externes ou les écrire en ligne avec le code html, en termes de performances et de facilité de maintenance.

Quelle est la pratique générale à cet égard?

Scénario réaliste: plusieurs pages HTML nécessitent une validation de formulaire côté client. Pour cela, j'utilise un plugin jQuery que j'inclus sur toutes ces pages. Mais la question est, est-ce que je:

écrire les bits de code qui configurent ce script en ligne?
inclure tous les bits dans un fichier partagé entre toutes ces pages HTML?
inclure chaque bit dans un fichier externe séparé, un pour chaque page html?

Merci.

La solution

Au moment où cette réponse a été publiée (2008), la règle était simple: tous les scripts devaient être externes. Tant pour la maintenance que pour la performance.

(Pourquoi la performance? Parce que si le code est séparé, il peut être plus facilement mis en cache par les navigateurs.)

JavaScript n'appartient pas au code HTML et, s'il contient des caractères spéciaux (tels que <, >), il crée même des problèmes.

De nos jours, l’évolutivité du Web a changé. La réduction du nombre de demandes est devenue une considération valable en raison de la latence des requêtes HTTP multiples. Cela rend la réponse plus complexe: dans la plupart des cas, le fait d’avoir JavaScript externe est toujours recommandé. Mais dans certains cas, en particulier de très petits morceaux de code, leur insertion dans le & # 8217; s HTML a du sens.

Autres conseils

La maintenabilité est certainement une raison pour les garder externes, mais si la configuration est un en une couche (ou en général plus courte que le temps système HTTP que vous obtiendrez pour rendre ces fichiers externes), il est préférable de les conserver en ligne. Rappelez-vous toujours que chaque requête HTTP génère une surcharge en termes de temps d'exécution et de trafic.

Naturellement, tout devient inutile dès lors que votre code est plus long que quelques lignes et qu'il n'est pas vraiment spécifique à une seule page. Au moment où vous voulez pouvoir réutiliser ce code, rendez-le externe. Si vous ne le faites pas, regardez sa taille et décidez ensuite.

Externaliser javascript est l’une des règles de performance de yahoo: http://developer.yahoo.com/performance/rules.html#external

Bien que la règle stricte selon laquelle vous devez toujours externaliser les scripts sera généralement un bon choix, dans certains cas, vous pouvez vouloir intégrer certains des scripts et styles. Cependant, vous ne devriez utiliser que des éléments en ligne qui, à votre connaissance, amélioreront les performances (car vous avez mesuré cela).

Si vous ne vous souciez que de la performance, la plupart des conseils de ce fil de discussion sont faussement erronés et le deviennent de plus en plus à l’époque de la SPA, où nous pouvons supposer que la page est inutile sans le code JS. J'ai passé d'innombrables heures à optimiser les temps de chargement des pages SPA et à vérifier ces résultats avec différents navigateurs. Globalement, l’augmentation des performances en ré-orchestrant votre code HTML peut être assez spectaculaire.

Pour obtenir les meilleures performances, vous devez considérer les pages comme des fusées à deux étages. Ces deux étapes correspondent approximativement aux phases <head> et <body>, mais imaginez-les plutôt comme <static> et <dynamic>. La partie statique est fondamentalement une constante de chaîne que vous enfoncez aussi rapidement que possible dans le canal de réponse. Cela peut être un peu délicat si vous utilisez beaucoup de middleware qui définissent les cookies (ceux-ci doivent être définis avant l'envoi du contenu http), mais en principe, cela efface le tampon de réponse, avant de passer à un code de template (rasoir, php, etc) sur le serveur. Cela peut sembler difficile, mais j’explique simplement que c’est faux, car c’est presque trivial. Comme vous l'avez peut-être deviné, cette partie statique devrait contenir tous les éléments javascript en ligne et minifiés. Cela ressemblerait à quelque chose comme

<!DOCTYPE html>
     <html>
         <head>
             <script>/*...inlined jquery, angular, your code*/</script>
             <style>/* ditto css */</style>
         </head>
         <body>
             <!-- inline all your templates, if applicable -->
             <script type='template-mime' id='1'></script>
             <script type='template-mime' id='2'></script>
             <script type='template-mime' id='3'></script>

Etant donné que vous ne payez pratiquement rien pour envoyer cette partie sur le réseau, vous pouvez vous attendre à ce que le client commence à la recevoir environ 5 ms + de latence après la connexion à votre serveur. En supposant que le serveur soit raisonnablement proche, cette latence peut être comprise entre 20 ms et 60 ms. Les navigateurs commenceront à traiter cette section dès qu'ils l'auront reçue et le temps de traitement dominera normalement le temps de transfert par un facteur supérieur ou égal à 20, ce qui constitue désormais votre fenêtre amortie pour le traitement côté serveur de la <=> partie.

Il faut environ 50 ms au navigateur (chrome, repos peut-être 20% plus lent) pour traiter en ligne jquery + signalr + angulaire + ng animé + ng tactile + ng route + lodash. C'est assez incroyable en soi. La plupart des applications Web ont moins de code que toutes les bibliothèques populaires mises en place, mais supposons que vous en ayez autant, nous gagnerions donc du temps de latence + 100 ms de traitement sur le client (ce gain de temps de latence provient du second bloc de transfert). À l’arrivée du deuxième bloc, nous avons traité l’ensemble du code et des modèles js et nous pouvons commencer à exécuter les transformations dom.

Vous pouvez objecter que cette méthode est orthogonale au concept en ligne, mais ce n’est pas le cas. Si vous, au lieu de vous aligner, liez à cdns ou à vos propres serveurs, le navigateur devrait ouvrir une ou plusieurs autres connexions et retarder l'exécution. Étant donné que cette exécution est fondamentalement gratuite (le côté serveur parlant à la base de données), il doit être clair que tous ces sauts coûteraient plus cher que de ne pas faire de sauts du tout. S'il y avait une bizarrerie dans le navigateur qui disait que js externe s'exécutait plus rapidement, nous pourrions mesurer quel facteur dominait. Mes mesures indiquent que les requêtes supplémentaires nuisent aux performances à ce stade.

Je travaille beaucoup avec l'optimisation des applications SPA. Il est courant que les gens pensent que le volume de données est un gros problème, alors qu’en réalité la latence et l’exécution sont souvent dominantes. Les bibliothèques minifiées que j'ai énumérées ajoutent jusqu'à 300 Ko de données, ce qui ne représente que 68 ko compressés, ou 200 ms de téléchargement sur un téléphone 3g / 4g à 2 Mbits, ce qui correspond exactement à la latence qu'il faudrait sur le même téléphone pour vérifier si les mêmes données étaient disponibles. déjà dans son cache, même s'il s'agissait d'un proxy mis en cache, car la taxe sur la latence mobile (latence de poste de travail) s'applique toujours. Pendant ce temps, les connexions de bureau qui ont une latence de premier saut inférieure ont généralement une bande passante plus élevée.

En bref, pour le moment (2014), il est préférable d’aligner tous les scripts, styles et modèles.

MODIFIER (MAI 2016)

Alors que les applications JS continuent à se développer et que certaines de mes charges utiles empilent jusqu'à 3+ mégaoctets de code minifié, il devient évident qu'au moins une bibliothèque commune ne devrait plus être en ligne.

Je pense que le est spécifique à une page, bref scénario est (uniquement) la casse défendable du script en ligne

En fait, il existe un cas assez solide pour utiliser le javascript en ligne. Si le format js est suffisamment petit (une ligne), j'ai tendance à préférer le javascript en ligne en raison de deux facteurs:

Localité . Il n'est pas nécessaire de naviguer dans un fichier externe pour valider le comportement de certains javascript
AJAX . Si vous actualisez une section de la page via AJAX, vous pouvez perdre tous vos gestionnaires DOM (onclick, etc.) de cette section, en fonction de la manière dont vous les avez liés. Par exemple, avec jQuery vous pouvez utiliser le live ou delegate méthodes pour contourner cela, mais je trouve que si le js est suffisamment petit, il est préférable de le mettre en ligne.

Une autre raison pour laquelle vous devez toujours utiliser des scripts externes est une transition plus facile vers la stratégie de sécurité du contenu (CSP). . Les valeurs par défaut CSP interdisent tout script en ligne, ce qui rend votre site plus résistant aux attaques XSS.

Je voudrais examiner le code requis et le diviser en autant de fichiers séparés que nécessaire. Chaque fichier js ne contiendrait qu'un seul & Quot; ensemble logique & Quot; des fonctions etc. un fichier pour toutes les fonctions liées à la connexion.

Ensuite, lors du développement du site sur chaque page HTML, vous n'incluez que celles qui sont nécessaires. Lorsque vous vous connectez à votre site, vous pouvez optimiser le résultat en combinant chaque fichier js d’une page à une autre.

La seule défense que je puisse offrir pour le javascript en ligne est que, lorsque vous utilisez des vues fortement typées avec .net MVC, vous pouvez vous référer aux variables c # au milieu de javascript, ce que j'ai trouvé utile.

Trois considérations:

De combien de code avez-vous besoin (les bibliothèques sont parfois un consommateur de premier ordre)?
Spécificité: ce code ne fonctionne-t-il que dans le contexte de ce document ou de cet élément spécifique?
Chaque code du document a tendance à le rendre plus long et donc plus lent. Outre que les considérations de référencement rendent évident le fait que vous réduisez au minimum les scripts internes ...

Les scripts externes sont également plus faciles à déboguer avec Firebug. J'aime effectuer des tests unitaires avec JavaScript et en disposer de toutes les aides externes. Je déteste voir JavaScript en code PHP et en HTML, cela ressemble à un gros désordre pour moi.

Sur le point de garder JavaScript externe:

ASP.NET 3.5SP1 a récemment introduit une fonctionnalité permettant de créer une ressource de script composite (fusionner plusieurs fichiers js en un seul). Un autre avantage à cela est que lorsque la compression du serveur Web est activée, le téléchargement d'un fichier légèrement plus volumineux aura un meilleur taux de compression que de nombreux fichiers plus petits (également moins de temps système (http overhead, aller-retour, etc.). Je suppose que cela enregistre le chargement initial de la page, puis la mise en cache du navigateur démarre comme mentionné ci-dessus.

ASP.NET mis à part, ce screencast explique les avantages plus en détail: http://www.asp.net/learn/3.5-SP1/ video-296.aspx

Un autre avantage caché des scripts externes est que vous pouvez les exécuter facilement via un vérificateur de syntaxe tel que jslint . Cela peut vous éviter de nombreux bogues IE6 déchirants et difficiles à trouver.

Dans votre scénario, il semblerait qu’il serait bon d’écrire les éléments externes dans un fichier partagé entre les pages. Je suis d'accord avec tout ce qui a été dit ci-dessus.

Au début du prototypage, conservez votre code en ligne pour une itération rapide, mais veillez à le rendre entièrement externe au moment de la production.

J'oserais même dire que si vous ne pouvez pas placer tout votre Javascript en externe, vous avez un mauvais design entre vos mains et vous devez refactoriser vos données et vos scripts

Google a inclus les temps de chargement dans ses mesures de classement de page. Si vous utilisez beaucoup d’alignements, les spiders mettront plus de temps à parcourir la page, ce qui peut influer sur le classement de votre page si vous devez en inclure beaucoup. dans tous les cas, différentes stratégies peuvent avoir une influence sur votre classement.

eh bien, je pense que vous devriez utiliser inline lorsque vous créez des sites Web à page unique, car les scripts n'auront pas besoin d'être partagés sur plusieurs pages

Essayez toujours d’utiliser des Js externes car js en ligne est toujours difficile à maintenir.

De plus, il est professionnellement requis d’utiliser un js externe car la majorité des développeurs recommandent d’utiliser js en externe.

J'utilise moi-même des js externes.

Licencié sous: CC-BY-SA avec attribution

Non affilié à StackOverflow