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 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 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.