Quando dovrei usare Inline vs. External Javascript?

Mi piacerebbe sapere quando dovrei includere script esterni o scriverli in linea con il codice html, in termini di prestazioni e facilità di manutenzione.

Qual è la pratica generale per questo?

Scenario reale: ho diverse pagine html che richiedono la convalida del modulo sul lato client. Per questo io uso un plugin jQuery che includo su tutte queste pagine. Ma la domanda è: io:

  • scrivi i bit di codice che configurano questo script in linea?
  • includere tutti i bit in un file che è condiviso da tutte queste pagine html?
  • includere ogni bit in un file esterno separato, uno per ogni pagina html?

Grazie.

Al momento in cui questa risposta è stata originariamente pubblicata (2008), la regola era semplice: tutti gli script dovrebbero essere esterni. Sia per manutenzione che per prestazioni.

(Perché le prestazioni? Perché se il codice è separato, può essere più facilmente memorizzato nella cache dai browser.)

JavaScript non appartiene al codice HTML e se contiene caratteri speciali (come < , > ) crea anche problemi.

Al giorno d'oggi, la scalabilità del web è cambiata. La riduzione del numero di richieste è diventata una considerazione valida a causa della latenza di effettuare più richieste HTTP. Ciò rende la risposta più complessa: nella maggior parte dei casi, è consigliabile avere JavaScript esterno. Ma per certi casi, in particolare pezzi di codice molto piccoli, è opportuno inserirli nell'HTML del sito.

La manutenibilità è sicuramente un motivo per mantenerli esterni, ma se la configurazione è un one-liner (o in generale più breve dell’overhead HTTP che si otterrebbe per rendere questi file esterni) è meglio per le prestazioni mantenerli in linea. Ricorda sempre che ogni richiesta HTTP genera un sovraccarico in termini di tempo di esecuzione e traffico.

Naturalmente tutto questo diventa irrilevante nel momento in cui il codice è più lungo di un paio di righe e non è realmente specifico per una singola pagina. Nel momento in cui vuoi essere in grado di riutilizzare quel codice, renderlo esterno. Se non lo fai, guarda le sue dimensioni e decidi allora.

L’esternalizzazione di javascript è una delle regole di rendimento di yahoo: http://developer.yahoo.com/performance/rules.html#external

Mentre la regola dura e veloce che devi sempre esternalizzare gli script sarà generalmente una buona scommessa, in alcuni casi potresti voler integrare alcuni degli script e degli stili. Tuttavia, dovresti solo integrare le cose che sai migliorare le prestazioni (perché hai misurato questo).

Se ti interessa solo le prestazioni, la maggior parte dei consigli in questa discussione è completamente sbagliata, e sta diventando sempre più sbagliato nell’era della SPA, dove possiamo supporre che la pagina sia inutile senza il codice JS. Ho trascorso innumerevoli ore ad ottimizzare i tempi di caricamento delle pagine SPA e a verificare questi risultati con diversi browser. In tutta la linea l’aumento delle prestazioni riorientando il tuo html, può essere piuttosto drammatico.

Per ottenere la migliore performance, devi pensare alle pagine come a razzi a due stadi. Queste due fasi corrispondono approssimativamente alle fasi e , ma le considerano invece come e . La porzione statica è fondamentalmente una costante di stringa che spinge il tubo di risposta il più velocemente ansible. 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 scaricando il buffer di risposta, si spera prima di saltare in qualche codice di template (razor, php, ecc.) sul server. Può sembrare difficile, ma poi sto solo spiegando che è sbagliato, perché è quasi banale. Come avrai intuito, questa porzione statica dovrebbe contenere tutti i javascript in linea e miniati. Sarebbe qualcosa di simile

            

Dal momento che non ti serve quasi nulla per inviare questa parte sul filo, puoi aspettarti che il client inizi a ricevere questo da qualche parte intorno a 5 ms + latenza dopo essersi connesso al tuo server. Supponendo che il server sia ragionevolmente vicino, questa latenza potrebbe essere compresa tra 20 ms e 60 ms. I browser inizieranno a elaborare questa sezione non appena la ottengono e il tempo di elaborazione normalmente domina il tempo di trasferimento per il fattore 20 o più, che ora è la finestra ammortizzata per l’elaborazione lato server della parte .

Ci vogliono circa 50ms per il browser (chrome, resto forse del 20% più lento) per processare jquery in linea + signalr + angular + ng animate + ng touch + ng routes + lodash. È abbastanza sorprendente di per sé. La maggior parte delle app web ha meno codice di tutte quelle librerie popolari messe insieme, ma diciamo che ne hai altrettante, quindi dovremmo vincere latenza + 100ms di elaborazione sul client (questa vittoria di latenza deriva dal secondo blocco di trasferimento). Quando arriva il secondo blocco, abbiamo elaborato tutti i codici js e i modelli e possiamo iniziare a eseguire le trasformazioni dom.

Si può obiettare che questo metodo è ortogonale al concetto di inlining, ma non lo è. Se tu, invece di inlining, link a cdns o ai tuoi server, il browser dovrebbe aprire un’altra connessione e ritardare l’esecuzione. Dato che questa esecuzione è fondamentalmente gratuita (dal momento che il server sta parlando al database) deve essere chiaro che tutti questi salti costerebbero di più che non fare affatto salti. Se ci fosse una stranezza del browser che dice che js esterni vengono eseguiti più velocemente, potremmo misurare quale fattore domina. Le mie misurazioni indicano che richieste extra uccidono le prestazioni in questa fase.

