MREmail load time optimisation
Things like adding video backgrounds, CSS animation, responsively showing/hiding images or content, complex media queries and other cool new effects people are doing is adding a lot of weight to emails.
I’ve been thinking of ways to tighten up on load times to compensate for this. Would be great to hear any thoughts on the below and additional ideas.
Keep the number of images down
Each image you load is a request to the server, 30 tiny images = 30 individual requests. I’ve not tried using sprites in email, might be able to do something with overflow:hidden; rather than background-image:
You can often use things like, styled text, unicode characters, CSS triangles etc. instead of images.
Save images for web
An obvious one but I’ve seen a couple of print optimised images used in email before. I’m assuming it was a mistake and they didn’t mean to include a 10mb image.
Crop unwanted white space
Using HTML to position an image rather than white space can easily reduce an image file size.
Minify HTML
Minifying can significantly reduce your HTML file size.
Avoid bloated code
This is hard, you need to bloat the code to get all your hacks working. But I do see a lot of duplicated code such as setting text styles on a <td> and a <span> and in a <style> block.
If you’re using prefixed CSS check the support, for example you can just use -webkit-animation
Keep the message short
Simply include less and your file size will be smaller.
This seems to be a trend anyway and emails often perform better with one simple message.
Paint times
I just read this today so will just share the article
Cheers,
Mark
I was thinking more along the lines of using them inside media queries to swap out images instead of inline.
or:
or even using data attributes:
Haven't actually tested any of that. But I would think there's a good chance it would all work on anything webkit. I've used the data attribute trick for rearranging labels in a table before and it worked across Android and iOS.
Some great thoughts.
I love ImageOptim great way to shave off a few KB, didn't realise you could automate it with Grunt. I've really got to set aside some time and get my head around Grunt.
Really interested in the switching images with data attributes idea, I've been looking for a way to lighten my SVG code.
As always, Campaign Monitor looked into using data URIs in email. Short version: Steer clear. Granted this was over a year ago, but we all know how quickly email client vendors move...
http://www.campaignmonitor.com/blog/post/3927/embedded-images-in-html-email
i find a free online css minifier http://www.online-code.net/minify-css.html to compress your css code, so it will reduce the size of web page.
If you test it out further, I'd be very curious to see the results. Be sure to post them.
Use
table-layout: fixedto improve rendering performance.Swap/hide images between desktop and mobile by using
backgroundattribute andbackground-imageso only one image gets downloaded.Do you have an example for the background/background-image idea? I code emails where I have to include separate desktop and mobile images, and I'd like to reduce image downloads/server hits where possible. Thanks!
Great tip about
table-layout: fixed;More info on why it's a good idea here
Gonna run a few tests and add that to my templates.
I worked at a web performance optimization startup for 2 years before working @ Litmus & learned a ton on web performance.
I question if web performance optimization in emails makes a big impact on CTR & other major email performance metrics. I think in order for optimization to have a big impact you'd need a a ton of images (50-100+) and very large file sizes (1-2MB+). However, if you're just trying to optimize from like 20 > 10 images or 300kb > 200kb in file size the effect on the performance of the email would be minimal.
When it comes to performance, JavaScript is the worst offender (which isn't rendered in email). After that, the number of assets/requests makes the biggest impact. You obviously want to optimize the file size too, but that's actually pretty forgiving as long as it's manageable. Since emails are only 1 file of code (HTML) and (generally) don't have that many images, they're pretty small to download comparatively. I haven't ever noticed issues with downloading an email either (excluding Gmail caching issues haha).
(*Note: Keep your audience in mind, too. Mobile devices are much slower to download than desktop browsers and applications. If you have a very large mobile audience, performance will be a much bigger issue and should influence your design decisions in terms of # of images and file sizes accordingly.)
Honestly, I think the biggest area for email designers to focus on is "Time to Display" or "Time to Paint" - the amount of time it takes for the client to show the content in the email. And, as email evolves into using more CSS, it puts more pressure on the browser/client to paint the HTML. That's the metric that would really matter to email designers. I would say, though, it's probably faster for the most part compared to websites.
We can always optimize the email for performance, I just wonder for most companies if it would make any difference in email and if it's worth spending extra time focusing on. I think you'd have to be a company of massive scale for it to be worth it IMO. It would be interesting to see an A/B test on just the performance aspect of email as I haven't seen any case studies on that, I'm just not sure it would yield conclusive results for most.
Breaking a lengthy email into multiple distinct sections (multiple tables stacked), rather than having a single table containing the entire email, allows the browser or email client to start laying out the email top-to-bottom. While this adds to the overall size of the email markup, having independent, stacked tables means most email clients can start rendering your content faster and the user perceives that your email loads faster.
Also, I'm a huge fan of HTML and CSS minification but it's worth noting that we found that certain versions of Outlook can choke when it encounters long lines of markup. All of the emails we send are minified before sending and then line-breaks are strategically re-inserted automatically to prevent lines from exceeding 2048 characters. And, as Kevin has pointed out in other discussions, CSS minification can interfere with advanced techniques (particularly animation and hacks) so it's best to use a whitespace-only CSS minifier so that your hand-coded CSS doesn't get broken.
From a workflow automation standpoint, HTML, CSS and image minification/optimizations are performed automatically by the Inkcite framework which I blogged about here.
If you're looking for SVG optimization I know the grunticon project from filament group recommends SVGO-GUI and SVGMIN. SVGO-GUI being a drag and drop option for optimizing SVG's and svgmin as a grunt task.
That looks brilliant, I'll have look into those.
Not using many SVG's in email at the moment but want to start using more.
Quick question about data URI:
Wouldn't that be detrimental to the email load time? I don't know what the support for it looks like, but I'm pretty sure that not every single email clients does. Since the data is encoded into the email, it will always be downloaded, whether it will be rendered or not. It may save us some HTTP requests, but what are some other benefits?
Researching this a little further, it seems you're correct, Data URI's actually have pretty terrible performance. Really are only recommended for use with very small resources/images.
Swapping image sources through the use of
content: url('data:image/jpeg;base64,/9j/4AAQSkZJRgABAQEASABIAAD....snip...');or
content: url('image.jpg');still seems like a better approach than the typical way I see image swapping trying to be accomplished in email, which is by trying to hide and show different images/tables.
Not sure it's really a relevant to the performance discussion though.
There's a good post here about using data attributes for image swapping. Apparently :before isn't supported on the <img> tag.
I ran a couple of my own tests by putting the image in a span. But it looks like email clients aren't supporting data:image set in content or as a background image.
Here's the code I used if you fancy messing about with it.
What do you think about srcset? I did some testing a week ago and I think it comes in very handy for emails with a lot of product images for example. The browser or engine only seems to load the image it needs. And it work fine in > iOS7 and a Galaxy device i tested on.