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 du monde réel - J'ai plusieurs pages html qui 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 distinct, un pour chaque page html?
Merci.
javascript
html
performance
frontend
Dan Burzo
la source
la source
La maintenabilité est certainement une raison pour les garder externes, mais si la configuration est une ligne (ou en général plus courte que la surcharge HTTP que vous auriez pour rendre ces fichiers externes), il est préférable de les garder 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 cela devient sans importance au moment où votre code est plus long que quelques lignes et 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 alors.
la source
L'externalisation du javascript est l'une des règles de performance de Yahoo: http://developer.yahoo.com/performance/rules.html#external
Alors que la règle absolue selon laquelle vous devez toujours externaliser les scripts sera généralement un bon pari, dans certains cas, vous souhaiterez peut-être intégrer certains des scripts et des styles. Cependant, vous ne devez inclure que les éléments dont vous savez qu'ils amélioreront les performances (car vous avez mesuré cela).
la source
Si vous ne vous souciez que des performances, la plupart des conseils de ce fil de discussion sont totalement faux et deviennent de plus en plus faux à l'ère 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. Dans l'ensemble, l'augmentation des performances en réorchestrant votre html peut être assez dramatique.
Pour obtenir les meilleures performances, vous devez considérer les pages comme des fusées à deux étages. Ces deux étapes correspondent à peu près à des phases
<head>et<body>, mais pensez-y plutôt comme<static>et<dynamic>. La partie statique est essentiellement une constante de chaîne que vous enfoncez le plus rapidement possible dans le tube de réponse. Cela peut être un peu délicat si vous utilisez beaucoup d'intergiciels qui définissent des cookies (ceux-ci doivent être définis avant d'envoyer du contenu http), mais en principe, il s'agit simplement de vider le tampon de réponse, espérons-le avant de sauter dans un code de modèle (razor, php, etc) sur le serveur. Cela peut sembler difficile, mais je l'explique simplement mal, car c'est presque trivial. Comme vous l'avez peut-être deviné, cette partie statique doit contenir tous les javascript incorporés et minifiés. Cela ressemblerait à quelque chose commeComme il ne vous coûte presque rien d'envoyer cette partie sur le fil, vous pouvez vous attendre à ce que le client commence à recevoir cela quelque part environ 5 ms + latence après la connexion à votre serveur. En supposant que le serveur est raisonnablement proche, cette latence pourrait être comprise entre 20 ms et 60 ms. Les navigateurs commenceront à traiter cette section dès qu'ils l'obtiendront, et le temps de traitement dominera normalement le temps de transfert d'un facteur 20 ou plus, qui est maintenant votre fenêtre amortie pour le traitement côté serveur de la
<dynamic>partie.Il faut environ 50 ms au navigateur (chrome, le reste peut-être 20% plus lent) pour traiter jquery + signalr + angular + ng animate + ng touch + ng routes + lodash. C'est assez étonnant en soi. La plupart des applications Web ont moins de code que toutes ces bibliothèques populaires réunies, mais disons que vous en avez autant, donc nous gagnerions une latence + 100 ms de traitement sur le client (cette victoire de latence provient du deuxième bloc de transfert). Au moment où le deuxième morceau arrive, nous avons traité tout le code js et les modèles et nous pouvons commencer à exécuter des transformations dom.
Vous pouvez objecter que cette méthode est orthogonale au concept d'inlining, mais ce n'est pas le cas. Si vous, au lieu de créer un lien vers des cdns ou vos propres serveurs, le navigateur devra ouvrir une ou plusieurs autres connexions et retarder l'exécution. Puisque cette exécution est fondamentalement gratuite (comme le côté serveur parle à la base de données), il doit être clair que tous ces sauts coûteraient plus cher que de ne faire aucun saut du tout. S'il y avait une bizarrerie du navigateur qui disait que les js externes s'exécutaient plus rapidement, nous pourrions mesurer quel facteur domine. Mes mesures indiquent que les demandes supplémentaires tuent les 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 vérité, la latence et l'exécution dominent souvent. Les bibliothèques minifiées que j'ai répertoriées ajoutent jusqu'à 300 Ko de données, et ce n'est que 68 Ko gzippés, ou 200 ms de téléchargement sur un téléphone 2 mbit 3g / 4g, ce qui est exactement la latence qu'il faudrait sur le même téléphone pour vérifier s'il avait les mêmes données dans son cache déjà, même s'il était mis en cache par proxy, car la taxe de latence mobile (latence téléphone-tour) s'applique toujours. Pendant ce temps, les connexions de bureau qui ont une latence de premier saut plus faible ont généralement une bande passante plus élevée de toute façon.
En bref, pour le moment (2014), il est préférable d'intégrer tous les scripts, styles et modèles.
EDIT (MAI 2016)
Alors que les applications JS continuent de croître et que certaines de mes charges utiles empilent maintenant jusqu'à 3+ mégaoctets de code minifié, il devient évident qu'au moins les bibliothèques courantes ne devraient plus être intégrées.
la source
Je pense que le cas de script court et spécifique à une page est (uniquement) un cas défendable pour le script en ligne
la source
En fait, il existe un cas assez solide pour utiliser du javascript en ligne. Si le js est assez petit (one-liner), j'ai tendance à préférer le javascript en ligne à cause de deux facteurs:
jQueryvous pouvez utiliser les méthodesliveoudelegatepour contourner cela, mais je trouve que si le js est suffisamment petit, il est préférable de le mettre simplement en ligne.la source
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 du CSP interdisent tous les scripts en ligne, ce qui rend votre site plus résistant aux attaques XSS.
la source
Je jetterais un œil au code requis et le diviserais en autant de fichiers séparés que nécessaire. Chaque fichier js ne contiendrait qu'un "ensemble logique" de fonctions, etc. 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 mettez en ligne votre site, vous pouvez optimiser en combinant chaque fichier js dont une page a besoin en un seul fichier.
la source
La seule défense que je peux offrir pour le javascipt en ligne est que lorsque vous utilisez des vues fortement typées avec .net MVC, vous pouvez vous référer aux variables c # mid javascript que j'ai trouvées utiles.
la source
Trois considérations:
la source
Les scripts externes sont également plus faciles à déboguer à l'aide de Firebug. J'aime tester en bloc mon JavaScript et avoir toutes les aides externes. Je déteste voir JavaScript dans le code PHP et HTML, cela me semble être un gros gâchis.
la source
Sur le point de garder JavaScript externe:
ASP.NET 3.5SP1 a récemment introduit une fonctionnalité pour créer une ressource de script composite (fusionner un ensemble 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 grand aura un meilleur taux de compression que de nombreux fichiers plus petits (également moins de surcharge http, aller-retour, etc.). Je suppose que cela économise sur 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
la source
Un autre avantage caché des scripts externes est que vous pouvez facilement les exécuter via un vérificateur de syntaxe comme jslint . Cela peut vous éviter de nombreux bugs IE6 déchirants et difficiles à trouver.
la source
Dans votre scénario, il semble que l'écriture des éléments externes dans un fichier partagé entre les pages serait bon pour vous. Je suis d'accord avec tout ce qui a été dit ci-dessus.
la source
Au début du prototypage, gardez votre code en ligne pour bénéficier d'une itération rapide, mais assurez-vous de le rendre entièrement externe au moment où vous atteignez la production.
J'oserais même dire que si vous ne pouvez pas placer tout votre Javascript à l'extérieur, alors vous avez une mauvaise conception entre vos mains, et vous devriez refactoriser vos données et vos scripts
la source
Google a inclus les temps de chargement dans ses mesures de classement de page, si vous intégrez beaucoup, il faudra plus de temps aux araignées pour explorer votre page, cela peut avoir une influence sur le classement de votre page si vous en avez trop inclus. dans tous les cas, différentes stratégies peuvent avoir une influence sur votre classement.
la source
Eh bien, je pense que vous devriez utiliser en ligne lors de la création de sites Web d'une seule page, car les scripts n'auront pas besoin d'être partagés sur plusieurs pages
la source
Essayez toujours d'utiliser des J externes car les js en ligne sont toujours difficiles à maintenir.
De plus, il est professionnellement requis que vous utilisiez un js externe car la majorité des développeurs recommandent d'utiliser js en externe.
J'utilise moi-même des js externes.
la source