Se ti preoccupi solo delle prestazioni, la maggior parte dei consigli in questo thread è completamente sbagliata e sta diventando sempre più sbagliata nell'era SPA, dove possiamo presumere che la pagina sia inutile senza il codice JS. Ho trascorso innumerevoli ore a ottimizzare i tempi di caricamento della pagina SPA e a verificare questi risultati con diversi browser. Su tutta la linea l'aumento delle prestazioni riorganizzando il tuo HTML, può essere abbastanza drammatico.
Per ottenere le migliori prestazioni, devi pensare alle pagine come a razzi a due stadi. Queste due fasi corrispondono approssimativamente a <head>e <body>fasi, ma pensali invece come <static>e <dynamic>. La parte statica è fondamentalmente una costante di stringa che spinge giù il tubo di risposta il più velocemente possibile. Questo può essere un po 'complicato se usi un sacco di middleware che imposta i cookie (questi devono essere impostati prima di inviare il contenuto http), ma in linea di principio sta semplicemente svuotando il buffer di risposta, si spera prima di saltare in un codice di template (rasoio, php, ecc.) sul server. Può sembrare difficile, ma poi lo sto solo spiegando male, perché è quasi banale. Come avrai intuito, questa parte statica dovrebbe contenere tutti i javascript incorporati e minimizzati. Sembrerebbe qualcosa del genere
<!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>
Dal momento che non ti costa quasi nulla inviare questa porzione via cavo, puoi aspettarti che il client inizierà a riceverla da qualche parte circa 5ms + latenza dopo la connessione al tuo server. Supponendo che il server sia ragionevolmente vicino questa latenza potrebbe essere compresa tra 20 e 60 ms. I browser inizieranno a elaborare questa sezione non appena la ottengono e il tempo di elaborazione normalmente dominerà il tempo di trasferimento per il fattore 20 o più, che è ora la finestra ammortizzata per l'elaborazione lato server della <dynamic>porzione.
Ci vogliono circa 50ms per il browser (Chrome, resto forse più lento del 20%) per elaborare jquery in linea + signalr + angular + ng animate + ng touch + ng route + lodash. È piuttosto sorprendente in sé e per sé. La maggior parte delle app Web ha meno codice di tutte quelle popolari librerie messe insieme, ma diciamo che ne hai altrettanto, quindi vinceremo latenza + 100 ms di elaborazione sul client (questa vincita di latenza viene dal secondo blocco di trasferimento). Quando arriva il secondo pezzo, abbiamo elaborato tutto il codice js e i modelli e possiamo iniziare a eseguire le trasformazioni dom.
Potresti obiettare che questo metodo è ortogonale al concetto in linea, ma non lo è. Se invece di inline, ti colleghi a cdns o ai tuoi server, il browser dovrebbe aprire un'altra connessione e ritardare l'esecuzione. Poiché questa esecuzione è sostanzialmente gratuita (poiché il lato server sta parlando con il database), deve essere chiaro che tutti questi salti costerebbero di più rispetto a non fare affatto salti. Se ci fosse una stranezza del browser che dicesse che js esterno viene eseguito più velocemente, potremmo misurare quale fattore domina. Le mie misurazioni indicano che in questo momento le richieste extra uccidono le prestazioni.
Lavoro molto con l'ottimizzazione delle app SPA. È comune per le persone pensare che il volume dei dati sia un grosso problema, mentre in verità la latenza e l'esecuzione spesso dominano. Le librerie minimizzate che ho elencato aggiungono fino a 300kb di dati, e questo è solo 68 kb gzipped, o 200ms download su un telefono 2m 3g / 4g, che è esattamente la latenza che sarebbe lo stesso telefono per verificare se avesse gli stessi dati nella sua cache già, anche se era in proxy proxy, perché si applica ancora la tassa di latenza mobile (latenza da telefono a tower). Nel frattempo, le connessioni desktop che hanno una latenza di primo passaggio inferiore in genere hanno comunque una larghezza di banda maggiore.
In breve, proprio ora (2014), è meglio incorporare tutti gli script, gli stili e i modelli.
EDIT (MAGGIO 2016)
Man mano che le applicazioni JS continuano a crescere e alcuni dei miei payload ora accumulano fino a 3+ megabyte di codice minimizzato, sta diventando ovvio che almeno le librerie più comuni non dovrebbero più essere incorporate.