Risposta breve: un file monolitico con un'intestazione del futuro lontano scade.
Risposta lunga: dipende. Se sei Gmail e hai più di 1 megabyte di javascript nella tua applicazione, dovrai dividerlo per ridurre il carico e migliorare l'esperienza utente. Per il resto di noi, tuttavia, la soluzione migliore che ho trovato è quella di caricare la libreria principale (come jQuery) da un CDN di terze parti (come Google). Quindi dividi in due il tuo file monolitico: lib.js e app.js . Lib dovrebbe contenere librerie di terze parti e app il tuo codice specifico del sito. L'idea generale è che raramente aggiornerai le librerie o ne aggiungerai di nuove, in modo che raramente i file vengano invalidati e scaricati in cache dagli utenti.
Utilizza una tecnica come quella descritta in questo sito per spostare quasi tutti i tag in-page <script> senza un attributo src in un file esterno:
link
Quindi quello che dovresti lasciare sono i tag <script> con src , e gli unici in linea rimanenti dovrebbero essere perché devi passare i dati dal tuo codice backend a javascript (e vuoi evitare una richiesta AJAX su caricamento della pagina che bloccherà il rendering). Supponi che lo spazio dei nomi del mio progetto sia Foo , quindi il tag in linea sarà simile a:
<script type="text/javascript">
Foo.Context = {{ js_context|safe }};
</script>
js_context è una variabile passata al mio modello dal mio backend ed è già un oggetto JSON. Le parentesi graffe e |safe sono solo dal motore di template front-end che ho usato (in questo caso, i modelli incorporati di Django). Ora il mio codice specifico della pagina, che vive in app.js , può guardare il contenuto di Foo.Context dopo che document.ready si attiva per qualsiasi variabile di cui ha bisogno evitando una richiesta AJAX iniziale.
Come al solito per i tuoi file statici, dovresti servirli con intestazioni future che scadono:
Cache-Control: public, max-age=31536000
Quando aggiorni i tuoi script, il tuo passo di costruzione dovrebbe rinominare il file concatenato e minimizzato o aggiungere un parametro di query GET alla fine del <script> src , in questo modo:
app.12345.js o app.js?v=12345
In questo modo gli utenti chiederanno il nuovo file, rompendo la cache. Come avvertenza, tieni presente che le versioni precedenti di alcuni proxy inversi (come Squid) non funzionano correttamente con i parametri GET su file statici, quindi l'ultima di queste due opzioni non funzionerebbe. Ma non mi sono mai imbattuto in questo problema, quindi la tua milizia potrebbe variare.
Quando raggiungi il livello Gmail delle dimensioni degli script, puoi iniziare a utilizzare una libreria come LABjs o RequireJS per caricare in modo dinamico solo i pezzi di app.js necessari per determinate pagine o funzionalità.
Ultimo ma non meno importante, spero che i tuoi tag <script> siano nella parte inferiore della pagina, proprio prima della chiusura di </body> . Ciò impedisce al browser di mostrare una pagina bianca vuota mentre gli script vengono scaricati, analizzati ed eseguiti. L'unica eccezione a questa regola sono le librerie che devono assolutamente essere nella funzione <head> , come Modernizr.