MB1
HTML/CSS Compressor
Has anybody used an HTML compressor with their code? I have a rather lengthy responsive newsletter with a lot of pictures. I've run an image compression on the photos to decrease the file size (https://tinypng.com/), but with all the sections that my client wants, the email is coming in at 123KB, which is quite a bit higher than the 102KB recommended size.
I'm still hoping to optimize content in order to get under the 100KB recommended send size, but does anybody know how a HTML or CSS compressor works? Is something like this worth using?
An example: https://htmlcompressor.com/compressor/
Thanks!
Hi, Mike -
I always minify. There are many misconceptions about compressors - and so most email coders are afraid to use them.
The most bang-for-your-buck comes from whitespace and comment removal. While valuable in making sense of complicated email code, indentation and comments are completely unnecessary at the time of sending. I've seen examples where unnecessary whitespace accounted for 70% or more of the email's overall code weight.
Avoid optimizers that try to merge/simplify/remove attributes - this is where email code can get corrupted. As we all have experienced, verbose syntax and attributes are often necessary to ensure compatibility. HTML/CSS optimizers will try to rewrite your code to make it smaller. Many offer a way for you to disable messing with your code. Disable any options that aren't specifically related to whitespace removal.
Avoid a single, uninterrupted line. Some email clients choke on excessively long lines of markup. I recommend breaking lines at 800 characters. The extra line breaks won't add a significant amount to your overall file size but ensure you won't run into unexpected problems due to long lines.
Although our workflow produces a separate minified ready-to-send email (without modifying the original HTML), any decent IDE can take a minified HTML/CSS file and reformat it back into readable, organized, indented code.
Always send the minified version to Litmus for testing just to make sure. It's highly unlikely that whitespace removal will introduce any rendering problems but it never hurts to test the version you intend to send to your recipients.
I wrote an in-depth blog post about the benefits of HTML/CSS minification for email. We've been sending minified emails for years and highly recommend it. A++++ will minify again!
On a separate note, it sounds like you're already tackling your image size problem. I haven't seen your artwork but make sure you're using the right image format for the types of images your including. Photos should be JPEGs, not PNGs. JPEGs can be dramatically compressed without sacrificing substantial quality. Image optimization can be completely automated - I use a pipeline of ImageOptim, MozJPEG and Guetzli to squeeze every extraneous byte from the images in our emails.
Hey,
I've personally never used a compressor on my email code, but some clients have sent me their html which has been and I generally have to sift through and fix it.
I wouldn't trust one with my own code, purely because of how fragile emails can be when it comes to rendering in the different mail apps.
If you do opt for a compressor, just make sure you test test afterwards.
Try to reduce line no as much as possible, i mean move next line near to previous line (side by side, not below), hope it will reduce size. Thanks
Assuming your images are hosted externally (which I would assume they are if you're using an EMS) the size of your images shouldn't effect the raw size of your email.
I ran some quick tests on one of the longer newsletters I've coded recently and using an html minifier (https://kangax.github.io/html-minifier/) and css minifier (https://cssminifier.com/)
In generally they get rid of line breaks which add to the file size but are largely for human reading not rendering engines. Running my css through saved little file space, but the html went from 46kb (~950 lines of code) to 34kb (a single line of code.)
I had to go back in a lot because it caused syntax errors to the point that constant contact wouldn't even let me save the file due to syntax errors ( I think a bunch of it was from MSO conditional codes, but it was really hard to tell since it's really hard to read the code once it's compressed).
Frankly if the email html file is that big, the email is probably just too long (to the point that who ever is receiving it probably not going to read half of it —especially keeping in mind that on mobile readers are going to be scrolling for miles. The client is probably insisting on cramming everything they possibly can into the email but the best bet is to either cut content or split it into two emails. Basically either they can cut content or email browsers are going to cut it anyway.