2015-07-10 4 views
11

Uso un meccanismo di scaricamento automatico che carica solo le immagini pertinenti una volta nella vista degli utenti.Segnaposto di origine per immagini di caricamento lenta

Per questo ho definito un attributo data-src che collega all'immagine originale e un'immagine segnaposto codificata Base64 come attributo src per rendere l'HTML valido.

<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAYAAAAfFcSJAAAAAXNSR0IArs4c6QAAAARnQU1BAACxjwv8YQUAAAAJcEhZcwAADsQAAA7EAZUrDhsAAAANSURBVBhXYzh8+PB/AAffA0nNPuCLAAAAAElFTkSuQmCC" data-src="/path/to/image.png" alt="some text"> 

ho notato che Chrome memorizza la stringa base64 ma la stringa è piuttosto lungo e contribuisce ad appesantire il mio HTML (ho un sacco di immagini su una pagina).

Quindi la mia domanda è se è meglio usare una piccola immagine base64 codificata o 1px x 1px segnaposto?

Nota: Per scopi SEO l'elemento deve essere un img. Anche il mio codice HTML deve essere valido, quindi è richiesto un attributo src.

+1

Si deve img? Sta usando css background-image un'opzione? – Christoph

+0

Qual è lo scopo dell'utilizzo di un'immagine segnaposto per i tag 'img' che si trovano all'esterno della finestra? Se è memoria, potresti invece applicare 'visibility: hidden' o una strategia simile? –

risposta

6

Vorrei usare il segnaposto nella tua situazione.

L'utilizzo del tipo di immagine codificata base64 di sconfigge lo scopo del caricamento lento poiché è ancora necessario inviare alcuni dati di immagine al browser. Se tutto ciò potrebbe essere dannoso per le prestazioni dal momento che l'immagine viene scaricata come parte della richiesta HTTP originale, piuttosto che tramite una richiesta separata come un browser potrebbe fare con un tag immagine e URL.

Idealmente se si tratta solo di un segnaposto di caricamento o di qualcosa di simile, lo creerei in CSS e poi lo sostituirò con l'immagine caricata quando l'utente scorrerà verso il basso sufficientemente da richiamare il caricamento di quella particolare immagine.

+0

Avrei dovuto affermare che ho bisogno di HTML valido e un tag img per scopi SEO (aggiornato la mia domanda). Quindi in pratica ho bisogno di inviare un'immagine comunque. Mi sto solo chiedendo cosa c'è di meglio in questo caso. Caricamento di segnaposti codificati in bas64 o immagini 1px x 1px? Entrambi creano ulteriori richieste http. – enyce12

+0

Se sei preoccupato per il SEO personalmente, sceglierei i tag '' con base64 come segnaposti e quindi sostituire dinamicamente l'origine. Questa è l'opzione migliore per quanto riguarda le richieste HTTP poiché ne verrà salvato uno aggiuntivo per ogni immagine man mano che il segnaposto piccolo arriva insieme al documento effettivo.Avrei dovuto aggiungere che se l'immagine codificata è molto piccola non dovrebbe avere un effetto negativo sulle prestazioni. Se stavi caricando, ad es. una versione a bassa risoluzione dell'intera immagine come l'immagine codificata sarebbe comunque. –

+0

Forse rendere l'immagine segnaposto immagine png trasparente 1x1, e dare il tag img larghezza e l'altezza dell'immagine originale in modo che occupa lo spazio finirà usare. Preferirei che il tuo caricatore pigro modificasse semplicemente l'attributo src sul percorso dell'immagine reale una volta che un'immagine fosse visibile, piuttosto che andare in giro con base64. Le società di navigazione hanno speso anni a caricare le immagini velocemente, non tentare di aggirarle. –

9

È possibile utilizzare questa immagine più breve nel tag src (1x1 pixel GIF) (ma valido!):

data:image/gif;base64,R0lGODlhAQABAAD/ACwAAAAAAQABAAACADs= 

Si noti che se si gzip il codice HTML (che si dovrebbe), la lunghezza della stringa non sarà così importante perché le stringhe ripetitive si comprimono bene.

A seconda delle esigenze, è possibile utilizzare un colore per il pixel 1x1 (risultati nei file gif più brevi). Un modo per farlo è usare Photoshop o uno strumento simile per creare la GIF 1x1 pixel nel colore giusto, e quindi usare uno strumento come ImageOptim per trovare la compressione migliore. Esistono vari strumenti online per convertire il file risultante in un URL di dati.

4

Ho notato che il chrome memorizza nella cache la stringa base64 ma la stringa è piuttosto lunga e gonfia il mio HTML (ho molte immagini su una pagina).

In questo caso, si consideri l'inserimento di un attributo src "reale" che punta sempre allo stesso segnaposto. Avete bisogno di una richiesta HTTP in più, ma :

  1. sarà quasi certamente pipeline e prendere poco tempo.
  2. attiva il meccanismo di memorizzazione nella cache dell'immagine, che base64 fa non do, in modo che l'immagine venga decodificata solo una volta. Non è un grande problema dato CPU e GPU di oggi, ma comunque.
  3. verrà anche memorizzato nella cache come una risorsa e con le intestazioni corrette rimarrà un tempo lungo , con un tempo di caricamento pari a zero in tutti gli accessi di pagina successivi dallo stesso client.

Se il numero di immagini su una pagina è significativo, si potrebbe facilmente star meglio con un'immagine "reale".

Mi piacerebbe arrivare ad essere più compatibile con browser, spider e cosa no - la codifica base64 è ampiamente supportata, ma le immagini semplici lo sono ancora di più.

anche rispetto ad the smallest images you can get in base64, 26 byte diventano this

src="data:image/gif;base64,R0lGODlhAQABAAD/ACwAAAAAAQABAAACADs=" 

mentre si può andare da

src="/img/p.png" 

fino

src="p.png" 

che sembra abbastanza unbloaty - se tale esiste persino una parola.

prova

Ho eseguito un test molto semplice

<html> 
<body> 
<?php 
    switch($_GET['t']) { 
     case 'base64': 
      $src = 'data:image/gif;base64,R0lGODlhAQABAAD/ACwAAAAAAQABAAACADs='; 

      break; 
     case 'gif': 
      $src = 'p.gif'; 
      break; 
    } 
    print str_repeat("<img src=\"{$src}\"/>", $_GET['n']); 
?> 
</body> 
</html> 

ed ho ottenuto:

images mode  DOMContentLoaded Load  Result 
200  base64 202ms    310ms  base64 is best 
200  gif  348ms    437ms 
1000  base64 559ms    622ms  base64 is best 
1000  gif  513ms    632ms 
2000  base64 986ms    1033ms  gif is best 
2000  gif  811ms    947ms 

Così, almeno sulla mia macchina, sembrerebbe Sto dando sei un cattivo consiglio, visto che non vedi vantaggi nel tempo di caricamento della pagina finché non hai quasi duemila ima GES.

Tuttavia:

  • questo dipende fortemente dalle impostazioni del server e di rete, e ancora di più sul layout di DOM reale.
  • Ho eseguito solo un test per ogni set, che è una statistica errata, utilizzando Firebug, che è una cattiva metodologia: se vuoi avere dati solidi, esegui diverse dozzine di pagine in entrambe le modalità utilizzando alcuni strumenti di monitoraggio delle prestazioni Web e un clone della tua pagina reale.
  • (cosa sull'utilizzo PNG invece di gif?)