Ci sono troppi maybes per questo avere alcuna soluzione garantiti, ma qui si va:
1) carico del CSS in alto - caricare tutto lì, se si sta facendo un sito con più pagine. Se stai realizzando un'applicazione di una pagina (in cui esegui gallerie e feed e articoli di Twitter, ecc. Sulla stessa pagina, e puoi aprire e chiudere diverse sezioni), puoi prendere in considerazione il caricamento di CSS specifici per widget, al momento stai caricando il tuo widget (se non è necessario all'avvio).
Do NON usa @import nel tuo CSS, se vuoi che si carichi rapidamente (lo fai).
2) carica la maggior parte del tuo JS nella parte inferiore della pagina.
Non c'è praticamente nulla che non possa essere pigro-caricato, o almeno non può essere inizializzato nella parte inferiore della pagina, dopo che il DOM è pronto, e se c'è davvero, servi quelli come file separati nella parte superiore della pagina e considera come potresti riscrivere per dipendere da loro meno.
3) fai attenzione ai timer - specialmente setInterval ... ... puoi far sì che le prestazioni della tua pagina siano un sacco di problemi con i timer gestiti male.
4) sii ancora più attento con gli event-handler su elementi come scroll, ridimensionamento, spostamento del mouse o key-down. Queste cose sparano molte, molte volte al secondo, quindi se hai scritto programmi di fantasia che dipendono da loro, devi ripensare a come fai il programma (ad esempio: non eseguirlo ogni volta che il gestore si spegne).
5) servire file JS è un compromesso: Compilare JS richiede un po '. Quindi, se stai caricando 40.000 righe in un file, il tuo browser si fermerà per un po 'mentre compila tutto questo.
Se si servono 18 file separati, è necessario effettuare 18 diverse chiamate al server.
Non è bello, neanche.
Quindi un buon bilanciamento è concatenare i file insieme che SAPETE che avrete bisogno per quella pagina, e quindi caricare pigro tutto ciò che è opzionale sulla pagina (come un widget per aggiungere un commento, o la lightbox widget, ecc.).
E caricarli entrambi dopo che tutti i prodotti principali sono attivi e funzionanti, O caricarli all'ultimo secondo possibile (come quando un utente preme il pulsante "aggiungi commento").
Se hai bisogno di avere 40.000 linee caricate nella tua app, non appena inizia, poi prendi il colpo, o decidi in quale ordine puoi caricarne ciascuno, e fornisci gli indicatori di "caricamento" (che dovresti fare su lazy-load sempre) per ciascun widget finché non è pronto (caricando il JS uno alla volta).
Queste sono le linee guida per aggirare i problemi di prestazioni generali.
Le specifiche sono difficili da rispondere anche quando il sito è direttamente di fronte a voi. Utilizza la console di sviluppo di Chrome per informazioni di profilo e prestazioni di rete e prestazioni di rendering, eccetera.
Re tuo primo scenario, sarei sorpreso se così fosse - dopo tutto, il è probabile che l'immagine venga convertita in un formato interno che sarà lo stesso per base64 e per risorse esterne. –
La risposta dipende. Se non hai bisogno di tutti gli script java subito, allora potrebbe essere meglio caricarli su richiesta in seguito. Esistono strumenti lato server come Require.js che consentono di risolvere questo problema. Cioè, che combinare e minimizzare, e che a carico pigro. – eSniff