Immagine vuota. Cosa usare: immagine JPEG Base64 vs 1x1


11

Sto costruendo un sito Web e desidero effettuare query HTTP il meno possibile per una migliore velocità e velocità del sito Web. La pagina che ho appena creato mostra le immagini sullo scorrimento (le immagini hanno un attributo data-scr che viene convertito in src quando l'utente scorre verso il basso sull'immagine corrispondente).

Poiché tutte le immagini hanno l' data-srcattributo invece di src, W3C mi mostra errori.

In questo momento ho trovato due opzioni per risolvere questo problema:

  1. Lo src iniziale di tutte le immagini deve essere un URL di un'immagine 1x1 vuota
  2. Lo src iniziale di tutte le immagini deve essere un'immagine vuota della base di dati 64

Quando sto usando un URL di un'immagine 1x1 vuota, quindi (testato con tools.pingdom.com) mostra 1 richiesta HTTP. Quando sto usando un'immagine vuota di base di dati64, mostra tutte le richieste quante il numero di immagini sulla pagina.

Quale di questi è il modo più efficiente, per una velocità maggiore di un sito Web e fa meno richieste HTTP? (supponiamo che l'utente stia caricando la pagina Web a una velocità di Internet di 14,4 kbps - prima velocità di Internet).

Ma per il SEO?

C'è qualche altra opzione?


8
"Quando sto usando un'immagine vuota di base di dati 64, mostra tutte le richieste quante il numero di immagini sulla pagina." - c'è qualcosa che non va? Il punto centrale dell'utilizzo di un URI di dati è che non esiste una richiesta HTTP esterna. (Solo gli user-agent che non comprendono gli URI dei dati potrebbero
generare

Se l'immagine vuota sarà più grande di 1x1 px (suppongo che lo sia), consiglierei un'immagine di sfondo più grande (10x10 px, 100x100 px) perché il rendering sarà più veloce .
totymedli,

3
Ne usi nessuno? È possibile creare dinamicamente il tag img allo stesso tempo convertendo data-src in src. Invece di avere un'immagine vuota con un data-src, è possibile memorizzare l'elenco di immagini e generare il tag quando necessario.
the_lotus,

@Pharap che non funziona perché il browser scaricherà le immagini anche se sono nascoste.
DisgruntledGoat

Qualunque cosa tu scelga per consegnare il contenuto, codificarlo come png8 sarà probabilmente più veloce di JPEG.
symcbean,

Risposte:


12

L'opzione immagine base64 dovrebbe essere utilizzata dove si avrebbe solo un numero molto piccolo di immagini e si desidera eliminare il sovraccarico della rete di recuperare un'immagine dal server. Tuttavia, da quello che stai indicando nella domanda, suppongo che questo potrebbe ridimensionarsi a un gran numero di immagini. In questo caso utilizzerei una singola immagine trasparente 1px x 1px dal server con una lunga durata della cache in quanto verrà recuperata dal server una volta quindi memorizzata nella cache nel browser e in tutti i server proxy intermedi.

Ad esempio, questa immagine avrebbe una dimensione di circa 95 byte ( https://commons.wikimedia.org/wiki/File:1x1.png ), per una stringa di immagine codificata in base64 potresti trovare che la dimensione sarebbe alla pari con questa immagine dimensione del file, ma sarebbe ripetuto per ogni singola immagine a cui lo aggiungi.

Per 2-5 immagini le dimensioni e la velocità sarebbero trascurabili e diminuirebbero il traffico del server eliminando un intero recupero, ma per di più le dimensioni della pagina inizierebbero a diventare troppo grandi, il che influenzerebbe i tempi di caricamento e, a sua volta, il posizionamento SEO.


6
Un'immagine base64 vuoto potrebbe avere 55 byte: data:image/gif;base64,R0lGODlhAQABAAAAACwAAAAAAQABAAA=. Se l'URL dell'immagine è un po 'più lungo (es: esempio.com/templates/template-name/files/1x1.png ), si consiglia l'immagine base64 perché non si eseguono query HTTP ed è più piccola in byte dell'URL dell'immagine (ripetuto per ogni immagine sulla pagina) + la dimensione dell'immagine esterna.
NETCreator Hosting

@ NETCreatorHosting-WebDesign Grazie per il tuo commento. Ho confrontato le dimensioni del sito Web quando si utilizza un'immagine base64 e un'immagine esterna e la dimensione è inferiore quando si utilizza un'immagine base64. Sto usando circa 40 immagini per pagina.
MM PP,

Oppure puoi caricare l'immagine sulla radice del tuo sito Web e utilizzare un URL relativo, quindi il sito Web sarà molto più piccolo.
NETCreator Hosting

3
gzip si occuperà delle ripetizioni, quindi avere 400 immagini codificate in base 64 nella tua pagina non costerà più larghezza di banda di 400 URL di immagini.
user2428118,

3
@Aron Se la tua pagina ha una dimensione di 25,6 MB (400 URI di dati lunghi 82 82 byte con 64 KB tra loro = 25.568.800 byte), hai problemi più grandi di cui preoccuparti di 32,8 KB di immagini codificate in base64.
user2428118

5

Sicuramente vai con l'URI dei dati, a meno che tu non abbia bisogno di supporto per IE <8. ( Supporto browser .)

Incorporare molte piccole immagini direttamente nell'HTML può sembrare che occuperà più larghezza di banda rispetto al collegamento diretto a esse, ma l'aumento sarà mitigato da gzip ; l'unica differenza nelle dimensioni della pagina verrà dalla differenza di lunghezza tra un URI di dati di un'immagine vuota e un URL dell'immagine sul tuo server. Una GIF vuota può essere piccola come 43 byte. Codifica base 64, ovvero 82 byte. Non c'è modo che abbia mai prestazioni peggiori di una richiesta HTTP> 500 byte , una risposta di dimensioni simili, e quindi non sto nemmeno prendendo in considerazione la dimensione del pacchetto TCP e altri costi generali.

Ecco l'immagine GIF a 43 byte con codifica Base 64:

data:image/gif;base64,R0lGODlhAQABAIAAAP///////yH5BAEKAAEALAAAAAABAAEAAAICTAEAOw==

Per quanto riguarda la SEO, dai un'occhiata al codice sorgente di un sito Google, ad esempio Google News , e cerca data:image/gif,base64...


La tua immagine è grande. Controlla il commento sopra per la versione a 55 byte.
Giosuè,

1
Questa risposta su StackOverflow con i test riportati (maggio 2014) sembra mostrare che l'incorporamento di grandi numeri (~ 1800) di immagini da 1px è notevolmente più lento rispetto al collegamento ripetuto alla stessa immagine esterna. L'immagine esterna viene richiesta una volta e memorizzata nella cache, mentre il browser deve decodificare ogni URI di dati separatamente come parte del processo di analisi HTML - questo sembrerebbe essere il collo di bottiglia. Ciò sembra suggerire che gli URI dei dati dovrebbero essere limitati a un numero limitato di (piccole) immagini.
DocRoot

@Joshua Anche se l'immagine viene visualizzata correttamente nel mio browser (Firefox), non può essere aperta da altri programmi (ad esempio Paint), quindi eviterei di usarla.
user2428118

2

In questo momento ho trovato due opzioni per risolvere questo problema: l'src iniziale di tutte le immagini deve essere un'immagine vuota della base di dati 64

Questa opzione non richiede solo un browser moderno, ma può essere più lenta sul lato client poiché il browser deve decodificare in base 64 i dati dell'immagine per produrre l'immagine.

Lo src iniziale di tutte le immagini deve essere un URL di un'immagine 1x1 vuota

È una mossa OK a condizione che l'URL dell'immagine vuota per tutti gli slot immagine sia esattamente lo stesso URL e che abbia una lunga durata della cache definita nell'intestazione HTTP "controllo cache". Il problema è che quando i nuovi file di immagine vengono caricati, i quadrati delle immagini passeranno alle nuove dimensioni, il che potrebbe rendere l'esperienza dell'utente non così meravigliosa.

L'idea quasi perfetta è questa ...

All'avvio della pagina, presenta una griglia con riquadri di dimensioni fisse in grado di accogliere ogni immagine. Va bene se l'intera griglia non si adatta allo schermo. Quindi crea javascript che viene eseguito dopo il caricamento dell'HTML e in quel javascript, crea un nuovo elemento immagine e collegalo a ciascuna cella della griglia, quindi imposta l'origine dell'immagine sul file immagine corretto. Fallo finché la prima schermata non si riempie. quindi rileva lo scorrimento all'interno di JavaScript e quindi quando si verifica lo scorrimento, ripeti il ​​processo sopra descritto per le nuove celle.

Ora, se vuoi il meglio del meglio e la qualità non è una grande preoccupazione, allora quello che raccomando (che ho implementato anche sul mio sito) è di costruire una griglia e impostarla in modo tale che l'immagine di sfondo di quella griglia sia un foglio sprite di tutte le immagini formattate come quadrati di immagini. Questo metodo è flessibile e veloce da caricare poiché è richiesta una richiesta per tutte le immagini.

Ecco un modello HTML da utilizzare se vuoi seguire la strada più veloce. Vengono fatte solo due richieste. Il codice HTML e l'immagine. In questo codice, suppongo che ogni immagine del foglio abbia una larghezza di 100 pixel e un'altezza di 200 pixel e che ogni immagine sia perfettamente allineata l'una accanto all'altra senza spazi vuoti.

<html>
<head>
<style type="text/css">
#imagegrid {background-color: black; background-image:url('http://example.com/url/to/imagesheet.jpg');}
A {display:block;width:100px;height:200px;margin:10px;float:left;}
#image1{background-position: 0px 0px}
#image2{background-position: 100px 0px}
#image3{background-position: 200px 0px}
...
#imageN{background-position: XXXpx 0px}
</style>
</head>
<body>
<div id="imagegrid">
<a href="image_one.htm" id="image1"></a>
<a href="image_two.htm" id="image2"></a>
<a href="image_three.htm" id="image3"></a>
...
<a href="image_N.htm" id="imageN"></a>
</div>
</body>
</html>

Nel mio codice ho aggiunto 3 punti. Ciò significa che puoi continuare ad aggiungere immagini aumentando i numeri e aumentando la posizione di 100 ogni volta a condizione che il tuo foglio sprite abbia solo una riga di immagini. Inoltre, con alcuni browser come Opera, potrebbe essere necessario aggiungere un segno negativo davanti ai valori di posizione in background per farli funzionare.


2
A meno che le immagini non abbiano dimensioni di mezzo gigabyte, non è possibile che la decodifica base64 di un'immagine abbia un impatto misurabile sulle prestazioni.
user2428118,

Dipende anche dal sistema informatico. Se il client ha ancora un computer vecchio stile come un pentium 1, è possibile che si verifichi un calo delle prestazioni.
Mike,

1

L'immagine, perché manutenibilità.

Nella mia esperienza funziona meglio usare l'immagine. Questo è più evidente nel codice attuale e più facile da ricordare. Dubito che ricorderai la stringa codificata per un'immagine trasparente e, anche se lo fai, i tuoi successori / colleghi.
Se torni a questo codice dopo alcune settimane, hai dimenticato la base64.

Mantenere il codice sarà molto più semplice se si utilizza l'immagine, i pro minimi non pesano fino a questo.


Molte persone usano gli script per generare valori di base 64, quindi il requisito di ricordare tali valori è fuori dalla finestra a meno che l'OP non utilizzi solo una serie di file HTML per rappresentare il codice del suo sito Web.
Mike,

1

Che ne dite di solo ~ 3 byte extra, 0 richieste http extra e 0 lunghezza img src extra (o 0 segnaposto di immagini di dati non memorizzati nella cache). Puoi usare un src vuoto per l'immagine?

<img src data-src="banannanannas.jpg" />

E se hanno alttag, puoi nasconderli dall'immagine di errore / errore:

<img src data-src="banannanannas.jpg" onerror="this.alt=''" alt="some desc" />

Visualizza: niente. L'hacking del tag alt ha un leggero ritardo FOUC dal bordo del segnaposto dell'immagine. Forse anche quello può essere ripulito.


2
Sebbene un srcattributo vuoto genererà ancora errori nel W3C Validator (che sembra essere la preoccupazione).
MrWhite,

@ w3dk Sì, fa schifo, ma poi passano pochissime modernizzazioni.
Dhaupin,

Se si desidera passare regole W3C, è necessario specificare qualcosa per src, anche se è un URL che restituisce un errore 404. Consiglio anche di specificare i valori degli attributi di larghezza e altezza per l'immagine in modo che gli utenti vedano inizialmente i segnaposto effettivi invece di piccole caselle che si gonfiano a metà del processo di caricamento.
Mike,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.