At Badsender, we are concerned about the climate crisis that our world is facing. Aware that in our business, the purpose of marketing actions is not always the most virtuous one, we wish to explain the basics of emailing eco-design with this guide.
See also: What is the role of a CRM team in the ecological transition?
What is eco-design?
Eco-design is the set of methods that allow to reduce the environmental impact of a product or a service. In the case of eco-design in email, it is about reducing the amount of energy and resources needed for the production, transport, display and storage of an email.
If there are many ways for the CRM professions to support the transition to a greener process, in this guide, we focus on good practices in terms ofemail design and html integration for email.
What is the email impact on the carbon footprint?
There are various studies that calculate the carbon footprint of an email but it is extremely difficult to measure it accurately. Many factors are to be taken into the calculation.
But there is one element that has a direct impact on the carbon footprint of an email: its weight. The heavier an email is, the more space it requires on a server and the more energy it needs to travel from the sender to the recipient.
Example: if we can put 1GB on a server, and if we store 100kb emails, we can put 10.000 emails on a server. But if they are 200kb emails, we now need 2 servers, so twice as much energy for the storage.
The average carbon footprint of an email is very difficult to estimate, because of the different servers and their energy consumption, the transit of emails, their weight, etc. It is therefore very complicated, if not impossible, to have precise figures. A 2010 study speaks of 4 grams of carbon per email. This figure can be found a lot on the internet but it is an estimation of an average and can differ greatly. And if 4 grams seems low, don't forget that you have to multiply that by the volume of emails sent to a database per year. For example: With a database of 500,000 recipients, to whom I send an average of 4 emails per month, I have 96 tons of CO2 per year. So yes, reducing the weight of an email will reduce its carbon footprint.
See also: Email, a micro-pile of digital carbon emissions?
How to reduce the weight of an email?
An email consists of two parts: the HTML code and the associated images; and in some cases a third part, the attachments. Of course, it is strongly advised not to put attachments in mass emails. It is much more effective to put a link to the file you want to show to your recipients. The design of the emailing also has a direct impact on the HTML code.
The problem must therefore be tackled from several angles.
Email eco-design and design
Design is an often misused tool in emails. The purpose of a design is to support a message and, in most cases, to make the recipients react by means of clicks in the email. Another point of design is also to carry the corporate image of a company. Whether the email is "pretty" or not is a totally subjective notion.
In this context, if we start eco-designing, we must conceive a design that limits the number of images and that also takes into account their size, their format and their compression. Less weight means less energy consumed. A design that also takes into account the limitations between the different email clients and anticipates the HTML code of the email will allow a more robust and lighter code.
Prefer eco-color web
Have you already immersed yourself in the subject of Dark Mode in emailing ? One of its advantages would be that dark backgrounds with light text would use less energy (because less brightness) than light backgrounds with dark text. In other words, the white background of your email will consume more energy than a black background, since the pixels of the screens displaying white (and therefore brightness) consume more energy than pixels displaying black. It also shows that white is the most energy consuming color, followed by blue, purple, pink, red, yellow, green, and finally black).

