2011-01-31 5 views
13

Sto cercando di ottimizzare i tempi di caricamento di un sito che ha un sacco di codice spaghetti JS. Alcuni di essi si presenta come questo:Più script JS inline rallentano il tempo di caricamento di una pagina?

<script>var x="foo";</script> 
<script>var y="bar";</script> 

Invece del codice di sane-programmatore:

<script> 
    var x="foo"; 
    var y="bar"; 
</script> 

quindi mi chiedevo se questo genere di cose in realtà fa male? A parte l'estetica, combinando gli script in un singolo tag di script si può trarre vantaggio dal tempo di caricamento?

risposta

12

Quando un browser incontra un elemento script durante il parsing di HTML di una pagina avviene quanto segue:

  1. Il browser sospende l'elaborazione del HTML.
  2. Il browser avvia un'istanza del suo interprete JavaScript.
  3. L'interprete JavaScript compila il codice JavaScript e lo aggiunge al pool JavaScript globale della pagina corrente.
  4. Il browser continua l'analisi dell'HTML, ripetendo 2. e 3. tante volte quanti sono gli elementi script nell'HTML.

Quindi, avendo più script elementi sarà rallenterà il rendering della pagina. Il minor numero di elementi script presenti nel codice HTML più veloce sarà il rendering della pagina.

Se il documento include script tramite src attrbute (ad esempio <script src="http://example.com/myscript.js">), è possibile utilizzare async attribute per ritardare l'elaborazione dello script. Questa funzione è supportata nei nuovi browser (ad esempio i browser Firefox 3.6 e Webkit based rilasciati da settembre 2010). Ma gli script integrati continueranno a bloccare l'analisi fino a quando non saranno stati interpretati.

+0

Una bella illustrazione è disponibile su http://www.growingwiththeweb.com/2014/02/async-vs-defer-attributes.html –

1

Nella misura in cui ci sono più byte da scaricare, il primo esempio è più lento.

Tuttavia, sono certo che sarà mai essere in grado di distinguere tra la micro-ottimizzazione trascurabile del secondo esempio e l'esempio precedente. Oltre all'organizzazione, non c'è motivo di preoccuparsi.

Detto questo, per l'organizzazione, mi preoccuperei sicuramente! Mantenere il codice organizzato velocizzerà i tempi di sviluppo. Mantenere tutti i tuoi JavaScript in un unico posto ti impedirà di correre alla ricerca di uno snippet.

Mi piacerebbe spostare prima tutto il codice in un file esterno e qualsiasi altra cosa in fondo al documento.

  1. Otterrai il massimo vantaggio di velocità utilizzando un file esterno (a causa del caching del browser) di qualsiasi altra cosa.
  2. Consentirà al rendering del markup di essere eseguito dal browser prima di scaricare o eseguire il codice JavaScript se si spostano i tag <script> sul piè di pagina della pagina. Questo creerà l'illusione di un download più veloce.

Per inciso, (e altrettanto banalmente) la versione più ottimizzata dello script (a parte utilizzando un file esterno) potrebbe essere:

<script> 
    var x='foo', y='bar'; 
</script> 
+0

Grazie! Probabilmente trasferirò la maggior parte del codice in file esterni. Almeno le cose che non hanno document.write in loro ... * headdesk * – Confuzed

0

Quando si digita più cose (JS nel tuo caso) su una pagina, aumenta la dimensione della pagina che rallenta in modo definitivo le prestazioni.

È necessario combinare il codice in singoli tag <script> e file js.

È possibile utilizzare Google's Page Speed (addon di Firebug), che vi proporrà su come è possibile migliorare le prestazioni del vostro sito :)

0

In realtà è meglio farlo il secondo modo che si ha. Rende il codice più facile da mantenere e leggere in quella forma. Un altro modo sarebbe utilizzare gli script esterni.

Il motivo per cui a volte lo si vede è che il sito include file diversi in momenti diversi.

+0

Quello che ho è in realtà una pagina, con diverse linee di variabili definite in questo modo, ciascuna nel proprio tag script. Semplicemente strano. – Confuzed

0

si dovrebbe assolutamente provare a utilizzare questo strumento cool cuzillion. Ti aiuterà a localizzare effetti di velocità sottile a grana fine come quello che stai menzionando.

Nel tuo caso sembra dire che c'è un effetto molto piccolo ma esistente di aprire più volte il tag.

1

C'è una differenza tra percettivo tempo di caricamento e effettivo tempo di caricamento.

Il primo è il più importante per l'utente finale. Alcuni siti non vengono mai caricati completamente perché dispongono di annunci che continuano ad aggiornare e caricare nuovi contenuti. Ecco perché la barra di stato continua a funzionare, anche quando sembra che la pagina sia finita.


La tua domanda sembra teorica, quindi tenterò una risposta teorica.

  • Quando il primo caso potrebbe essere più veloce

    Il tempo di caricamento ottimale percepito dipende da ciò che i due script fanno e che cosa il vostro sito richiede. Se il tuo sito è orientato al JS, il layout, lo stile e gli elementi HTML sono creati/controllati principalmente da JavaScript, quindi il primo modo potrebbe essere più veloce. Dovresti fare tutte le creazioni di elaborazione visiva e degli elementi nel primo script. In realtà, potresti avere una pagina HTML vuota e un sito creato esclusivamente da JS (altamente sconsigliato), ma possibile. Non è quasi mai il caso, ma in quella circostanza dovrebbero essere collocati tutti gli elementi visivi e gli elementi. Il secondo script dovrebbe includere tutto l'altro codice che un utente non noterebbe in una frazione di secondo (animazioni di presentazioni, effetti di passaggio del mouse, metodi di clic).

    Non citatemi su questo, ma penso che sia perché ogni script (nella testa HTML) viene interpretato dopo che è stato caricato, rompendo gli script necessari e non necessari potrebbe accelerare alcuni processi di pre-elaborazione.

  • Velocità rete/interpretazione | Secondo caso per la maggior parte

    La maggior parte dei siti non dipende però da JavaScript, quindi il secondo caso è il modo generale di fare le cose.Ci sono motivi di dimensioni/cache per rompere il codice personalizzato, ma per il codice non personalizzato, come i vari framework, c'è una ragione per cui non esiste un framework jQuery/Prototype combinato, per le persone che usano entrambi. Ci sono anche alcune situazioni in cui inserire codice inline (nel corpo) potrebbe essere più vantaggioso.

    Nella maggior parte dei casi è preferibile il secondo metodo o un metodo simile a quello elencato da Stephen. Ciò è solo perché si riduce l'overhead di byte che viene trasferito sulla rete; inoltre stai riducendo al minimo la quantità di caratteri che il browser deve tradurre. Il vero metodo sovra-ottimizzato sarebbe <script type="text/javascript">x='foo',y='bar';</script> (non è necessario il numero var).

Problemi correlati