On Thu, Jan 21, 2016 at 10:32 PM, jude <flexcapaci...@gmail.com> wrote:
> Even if the initial download size is bigger it can actually load faster. > This is because: > > *Fetching resources over the network is both slow and expensive: the > download may require multiple roundtrips between the client and server, > which delays processing and may block rendering of page content, and also > incurs data costs for the visitor. [1]* > Agreed that downloading assets individually is quite costly. But Base64 encoding assets and sticking them in JS files is not a great way to solve this problem. You loose browser based caching for assets, sharing assets across applications from same domain, along with an increased page load time. Also, Base64 encoded images are roughly 1.37 times the size of the original image [1] As I mentioned earlier, spritesheets are a much better alternative. With spritesheets, you incur only one additional download and it is pretty easy to use. [2] CSS even natively supports image sprites. > > So using data uri's can get you a faster TOF (time of flight) page render. > Not sure if I'm using that right but it sounds cool. I am not quite sure what that means ;-) > The downside is that > if you reload the page nothing is in the cache. But then again, if you plan > it right you should only be downloading the changed content (a small JSON > object). > > I'm using data URI's in a few places and for small graphics like lines and > boxes and it's only a few lines of content. The reason I'm doing this is to > translate an SVG graphic into something older browsers can render, for > example, the webkit in AIR does not render SVG (in my tests) so converting > those to data URI allows the page to render as expected. > Instead, I would suggest having an external stylesheet that has the definitions of all the base 64 encoded images and load it separately. At least it would be cache-able then. The performance of this would be better than embedding it in code, but comparable to the spritesheet method. The problem I see is not with the encoding of the image as base64, but the fact that we have to dump it in a JS or HTML file, thereby losing the browser cacheability that a png or jpg provides. Thanks, Om [1] https://en.wikipedia.org/wiki/Base64 [2] http://www.williammalone.com/articles/create-html5-canvas-javascript-sprite-animation/ [3] http://www.w3schools.com/css/css_image_sprites.asp > > Google has some good info but the information shouldn't be taken as gospel. > They are still catching up to things we are used to. For example, Angular > JS is being rewritten from the ground up. > [1] > https://developers.google.com/speed/docs/insights/LeverageBrowserCaching > > On Thu, Jan 21, 2016 at 8:53 AM, OmPrakash Muppirala <bigosma...@gmail.com > > > wrote: > > > Any reason we want to embed images? It makes sense in a swf because it > is > > a compact file format. > > > > For the HTML version if we stick a big base 64 image in the minified > code, > > we are unnecessarily making the initial download size bigger. > > > > A better approach would be to use spritesheets when dealing with image > > data. These spritesheets should be downloaded on demand like all other > > assets. > > > > Thanks, > > Om > > On Jan 21, 2016 8:43 AM, "Alex Harui" <aha...@adobe.com> wrote: > > > > > > > > > > > On 1/21/16, 8:24 AM, "Michael Schmalle" <teotigraphix...@gmail.com> > > wrote: > > > > > > >If/when you have time, could you make a JIRA that sort of outlined the > > > >process for the base64 encoding? I am good at somethings but something > > > >like > > > >this I really don't have any experience, I know the hooks in the > > compiler > > > >and such but what would actually be involved in getting the bytes to > > emit > > > >out. > > > > > > I would have to do research as well. Maybe Josh can provide more > detail. > > > My concern is, if overused, embeds could make the html file really > huge. > > > > > > -Alex > > > > > > > > >
