Perché non incorporare stili / script in HTML invece di collegare?

Perché il salvataggio delle richieste HTTP è di scarsa utilità quando lo si ottiene interrompendo la memorizzazione nella cache. Se i fogli di stile e gli script vengono pubblicati separatamente, possono essere memorizzati nella cache molto bene e ammortizzati per molte, molte richieste a pagine molto diverse. Se sono fusi nella stessa pagina HTML, devono essere ritrasmessi a tutti. Singolo. Richiesta.

L'HTML di questa pagina, ad esempio, è attualmente di 13 KB. I 180 KB di CSS colpiscono la cache, e così pure i 360 KB di JS. Entrambi gli hit della cache richiedevano una quantità minima di tempo e consumavano praticamente nessuna larghezza di banda. Estrarre il profiler della rete del browser e provarlo su altri siti.

Semplicemente perché le prestazioni Web sono davvero importanti! Il 99% delle volte ti darà tempi di risposta più rapidi per gli utenti finali.

Ecco alcuni esempi di Velocity Conf.

• Bing : una pagina con un ritardo di 2 secondi ha comportato un calo del 4,3% delle entrate / utente.
• Google : un ritardo di 400 millisecondi ha causato un calo dello 0,59% nelle ricerche / utenti.
• Yahoo ! - Un rallentamento di 400 millisecondi ha provocato un calo del 5-9% del traffico a tutta pagina.
• Shopzilla - Accelerare il loro sito di 5 secondi ha aumentato il tasso di conversione del 7-12%, raddoppiato il numero di sessioni del marketing sui motori di ricerca e ridotto a metà il numero di server richiesti.
• Mozilla - La rasatura a 2,2 secondi dalla loro pagina di destinazione ha aumentato le conversioni di download del 15,4%, che stimano provocherà 60 milioni di download di Firefox in più all'anno.
• Netflix - L'adozione di una singola ottimizzazione, compressione gzip, ha comportato un aumento del 13-25% e ha ridotto il traffico di rete in uscita del 50%.

Da Steve Souders, pioniere nell'ottimizzazione delle prestazioni Web,

80-90% of the end-user response time is spent on the frontend - Start here first.

L'uso di file esterni produce pagine più veloci perché i file JavaScript e CSS vengono memorizzati nella cache dal browser / network / proxy (come definito nel protocollo HTTP con intestazioni di cache). JavaScript e CSS che sono inline nei documenti HTML vengono scaricati ogni volta che viene richiesto il documento HTML. Questo riduce il numero di richieste HTTP necessarie, ma aumenta la dimensione del documento HTML. Se si utilizzano script di tipo Jquery, è facile rifrare 300 KB di script e non si ritiene che tutti abbiano una larghezza di banda di 100 MB / s con bassa latenza, eseguendo una singola applicazione, il browser, aperta sul proprio sito Web. Il 99% delle volte ti darà tempi di risposta più rapidi per gli utenti finali.

Anche la frequenza con cui le componenti JavaScript e CSS esterni sono memorizzate nella cache rispetto al numero di documenti HTML richiesti è importante. Se gli utenti del tuo sito hanno più visualizzazioni di pagina per sessione e molte delle tue pagine riutilizzano gli stessi script e fogli di stile (bundle), esiste un potenziale vantaggio maggiore dai file esterni memorizzati nella cache.

Tuttavia, l'allineamento è preferibile a volte per l'applicazione di una sola pagina o per i siti Web con una singola visualizzazione di pagina per sessione. Non esiste una regola d'oro, e in genere la dimenticherò poiché riguarda principalmente siti web molto specifici realmente coinvolti dalle prestazioni dell'utente finale.

Puoi leggere here perché la performance è importante ( Disclaimer: I am the author)

L'ultima versione di HTTP è stata creata nel lontano 1999. Nel 1999, tutti si collegava a Internet con dial-up. Internet era molto lento. 16 anni dopo, le cose si sono spostate molto, ma i protocolli che usiamo non lo sono.

Le risposte che non dovremmo inlineing perché interferiscono con il caching sono un po 'fuorvianti, in particolare nell'era di Internet superveloce. Quando si eseguono i calcoli, spesso vi è una differenza trascurabile tra i tempi di caricamento con gli utenti cache-warm e cache-cold se si è inline. Il fatto che ci sia una piccola differenza non è intrinsecamente perché hai inline, ma a causa del design inflessibile di HTTP / 1.1.

