Menu icon Foundation
HTML File Sizes with Foundation For Emails

Just wanted to let you guys in on some issues we were having with our marketing emails. All emails are rendering and acting as they should. The only thing that we are experiencing are emails getting clipped which we believe is also causing some deliver-ability issues along with being marked as spam.

Gmail and yahoo both have a pretty rigid 102KB rule. If you're email is even 1KB over that number, Gmail will clip the message and an option to "view the entire message" depending on device shows.  We noticed A significant dip in revenue for the first month of full use during our regular weekly sends as compared to previous months with the same amount of traffic and similar deals.

We initially tested our responsive template in emails via Shopping Cart Abandonment Funnel, Life Cycle (30,60,90,180,365 days after purchase and review your purchase emails). All of those emails are performing much better than our previous non-responsive emails. Open rates were up, CTR was up and conversions were up.  The opens and deliver-ability were not affected.  After going back and looking at file size of those emails, I believe the reason is they were all under the 102KB threshold. Image size did not play a role in any message being clipped. Only the final output size of the HTML.

Based on that information, I setup a spreadsheet of our emails from pre-responsive and post-responsive.  

https://docs.google.com/spreadsheets/d/12sM5hNwW7E0ifCsgD-zEk7RzS2TmsMBACpxaMYKjLto/edit?usp=sharing What I've noticed is the email provider we use (Listrak) doe not appear to be using a minified version of our file. Or, after gmail restructures the URL and re-writes the image path, all the columns, tabs and spaces are added back to the file (still trying to track that).  The reason I believe it's the latter (please refer to column F title Prod Non-min in the document above) is because when I clicked the view in browser link and viewed the source code; of the emails that were clipped (highlighted in red) all of those file sizes were over the 102KB threshold.

As a test, I viewed the code that gmail generated with tracking urls and made a minified version of that file to see what the file size was.  In every test the file size only increased on average between 3-6KB which would account for the tracking urls and re-writing for proxy images. Based on that file size I would have assumed that only 1 of my emails would have been clipped.  (Refer to column E lines 4,5,13,15, 16, 23 and 24). However, those emails were in fact clipped which lead me to my original theory (Gmail isn't using a minified version of the file or my esp isn't).

The foundation framework is really good, my only complaint and warning to others would be to double check your file size and not to assume that the minified version you are using is actually being used by your ESP or by the email clients such as yahoo and google.

