tl; dr
1) Crea obiettivi conrete
2) Misura prima di implementare
3) Misura dopo l'implementazione, se hai raggiunto gli obiettivi
Dal livello di dettaglio che presenti qui, è difficile dire quale sia esattamente il tuo problema e se la soluzione che cerchi di implementare risolva effettivamente questo problema.
Qual è il tuo attuale punto di dolore?
Senza saperlo, uno ha bisogno di una buona palla di vetro funzionante per aiutarti - il mio è solo rotto.
Combine several the JavaScript source files into one
In alcune circostanze, questa potrebbe essere una buona cosa da fare. A seconda del dispositivo di destinazione e / o della rete di destinazione.
-
Se stai facendo il cellulare, hai il vantaggio che, quando il file è già nella cache del browser, una seconda richiesta con il flaky - mobile è quasi sempre instabile -
le condizioni della rete sono gratuite. Quindi potrebbe essere una buona idea concatenare e minimizzare il tuo javascript. D'altra parte, il tempo di caricamento della pagina può aumentare se si riceve al primo caricamento una grande porzione di JS che deve essere prima scaricata (su una connessione forse lenta e instabile ) e quindi interpretato per il primo utilizzo del sito. Senza numeri concreti è difficile giudicare se sia accettabile per te (o per i tuoi utenti) o meno.
-
Supponiamo che tu stia mirando agli utenti desktop - anche se i dispositivi mobili sono in aumento, questo non è un obiettivo insolito - con una connessione affidabile a 50 Mbps, la domanda potrebbe essere legittima da chiedere, quali sono i benefici attesi da la tua strategia?
-
In cima: se stai sviluppando una soluzione intranet, è più difficile rispondere alla domanda sulla minificazione.
Potrebbe esserci un'altra strategia, inclusa solo una scheletro di funzionalità al primo carico e recuperare in modo dinamico JS aggiuntivo, se necessario.
Ci sono molte soluzioni a molti problemi.
Include that same, single JavaScript source file on every web page
Questa potrebbe o non potrebbe essere un'opzione valida.
At design time, it's easy to reuse existing JavaScript modules (because the existing modules must be designed as reusable modules, included on and therefore available on every web page)
La modularità è una cosa carina e con una base di codice composta da 4k LOC è la cosa più ovvia da fare per mantenere uno stato mentale sano.
At run-time, it's performant: because the user's browser (which includes mobile browsers) only has one JS source file to download; and that file is presumably already cached in the browser when it loads a second or a third web page (i.e. any page except the first
Questo è in qualche modo un punto valido. Se uno script viene interpretato per la prima volta, l'interprete produce i dati della cache ed è in grado di riutilizzare queste informazioni per offrire un'esperienza utente più rapida nelle visite successive.
D'altra parte: questo vale anche per più file JS. Una volta caricati, vengono anche memorizzati nella cache.
Is this a reasonable thing to do? Is it normal, or is it a WTF thing to do? Are there disadvantages I should consider, and are they significant?
Se non fornisci ulteriori dettagli, la risposta è: forse (non).
I hesitate because it implies code being loaded into a page, which isn't required by that page.
Quindi cosa? È la tua applicazione. Finché raggiungerai i tuoi obiettivi con il design, a chi importa? Sei al comando.