So why not design all our emails with dark backgrounds? This would also help to solve some of the issues specific to Dark Mode Email. This hypothesis requires many verifications and tests to be able to affirm it definitively. In particular because the influence of colors on energy depends on the screen technology (LCD, IPS, Retina, AMOLED, Super AMOLED, TFT).
Use text instead of images
Why do you absolutely want to represent the social networks on which you are present via icons? Icons that, by the way, evolve more or less regularly, and we are never sure to have the latest version. And by the way, how to reconcile the colors of these icons with your own graphic charter? So many questions you don't have to worry about when you use a simple text with a hyperlink.
In the same way, why not take advantage of the phenomenal choice of HTML special characters before considering an image? For example, does a text bubble or a bulleted list really need to be in a particular design? Why not just use the typeface &bull
which not only allows your recipient to display this element as soon as the email is opened, without downloading the images, but also reduces the need to call on external resources?
Try emojis
Emojis, these small images used in an email message to express an emotion, represent a character, an action, an object... they allow to quickly bring a graphic dimension to the email. And yet, they are not strictly speaking an image (at least for the emoji characters imported in the Unicode space)!
It is true that the emoji is not displayed in the same way in different browsers and messaging solutions. But this is a very good example of acceptable degradation in emailing : in the end, as long as the message gets through, and the graphic aspect is relatively respected, that's what matters, right?
Avoid exotic or non-web-safe fonts
The graphic creation includes of course the formatting of textual elements. You should know that it is obviously possible to create very graphic and aesthetic emails only with text, formatting of this text, and a little color. It is not mandatory to use images. Less is more. But it sometimes requires the choice of particular typographies, taken from sites like dafont.com, or Google Fonts. These are so-called "non-web-safe" fonts, or exotic typographies. Why this name? Because they are probably not installed by default on your recipients' machines.
In addition to the difficulty of correctly displaying typography on all messaging solutions, it should be noted that their proper display not only requires additional HTML code, but also requires an additional call to these hosted typographies (which are therefore external resources). This requires, logically, energy. And if you were thinking of converting these texts into images, you should know that this is not the best solution either, because of email accessibility, adaptability or simply translation.
Ideally, use web-safe fonts that are already present on your recipients' machines: CSS Font Stack: Web Safe and Web Font Family with HTML and CSS code.
Working in "One Column
To avoid emails that are too "long" and because technology allows it, email designers have taken the habit of building some content in their design on several columns side by side. So on desktop, the columns are next to each other, and stacked on mobile.
However, this method requires much more HTML code:
- First because you have to nest HTML tables inside each other
<table>
which, remember, are not data tables, and therefore require, for accessibility reasons, arole="presentation"
and therefore additional code.- Moreover, we will need media queries to achieve cell stacking on the mobile version.
- Finally, for the stacking to take place, the cells will not be
<td>
but some<th>
. And the<th>
request a CSS reset to overcome rendering problems specific to some email solutions.
In short, you have understood: the multiple columns method requires more development time. But also more code, and therefore more storage capacity. Favoring a single-column design would therefore simplify the coding time and reduce the final weight of the HTML file.
Prepare the images correctly
You have understood that when you can do without an image, you should not hesitate to do so. Great. But in some cases, you have no choice but to insert visuals (regular images or background images) in your email design. Let us see what are the good practices to generate them.
Prepare the images at the right size
It is highly recommended to design your visuals at the dimensions at which they are displayed and called in the HTML code (except in the case of Retina). It is not necessary to design images larger than the dimensions at which they will be displayed, because then your images are heavier for no good reason.
Delete metadata
When a picture is taken from a camera, the file of the visual includes information: date of shooting, type and model of camera, geolocation... All those data are an extra weight for the file! It's obvious, but remember to make sure that the visuals you use have no metadata attached.
Optimize weight
You put visuals in your email, so be it. That's understandable. And what software do you use to prototype your emails: Figma? Photoshop? Invision? Adobe XD? In any case, it is important to export your visuals:
- in a relevant format, it is a first step, but we will address this topic in the following chapters.
- by reducing their weight. Because images require server hosting; and the heavier your images are, the more space you require, and therefore energy.
With Photoshop, nothing could be easier, since you can reduce the "quality" of your file with a slider at the time of export. You also have the possibility, at the same time, to evaluate the weight gain and the final quality of your visual.
On Figma, there are plugins like Downsize to compress and resize your images without leaving Figma! However, if none of these solutions speak to you, you can choose online solutions like squoosh.app, tinypng.com, or tinyjpg.com, depending on whether you want to do batch or non-batch processing.