Also, as a result of emails being clipped, the open rates dropped.  We believe (and are testing this theory) that if an email is above 102KB, in addition to some messages getting the clipped message, it is likely the message is being flagged as spam.  This would account for opens dropping, CTR dropping, revenue dropping but conversions improving.  This means that the people who are are getting/seeing the responsive version are giving us the results we expected and want, We now have to make sure the emails are ending up in the inbox and not being blocked by spam or not being delivered at all (I'm talking to you COMCAST!).

We're doing another send this morning and plan to monitor the opens on that email since we know it is below the 102KB threshold.  It's being sent to about 450,000 people. 

file sizeemailsClippedgmailMessage Clipped

Just wanted to let you guys in on some issues we were having with our marketing emails. All emails are rendering and acting as they should. The only thing that we are experiencing are emails getting clipped which we believe is also causing some deliver-ability issues along with being marked as spam.

Gmail and yahoo both have a pretty rigid 102KB rule. If you're email is even 1KB over that number, Gmail will clip the message and an option to "view the entire message" depending on device shows.  We noticed A significant dip in revenue for the first month of full use during our regular weekly sends as compared to previous months with the same amount of traffic and similar deals.

We initially tested our responsive template in emails via Shopping Cart Abandonment Funnel, Life Cycle (30,60,90,180,365 days after purchase and review your purchase emails). All of those emails are performing much better than our previous non-responsive emails. Open rates were up, CTR was up and conversions were up.  The opens and deliver-ability were not affected.  After going back and looking at file size of those emails, I believe the reason is they were all under the 102KB threshold. Image size did not play a role in any message being clipped. Only the final output size of the HTML.

Based on that information, I setup a spreadsheet of our emails from pre-responsive and post-responsive.  

https://docs.google.com/spreadsheets/d/12sM5hNwW7E0ifCsgD-zEk7RzS2TmsMBACpxaMYKjLto/edit?usp=sharing What I've noticed is the email provider we use (Listrak) doe not appear to be using a minified version of our file. Or, after gmail restructures the URL and re-writes the image path, all the columns, tabs and spaces are added back to the file (still trying to track that).  The reason I believe it's the latter (please refer to column F title Prod Non-min in the document above) is because when I clicked the view in browser link and viewed the source code; of the emails that were clipped (highlighted in red) all of those file sizes were over the 102KB threshold.

As a test, I viewed the code that gmail generated with tracking urls and made a minified version of that file to see what the file size was.  In every test the file size only increased on average between 3-6KB which would account for the tracking urls and re-writing for proxy images. Based on that file size I would have assumed that only 1 of my emails would have been clipped.  (Refer to column E lines 4,5,13,15, 16, 23 and 24). However, those emails were in fact clipped which lead me to my original theory (Gmail isn't using a minified version of the file or my esp isn't).

The foundation framework is really good, my only complaint and warning to others would be to double check your file size and not to assume that the minified version you are using is actually being used by your ESP or by the email clients such as yahoo and google.

Also, as a result of emails being clipped, the open rates dropped.  We believe (and are testing this theory) that if an email is above 102KB, in addition to some messages getting the clipped message, it is likely the message is being flagged as spam.  This would account for opens dropping, CTR dropping, revenue dropping but conversions improving.  This means that the people who are are getting/seeing the responsive version are giving us the results we expected and want, We now have to make sure the emails are ending up in the inbox and not being blocked by spam or not being delivered at all (I'm talking to you COMCAST!).

We're doing another send this morning and plan to monitor the opens on that email since we know it is below the 102KB threshold.  It's being sent to about 450,000 people. 

Jonathan over 3 years ago

Corey Schaaf, I have the same problem, do you have any solution ?, what version of foundation are using?

Corey Schaaf over 3 years ago

@Jonathan - Who's your ESP? We are using Foundation for Emails 2.2.1

The only way we've been able to combat this issue is to make sure the ESP is using the minified version of the HTML. Making edits to the HTML in the ESP was part of our problem. Making any edit in Listrak and then using the Preview tab and then clicking back over to the HTML tab would reflow all the HTML and add all the spaces / tabs back in. 

So we came up with a new process to make sure edits only happend locally and only copied the HTML without using the preview tab. (there is a preview button close to the save button at the bottom of the page that you can use - if your ESP is Listrak of course). 

However, even in making sure that the minified version is being used there are some cases where the HTML code was still larger than 102KB (thus getting clipped in yahoo and gmail).  

The next thing I did was remove some of the foundation code / components we don't use. 

Navigate to the node_modules/foundation-emails/scss/foundation-emails.scss

I commented out menu, thumbnail, block-grid as these were things none of templates use. That has helped lower file size.  But other than that - there's nothing else I can think of to do other than to remove content. 

Corey Schaaf over 3 years ago

As another follow up question, are you also having issues with deliverability / your messages being marked as SPAM when they are over the threshold? 

Rafi Benkual over 3 years ago

There is an article from Mailchimp that explains this: http://kb.mailchimp.com/delivery/deliverability-research/gmail-is-clipping-my-email

 

Some tactics you can use:

- Keep your emails short and focussed

- Use HTML compression in the inliner (removes whitespace which counts as characters)

- avoid using unnecessary markup like nested columns when not needed or extra rows and columns

 

Haven't seen any hacks or workarounds for this. Have you guys?

Corey Schaaf over 3 years ago

We've just been keeping our emails under the 102KB threshold and removing any unnecessary css for components we don't use. 

We've been running split test of the new (responsive) vs old (static) templates to see if we're still having issues with deliver-ability even if our files are below 102KB.  

In our first split test, the responsive template had a slight edge in open rates, and click through rates which is what we would expect.  However, for some strange reason the conversion rate on the new template was 3% and the conversion rate on the old template was 4%.  While emails don't play a part in the conversion process, that's more of the website functionality - it is very odd that we had 110 conversions for the responsive template and 140 for the non-responsive.  We're trying to figure out if something is happening after a user clicks a link inside the email and for one reason or another, don't make it to the sight.  

We're running another split test this morning to see if this was just a fluke.  

Ant James over 3 years ago

Corey, how did the results of the split test look?

Corey Schaaf over 3 years ago

Keeping the emails under the 102KB seems to have been the culprit.  Our open rates and clicks seem to be on par with with that they were previously.  We're still keeping an eye on it but the emails seem to be surpassing our benchmark with every send. We've sent out several other emails since the test in the the responsive format and it appears all is well.  Just means you have to be very careful with how complex your emails are. 

Ant James over 3 years ago

Thanks for replying so quickly. That's helpful to hear your case as I've not been able to do a split test here. Our newsletters feature quite a few products so are ticking over 102KB... In the short-term I'll have a think on what can be done to reduce bulk.

If there's anything that can be done within the FFE framework itself to help us users then I eagerly await it!

Corey Schaaf over 3 years ago

Keep in mind if there are pieces of Foundation that you aren't using, you can always exclude it by commenting the code out in the import (much like you can foundation for sites). For example navigate to the following folder: 

node_modules/foundation-emails/scss/foundation-emails.scss

Instead of importing everything, I know that none of my templates use the block-grid, thumbnail or menu, so I commented those pieces out. I think that saved about 6KB off the email.  Doesn't seem like a lot, but anything you're not using will help towards that overall total. 

Also, sometimes you can simply write your own table structures instead of using the the <row><column> method depending on your layout or content.  Sometimes people forget that you can write your own <tables> in the inky markup without running into problems. This cuts down on nesting which also increases bloat. (just make sure you practice good syntax and close all tags! 

Jeremy Blumenfeld over 2 years ago

This is really helpful. The structure is great for quickly coding things up and trying out different layouts, but we are definitely running into a lot of bloat.

I'm wondering if there is anyway that people have used within their stack to shorten the classnames that are applied?

Jeremy Blumenfeld over 2 years ago

This is really helpful. The structure is great for quickly coding things up and trying out different layouts, but we are definitely running into a lot of bloat.

I'm wondering if there is anyway that people have used within their stack to shorten the classnames that are applied?

Corey Schaaf over 2 years ago

Not that I'm aware of - but I believe some people are having success using UnCSS with the framework.