Strumenti per sviluppatori · Codificatore e decodificatore Base64
Immagini Base64 in linea in CSS: quando i dati: gli URI aiutano e quando fanno male
· Perché è importante
base64 prestazione
Incorporamento di un'immagine come dati Base64: URI rimuove una richiesta ma aumenta il file e annulla la memorizzazione nella cache. Questo post spiega quando vale la pena fare uno scambio e quando un file separato è più veloce.
Il foglio di stile che è cresciuto fino a raggiungere centinaia di kilobyte: l'abitudine di incorporamento di un team e come si presentava nei tempi di caricamento
Un team di sviluppo ha deciso che incorporare piccole icone come dati Base64: URI nei loro CSS ridurrebbe le richieste HTTP e migliorerebbe la velocità di caricamento della pagina. Nel corso del tempo, man mano che venivano aggiunte più icone, il foglio di stile è cresciuto fino a 400 kilobyte.
Il bundle CSS, che dovrebbe contenere regole di stile, è ora dominato dai dati dell'immagine. Il team ha misurato i tempi di caricamento e ha scoperto che la pagina era più lenta rispetto a prima dell'incorporamento, non più veloce. Il problema divenne chiaro: il foglio di stile 400-kilobyte viene scaricato a ogni caricamento di pagina e memorizzato nella cache per pagina, mentre se le icone fossero file separati, un singolo file di icone verrebbe memorizzato nella cache e condiviso su ogni pagina.
Che dati: URI inline e perché è Base64: la sintassi, il tipo di supporto e la penalità dimensionale
L'aggiunta di più pagine al sito ha peggiorato il problema, poiché ogni pagina scarica nuovamente lo stesso foglio di stile con tutte quelle immagini incorporate. Questo post spiega cos'è un data: URI, perché è Base64, in che modo l'inlining influisce sulla memorizzazione nella cache e sulle prestazioni e le regole pratiche per decidere quando vale la pena scendere a compromessi. Un dato: URL è un modo per incorporare una risorsa direttamente in un file HTML o CSS invece di collegarsi a un file esterno. La sintassi è data:mediaType;base64,encoded_bytes.
Il mediaType dichiara il tipo di risorsa che segue, ad esempio image/svg+xml per SVG, image/png per PNG o text/plain per il testo. Il flag ;base64 indica che il payload è testo con codifica Base64 anziché con codifica percentuale. Gli encoded_bytes sono i dati effettivi. Quando un browser incontra un dato: URL in una proprietà href, src o background-image, decodifica Base64 e rende la risorsa in linea. Non avviene alcuna richiesta HTTP perché la risorsa è già lì, incorporata nel documento principale. Ciò consente di risparmiare una o alcune richieste HTTP, il che è importante in un mondo HTTP/1.1 in cui ogni richiesta ha un sovraccarico.
Caching e percorso critico: perché i byte incorporati vengono scaricati nuovamente con ogni pagina che include il foglio di stile
In un mondo HTTP/2 o HTTP/3 in cui molte richieste possono essere multiplexate su una connessione, i risparmi sono minori. La penalizzazione dimensionale della codifica Base64 è immediata e significativa. Un'icona SVG che è 3 kilobyte se salvata come file XML diventa 4 kilobyte quando codificata Base64 e incorporata come dati: URI. L'aumento delle dimensioni del 33% dovuto alla codifica deve essere aggiunto a ogni pagina che include il foglio di stile. Se l'icona viene utilizzata su dieci pagine, il foglio di stile viene scaricato dieci volte, ogni volta includendo la stessa immagine codificata da 4-kilobyte.
Se l'icona fosse un file separato, l'originale di 3-kilobyte verrebbe scaricato una volta e memorizzato nella cache, quindi utilizzato dalla cache su tutte e dieci le pagine. La scelta economica è chiara per la maggior parte delle icone: i file separati sono complessivamente più piccoli. Il vantaggio dell'incorporamento si applica solo quando un'icona viene utilizzata esattamente su una pagina o su pochissime pagine e l'icona è veramente fondamentale per quella pagina. Una favicon che appare su ogni pagina non è una buona candidata per l'incorporamento; è meglio come file memorizzato nella cache separato.
Costi di analisi sul client: quanto grandi stringhe in linea vengono gestite dai parser CSS e HTML, descritti qualitativamente
Un'illustrazione una tantum utilizzata solo su una pagina di destinazione potrebbe trarre vantaggio dall'incorporamento per salvare una richiesta. La memorizzazione nella cache vanifica la maggior parte dei vantaggi dell'incorporamento dei dati: URI nei fogli di stile. Un foglio di stile viene generalmente memorizzato nella cache per giorni o settimane. Quando il foglio di stile viene scaricato, ogni risorsa in esso incorporata viene scaricata nuovamente, anche se l'immagine è già memorizzata nella cache del browser. Se il foglio di stile viene aggiornato, tutti i dati incorporati devono essere riconvalidati o scaricati nuovamente, anche se è stata modificata solo una regola CSS.
Ciò causa un sovraccarico: le modifiche ai colori o alla spaziatura attivano un nuovo download completo del foglio di stile, inclusi kilobyte di dati di immagine che non sono cambiati. Un file immagine separato può essere memorizzato nella cache in modo indipendente con le proprie intestazioni di scadenza, aggiornato separatamente e riutilizzato su fogli di stile e pagine. La cache del browser è molto più efficiente quando le risorse sono file separati rispetto a quando sono incorporate in documenti più grandi. I costi di analisi e rendering aumentano quando stringhe Base64 di grandi dimensioni vengono incorporate nei fogli di stile. Un parser CSS deve leggere l'intero foglio di stile prima di applicare le regole.
Esempio realizzato: incorporare una piccola icona SVG come testo: incollare il markup nel codificatore e assemblare i dati: URI a mano
Un foglio di stile da 400 kilobyte con Base64 incorporato contiene 400 kilobyte di testo che devono essere analizzati prima di poter applicare qualsiasi regola. Un parser HTML che esegue il rendering di una pagina con dati di grandi dimensioni: URI in un attributo di stile o una proprietà background-image deve decodificare Base64 e costruire l'immagine prima che l'elemento possa essere visualizzato. Per le icone SVG semplici questo è banale. Per immagini più complesse o icone più grandi, la decodifica e il rendering avvengono nel thread principale, bloccando potenzialmente l'interattività. Il costo qualitativo è reale ma difficile da misurare senza profilazione.
Di norma, se l'immagine incorporata è più grande di qualche kilobyte, i file separati sono più veloci. Un esempio pratico mostra l'esatto compromesso. Prendi una semplice icona freccia SVG, 1.2 kilobyte di XML. Con codifica Base64 diventa 1600 caratteri o circa 1.6 kilobyte con i dati: prefisso URL. Una regola CSS separata con immagine di sfondo: url(/icons/arrow.svg) aggiunge forse 40 bytes al foglio di stile. Il file dell'icona viene scaricato una volta, memorizzato nella cache e riutilizzato. L'incorporamento salva una richiesta HTTP per quell'icona ma aggiunge 1.6 kilobyte a ogni caricamento del foglio di stile.
Regole pratiche che reggono: risorse minuscole, critiche e monouso in linea; tutto il resto come file
Se il foglio di stile è di 50 kilobyte ed è condiviso su 20 pagine, l'incorporamento dell'icona aumenta il download totale di 32 kilobyte per visita al sito. La richiesta HTTP salvata comporta al massimo qualche centinaio di byte di sovraccarico. La richiesta viene inoltre automaticamente multiplexata in HTTP/2, eliminando la differenza di sovraccarico. Il commercio di inlining perde molto, a meno che il foglio di stile non sia piccolo, l'icona sia enorme o l'icona non appaia esattamente su una pagina e da nessun'altra parte. Le regole pratiche che sopravvivono all’esame accurato sono limitate e specifiche.
È possibile integrare risorse di piccole dimensioni, critiche e monouso. Una freccia 200-byte SVG che appare solo su una pagina insolita potrebbe essere incorporata per risparmiare sovraccarico sulla richiesta. Tutto il resto dovrebbe essere separato. La logica del percorso di rendering critico è importante: se un'icona deve essere visibile immediatamente e ogni millisecondo di tempo di caricamento costa la conversione, l'incorporamento potrebbe vincere. Per le pagine tipiche con icone tipiche, i file separati sono quasi sempre migliori. Testa entrambi gli approcci con le tue risorse effettive e misura il caricamento della pagina, i tassi di successo della cache e la cascata delle richieste.
Che cosa non copre: HTTP/2 e HTTP/3 dettagli sul multiplexing e compressione del formato immagine
Non dare per scontato che l'inlining sia un'ottimizzazione senza misurazione. Il modo più semplice per ritrovarsi con un foglio di stile gonfio è quello di incorporarlo in modo incrementale senza misurare se ogni aggiunta sia effettivamente più veloce. Il codificatore e decodificatore Base64 ti aiuta a prendere questa decisione prima di impegnarti nell'incorporamento. Incolla il markup SVG o altra fonte di icone nello strumento come testo. Fai clic su Codifica e imposta le opzioni per generare dati: URI. Lo strumento mostra la lunghezza esatta dei dati: URL. Confrontalo con la dimensione di una regola CSS separata e del file di risorse stesso.
Calcola quante pagine dovrebbero condividere il foglio di stile per pareggiare l'inlining rispetto ai file separati. Assembla i dati: URI e testali in una pagina HTML effettiva prima di inserirli nel foglio di stile. Se URI è più lungo di poche centinaia di caratteri, il costo dell'incorporamento è probabilmente maggiore del vantaggio di salvare una richiesta. Utilizza lo strumento per testare le icone e le risorse effettive, quindi misurare l'impatto sulle metriche di caricamento della pagina reale prima e dopo l'incorporamento.
In conclusione: incorpora con parsimonia e misura: come il codificatore e decodificatore Base64 ti consente di codificare il markup SVG e vedere la dimensione esatta prima di impegnarti
L’approccio performante deve essere selettivo riguardo all’inlining. Le icone utilizzate su ogni pagina o su più pagine sono file memorizzati nella cache separati. È possibile incorporare le icone utilizzate esattamente su una pagina o veramente critiche per la prima verniciatura. Misura il compromesso per le tue risorse e pagine effettive anziché seguire consigli generici. Utilizza il codificatore e decodificatore Base64 per vedere la dimensione esatta di qualsiasi risorsa incorporata prima di aggiungerla a un foglio di stile. La penalità dimensionale è reale e si moltiplica a ogni visualizzazione di pagina.
La memorizzazione nella cache e il multiplexing delle richieste hanno reso meno importante il vantaggio originale dell'inlining. Per la maggior parte delle applicazioni moderne, fogli di stile più piccoli e una migliore efficienza della cache da file separati superano il sovraccarico della richiesta. In linea con parsimonia, misura il risultato e affidati alla misurazione piuttosto che all'intuizione.