Quando dovrei usare Inline vs. Javascript esterno?

StackOverflow https://stackoverflow.com/questions/138884

Domanda

Vorrei 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 dei moduli sul lato client. Per questo utilizzo un plug-in jQuery che includo in tutte queste pagine. Ma la domanda è: devo:

  • scrivere i bit di codice che configurano questo script in linea?
  • includi tutti i bit in un file condiviso tra tutte queste pagine html?
  • includi ogni bit in un file esterno separato, uno per ogni pagina html?

Grazie.

È stato utile?

Soluzione

Al momento in cui questa risposta era stata originariamente pubblicata (2008), la regola era semplice: tutto lo script doveva essere esterno. 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 persino problemi.

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. Questo rende la risposta più complessa: nella maggior parte dei casi, avere JavaScript esterno è ancora raccomandato. Ma per alcuni casi, specialmente pezzi di codice molto piccoli, inserendoli nel codice HTML del sito & # 8217; s ha senso.

Altri suggerimenti

La manutenibilità è sicuramente un motivo per mantenerli esterni, ma se la configurazione è un one-liner (o in generale più corta dell'overhead HTTP che otterresti per rendere quei file esterni) è meglio dal punto di vista delle prestazioni mantenerli in linea. Ricorda sempre che ogni richiesta HTTP genera un sovraccarico in termini di tempo di esecuzione e traffico.

Naturalmente tutto ciò diventa irrilevante nel momento in cui il codice è più lungo di un paio di righe e non è specifico per una singola pagina. Nel momento in cui vuoi poter riutilizzare quel codice, rendilo esterno. In caso contrario, osserva le sue dimensioni e decidi quindi.

Esternalizzare javascript è una delle regole di performance di yahoo: http://developer.yahoo.com/performance/rules.html#external

Mentre la regola rigida che dovresti sempre esternalizzare gli script sarà generalmente una buona scommessa, in alcuni casi potresti voler incorporare alcuni degli script e degli stili. Tuttavia, dovresti solo incorporare cose che sai miglioreranno le prestazioni (perché l'hai misurato).

Se ti preoccupi solo delle prestazioni, la maggior parte dei consigli in questo thread è completamente sbagliata e sta diventando sempre più sbagliata nell'era della SPA, dove possiamo presumere che la pagina sia inutile senza il codice JS. Ho trascorso innumerevoli ore a ottimizzare i tempi di caricamento della pagina SPA e a verificare questi risultati con diversi browser. A livello generale, l'aumento delle prestazioni riorganizzando il tuo HTML, può essere piuttosto drammatico.

Per ottenere le migliori prestazioni, devi pensare alle pagine come a razzi a due stadi. Queste due fasi corrispondono approssimativamente alle fasi <head> e <body>, ma pensali invece come <static> e <dynamic>. La parte statica è fondamentalmente una costante di stringa che spinge giù il tubo di risposta il più velocemente possibile. 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 svuotando il buffer di risposta, si spera prima di saltare in un codice di template (razor, php, ecc.) sul server. Può sembrare difficile, ma poi lo sto solo spiegando male, perché è quasi banale. Come avrai intuito, questa parte statica dovrebbe contenere tutti i javascript incorporati e minimizzati. Sembrerebbe qualcosa di simile 

<!DOCTYPE html>
     <html>
         <head>
             <script>/*...inlined jquery, angular, your code*/</script>
             <style>/* ditto css */</style>
         </head>
         <body>
             <!-- inline all your templates, if applicable -->
             <script type='template-mime' id='1'></script>
             <script type='template-mime' id='2'></script>
             <script type='template-mime' id='3'></script>

Dal momento che non ti costa quasi nulla inviare questa porzione via cavo, puoi aspettarti che il client inizierà a riceverlo da circa 5ms + latenza dopo essersi connesso al tuo server. Supponendo che il server sia ragionevolmente vicino, questa latenza potrebbe essere compresa tra 20 e 60 ms. I browser inizieranno a elaborare questa sezione non appena la ottengono e il tempo di elaborazione normalmente dominerà il tempo di trasferimento per il fattore 20 o più, che è ora la finestra ammortizzata per l'elaborazione lato server della parte <=>.

Il browser impiega circa 50ms (chrome, resto forse più lento del 20%) per elaborare jquery in linea + signalr + angular + ng animate + ng touch + ng route + lodash. È piuttosto sorprendente in sé e per sé. La maggior parte delle app Web hanno meno codice di tutte quelle popolari librerie messe insieme, ma diciamo che ne hai altrettanto, quindi vinceremo latenza + 100 ms di elaborazione sul client (questa vincita di latenza viene dal secondo blocco di trasferimento). Quando arriva il secondo pezzo, abbiamo elaborato tutto il codice js e i modelli e possiamo iniziare a eseguire trasformazioni dom.

Potresti obiettare che questo metodo è ortogonale al concetto in linea, ma non lo è. Se invece di inline, ti colleghi a cdns o ai tuoi server, il browser dovrebbe aprire un'altra connessione e ritardare l'esecuzione. Poiché questa esecuzione è sostanzialmente gratuita (poiché il lato server sta parlando con il database), deve essere chiaro che tutti questi salti costerebbero di più rispetto a non fare affatto salti. Se ci fosse una stranezza del browser che dicesse che js esterno viene eseguito più velocemente, potremmo misurare quale fattore domina. Le mie misurazioni indicano che in questo momento le richieste extra uccidono le prestazioni.

Lavoro molto con l'ottimizzazione delle app SPA. È comune per le persone pensare che il volume dei dati sia un grosso problema, mentre in verità la latenza e l'esecuzione spesso dominano. Le librerie minimizzate che ho elencato aggiungono fino a 300kb di dati, e questo è solo 68 kb gzipped, o 200ms download su un telefono 2m 3g / 4g, che è esattamente la latenza che sarebbe lo stesso telefono per verificare se avesse gli stessi dati nella sua cache già, anche se era in proxy proxy, perché si applica ancora la tassa di latenza mobile (latenza da telefono a tower). Nel frattempo, le connessioni desktop che hanno una latenza di primo passaggio inferiore in genere hanno comunque una larghezza di banda maggiore.

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

MODIFICA (MAGGIO 2016)

Man mano che le applicazioni JS continuano a crescere e alcuni dei miei payload ora accumulano fino a 3+ megabyte di codice minimizzato, diventa ovvio che almeno le librerie più comuni non dovrebbero più essere incorporate.

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

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

  • Località . Non è necessario 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 live o delegate metodi per aggirare questo, ma trovo che se js è abbastanza piccolo è preferibile metterlo in linea.

Un altro motivo per cui dovresti sempre usare script esterni è per una transizione più semplice a Policy sulla sicurezza dei contenuti (CSP) . Le impostazioni predefinite di CSP vietano tutti gli script inline, rendendo il tuo sito più resistente agli attacchi XSS.

Darei un'occhiata al codice richiesto e lo dividerei in tutti i file separati necessari. Ogni file js conterrebbe solo un & Quot; set logico & Quot; di funzioni ecc. es. un file per tutte le funzioni relative all'accesso.

Quindi durante lo sviluppo del sito su ogni pagina html includi solo quelli necessari. Quando vai online 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 javascript inline è che quando si usano viste fortemente tipizzate con .net MVC è possibile fare riferimento a variabili c # mid javascript che ho trovato utili.

Tre considerazioni:

  • Di quanto codice hai bisogno (a volte le biblioteche sono un consumatore di prima classe)?
  • Specificità: questo codice funziona solo nel contesto di questo documento o elemento specifico?
  • Ogni codice all'interno del documento tende a renderlo più lungo e quindi più lento. Oltre a ciò le considerazioni SEO rendono ovvio che minimizzi gli script interni ...

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

Sul punto di mantenere JavaScript esterno:

ASP.NET 3.5SP1 ha recentemente introdotto funzionalità per creare una risorsa di script composito (unire un mucchio di file js in uno). Un altro vantaggio di questo è quando la compressione di Webserver è attivata, il download di un file leggermente più grande avrà un rapporto di compressione migliore rispetto a molti file più piccoli (anche meno overhead http, roundtrip ecc ...). Immagino che questo risparmi sul caricamento della pagina iniziale, quindi la cache del browser inizia come sopra menzionato.

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

Un altro vantaggio nascosto degli script esterni è che è possibile eseguirli facilmente attraverso un correttore di sintassi come jslint . Ciò può salvarti da molti bug strazianti, difficili da trovare, IE6.

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

Durante i primi prototipi, mantieni il tuo codice in linea per il beneficio di una rapida iterazione, ma assicurati di renderlo tutto esterno quando raggiungi la produzione.

Oserei persino dire che se non riesci a posizionare tutto il tuo Javascript esternamente, allora hai un cattivo design sotto le tue mani e dovresti refactoring di dati e script

Google ha incluso i tempi di caricamento nelle sue misurazioni del posizionamento delle pagine, se sei molto in linea, ci vorrà più tempo perché gli spider scorrano attraverso la tua pagina, questo potrebbe influenzare il tuo posizionamento se devi includere molto. in ogni caso strategie diverse possono influire sulla tua classifica.

bene penso che dovresti usare inline quando crei siti web a pagina singola poiché gli script non dovranno essere condivisi su più pagine

Cerca sempre di usare J esterni poiché js in linea è sempre difficile da mantenere.

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

Io stesso uso js esterni.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top