Lavoro molto con l’ottimizzazione delle app SPA. È comune per le persone pensare che il volume dei dati sia un grosso problema, mentre in realtà la latenza e l’esecuzione spesso dominano. Le librerie miniate che ho elencato sumno fino a 300kb di dati, e questo è solo 68 kb gzip, o 200ms di download su un telefono 3m / 4g 2mbit, che è esattamente la latenza che ci vorrebbe sullo stesso telefono per verificare se avesse gli stessi dati già nella sua cache, anche se è stato inserito nella cache del proxy, perché si applica ancora la tassa di latenza mobile (da telefono a torre-latenza). Nel frattempo, le connessioni desktop che hanno una latenza del primo hop più bassa hanno in genere comunque una maggiore larghezza di banda.

In breve, al momento (2014), è meglio incorporare tutti gli script, gli stili e i modelli.

EDIT (MAGGIO 2016)

Mentre le applicazioni JS continuano a crescere e alcuni dei miei payload ora impilano fino a 3+ megabyte di codice miniato, è ovvio che almeno le librerie comuni non dovrebbero più essere in linea.

Penso che il caso specifico per una pagina, il breve script sia (solo) un caso difendibile per lo script in linea

In realtà, c’è un caso abbastanza solido per usare javascript in linea. Se il js è abbastanza piccolo (one-liner), tendo a preferire il javascript inline a causa di due fattori:

  • Località Non c’è bisogno di navigare in un file esterno per convalidare il comportamento di alcuni javascript
  • AJAX . Se stai aggiornando alcune sezioni della pagina tramite AJAX, potresti perdere tutti i gestori DOM (onclick, ecc.) Per quella sezione, a seconda di come li hai associati. Ad esempio, utilizzando jQuery puoi utilizzare i metodi live o delegate per aggirare questo problema, ma trovo che se il js è abbastanza piccolo è preferibile semplicemente inserirlo in linea.

Un altro motivo per cui è consigliabile utilizzare sempre script esterni è facilitare la transizione a Content Security Policy (CSP) . Le impostazioni predefinite CSP vietano tutto lo script inline, rendendo il tuo sito più resistente agli attacchi XSS.

Darei un’occhiata al codice richiesto e dividerlo in tutti i file separati necessari. Ogni file js contiene solo un “set logico” di funzioni, ecc. un file per tutte le funzioni relative al login.

Quindi, durante lo sviluppo del sito su ogni pagina html, includi solo quelli necessari. Quando vai a vivere con il tuo sito puoi ottimizzare combinando ogni file js di cui una pagina ha bisogno in un unico file.

L’unica difesa che posso offrire per javascipt in linea è che quando si utilizzano viste fortemente tipizzate con .net MVC, è ansible fare riferimento a variabili di c # mid javascript che ho trovato utili.

Tre considerazioni:

  • Di quanto codice hai bisogno (a volte le biblioteche sono un consumatore di prima class)?
  • Specificità: questo codice funziona solo nel contesto di questo specifico documento o elemento?
  • Ogni codice all’interno del documento tende a renderlo più lungo e quindi più lento. Inoltre, le considerazioni SEO rendono ovvio che minimizzi lo scripting interno …

Gli script esterni sono anche più facili da eseguire il debug utilizzando Firebug. Mi piace Unit Test il mio JavaScript e avere tutti gli aiuti esterni. Odio vedere JavaScript in codice PHP e HTML mi sembra un gran casino.

Al punto di mantenere JavaScript esterno:

ASP.NET 3.5SP1 ha recentemente introdotto la funzionalità per creare una risorsa di script Composite (unire un gruppo di file js in uno solo). Un altro vantaggio è quando la compressione del server Web è triggersta, il download di un file leggermente più grande avrà un rapporto di compressione migliore di molti file più piccoli (anche meno overhead HTTP, roundtrip ecc …). Immagino che questo salvi il caricamento iniziale della pagina, quindi il caching del browser entra in gioco come detto sopra.

ASP.NET a parte, questo screencast spiega i vantaggi in modo più dettagliato: http://www.asp.net/learn/3.5-SP1/video-296.aspx

Un altro vantaggio nascosto degli script esterni è che è ansible eseguirli facilmente tramite un controllo della syntax come jslint . Questo può salvarti da un sacco di bug IE6 strazianti e difficili da trovare.

Nel tuo scenario sembra che scrivere le cose esterne in un file condiviso tra le pagine sarebbe un bene per te. Sono d’accordo con tutto quanto sopra detto.

Durante la prototipazione iniziale mantieni il tuo codice in linea a beneficio di una iterazione veloce, ma assicurati di renderlo tutto esterno nel momento in cui raggiungi la produzione.

Oserei dire che se non riesci a posizionare tutti i tuoi javascript esternamente, allora hai un cattivo design sotto le tue mani e dovresti rifattorizzare i tuoi dati e script

Google ha incluso i tempi di caricamento nelle sue misure di classificazione della pagina, se inline molto, ci vorrà più tempo per gli spider a strisciare attraverso la tua pagina, questo potrebbe influenzare il ranking della tua pagina se devi includere molto. in ogni caso strategie diverse potrebbero influenzare la tua posizione.

beh, penso che dovresti usare in linea quando crei siti web a pagina singola in quanto gli script non devono essere condivisi su più pagine

Cerca sempre di usare Js esterni poiché inline js è sempre difficile da mantenere.

Inoltre, è richiesto professionalmente di utilizzare un js esterno poiché la maggior parte degli sviluppatori consiglia di utilizzare js esternamente.

Io stesso uso js esterni.