Taking advantage of Retina
Retina is a brand of screen resolution used by Apple on its devices, such as iPhones, iPads and MacBooks. A Retina display has a very high resolution, which means it can display images and text with great sharpness and precision.
However, in an email, to display high quality images on a Retina screen, it is necessary to call visuals with dimensions twice as large as the dimensions given in the HTML code. This implies heavier visuals (instead of 2 pixels by 2 pixels for a given surface, we will have 4 pixels by 4 pixels, since the resolution is twice as high. So we won't have 4 pixels in total, but 16 pixels).
Should the Retina then be imposed on all visuals? Well, no, EXCEPT if your Retina visuals are highly compressed, and this is a tip we give you: Let's take a visual of 250 pixels wide by 166 pixels high.
Without image compression and without planning for Retina, this same visual will weigh 55kb. After compressing this visual to 90% on a solution like Squoosh.app, this visual goes from 55kb to 16kb. And the quality remains the same to the naked eye.
We could think that by preparing this visual for the Retina by doubling the width and respecting the homothety, the visual would be heavier. Without a doubt... UNLESS YOU COMPRESS THE QUALITY OF THE VISUAL IN PHOTOSHOP! Because, as the visual is larger and more detailed, it is also possible to compress it much more. And, surprisingly, the weight of the Retina display can then compete with the weight of the non-Retina display, or even beat it, while keeping a better level of details!
Limit (drastically) the animated gifs
Animated gifs are very useful to simulate a video or to present an animated visual, that's a fact. However, they are usually very heavy and difficult to optimize while keeping a respectable image quality. Ask yourself the right questions: is this animation really worth being animated? Can I insert all this information in a static visual, in jpg?
If the GIF animation must be present at all costs, do not forget to optimize it (by compressing it, reducing the quality, removing some unnecessary states) as much as possible with platforms like ezgif.com.
Choose the format
Only three image formats are properly supported in an email: JPEG, GIF and PNG. Know which format to choose when exporting your visual with the table below. But above all, between these three formats, it is important to understand that the weight will not be the same for the same visual.
Benefits | Disadvantages | |
---|---|---|
JPEG | JPEG retains optimum image quality with 16 million colors | Does not support transparency or animation. |
GIF | GIF is an 8-bit limited image format, which makes it generally lighter than JPEG or PNG. In addition, it supports animation. | It is limited in terms of colors and image quality. Animated gifs are "blocked" in their first state on Outlook email software on Windows. |
PNG | PNG is a lossless image format, which offers a higher quality than GIF while maintaining transparency | Using a PNG format for an image with many colors can make your PNG heavier than your JPEG. |
It is important to note that the choice of format will depend on the intended use of the image. For example, if you need an image with lots of detail and little concern for file size, PNG would be a better choice. If you need an animated image, GIF would be the ideal format. And if you need an image with a good compromise between image quality and file size, JPEG might be the best choice.
Take advantage of the images already hosted...
There are visuals that can be found on several campaigns: the logo, the pictograms of social media, the visuals of the reassurance banner... So why not take advantage of it? It is not necessary to export these images again for each new campaign, and have to optimize them. Simply take advantage of the work already done!
... and clean your images
If your campaign has been a while ago... Is it necessary to keep the images on the server? It is unlikely that your recipients will open this campaign again after a long time, right? This can be the opportunity to delete the images of campaigns that are too old on your server, in order to reduce the necessary storage space. Because eco-design is not only before hand, or in the moment... It's also afterwards!
Dissociate textual content and graphic formatting
To simplify the HTML integration of the email, to guarantee optimal accessibility, but also to use a minimum of visuals, we recommend, as much as possible, to design in raw HTML (with CSS formatting if necessary) as much as possible textual content.
Coding the buttons
A Call to action can take several forms, but the most common one is a button, with rounded corners or not, with a border or not. Limiting yourself to these few graphic layouts (without forgetting the formatting of the text that the button contains of course) can easily be managed entirely with HTML attributes and CSS properties.
A button like the one above can therefore be coded as follows:
<table role="presentation" cellpadding="0" cellspacing="0" border="0" align="center">
<tr>
<td bgcolor="#141414" style="border-radius:50px; padding:20px 40px;"><p style="margin:0; font:bold 18px/22px Arial, Helvetica, sans-serif; text-transform:uppercase;"><a href="/en/<https://www.monsite.fr>/" style="color:#FFD845; text-decoration:none;">I go for it!</a></p></td>
</tr>
</table>
Not only do you gain in user experience, since the button will be displayed right away, with no image download required, but you also greatly limit the call to external resources. We could also add a drop shadow on the button directly in CSS, or a hover effect with the pseudo CSS class :hover
provided, of course, that you accept its elegant degradation.
Think about the background images
The background images are a real asset on the design of an email. They allow you to use text or buttons with an image in the background. We are therefore in the dissociation of the textual content and the graphic formatting.
However, if their primary implementation technique is relatively simple (use of the CSS background
), it requires much more code when you want to ensure its display on most messaging solutions. It will therefore often be necessary to accumulate both the HTML attribute background
, the CSS property background
, and the CSS property background-image
.
But it's a different story when you look at their display on... Outlook, the email desktop application for Windows.
Indeed, in order for a background image to appear on this messaging software, it is necessary to add VML (Vector Markup Language); a code in which it will be essential to add fixed dimensions. Apart from the problem of automatic block stretching, this also represents additional code. So :
<td background="<https://www.monsite.fr/images/monimagedefond.jpg>" style="background:url('<https://www.monsite.fr/images/monimagedefond.jpg>') no-repeat top center; background-image:url('<https://www.monsite.fr/images/monimagedefond.jpg>'); background-repeat:no-repeat; background-position:top center;">
</td>
Will become, for the background image to be supported on Outlook :
<td background="<https://www.monsite.fr/images/monimagedefond.jpg>" style="background:url('<https://www.monsite.fr/images/monimagedefond.jpg>') no-repeat top center; background-image:url('<https://www.monsite.fr/images/monimagedefond.jpg>'); background-repeat:no-repeat; background-position:top center; width:200px; height:200px;">
<!--[if gte mso 9]>
<v:rect xmlns:v="urn:schemas-microsoft-com:vml" fill="true" stroke="false" style="width:200px;height:200px;">
<v:fill type="frame" src="<https://www.monsite.fr/images/monimagedefond.jpg>" color="#000000" />
<v:textbox inset="0,0,0,0">
<![endif]-->
<div>
</div>
<!--[if gte mso 9]>
</v:textbox>
</v:rect>
<![endif]-->
</td>
Do you see where we are going? Background images should be used with care, as they greatly overload the weight of the final HTML code.
Moderating innovations
Another important part is to limit the "gadget" sections. A carousel in an email is fun, but it only works in a few email clients. And that requires a significant amount of code, plus a second layer of code to handle some cases where the carousel doesn't work.
The impact of a carousel compared to a "standard" section is also often negligible. This is the kind of element that pleases decision makers and marketers who are looking for a "WAOW" effect. Even for Badsender, this is something we appreciate for the technological challenge, the research and development and therefore the challenge. But in the end, it will have very little impact on the expected objectives of an email.
Design System Email
We often talk about Design System Email as, among other things, a gain in consistency and efficiency in the production of emails. The gain in efficiency already represents, in itself, a gain in production time, and therefore energy. But these are clearly not the only advantages! The Design System Email also allows, whether it is on design stage or code stage, to make "savings" on the weight of the files to create.
Let's take the example of the Figma prototyping platform: if you design atoms, molecules, organisms according to the principle of Atomic Design, you can call these organisms as instances of the main components in your future campaigns. You no longer need to recreate each organism separately, each time.
Coding in Fluid or Spongy
The Fluid or Spongy coding method consists in providing emails of 100% width, fluid therefore, with a maximum width via the CSS property max-width
to limit the width of the email for the desktop format.
This technique is designed to display a mobile version of the email on email solutions that do not support media queries or that remove the media queries contained in the <style>
style tag in the head <head>
of the email.
It has both advantages and disadvantages.
- Advantages: It often includes design constraints, favoring the one column or a settlement system. As a result, the design is generally a bit more simplified. As this method does not change the "size" of some elements on mobile (since media queries are excluded), it can also simplify the work and time spent on the design. And since media queries are not required, it's a lot less code to write. No need to worry about breakpoints either since the email automatically adapts to the screen size.
- Disadvantages: because the CSS property
max-width
is not supported on the Outlook desktop application on Windows, it is necessary to surround fluid tables with conditional comments by so-called "phantom" tables, which have a fixed width. And to add<div>
... And CSS reset... Anyway, this includes using additional code, making it more difficult to understand and maintain, but above all more cumbersome.

We are talking here only about the Fluid or Spongy method, and not Hybrid, which combines both the Fluid method + the use of media queries to further optimize the display of the mobile version of the email on messaging solutions that support them.
Need help?
Reading a guide can not make everything perfect. Maybe the best thing to do is to ask us. No ?
Email eco-design and code
Coding an email is complex. It is a question of having a correct rendering in different email clients that each have their own quirks. For this, we tend to have redundant code because one email client will understand instruction A and the other will understand instruction B. If we want to reduce the code, and therefore the weight of the email, we must find solutions to optimize the amount of code that will be written.
A few characters on an email will result in a fairly small change in weight, only a few kilobytes. But with the scale effects, even a few kilobytes - multiplied by hundreds of thousands, or even millions of emails, over several sendings per month - tends to be a serious weight.
For example, 10kb on four emails per month sent to 500.000 recipients, represents 240GB per year...
Calling non-websafe fonts
We will not discuss here the support or the simplicity in implementing this or that method. That is not the point. We focus on the resources called, or the weight of the code.
Several methods are possible to call an exotic typeface. We will detail here the two most common ones:
- The method
<link>
with the link tag with the path of the CSS sheet where the hosted font is described. In the case of a Google Font, for example :
<link rel="preconnect" href="">
<link rel="preconnect" href="" crossorigin>
<link href="" rel="stylesheet">
- The method
@font-face
. Copy and paste the content of this CSS sheet into the style tag<style>
of your email. This gives :
/* cyrillic-ext */ @font-face {
font-family: 'Montserrat';
font-style: normal;
font-weight: 400;
font-display: swap;
src: url() format('woff2');
unicode-range: U+0460-052F, U+1C80-1C88, U+20B4, U+2DE0-2DFF, U+A640-A69F, U+FE2E-FE2F;
} /* cyrillic */
@font-face {
font-family: 'Montserrat';
font-style: normal;
font-weight: 400;
font-display: swap;
src: url() format('woff2');
unicode-range: U+0301, U+0400-045F, U+0490-0491, U+04B0-04B1, U+2116;
} /* vietnamese */
@font-face {
font-family: 'Montserrat';
font-style: normal;
font-weight: 400;
font-display: swap;
src: url() format('woff2');
unicode-range: U+0102-0103, U+0110-0111, U+0128-0129, U+0168-0169, U+01A0-01A1, U+01AF-01B0, U+1EA0-1EF9, U+20AB;
} /* latin-ext */
@font-face {
font-family: 'Montserrat';
font-style: normal;
font-weight: 400;
font-display: swap;
src: url() format('woff2');
unicode-range: U+0100-024F, U+0259, U+1E00-1EFF, U+2020, U+20A0-20AB, U+20AD-20CF, U+2113, U+2C60-2C7F, U+A720-A7FF;
} /* latin */
@font-face {
font-family: 'Montserrat';
font-style: normal;
font-weight: 400;
font-display: swap;
src: url() format('woff2');
unicode-range: U+0000-00FF, U+0131, U+0152-0153, U+02BB-02BC, U+02C6, U+02DA, U+02DC, U+2000-206F, U+2074, U+20AC, U+2122, U+2191, U+2193, U+2212, U+2215, U+FEFF, U+FFFD;
}
You will logically see that the second method is more code-intensive. This is probably true. But is it more energy-intensive on the called resources? Indeed, we are not calling an external stylesheet here, since its content is directly filled in the email code.
We do not have the definite numbers, so it is up to you to draw your conclusions.
Exploiting the HTML5 doctype
This doctype declaration, made at the very beginning of your HTML code in the form a specific tag !DOCTYPE HTML <!DOCTYPE HTML>
has a significant advantage: to be able to shorten the writing of self-closing tags even more. Thus, the :
<meta />
<link href="" />
<img />
<br />
<hr />
Can, with the HTML 5 doctype, be written in the following way:
<meta>
<link href="">
<img>
<br>
<hr>
Define the click zones
You may want to make the entire email clickable. This maximizes the chances of clicks on campaigns effectively, but it puts a considerable burden on the code weight.
Know how to correctly delimit the click zones of your campaign. Generally, buttons or texts with underlining are to be preferred.
Perfecting media queries
The media queries, necessary for the proper display of the mobile version of the email, can be refined in several ways to reduce their weight and maintainability.
Think about the naming of class
CSS.
To make it easier for any new integrator to find his way around your CSS classes (and thus gain in efficiency, productivity and work time, and therefore energy), do not hesitate to use explicit class naming. Let us clarify with a concrete case: we regularly encounter obscure classes in email codes. For example:
<p class="xd_45_haut">My paragraph</p>
For a higher statement of the sort:
@media screen and (max-width:600px) {
.xd_45_haut {
font-size:18px !important;
}
}
How can you expect any new integrator to take over the HTML integration to know that the xd_45_haut
can be used to change the font size of the element to 18px
on mobile? And, in fact, why not simply name this class fontsize18px
? It's a bit more explicit, isn't it?
Declare the classes separately.
Here again, let's use a concrete case.
<p class="premier_paragraphe">My paragraph</p>
<p class="second_paragraphe">My paragraph</p>
<p class="troisieme_paragraphe">My paragraph</p>
And the following attached media query:
@media screen and (max-width:600px) {
.premier_paragraph {
font-size:18px !important;
color:#000000 !important;
text-align:center !important;
}
.second_paragraph {
font-size:18px !important;
color:#000000 !important;
text-align:left !important;
}
.troisieme_paragraph {
font-size:18px !important;
color:#000000 !important;
text-align:left !important;
}
}
You could greatly simplify the understanding and weight of the code in the following way:
<p class="fontsize18px colornoir textaligncenter">My paragraph</p>
<p class="fontsize18px colornoir textalignleft">My paragraph</p>
<p class="fontsize18px colornoir textalignleft">My paragraph</p>
And the following media queries:
@media screen and (max-width:600px) {
.fontsize18px {
font-size:18px !important
}
.colornoir {
color:#000000 !important;
}
.textaligncenter {
text-align:center !important;
}
.textalignleft {
text-align:left !important;
}
}
Minimize the code
Minification allows you to reduce the weight of the HTML file by removing the indentation (the arrangement) of the HTML code and so allowing you to lose a few kilobytes (even a lot of weight!). In addition to indentation, minification in its extreme version also makes it possible to remove all line breaks in the HTML code. This practice can be used, but always make sure that the rendering of the HTML code is not "broken" or that the ESP supports this minification!
In the framework Maizzle, when producing the final code, we can ask the code to be minified (indentation and line breaks removed). At Badsender, depending on the case, we do not minify our HTML code so that the client can update the code, make changes and find his way around easily.
Delete comments
At Badsender, we don't necessarily think about deleting comments for the good reason that they are there... for a good reason. But in general, we don't have any comments, especially in our CSS code: to avoid bugs but also to reduce the weight of the code a bit. So, don't forget to clean up your HTML code of any unnecessary comments!
Shorten...
Hexadecimal codes
It is customary to write a hexadecimal code for a color in six characters, for example #FF0000
for red. However, this value can be shortened to three characters for codes composed of identical pairs. Thus, #FF0000
will become #F00
.
CSS values and properties
Here we talk about the values of the CSS properties, and the CSS properties themselves. Let's first imagine a cell with the following CSS properties:
<td style="padding-top:10px; padding-right:20px; padding-bottom:10px; padding-left:20px;">
Well, you can shorten all of these individual properties statements : padding-top
, padding-right
, padding-bottom
and padding-left
in a single CSS property padding
, this way:
<td style="padding:10px 20px;">
This is of course applicable to the CSS property margin
. (At Badsender, as we use the Maizzle framework, it is more difficult to gather all these variations in a mega-property). Let's now consider another example, the formatting of a text. Let's imagine a paragraph with the following graphic formatting:
<p style="font-family:Arial, Helvetica, sans-serif; font-size:16px; line-height:22px; font-weight:bold; font-style:italic;">
You should know that it is possible to shorten the code this way :
<p style="font: Arial, Helvetica, sans-serif 16px/22px bold italic;">
And the support is really good! Be careful though to respect the order of the values to make it work. Can I email... font shorthand
Take advantage of automatic tag formatting
Some HTML tags (obsolete for some of them, of course) inherit an automatic graphic formatting. These are the <b>
, <strong>
, ,
,
. Here is the reconciliation of their graphic layout :
Tags | Graphic layout |
---|---|
<b> | fat |
<strong> | fat |
italics | |
italics | |
underlined |
So why not use these tags whose formatting is unanimously approved? See this code:
<span style="font-weight:bold; font-style:italic; display:inline;">My text</span>
From this code, we can then simply obtain :
<b><i>My text</i></b>
Practical, isn't it? On the other hand, it is essential to also think about "accessibility", and therefore, use the appropriate tags. If it is only about graphic formatting (bold, italic), you can use the ,
,
<b>
. But if the text is important, use the <strong>
or .
<strong><i>My text</i></strong>
In the same way, let's be "practical": an HTML element <a>
to insert a link around a text, will (no doubt) make the text underlined automatically. So is it necessary to add an attribute style
with the value text-decoration:underline
to this link? No.
Abandon the target="_blank"
Today we are used to declaring all links as follows:
<a href="https://www.monsite.fr" target="_blank">
Either with an attribute target="_blank"
to open a new tab on a browser when consulting emails in a webmail. However, in terms of user experience (UX), it is strongly recommended not to change the native behaviors of elements. In fact, we can take the liberty of not declaring this attribute target
and thus gain weight.
Also, do not add a title
to your links, counterproductive in terms of accessibility.
Deletion of units
Still looking for a few characters to delete? Then why not look at the units set to zero values? If the values are equal to 0
, why keep the unit? So:
<td style="padding:0px 0px 0px 10px;">
will become :
<td style="padding:0 0 0 10px;">
Getting out of the <table>
Mark Robbins as Rémi Parmentier have already raised the idea and taken this initiative, through their respective movements "Get off the table" and "Thinking outside the <table>". A small overview of the test results we are currently shooting.
- Most HTML elements (
<hn>
,<p>
,
,,
,
<strong>
,<b>
,,
...) have a automatic graphic formatting (or by default) which differs according to the mail clients, media and browsers. Bold, italic, background color, indentation, bullets, text size... We can see that the tags of type
<hn>
are for example automatically in bold on almost all mail clients. This implies a series of "resets" in CSS. Can we then apply them directly in the<style>
present in the<head>
? - The
<style>
present in the<head>
is not interpreted by Android 5.1, Android 6.0, or on Gmail App IMAP (Android 4.4), nor on T-Online (regardless of the browser). This major constraint forces us to write our styles online (inline), directly on our HTML elements. - Inline CSS reset through CSS properties
line-height
,font-size
,margin
,padding
,font-family
,font-weight
tags work correctly on<hn>
or<p>
. - We see that we can use the element
<div>
within an HTML email integration, but it does not support the CSSbackground-color
on Outlook 2007, 2010, 2013, 2016, and 2019. In addition, the CSS propertywidth
is not interpreted at all on Outlook 2007, Outlook 2010, Outlook 2013, Outlook 2019 on Windows 10, and Windows 10 Mail (Windows 10), nor the CSS propertymax-width
. Therefore, we are forced to use conditional comments specific to Outlook (versions greater than or equal to Outlook 2007) to simulate fixed widths on tables.
Without totally leaving the <table>
However, it is possible to limit their use! Here are some tips...
Using semantic tags
Since we are concerned with accessibility in email marketing, it is customary to use semantic tags: multi-level titles (<h1>
, <h2>
, <h3>
, <h4>
, <h5>
, <h6>
), paragraphs (<p>
), bulleted lists (
and )...
But did you know that you can also take advantage of these tags to lighten the weight of the code by accumulating these tags one after the other, without necessarily declaring a new row and cell each time? Thus:
<table>
<tr>
<td>Level 01 title</td>
</tr>
<tr>
<td>Level 02 title</td>
</tr>
<tr>
<td style="padding-top:20px;">Paragraph 01</td>
</tr>
<tr>
<td>Paragraph 02</td>
</tr>
</table>
Will become :
<table>
<tr>
<td><h1>Level 01 title</h1>
<h2>Level 02 title</h2>
<p style="margin-top:20px;">Paragraph 01</p>
<p>Paragraph 02</p></td>
</tr>
</table>
Use the padding
and margin
An old myth in email coding is that margins between elements can only be designed with empty cells and rows. However, there are two handy CSS properties for handling both external and internal margins: margin
and padding
.
These two CSS properties can be used with the knowledge of their support and their small specificities: for example, the padding
will be mainly well supported on <td>
. However, beware of their use in the case of sister cells. The margin
can be correctly used on paragraphs or titles.
Thus, the following code :
<table bgcolor="#F6F6F6">
<tr>
<td style="line-height:1px; font-size:1px; height:40px; width:40px;" height="40" width="40"> </td>
<td style="line-height:1px; font-size:1px; height:40px;" height="40"> </td>
<td style="line-height:1px; font-size:1px; height:40px; width:40px;" height="40" width="40"> </td>
</tr>
<tr>
<td style="line-height:1px; font-size:1px; width:40px;" width="40"> </td>
<td><h2>Title</h2></td>
<td style="line-height:1px; font-size:1px; width:40px;" width="40"> </td>
</tr>
<tr>
<td style="line-height:1px; font-size:1px; height:10px;" height="10" colspan="3"> </td>
</tr>
<tr>
<td style="line-height:1px; font-size:1px; width:40px;" width="40"> </td>
<td><p>My paragraph</p></td>
<td style="line-height:1px; font-size:1px; width:40px;" width="40"> </td>
</tr>
<tr>
<td style="line-height:1px; font-size:1px; height:40px; width:40px;" height="40" width="40" colspan="3"> </td>
</tr>
</table>
Can be transformed in the following way:
<table bgcolor="#F6F6F6">
<tr>
<td style="padding:40px;"><h2>Title</h2>
<p style="margin-top:10px;">My paragraph</p></td>
</tr>
</table>
Quite a difference, isn't it?
Handling the "accessibility VS HTML file size" paradox
Coding methods to provide accessible email to people with disabilities include:
- The use of semantic tags (
<p>
,<h1>
,<h2>
,<h3>
...). - The implementation of attribute
role="presentation"
on all tables that are not data tables. - The addition of an attribute
lang
on the tag<html>
to specify the language of our content. - The addition of a
. - The addition of a
<div>
just after the<body>
...
Yes, but let's take the example of semantic tags: if we want to use them, we have to think about adding CSS reset so that we don't inherit the default styles of some browsers or email solutions.
In short, many additions to be made. But then, this is counterproductive with our will to lighten the HTML code, isn't it? Or rather, our will to reduce the emailing carbon footprint?
Yes... and no. Because if you don't offer an accessible version of your email, the user with a disability will use other solutions (which themselves generate digital usage) to try to browse and understand the content of your email. So, you might as well be ahead of the curve.
And then, it is quite possible to find a balance between these two objectives, isn't it?
Keep only the minimum
A well-designed email is an email that works, renders and complies with all email solutions... And that contains only the bare minimum in terms of HTML code, without superfluous. And this can be a paradox. Because, in order to have a rendering that conforms to all email solutions, it is sometimes necessary to double HTML attributes with CSS properties for example, whose function will be the same (but not the support).
Moreover, spending time to make sure that the graphic rendering of the email is compliant sometimes requires code adjustments, multiple tests... In short, time spent! And time spent on a computer is also, in itself, an expenditure of energy...
Accepting the paradox with Render / Pixel perfect
One of the complexities of email marketing is the difficulty to have an identical rendering in the different email clients. And yes, everyone obviously thinks of Outlook... Here it is important to know your target. If you target individuals, the use of Outlook desktop applications will be marginal. So it is not relevant to spend time and code weight to have a "perfect" rendering in Outlook. Often, a whole series of degradations will be acceptable and will not hinder the message at all (background images replaced by color, rounded corners that become straight, etc.). And if your target audience uses Outlook for the most part, then it will be important at the design stage to conceive a creative that will meet your objectives and that will be realistic in view of the limitations of Outlook software.
Outlook is an example, but it is not limited to this case. There are many different contexts desktop and mobile versions, optimization for multiple screen sizes, retina images, darkmode, and of course, all the different interpretations between email clients. Again, the goal of design is to meet the objectives of an email.
The elegant degradation
The premise of elegant degradation is to first build for the leading edge and the best, and then manage the worst performing systems.
http://www.pompage.net/traduction/degradation-elegante-et-amelioration-progressive
This concept applied to email design and email code resides in the acceptance of a degradation, for example of a CSS effect on email solutions that are less efficient in terms of support.
Let's take the example of rounded corners: To design rounded corners in CSS, you must use the border-radius
. This same property is not supported by all messaging solutions.
To guarantee the display of rounded corners on all messaging solutions, it would therefore be necessary :
- use rounded corners in images,
- or use VML.
And therefore add extra code (not to mention the problems that this can also produce on the Dark Mode or on the elasticity of the elements, since the VML requires to use fixed widths and heights).
Rendering an element with just the CSS property border-radius
If the message is to be displayed on a messaging solution that does not support this same property, it will be square corners, without workaround. But does this affect the understanding of the message?
Of course not. We can therefore "accept" that graphic effects or formatting are not supported, as long as they are not essential to the graphic rendering of the email or to the understanding of the message.
Choose your tools
Another part on which Badsender has the hand on the design of an email is the choice of the tools. We do indeed choose responsible digital tools. We have for example left Microsoft Teams and OneDrive to go towards Infomaniaka Swiss provider of similar services with carbon neutral servers and data protection in accordance with Swiss laws (and RGPD compliant), we opt for OpenSource tools whenever possible, etc.
Email Builder & Framework
Beware of heavy email builder codes that include many cases (without making a generalization). The best is to code emails by hand.
Of course, when many emails are produced, it is interesting to use an Email Builder. But is it necessary to use a Builder when you only do 4 campaigns a year? Be careful when choosing your Email Builder, try to choose one that is responsible for the HTML code produced.
Le Patron, the email builder developed by Badsender, is a special case, since it is an email builder that uses a "hand-made" and customized code.
At Badsender, we also use, for the production of HTML code, a framework named Maizzle which does not necessarily accept all the recommendations quoted above, but which allows us to gain greatly in production time. As a result, we can "find ourselves" between the time saving (energy saving) and the heavier code produced via this framework.
Reduce testing
Email preview tests are essential for debugging and validating the rendering of an email campaign before sending, that's a fact.
But do we have to test a lot? Besides the fact that this can quickly represent a considerable cost, it is also important to note that testing requires not only time (and therefore energy spent by the integrator and the machine) but also hosted screenshots (more than 80 for example on EmailOnAcid).
Therefore, opt for tests when you are sure that your email is completely finalized, or that you have made all the necessary returns. And don't forget to archive or delete your test results on these platforms when you no longer need them!
The Mantra to eco-design your emails
Before starting any investigation into an innovation, a design idea, a particular parameter, always ask yourself the question: is it worth it? Is it necessary to spend so much time in R&D to achieve such a rendering, such a configuration?
It is not clear? So let's take the example of Dark Mode: Rendering emails on media or email solutions configured in dark mode is really not easy to perfect. But is this really the goal? Get to know the viewing habits of your recipients (which email solution do they use? What is their primary viewing format? Desktop? Mobile? Tablet?).
The results you will get from this will allow you to highlight the choices to make in your design and coding methods. If your recipients are mainly a BtoC target, there is little chance that the opening will be mainly on the Outlook for Windows software. So can't we abandon all the code palliatives specific to Outlook to lighten the load?
To conclude
Marketing is a practice that often goes against the ecological needs of our time. Badsender is aware of this, and we want to do everything we can to be consistent with our values. This includes reducing, as much as possible, the carbon footprint of an email. From now on, this is something we will systematically put forward and propose to our customers.
And we're only talking about the levers that can be used to create the email, but There are many other ways to limit the impact of email marketing in general: target relevant recipients for emails, in order to send less; use the most carbon-friendly tools and providers possible (You can see the result of Badsender's 2021 carbon footprint here); getting involved in projects such as Zero Carbon Email (supported by Badsender); making it easy to unsubscribe so you don't send emails to people who aren't interested; etc. All of which will require further articles to explore.