At the end of my last post on base64 encoding I wanted to see how numbers changed when using a large image sprite and also how page speed was affected.
To do this I decided to work with one Google’s larger image sprites nav_logo107.png
And to focus the test I removed 2 of the previous test cases (the individual binary images and split base64 encodes) as it was clear from the first post that they would not be small enough to compete.
So that leaves a pure binary sprite and a sprite encoded as base64 for which I created 2 test pages:
First: File Size
The good news is that results from my previous post were still true.
If we set the baseline that the delivered css for both cases is minified and gzipped then both end up being almost exactly the same overall byte size.
Second: Page Speed
To check page speed I ran 3 sets of tests using webpagetest.org:
- Dulles, VA / Chrome / DSL
sprite.html – http://www.webpagetest.org/result/120412_A5_3YAXN/
b64-sprite.html – http://www.webpagetest.org/result/120412_DZ_3YAXS/
- Dulles, VA / IE8 / DSL
sprite.html – http://www.webpagetest.org/result/120412_F1_3YAXE/
b64-sprite.html – http://www.webpagetest.org/result/120412_KX_3YAXG/
- Dulles VA / IE9 / DSL
sprite.html – http://www.webpagetest.org/result/120412_EW_3YAY1/
b64-sprite.html – http://www.webpagetest.org/result/120412_CS_3YAY3/
Each test was run 5 times for both First View (no cache) and Repeat View (cache)
My initial thought was that the base64 encoded sprite would be faster (as it would be 1 less request)… and it is when looking at total page load time.
In most tests b64-sprite.html total page load time was around 200ms faster without the additional image request.
So if we were only looking at total load time then we have a clear winner.
But take a moment and look at start render times in those same tests.
On “First View” tests sprite.html has start render times that are around 200ms to 300ms faster in each comparison.
You can see what this translates to visually in this video:http://www.webpagetest.org/video/view.php?id=120412_5129cebbfde1452b10358afa3a1f5dacd106366d
Have you ever heard a user say the phrase “this page feels slow”?
I find that in most cases when questioned further the feeling of slowness was due to the time they were waiting for something (anything) to render to the screen.
This is important to keep in mind when deciding if base64 encoding sprites will make sense for your site.
Yes you are saving a request (which will reduce total load time) but you are also making your css files larger (which could increase start render time).
Even in “Repeat View” where resources are cached locally the start render times for sprite.html are faster. Yes I know we are talking about 10s of milliseconds but try to think of this on a full production site with lots of other resources. Remember even though the css is cached locally the browser still needs to pull it from local cache and render it. So if the cached file is larger in size it will take longer to render.
As an aside: IE8 throws a nice wrench into the gears on this as well. IE8 only supports data URIs up to 32k in size. So if you plan to base64 encode large image sprites you will run into issues with IE8 (basically they won’t render at all in that version).
I hate to say this but when choosing which option is best it will depend mostly on the project.
I would ask the following questions if you are using a large image sprite:
1) Are start render times more important than overall load time for your users? If yes then based on the above findings it would make sense to try the image in pure binary first and run speed tests.
2) Do you still support IE8? If yes then go with a pure binary sprite.
3) Do you plan to set expires headers the same on css and images? If no then consider a pure binary sprite. That way when a user’s local cache is cleared on your css they won’t have to download a larger file each time.
Thank you for reading and please let me know your thoughts in the comments below