Quand devrais-je utiliser le Javascript en ligne par rapport au Javascript externe?
Je voudrais savoir quand je devrais 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 pour cela?
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 morceaux 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.
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 et 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, il est logique de les insérer dans le code HTML du site.
La maintenabilité est certainement une raison pour les garder externes, mais si la configuration est une ligne (ou généralement plus courte que la surcharge HTTP que vous obtiendriez 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.
L’externalisation de 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 pari, dans certains cas, vous voudrez peut-être 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 erronés, et le sont de plus en plus à l’époque du 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, parce que 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. Ça 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>
Comme cela ne vous coûte pratiquement rien d’envoyer cette partie, vous pouvez vous attendre à ce que le client commence à la recevoir quelque part au moins 5 ms 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 <dynamic>.
Il faut environ 50 ms au navigateur (chrome, repos peut-être 20% plus lent) pour traiter en ligne jquery + signalr + angulaire + ng animer + ng toucher + ng routes + 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). Au moment où le deuxième bloc arrive, nous avons traité tout le code et les 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 autre connexion 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 le facteur dominant. 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, soit 68 ko compressés, ou 200 ms de téléchargement sur un téléphone 2mbit 3g/4g, ce qui correspond exactement à la latence qu'il faudrait sur le même téléphone pour vérifier s'il dispose des mêmes données. déjà dans son cache, même s'il s'agissait d'un proxy mis en cache, car la taxe de latence pour les mobiles (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.
EDIT (MAI 2016)
Alors que les applications JS continuent à se développer et que certaines de mes charges utiles empilent maintenant jusqu'à plus de 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 spécifique à une page, cas de script court est (uniquement) un cas défendable pour le script en ligne
En fait, il existe un cas assez solide pour utiliser le javascript en ligne. Si le js est assez petit (une ligne), j'ai tendance à préférer le javascript en ligne à cause 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, en utilisant
jQuery, vous pouvez soit utiliser les méthodesliveoudelegatepour contourner cela, mais je trouve que si js est suffisamment petit, il est préférable de simplement le mettre en ligne.
Une autre raison pour laquelle vous devriez toujours utiliser des scripts externes est la transition plus facile vers Politique 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 "ensemble logique" de fonctions, par exemple. 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 ceux qui sont nécessaires. Lorsque vous vous connectez à votre site, vous pouvez l’optimiser en combinant tous les fichiers js dont une page a besoin dans un fichier.
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 # de javascript que j'ai trouvées utiles.
Trois considérations:
- De combien de code avez-vous besoin (les bibliothèques sont parfois un consommateur de premier ordre)?
- Spécificité: ce code est-il uniquement fonctionnel dans le contexte de ce document ou de cet élément spécifique?
- Chaque code dans le 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 ...
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 un groupe de 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 (moins de temps système, de trafic, etc.). Je suppose que cela enregistre le chargement initial de la page, puis la mise en cache du navigateur démarre comme indiqué ci-dessus.
ASP.NET mis à part, cette capture d'écran 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.
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 dans le code PHP et le code HTML.
Google a inclus les temps de chargement dans ses mesures de classement de page. Si vous insérez beaucoup de lignes, les robots d'exploration prendront plus de temps à parcourir votre page. Cela 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.
Dans votre scénario, il semblerait que l’écriture des éléments externes dans un fichier partagé entre les pages vous convienne. Je suis d'accord avec tout ce qui est dit ci-dessus.
Au début du prototypage, conservez votre code en ligne pour une itération rapide, mais assurez-vous de le rendre totalement externe au moment où vous atteignez 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
eh bien, je pense que vous devriez utiliser inline lorsque vous créez des sites Web d'une seule page, car les scripts n'auront pas besoin d'être partagés sur plusieurs pages.
Essayez toujours d'utiliser des Js externes, car les JS en ligne sont toujours difficiles à 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.