Hvor mye raskere er det å bruke inline / base64 bilder til en nettside enn bare å koble til hard fil?

stemmer
27

Hvor mye raskere er det å bruke en base64 / line for å vise bilder enn motsetning til bare å koble til hard fil på serveren?

url(data:image/png;base64,.......)

Jeg har ikke vært i stand til å finne noen form for resultattall på dette.

Jeg har noen bekymringer:

  • Du trenger ikke lenger få nytte av caching
  • Er ikke en base64 MYE større i størrelse enn hva en størrelse PNG / JPEG-fil?

La oss definere raskere som i: den tiden det tar for en bruker å se en fullstendig gjengitt HTML nettside

Publisert på 15/10/2009 klokken 18:48
kilden bruker
På andre språk...                            


4 svar

stemmer
4

Du trenger ikke lenger få nytte av caching

Enten som teller vil variere avhengig av hvor mye du er avhengig av caching.

Er ikke en base64 MYE større i størrelse enn hva en størrelse PNG / JPEG-fil?

Filformatet / bildekomprimeringsalgoritmen er det samme, jeg tar det, det vil si det er PNG.

Under anvendelse av basis-64, representerer hver 8-bit-tegn 6-bitene: derfor binære data blir dekomprimert ved et forhold på 8 til 6, det vil si bare omtrent 35%.

Svarte 15/10/2009 kl. 19:03
kilden bruker

stemmer
5

Hvor mye raskere er det

Definer 'raskere'. Mener du HTTP ytelse (se nedenfor) eller gjengivelse?

Du trenger ikke lenger få nytte av caching

Egentlig, hvis du gjør dette i en CSS-fil vil det fortsatt bli lagret. Selvfølgelig vil eventuelle endringer i CSS-cache ugyldig.

I noen situasjoner kan dette brukes som en stor ytelsesforbedring over mange HTTP-tilkoblinger. Jeg sier noen situasjoner fordi du kan sannsynligvis dra nytte av teknikker som bilde sprites for de fleste ting, men det er alltid godt å ha et annet verktøy i ditt arsenal!

Svarte 15/10/2009 kl. 19:19
kilden bruker

stemmer
38

Raskere er en vanskelig ting å svare på fordi det er mange mulige tolkninger og situasjoner:

Base64 koding vil utvide bildet med en tredjedel, noe som vil øke båndbredden utnyttelse. På den annen side vil inkludere det i filen du fjerne en av GET rundtur til serveren. Så vil et rør med stor gjennomstrømming, men dårlig latency (slik som en satellitt Internett-tilkobling) sannsynligvis laste en side med inlined bilder raskere enn om du bruker forskjellige bildefiler. Selv på min (landlig, treg) DSL-linje, nettsteder som krever mange rundturer tar mye lenger tid å laste enn de som er bare relativt store, men krever bare et fåtall blir.

Hvis du gjør base64 koding fra kildefilene med hver forespørsel, vil du være å bruke opp mer CPU, juling data cacher, etc, som kan skade dine servere responstid. (Selvfølgelig kan du alltid bruke memcached eller slik for å løse det problemet).

Å gjøre dette vil selvfølgelig forhindre de fleste former for caching, som kan skade mye hvis bildet vises ofte - la oss si, en logo som vises på hver side, som normalt kan bli lagret av nettleseren (eller en proxy cache som blekksprut eller uansett) og ba om en gang i måneden. Det vil også hindre mange mange optimaliseringer webservere ha for å tjene statiske filer ved hjelp av kjerne APIer som sendfile (2).

I utgangspunktet vil gjøre dette hjelpe i visse situasjoner, og vondt i andre. Du må identifisere hvilke situasjoner er viktig for deg før du kan virkelig finne ut om dette er en verdig triks for deg.

Svarte 15/10/2009 kl. 19:24
kilden bruker

stemmer
16

Jeg har gjort en sammenligning mellom to HTML-sider som inneholder 1800 en-pixel bilder.

Den første siden erklærer bilder inline:

<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAYAAAAfFcSJAAAAAXNSR0IArs4c6QAAAARnQU1BAACxjwv8YQUAAAAJcEhZcwAADsQAAA7EAZUrDhsAAAANSURBVBhXYzh8+PB/AAffA0nNPuCLAAAAAElFTkSuQmCC">

I den andre, bilder referanse til en ekstern fil:

<img src="img/one-gray-px.png">

Jeg fant ut at når du legger flere ganger det samme bildet, hvis det er erklært inline, utfører leseren en forespørsel for hvert bilde (jeg antar at det base64-dekoder det en gang per bilde), mens i det andre scenariet, blir bildet bedt om en gang per dokument (se sammenligningen bildet nedenfor).

Dokumentet med innebygde bilder belastninger i ca 250ms og dokumentet med koblede bilder gjør det på 30ms.

(Testet med Chromium 34)

Scenariet av et HTML-dokument med flere forekomster av samme inline bildet gjør ikke mye fornuftig a priori. Men jeg fant at plugin jquery lazyload definerer en innebygd plassholder som standard for alle de "late" bilder, hvis srcattributtet vil bli satt til det. Deretter, hvis dokumentet inneholder mange late bilder, kan en situasjon som beskrevet ovenfor skje.

Tidslinje sammenligning

Svarte 21/05/2014 kl. 07:43
kilden bruker

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more