Il protocollo SPDY implementa qualcosa chiamato server push . Questo essenzialmente prende inlining dal documento HTML stesso e nel protocollo. Un server intelligente saprà quali risorse ha già il client. Un server stupido semplicemente invierà tutto a prescindere - questo sarà comunque un vantaggio in termini di prestazioni, ma potrebbe costare in termini di larghezza di banda. Se il browser ha il contenuto nella sua cache, può semplicemente scartare le copie in arrivo. Il server attende il caricamento dell'HTML prima di inviare le risorse aggiuntive: in teoria il browser può inviare un segnale per annullare il push del server.

HTTP / 2.0 è basato su SPDY e molto probabilmente implementerà il push del server, ma in teoria è possibile iniziare a utilizzare SPDY oggi. Quindi la vera ragione per cui non siamo in linea è quella del passato: i protocolli attualmente esistenti sono vecchi e non sono sufficientemente flessibili da raggiungere "l'inlining a livello di protocollo".

Oltre alla memorizzazione nella cache e al recupero delle preoccupazioni sollevate dalle altre risposte, vorrei evidenziare un altro problema più oscuro: analisi .

JavaScript visualizzato in HTML può essere eseguito in problemi di analisi, come in questo esempio:

<html>
<head>
<script>
function myfunc() {
    if ("</style> isn't a problem")
        return "but </script> is"
}
</script>
<style>
body::after {
  content: '</script> is okay, but not </style>'
}
</style>
</head>
<body>
<script>document.write(myfunc())</script>
</body>
</html>

... il che significa che dovresti trasformare lo script per evitare alcuni caratteri attivati in HTML. Questo problema scompare quando fornisci CSS e JavaScript come risorse esterne, perché non devono più tenere conto del contesto di analisi "principale".

Se pubblichi i tuoi contenuti in formato XML, puoi fare un giro parziale usando le sezioni CDATA. CDATA, tuttavia, ha un problema simile:

<?xml version="1.0" encoding="utf-8"?>
<html>
<head>
<script>
// <![CDATA[
function myfunc() {
    if ("</script> is no longer a problem")
        return "but ]]> is"
}
// ]]>
</script>
<style>
<![CDATA[
body::after {
  content: 'same ]]> issue here'
}
]]>
</style>
</head>
<body>
<script>document.write(myfunc())</script>
</body>
</html>

Gli Inliner sono attenti.

La separazione del contenuto dallo stile della sua presentazione è di solito un vantaggio maggiore rispetto a un minor numero di richieste http.

Separare tutti gli stili abilita e incoraggia il riutilizzo e i file condivisi.

Il contenuto dei file sarà anche più statico e disponibile per la memorizzazione nella cache su server e client sia per quella pagina sia per le altre pagine visitate.

Per te una domanda specifica però ... Se il server è fatto per eseguire il minitaggio stesso, rende le risorse più difficili da mantenere e risolvere i problemi. Tuttavia molti framework ora lo fanno a livello di file, ad es. tutti i cs e tutti i js. Ad esempio il framework ruby on rails ora riduce le sue risorse per la produzione. Di solito, 5-10 richieste http extra non sono il collo di bottiglia, più se ci sono più di 100 richieste http (che spesso si ottengono con le immagini).

Il passo ulteriore di includere effettivamente il codice nelle pagine stesse avrebbe lo svantaggio di pagine più grandi che dovresti gestire con attenzione la sequenza di download e la pagina non è in grado di visualizzare il contenuto spesso senza il resto della (ora grande) in fase di download.

1. Riduci al minimo la codifica duplicata. per risparmiare tempo (puoi riutilizzare lo stile e la funzione JS codificata per una pagina).
2. Riduci al minimo lo sforzo di modifica. (Se il tuo cliente ti chiede di cambiare il colore del pulsante del sito web, devi andare una pagina per volta).
3. Riduci il tempo di caricamento (se il tuo CSS e JS sono duplicati significa che le dimensioni delle singole pagine aumentano e richiedono molto tempo per essere scaricate, ma il CSS JS comune non è necessario scaricarlo più e più volte).
4. Utilizzo remoto. (puoi posizionare il tuo comune CSS js JS in un posto remoto, non lo stesso server ospitato)
5. Riduci i tempi di correzione dei bug. Se c'è un bug in una funzione devi andare pagina per pagina per correggere gli errori in JS e CSS incorporati.
6. Per aumentare il SEO (semplicemente separare il contenuto con i metadati)
7. Pulitore e comprensibile del codice (se si incorpora tutto in un file debug e la chiarezza del codice è andata via e ogni pagina sarà una pagina molto lunga).
8. Inoltre, questo ti aiuterà a ridurre le dimensioni del prodotto.
9. Ma puoi comunque considerare di incorporare la cosa più unica nella stessa pagina.