Perché non incorporare stili / script in HTML invece del collegamento?

Concateniamo file CSS e JavaScript per ridurre il numero di richieste HTTP, migliorando le prestazioni. Il risultato è HTML come questo:

<link rel="stylesheet" href="all-my-css-0fn392nf.min.css">
<!-- later... -->
<script src="all-my-js-0fn392nf.min.js"></script>

Se abbiamo una logica lato server / build per fare tutto questo per noi, perché non fare un ulteriore passo avanti e incorporare quegli stili e script concatenati nell'HTML?

<style>.all{width:100%;}.my{display:none;}.css{color:white;}</style>
<!-- later... -->
<script>var all, my, js;</script>

Sono due le richieste HTTP in meno, ma non ho visto questa tecnica in pratica. Perchè no?

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

L'HTML di questa pagina, ad esempio, è 13 KB in questo momento. I 180 KB di CSS hanno colpito la cache, così come i 360 KB di JS. Entrambi gli accessi alla cache hanno richiesto una minuscola quantità di tempo e praticamente non hanno consumato larghezza di banda. Montare il profiler di rete del browser e provarlo su altri siti.

Semplicemente perché le prestazioni Web contano davvero! Il 99% delle volte offre tempi di risposta più rapidi per l'utente finale.

Ecco alcuni esempi di Velocity Conf.

• Bing : una pagina più lenta 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 / utente.
• Yahoo ! - Un rallentamento di 400 millisecondi ha comportato un calo del 5-9% nel traffico a tutta pagina.
• Shopzilla - L'accelerazione del sito di 5 secondi ha aumentato il tasso di conversione del 7-12%, ha raddoppiato il numero di sessioni dal marketing dei motori di ricerca e ha dimezzato il numero di server richiesti.
• Mozilla - La rasatura di 2,2 secondi dalle pagine di destinazione ha aumentato le conversioni di download del 15,4%, che stimano comporterà 60 milioni di download di Firefox in più all'anno.
• Netflix : l'adozione di una singola ottimizzazione, la compressione gzip, ha portato a una velocità del 13-25% e ha ridotto del 50% il traffico di rete in uscita.

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

L'80-90% del tempo di risposta dell'utente finale viene impiegato nel frontend: iniziare prima da qui.

L'uso di file esterni produce pagine più veloci perché i file JavaScript e CSS sono memorizzati nella cache dal browser / reti / proxy (come definito nel protocollo HTTP con le intestazioni della cache). JavaScript e CSS incorporati nei documenti HTML vengono scaricati ogni volta che viene richiesto il documento HTML. Ciò riduce il numero di richieste HTTP necessarie, ma aumenta la dimensione del documento HTML. Se stai usando script simili a Jquery, è facile aggiornare 300 KB di script e non credi che tutti abbiano una larghezza di banda di 100 MBits / s con bassa latenza, eseguendo una singola applicazione - il browser - aperta sul tuo sito web. Il 99% delle volte offre tempi di risposta più rapidi per l'utente finale.

È anche importante la frequenza con cui i componenti JavaScript e CSS esterni vengono memorizzati nella cache in relazione al numero di documenti HTML richiesti. 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), i potenziali file esterni memorizzati nella cache offrono un vantaggio maggiore.

In linea di principio, tuttavia, è preferibile per applicazioni a pagina singola o siti Web con una visualizzazione a pagina singola per sessione. Non esiste una regola d'oro, e generalmente la dimentica in quanto riguarda principalmente siti Web molto specifici realmente coinvolti dalle prestazioni dell'utente finale.

Puoi leggere qui perché le prestazioni contano (Disclaimer: sono l'autore)

L'ultima versione di HTTP è stata creata nel lontano 1999. Nel 1999, tutti si sono connessi a Internet con la connessione remota. Internet è stato molto lento. 16 anni dopo, le cose sono cambiate molto, ma i protocolli che usiamo non lo sono.

Le risposte che non dovremmo includere "perché interferiscono con la memorizzazione nella cache" sono un po 'fuorvianti, in particolare nell'era di Internet superveloce. Quando si eseguono effettivamente i calcoli, c'è spesso una differenza trascurabile tra i tempi di caricamento con gli utenti cache-warm e cache-cold se sono stati incorporati. Il fatto che ci sia una piccola differenza non è intrinsecamente dovuto al fatto che è stato inserito, ma a causa della progettazione inflessibile di HTTP / 1.1.

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

HTTP / 2.0 si basa 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 dell'eredità: i protocolli attualmente esistenti sono vecchi e non sono abbastanza flessibili da ottenere un "allineamento a livello di protocollo".

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

JavaScript che appare in HTML può incorrere 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 il tuo script per sfuggire ad alcuni caratteri che si attivano in HTML. Questo problema scompare quando si forniscono CSS e JavaScript come risorse esterne, poiché non devono più tenere conto del contesto di analisi "principale".

Se offri i tuoi contenuti come XML, hai una soluzione parziale usando le sezioni CDATA. CDATA, tuttavia, presenta 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 interni sono attenti.

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

La separazione di tutti gli stili consente e incoraggia il riutilizzo e i file condivisi.

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

Alla tua domanda specifica però ... Se il server è fatto per eseguire la minificazione stessa, rende le risorse più difficili da gestire e da correggere. Tuttavia molti framework ora lo fanno a livello di file, ad esempio tutti i CS e tutti i J. Ad esempio, il framework ruby ​​on rails ora riduce i suoi asset per la produzione. 5-10 richieste HTTP aggiuntive non sono di solito il collo di bottiglia, è più se ci sono più di 100 richieste HTTP (che spesso si ottengono con le immagini).

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

1. Riduci al minimo la codifica duplicata. per risparmiare tempo (è possibile riutilizzare lo stile e la funzione JS codificati per una pagina).
2. Ridurre al minimo lo sforzo di cambiamento. (Se il tuo cliente ti chiede di cambiare il colore dei pulsanti del sito Web. Devi andare una pagina alla 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 il download. Ma i CSS comuni JS non devono essere scaricati più e più volte).
4. Utilizzo remoto. (puoi posizionare i tuoi CSS comuni js JS in un luogo remoto. non lo stesso server ospitato)
5. Ridurre i tempi di correzione dei bug. Se esiste un bug in una funzione, è necessario andare pagina per pagina per correggere i bug in JS e CSS incorporati.
6. Aumentare la SEO (semplicemente separare i contenuti con i metadati)
7. Più pulito e comprensibile del codice (se si incorpora tutto in un file, il debug e la chiarezza del codice scompaiono. Ogni pagina sarà una pagina molto lunga).
8. Inoltre, ciò ti aiuterà a ridurre le dimensioni del prodotto.
9. Ma puoi comunque considerare di incorporare la cosa più unica nella stessa pagina.

Non dovremmo incorporare stili / script in HTML perché

Gli stili / script incorporati devono essere scaricati con ogni richiesta di pagina:

Questi stili non possono essere memorizzati nella cache dal browser e riutilizzati per un'altra pagina. Per questo motivo, si consiglia di incorporare una quantità minima di CSS / JS possibile.

invece usiamo il linking coz quando usiamo il link per legare css / script

La velocità del sito aumenta per richieste di più pagine:

Quando una persona visita per la prima volta il tuo sito Web, il suo browser scarica l'HTML della pagina corrente più i file CSS e JS collegati. Quando accedono a un'altra pagina, il loro browser deve solo scaricare l'HTML della nuova pagina, il file CSS / JS viene memorizzato nella cache, quindi non è necessario scaricarlo di nuovo. Questo può fare una grande differenza in particolare se hai uno stile e un file di script di grandi dimensioni.