Category: Web sobriety

Methodology

In order to measure the various elements that make up a web page, we started by creating as basic an HTML/CSS page as possible to serve as a reference for the measurements. This page has an all-black background. For each element to be measured, an HTML page is created from this reference page, to which only the element to be measured is added. The CSS is created in a separate file, containing at least the all-black background. This file is not minified (deletion of characters not required for code interpretation), as the input on such a short file is negligible.

Next, a simple path is automated in GDSL (Greenspector’s automation language) to simulate standard user behavior, based on a basic usage of the measured component. Then, once the measurements have been taken on the measurement bench, we generate a dashboard and environmental projection. These results are then used to analyze and rank the impact of the various elements measured.

As far as the media integrated into the page as an example for measurement purposes are concerned, we have used the elements used in the MOOC activity. The latter originally featured a Twitter feed, which has since been removed. With INRIA, we decided to replace it with a Facebook feed (INRIA’s own), both in the activity and in the sample measured here.

Furthermore, we decided to measure elements based on their nominal usage :

• Images, animation and animated image : loading, pause
• Audio and video files : loading, pause, playing
• Facebook embed, table, text : loading, pause, scrolling, pause
• Interactive map : loading, pause, zooming, pause.

The measurements were carried out on a Samsung Galaxy S9, using WIFI.

Various assumptions have been made for the environmental projection:

• 100% of users and servers located in France
• Distribution of user terminals (source: https://datareportal.com/reports/digital-2023-france) :
  • 50% on smartphone
  • 3% on tablet
  • 47% on PC

The environmental projection methodology is described in this dedicated article.

Ranking page elements by weight

Warning: this article contains spoilers. It is based on the expected result for the activity “Compare the weight of elements on a web page”. If you haven’t done this activity yet, do it now.

In the MOOC activity, the proposed ranking is as follows (from the component with the highest weight to the one with the lowest weight):

1. High Definition Video
2. Low Definition Video
3. Audio podcast
4. Raw image
5. OpenStreetMap
6. A social network feed
7. Autres traductions
8. Text only

As a result of the measurements we have carried out, the data transferred when the corresponding pages are loaded gives the following results:

This is more or less the same classification as in the activity, with slight differences due to the content chosen for each content type.. It should be noted that the weight of these elements depends on several factors, in particular the social network selected and the content integrated here (message, message thread, etc.). The same applies to the other elements measured here, but the order of magnitude is still quite correct.

So here we can validate the ranking of element weights as proposed in the INRIA MOOC activity. We could stop here, but now let’s take it a step further. To do so, let’s take a look at what happens after the page has loaded, as well as at other metrics and indicators.

Other impacts of web page elements

So we’re sticking with the eight elements proposed in the activity.

The dashboard generated via Greenspector Studio lists several other metrics and indicators. The first score calculated concerns performance. However, on such lightweight pages, loading is too fast to be able to differentiate between elements in any meaningful way due to “noise”, in particular TTFB (Time to First Byte), which can vary slightly from one iteration to the next.

Data transferred beyond initial upload

Let’s start by looking at the data transferred after the page has loaded: pause for 30 seconds, scroll to the bottom of the page, then pause again for 30 seconds.

We see here that the data transferred beyond loading is most of the time not negligible. In particular, in the case of video and audio playback (as one might expect) but also for the Facebook feed.

Energy consumption

Over all the stages measured, the energy consumed according to the elements is as follows:

We see that the order remains generally coherent with a few exceptions (we will come back to this later) but especially the Facebook feed which, although less impactful than the video, is more so than the other elements (notably the audio player).

Facebook feed

The page containing the Facebook feed is by far the most impactful in terms of energy. While it’s logical that scrolling and loading should have an impact (since these steps involve at the very least a modification of the display), it’s even more surprising when it comes to pauses. Indeed, when the user is inactive, the display is normally not modified. So it remains to be seen whether any “parasite” requests occur. In the Greenspector Studio web interface, we obtain the following representation:

On a “normal” pause stage, no data transfer takes place (apart from any requests related to Chrome browser telemetry). If, in addition, the display is not modified, we would expect to see a stable, low CPU load and no data transfer. This is not the case here. Apart from a strong CPU peak, correlated with data transfer, the CPU peaks seem to be more related to tracking.

When integrating content from an external service, it is common for requests to be sent at regular intervals to the source site to inform it of user behavior and interactions with the integrated content. We see it here in the case of Facebook but be aware that most social networks do this (in this regard, I recommend that you test the integration of Linkedin content…).

For more information, see our article on integrating third-party services on a web page: https://greenspector.com/fr/service-tiers-youtube/

Audio file integration

The text appears more impactful for energy than the interactive map or images. All these contents do not cause any change in the display once loaded and just viewed. On the other hand, on an AMOLED screen (like that of the S9 used here), the display of the text is more impactful than the images and the interactive map because the background is black but the text white. On this type of screen (and this is the reason for dark mode from a energy consumption point of view), a black pixel is much less expensive to display than a white pixel. We are therefore here in a special case but one which allows us to understand where the impact of a page in consultation only comes from.

For more information, see the article on the impact of color on energy consumption: https://greenspector.com/fr/faut-il-changer-son-fond-decran-pour-consommer-moins-de-batterie/

Intermediate conclusion

For MOOC activity elements, the measurement of transferred data confirms the expected ranking, with only a slight downside related to integrated social networking content.

However, if we look more closely at the energy consumed, we see that much of the impact of the Facebook feed occurs after loading, via regular requests to third-party services. This underlines the need to go beyond measuring requests, transferred data and the DOM, and also to measure what happens after the initial load, at the risk of missing out on third-party services (and elements whose loading is deferred, often for performance reasons). Also, it is a question (at the risk of insisting) of being as close as possible to user behavior.

Let’s take a look at how to add to the initial list of new items often found on the web.

Other elements integrated into a web page

In addition to the elements proposed in the MOOC activity, we looked at other items:

• Animated GIF
• CSS animation (simple text animated to arrive progressively on the screen from the right, in an infinite loop) based on a basic example from MDN: https://developer.mozilla.org/fr/docs/Web/CSS/CSS_Animations/Using_CSS_animations
• Native HTML table

The methodology for measuring and creating the sample pages is exactly the same as that described above.

Let’s take a look at the results.

Data transferred during initial loading

As a result of the measurements we have carried out, the data transferred when the corresponding pages are loaded gives the following results:

In addition to the above ranking of activity elements, we note that the selected GIF is heavier than most elements (which is of course linked to the content chosen for integration).

The table is less voluminous than the text because it contains fewer characters (fewer sentences of dummy content have been introduced into the table than into the page used to measure the impact of the text alone). We’ll see later that, in the case of the table, the overconsumption lies elsewhere. The animation here appears rather light (a few lines of HTML and CSS).

Note that the elements added here do not involve any additional data transfer beyond the initial loading stage.

Energy consumption

The results obtained here are as follows:

When limited to the elements of the MOOC activity, we noted a few differences with the ranking initially proposed. In particular, the Facebook feed stood out as the most impactful in terms of energy.

Here, we can see that the CSS animation is by far the most impactful in terms of energy. The Facebook feed comes right after the videos, followed by the animated GIF. This order is noteworthy: unlike the animated GIF, which continuously modifies the display, the Facebook feed appears rather static when the user is inactive. As mentioned above, its excessive energy consumption is due to what is not visible: requests to Facebook and video preloading.

The native HTML table is slightly more energy-intensive than plain text, even though it contains fewer characters. So, from the moment it’s displayed, the table makes slightly greater demands on the CPU (more on this later).

This was already mentioned in the article on sober sites:
https://greenspector.com/fr/un-site-sobre-est-il-necessairement-moche/

When an element on a page causes continuous or almost continuous changes to the display, the energy impact can be considerable. We’ll see in the last part of this article how this affects environmental impact.

Intermediate conclusion

The three added elements fit in unsurprisingly with the initial ranking based on data transferred. However, from an energy point of view, the CSS animation and the animated GIF have a considerable impact. This underlines the need for measurement to go beyond HTTP requests, transferred data and DOM. The usefulness of the latter metric for environmental projection remains debatable. The cases presented here are good illustrations of cases where the DOM is very light but the impacts are very significant.

This is detailed in another blog post: https://greenspector.com/en/dom-as-a-metric-for-monitoring-web-sobriety/

Finally, we’re going to use a different measurement methodology and collect data to get a more global view of the various elements.

Measuring pages with a “classic” benchmark

For this new series of measurements, we started with the same sample of pages, but used a classic benchmark. Each page is measured over a period of 70s, using the following steps:

• Page loading
• A pause with the page displayed in the foreground
• A pause step with the page displayed in the background
• Scrolling on the page

To find out more about the benchmark, visit this page: https://greenspector.com/fr/comment-est-calcule-lecoscore-dans-le-cas-dun-benchmark-web-ou-mobile/

The results are as follows:

As far as data transfer is concerned, we can see what we’ve already observed. However, it is more difficult to distinguish between CSS animation, text and HTML tables, as the quantities of data transferred are very small.

As for the CPU, we note some slight variations but above all the excess consumption for the CSS animation, the GIF and the Facebook feed are all the clearer. Following this top trio, we find the HTML table which, despite the small amount of data necessary for its loading, turns out to be impactful for the CPU.

For his part, Alexander Dawson has begun to investigate the impact of various standard HTML and CSS elements: https://websitesustainability.com/cache/files/research23.pdf [PDF 384 kb].

In terms of HTTP requests, the Facebook feed and the OpenStreetMap map are unsurprisingly at the top of the list. This involves the integration of dynamic elements provided by third-party services, which require more files to function. It’s worth noting that requests to and from Facebook are almost continuous, reaching more than 170 in all after a few minutes of user inactivity (as we saw above).

Regarding greenhouse gas emissions equivalents, animation and moving images have the most impact, followed by the Facebook feed (due to its high data and CPU consumption). For information, land use and water are also indicated (see the article on environmental projection: https://greenspector.com/en/environmental-footprint-methodology/). The rankings for these two other indicators remain broadly identical.

Intermediate conclusion

These new measurements, with a slightly different methodology, once again underline the need to take into account not only different metrics, but also the discrepancies observable during the evaluation of several environmental indicators.

Overall conclusion

Staying within the same perimeter (data transferred during initial loading), the measurements confirm the ranking of elements proposed by INRIA’s MOOC activity. The only point to be discussed is the integration of a social network element. In the sample selected here, the integration of the Facebook feed has a greater impact than the interactive map from OpenStreetMap (without even counting the other impacts identified beyond the initial loading or energy-related data).

If we go beyond this measurement perimeter (by also looking at other environmental metrics and indicators), the ranking may change, particularly because of the impact on energy consumption.

Lastly, the addition of new elements that can be integrated into a web page inevitably modifies the ranking, but above all refines the mental model mentioned in the introduction to this article. In particular, CSS animation and animated GIFs (as well as HTML tables to a lesser extent) highlight the impact on metrics that are not currently measured by most tools, even though they play a key role in environmental impact. For example, the CPU’s impact on the terminal’s battery discharge can lead to an acceleration in the terminal’s battery renewal, and therefore to major environmental impacts linked to this operation. This observation directly calls into question the widely adopted mental model for the environmental impacts of digital technology, which leads some people to “compensate” for their self-imposed diet of transferred data by setting up animations. By extension, this also raises questions about the impact of different formats and codecs for certain content (where the reduction in weight can be offset by a calculation overload that reduces or even cancels out the environmental gains).

While it’s normal to start with a simple mental model, this article also aims to highlight the need to refine it so that you have all the elements in hand to make informed choices. Hopefully, some of the results presented here will contribute to this.

In conclusion, two rankings are proposed here.

The first relies only on the data transferred during the initial loading, as initially planned in the activity (from least to most impacting):

1. Table
2. Text 
3. Animation 
4. Optimized image
5. Interactive map
6. Integration of social network content
7. Animated GIF
8. Audio file
9. Low-definition video
10. Raw image
11. High-definition video

The second ranking is based directly on the projection of greenhouse gas emissions over all measurement stages (which means going back to the metrics to explain, but also being transparent about the environmental projection model):

1. Text 
2. Table 
3. Light image
4. Interactive map 
5. Audio file
6. Raw image
7. Low-definition video
8. High-definition video
9. Integration of social network content
10. Animated gif
11. Animation 

Laurent DEVERNAY

After working for more than 15 years in web development, Laurent Devernay became a technical consultant in responsible digital technology at Greenspector. When he is not coaching organizations on the eco-design of their digital services, he teaches courses on digital sobriety technologies.

ldevernay.github.io/

Key numbers

The results obtained for opening links in another tab are summarized as follows:
The overall impact is 1.9 gCO2eq, 0.4 L water consumption and 4.1 cm2 land use.

The results obtained for opening links in the same tab are summarized as follows:
The overall impact is 1.8 gCO2eq, 0.3 L water consumption and 3.9 cm2 land use.

On a website, the default behavior when a link is clicked is to open it in the tab the user is already in. To return to the initial page, the easiest thing to do is to use the browser’s (or your phone’s) backspace function. This may be seen by some Internet users as an inconvenience. There are at least two possible solutions:

• On the user’s side: hold down the Ctrl key to open the link in another tab, or click with the mouse wheel.

• For developers: force the link to open in a new tab (via the target=”_blank” attribute or via JS). However, this means leaving the user no choice. It is therefore advisable to notify the user of this behavior (Opquast Rule 141 – Users are notified of new window openings). Otherwise, this may lead to accessibility problems.

In all cases, target=”_blank” must be accompanied by additional attributes for security reasons, as follows:

<a href=”https://greenspector.com/fr/le-petit-bout-de-la-lorgnette/” target=”_blank” rel=”noopener noreferrer”> 

The “noopener” (https://html.spec.whatwg.org/multipage/links.html#link-type-noopener [EN]) and “noreferrer” (https://html.spec.whatwg.org/multipage/links.html#link-type-noreferrer [EN]) values ensure that context information is not passed on when the link is clicked. Seemingly redundant, they are mentioned here together to support some (very) older browsers: https://stackoverflow.com/a/57630677 [EN].

The discussion about whether or not to open links in another tab (or on another page) is not new, and the arguments are numerous. Many of them can be found here: https://www.badsender.com/en/2023/01/27/target-blank-links-email/

From the point of view of environmental impact, there is also room for discussion. Opening the link in another tab could lead to an unnecessary multiplication of open tabs, thus increasing the environmental impact (by putting more strain on the terminal). Conversely, opening the link on the same page could lengthen the user’s journey on the original site, risking a loss of progress after going back (entering information, reading an article in progress, etc.).

As always, it’s important to get back to the real reasons behind this choice, especially if it’s a question of improving your own site’s statistics by keeping it open while the user explores other links (which is not a good way of doing things).

In the absence of an ideal answer to this problem, we decided to use measurement to shed further light on the issue.

Methodology

We’ve created a test page that’s as simple as possible. It features two links leading to the same page. The first opens in the same tab, the second in another tab.

For the measurement, two GDSL scripts were created to automate the route and take the measurements:

• A script that consists of clicking on the link that opens in another tab and then returning to the first tab (three times in a row)
• A script that consists in clicking on the link that opens in the same tab and then going back via the browser directly (three times in a row)

Each of these routes follows the same stages :

1. Load test page

2. Pause for 30s on test page

3. Load destination page (click on link)

4. Pause for 30s on destination page

5. Going back
   
6. Pause for 30s on original page

Steps 3 to 6 are repeated 3 times each, in this order.

In all cases, the link destination page is the same. The idea here was to choose a lightweight page with enough content for the measurements to be meaningful. We therefore chose an article from the Greenspector blog: https://greenspector.com/fr/le-petit-bout-de-la-lorgnette/ Beyond the first iteration, the cache limits the number of requests made by relying on elements stored on the client side (as with any web page, provided it is correctly configured).

The measurements are performed on the latest version of the Chrome browser on a Samsung S9 phone with brightness set to 50%, in WIFI. Ten iterations of measurements were performed for each script.

Measurements were taken between August 24 and 29, 2023. Following these measurements, a campaign dashboard (aggregating data from Greenspector tools) was generated, in particular to be able to compare measurement stages and calculate an overall Ecoscore based on Performance, Transferred Data and Energy scores.

For the environmental projection, the following assumptions are made:

• 100% of users and servers in France
• 100% complex servers
• 51% of users on smartphone, 3% on tablet, 46% on PC (average stats for France)

Results 

The results obtained for opening links in another tab are summarized as follows:

The overall impact is 1.9 g CO2e, 0.4 L water consumption and 4.1 cm2 land use.

The results obtained for opening links in the same tab are summarized as follows:

The overall impact is 1.8 g CO2e, 0.3 L water consumption and 3.9 cm² land use.

Initially, therefore, it appears that opening links in the same tab is slightly more advantageous from an environmental point of view. In particular, it appears that the path is much shorter when opened in the same tab. In fact, it’s easier to go back via the button on Android phones than to go through the list of open tabs.

Presumably, keeping tabs open has a greater impact on the phone’s battery. Let’s take a closer look.

The following diagram shows the energy consumption of the various stages:

Blue indicates the opening of links in another tab. Black indicates opening in the same tab.

Stages of the journey with links opened in the same tab are almost systematically less impactful. In particular, this is true for pause steps, which seems to confirm the impact of multiple tabs opened when pausing on the current tab. This also reflects the fact that going back is much easier via the phone button than via the tab list.

For all the steps measured, very little data is transferred. However, for users who need to go back, it’s important to integrate the bfcache (https://web.dev/bfcache/ [EN]). This browser optimization makes backtracking and forwarding smoother.

Conclusion 

Based on the environmental metrics and projections for the test case chosen here, it seems more advantageous to open the links in the same tab by default. On the other hand, it’s important to bear in mind that the user mustn’t lose progress in this way (e.g. while typing or reading a long page). What’s more, the bfcache must be correctly implemented to allow subsequent backtracking. In this case, the user is free to open the link in another tab using the shortcuts provided. However, it is essential to provide information on the behavior of links if this is not the default behavior (as well as the language of the destination page if it differs from the original page). In conclusion, let’s not forget that accessibility and quality (as implemented via the Opquast rules) must remain a priority when integrating links.

Laurent DEVERNAY

After working for more than 15 years in web development, Laurent Devernay became a technical consultant in responsible digital technology at Greenspector. When he is not coaching organizations on the eco-design of their digital services, he teaches courses on digital sobriety technologies.

ldevernay.github.io/

Content in 3 minutes

What is a third party service? They are services that allow to integrate a functionality or a complex content via code that we have little control over. The 10 most frequent third-party services block the loading of sites for about 1.4s. Google fonts are the most common service even though its use may contravene the RGPD.

The impacts of third-party services are far from negligible. In terms of environment, performance, security but also personal data management, attention grabbing and sometimes even accessibility. It is therefore advisable to use them as little as possible. This last point is supported by the RGESN and GR491 guidelines.

Best practices for limiting third-party services?

• Your site is under construction: do not include third-party services
• Your site is already built: limit the addition of content or remove certain third-party services (by checking compatibility with the design, marketing or strategy already in place)
• Your site will load faster: a bonus for sustainable digital as well as user experience.

A concrete example:
During a client audit, it was decided to remove the twitter feed present on several pages of the site. Results:
A significant improvement in metrics and indicators. In particular:

• Reduction of the battery discharge rate by 36%.
• Reduction of the CPU load by 76%
• Reduced the volume of data transferred by 68%.

Context

Third-party services are present on 94% of websites and represent 45% of the requests made by all websites. These services are used to integrate a functionality or complex content via code most often hosted on another site, with little or no control over it. Thus, it can be an analytics solution, a video, the contents of a social network, a captcha, trackers, etc.
Here is a list (sorted by categories), built by Patrick Hulce.

You can find more information about them as well as statistics on their use in the Third-parties chapter of the Web Almanac : https://almanac.httparchive.org/en/2022/third-parties

The statistics show that the 10 most frequent third-party services block the loading of sites for an average of 1.4s and that technical optimizations are often possible (minification, compression, delayed loading, but also removal of obsolete JS code). Also, most of the most used third-party services are linked to Google.

It is interesting to note that Google fonts are the most widely used service, even though their use may contravene the GDPR. One way to fix this is to host the corresponding files yourself. Of course, the best thing to do is to stick to the available system fonts as much as possible.

All this shows that the impact of third-party services, especially on websites but also on mobile applications, is far from negligible. In terms of environment, performance, security, but also in terms of personal data management, attention grabbing and sometimes even accessibility (see the Temesis article on this subject [FR]: https://www.temesis.com/blog/contenus-tiers-exemptes-deroges-audites/). It is therefore advisable to use them as little as possible.

At Greenspector, this is something we look at very closely for our customers, using specific tools to list third-party services and estimate their respective impacts. This is a significant added value of measurement. It is also an essential step in reducing environmental impacts and improving the user experience.

Today, let’s look at a best practice of sobriety, which consists of integrating as few third-party services as possible into a digital service.

Existing reference systems

This criterion can be found in the Specifications family of the RGESN [FR](Référentiel Général d’écoconception de services numériques): 2.5 – Has the digital service taken into account the environmental impacts of third-party services used during their selection ?

This is also found in GR491 (Reference Guide to Sustainable Design of Digital Services): Are third-party services (social network feeds, social wall, carousels, google maps, etc.) not used for convenience to compensate for the lack of content production resources ?

Good practice

Objective

This sobriety best practice consists in limiting the number of third-party services in a digital service.

When to use it?

It occurs at the design stage of the service (choose not to include the services in question) but also when adding content (for example, do not integrate directly a Youtube video in an article).

Ease of implementation

It is technically easy to remove a third-party service. On the other hand, this removal may require upstream discussions on design, marketing or strategy. That’s why this decision should be made as early as possible in the project.

Estimated gains

The gains can be significant in several areas related to Sustainable Digital. In all cases, this proves beneficial to the user.

Case study

While working for a client (initial audit then daily measurements and expertise), it was decided to remove the Twitter feed on all pages of the site. The modification took place on February 1st, 2023. The measurements on the homepage highlight the gains linked to this modification, which can be observed by measuring the consumption of IT resources and energy via the Greenspector tool.

Evolution of page load metrics between February 1 and 2, 2023

Ecoscore (web benchmark) of February 1st 2023

Ecoscore (web benchmark) of February 2, 2023

We can see here a significant improvement of the metrics and indicators. In particular:

• 36% reduction in battery discharge rate
• 76% reduction in CPU load
• Reduction in the volume of data transferred by 68%.

Following the environmental projection via the Greenspector methodology, we can see that the impact of this homepage was, before deleting the Twitter feed, 0.95g eqCO2. After deleting this feed, it is 0.54g eqCO2.

The page in question has more than 2.5 million views per year.

For the sake of simplicity, we leave aside here the contributions of the client-side cache (even if they are certainly non-negligible), the disparities of time spent by each person on this page, as well as the modifications made during this time.

We go from an impact of 2.38T eqCO2 to 1.36T eqCO2 over one year, which is a reduction of more than 40% of the impact in terms of greenhouse gas emissions.
For the other impacts assessed, the trend is similar. Thus, over one year, we go from 383047 to 224675 L of water consumed and from 383 to 230 m² of land use.

To go further

For third-party services that are deemed essential, there are methods to reduce their impact (via efficiency). This can include integrating an interactive map or video as a clickable thumbnail.

Some articles approach the subject from a web performance perspective:

• Reducing the Site-Speed Impact of Third-Party Tags, par Andy Davies : improving performance through tag management 
• How to Find the Third-Parties on Your Site, par Simon Hearne : presentation of the RequestMap tool, used on Webpagetest to detect third-party services. This tool was already discussed on an article about auditing Android applications. 
• Identifying, Auditing, and Discussing Third Parties, par Harry Roberts : how to audit third-party services on a website
• Reducing The Web’s Carbon Footprint: Optimizing Social Media Embeds, par Michelle Baker
• Partytown : a library to handle third-party services through a WebWorker 
• Are my third parties green, par Fershad Irani : an online tool to assess the environmental impacts of third-party services through the origin of electricity used by the servers

Laurent DEVERNAY

After working for more than 15 years in web development, Laurent Devernay became a technical consultant in responsible digital technology at Greenspector. When he is not coaching organizations on the eco-design of their digital services, he teaches courses on digital sobriety technologies.

ldevernay.github.io/

With the arrival of digital technology and in particular the web, many people predicted that this would greatly limit the volume of printing. In reality, the opposite has happened as these new technologies, coupled with the democratisation of personal printers, have made it easier for everyone to print. In passing, this can be seen as an illustration of the rebound effect or Jevons’ paradox. 

It should be borne in mind that printing is still used for personal or business purposes for the transmission or storage of information. 

We will therefore look here at how to make the printing of website content as low impact as possible. We won’t discuss the printer, paper or inks used (printing in draft quality, double-sided, multiple sheets per page, etc). Instead, we will look at good design practices that can make printing less impactful and the printed content more readable.

To begin with, let’s look at what the existing guidelines mention on this subject.   

• The GreenIT.fr collective’s repository of 115 good practices in web ecodesign proposes BP_027: “Provide a print CSS”. The brief example provided already covers a good part of the recommendations that we will detail in the rest of the article.   
• GR491 suggests checking that a clean version is available for print and that a font optimised for print is used.   

This is partly in line with what we will now see in terms of recommendations.

Limit the number of pages 

Often, when trying to print a simple web page directly, the number of sheets used seems disproportionate. This is the case, for example, when printing an electronic ticket, such as a train ticket. There are a number of ways of overcoming this: 

• Reduce page margins  
• Reduce the spacing between elements  
• Reduce the size of titles and texts  
• Linearise content  

• Remove peripheral content (decorative images, contextual elements such as blocks presenting similar articles or the latest articles, menus, top and bottom of the page, navigation elements, etc) 

Limiting ink surfaces 

If we saw in the previous good practice how to limit the amount of paper used, it is also possible to limit the use of ink. If a dark mode is in place, make sure that the background is white when printed. Again, it may be worth removing unnecessary visuals such as decorative images.   

Some fonts are specially designed to reduce the amount of ink used in printing. Take a look at Ryman Eco or tools like EcoFont.   

Another option is to allow the user to print the content without the images. In some contexts, images can help with comprehension, but you might as well give the user the choice of printing a page with or without the images.   

In addition, CSS filters can limit the ink cost of images: Quality print versions with CSS filters. 

How to implement these good practices?  

As mentioned in the 115 best practices for web eco-design, the easiest way is to set up a stylesheet dedicated to print and used for the whole website. For this, I invite you to read the Smashing Magazine article “Print stylesheets in 2018“.   

Conclusion  

In order to facilitate the printing of website content, we have seen here the best practices to implement. The development costs are limited but the benefits for users can be substantial. It is indeed essential to keep in mind all the contexts of use of a website. 

Laurent DEVERNAY

After working for more than 15 years in web development, Laurent Devernay became a technical consultant in responsible digital technology at Greenspector. When he is not coaching organizations on the eco-design of their digital services, he teaches courses on digital sobriety technologies.

ldevernay.github.io/

Awwwards references websites that stand out from the crowd in terms of their conception, user experience and design. It is a true reference for web designers and web developers around the world. The concept is simple : every day, designers submit their websites to Awwwards. The site is submitted in the “Site of the day” category. It is judged by members of the Awwwards community of designers, developers and agencies. The best site of each day of the year appears in the book “The 365 Best Websites Around the World”. Every month, a site is elected “Site of the month”. At the end of the year, during a ceremony, the jury chooses the best of the year.

The Awwwards site has grown since its creation in 2009. The nominees are divided into 6 groups:

• Sites of the Day
• Sites of the Month
• Sites of the Year
• Developer
• Mobile Excellence
• Honorable

There are also site themes called Categories, of which there are 26.

Pretty sites but not necessarily sober ?

Our curiosity led us to analyze 10 sites nominated on Awwwards. We have selected sites nominated in the “Mobile Excellence” group. These sites are judged on 4 criterias :

• Friendliness
• Performance
• Usability
• PWA

Awwwards assigns a score for each of the above criteria, which is then used to calculate a total score.

At Greenspector, we decided to go further in the analysis of these sites to see if they met our sobriety criteria.

Additional analysis of sites at the bottom of the ranking 

Betterup.com

More than 200 HTTP requests to load the page and then 1 request about every 10 seconds. The requests point to about 50 domains.

These queries can be found on the RequestMap (a tool created by Simon Hearne):

While the presence of the cookie banner is legitimate, the chatbot obscures a good part of the display, which is problematic for an Awwward-awarded site. Is this chatbot really necessary? Shouldn’t it open (and load) only on user request? 

It should also be noted (but unfortunately this is often the case) that about thirty requests are triggered as soon as cookies are accepted.  

When scrolling, the number of requests and the amount of data transferred increase considerably following the direct integration of a Vimeo video. The use of the facade pattern would have been more judicious. We also notice a carousel which is difficult to use on mobile (swipe only). 

The lazy-loading is well implemented but we note various superfluous visual effects (in particular parallax) which still come to weigh down the site, in particular with scrolling.  

When we scroll down to the bottom of the page, we are at more than 400 HTTP requests and more than 12 MB of data transferred.

Finally, the Wave plugin detects about 40 accessibility errors and about 30 contrast errors.

We had previously discussed the subject of sober sites, but here we are typically on a site where a very busy design and too many third-party scripts greatly degrade the user experience. This is particularly true when we look at the measurements during the pause stages:

Ideally, there should not be any data transfers or such sharp spikes in the battery discharge rate. This may be due to third party services or animations.

Datagrid.co.jp

For this site, the loading never really ends, as the Firefox developer tools show:

The stats here (including loading time) never stop increasing.  

The site is undoubtedly interesting from the point of view of pure design but it is a site that is absolutely not usable:  

-The perpetual movements (without the possibility of control) will make it inaccessible for some users.  
-The continuous requests to about fifteen domains will put a strain on the data plan of some users.  
-Contrast errors are indeed present and keyboard navigation is more than laborious.  

All this results in an environmental impact more than consequent with continuous data transfers and solicitation of the battery of the smartphones used, even in background.

Webflow.com

The remarks on the two previous sites apply largely to this one. When loading, there are more than 200 requests for 2 MB transferred. Indeed, there are more than 57 domains, which corresponds well to the slogan of the site proposing to make your website a marketing asset.  

If the size of the images is rather well controlled, most of the weight of the site comes from the JS with more than 100 requests of which a dozen are more than 100 kb each.

The lazy-loading of the images does not seem to have been implemented and the design of this homepage seems to be much too heavy anyway.  

On the other hand, the errors reported by the Wave plugin are almost non-existent.  

In short, there is still work to be done in order to make this homepage more sober, to better integrate certain elements but also to limit the use of third party services.  

Additional analysis of top-ranked sites 

Ladispensadelchianti.it

This site is rather light (just over 1 MB) and fast to load. We still get 60 HTTP requests for the first load, spread over 15 domains.  

This homepage is visually rich but remains clear. The images are optimized (especially through the use of webp format). It is regrettable that lazy-loading is not implemented. 

The cache is globally well managed, which is a very good thing.  

On the other hand, we notice that the fonts are rather large, for a total of 5 requests. It would be better to use system fonts or a variable font to limit the number of requests.  

Also, from an RGPD perspective, it would be best to avoid Google fonts or host them yourself. 

Some accessibility errors appear with Lighthouse.  

Animations should be limited to the scroll and cursor movement effects seem superfluous (even harmful for the user). 

Ingridparis.com

This site is apparently quite sober. No requests to third party services and globally optimized images but too many. The implementation of lazy-loading (preferably natively) would be a very good thing.  

The loading time is made longer by the default loading of a 1 MB video and about 20 requests for the fonts alone. 

On the other hand, the cache is implemented on almost all elements. 

Even if Wave reports few accessibility errors, animations should be less present at the scroll on the page. Currently, they make the scroll step the most impactful step from the point of view of the battery discharge speed.

Azzerad.com

The trend observed so far seems to be confirmed: many images (optimized but most of them are loaded twice) and many animations.  

15 queries just for fonts but not many queries to third party services.  

In short, a site that would benefit from being a little more sober in its presentation and from going further in the technical optimization to avoid that the efforts (especially image optimization) are cancelled out by bad practices (such as double loading of images).  

On the Wave side, some accessibility errors come up but mostly contrast problems.

Data projection to measure environmental impact

We went further in the analysis by carrying out a data projection in order to obtain additional details, notably on the CO2 impact, the water footprint and the soil footprint.

Here, energy, data exchange, CPU and memory usage are directly measured on the device. The environmental impact and Ecoscore (based on the measurements but also on the application of good practices) are calculated. You will find the details in the dedicated article on the blog. It is thus possible to compare the different sites, classified here according to their Ecoscore (the higher the better).

Conclusion

When the design of sites must be judged or compared, those that come out on top are often sites offering a profusion of images and other visual effects such as animations or video. Even if these design choices can be more attractive or entertaining, they often harm accessibility but also environmental impacts… and therefore, ultimately, the users themselves. 

Even when looking for sites specifically dedicated to sustainability, one finds examples with numerous accessibility errors or transferring files larger than 5 MB when loading. 

On the Awwwards site, usability is indeed one of the criteria taken into account. However, a quick look at the scores shows that even for betterup.com, which has many accessibility errors, the usability score is often very high. It is normal that a subjective element, often linked to personal experience and the perception one has of such creations, comes into play. Nevertheless, an objective measure should allow to relativize and nuance the statement, as well for accessibility as for sobriety (even performance). These additional constraints could be a source of creativity and give rise to innovative user experiences while remaining respectful of users and the planet. 

Laurent DEVERNAY

After working for more than 15 years in web development, Laurent Devernay became a technical consultant in responsible digital technology at Greenspector. When he is not coaching organizations on the eco-design of their digital services, he teaches courses on digital sobriety technologies.

ldevernay.github.io/

It is not easy to choose the right type of image to reduce environmental website impact. We can focus on image size or on display performance (are they two related ?). This may be the right approach. However, an energy measurement will be a more precise element if you really want to measure the actual consumption and move towards reducing the environmental impact.

in 2017 we carried out a benchmark of the new WebP format compared to JPEG and PNG. Support for Webp in browsers was beginning. In addition, AVIF, a promising image format, has arrived.

Here is an updated study.

Methodology

As a test image, we used the one proposed by Addy Osmani in an article on Smashing Magazine.

The images were generated to have the same perceived quality. Compression qualities are therefore different between formats.

Image 1 : https://res.cloudinary.com/ddxwdqwkr/image/upload/v1632192015/smashing-articles/206-webp-ayousef-espanioly-DA_tplYgTow-unsplash.webp

• Test 1 Default quality given by Sqoosh (https://github.com/GoogleChromeLabs/squoosh/) : JPEG original (560KB), JPEG@q75 (289KB), WebP@q75 (206KB),  AVIF@q30 (101KB)
• Test 2 Target quality JPEG@q70 : JPEG (323KB), WebP@q75 (214KB), AVIF@60 (117KB)
• Test3 Low quality : JPEG@q10 (35KB), WebP@q1 (35KB), AVIF@q17 (36KB)2

Image 2 : https://res.cloudinary.com/ddxwdqwkr/image/upload/v1632080886/smashing-articles/q50jpg.jpg

• Test1 : Target quality of 45k : Original (442kB), JPEG@q50 , WebP@q54, AVIF@q36

Image 3 : https://res.cloudinary.com/ddxwdqwkr/image/upload/v1632082138/smashing-articles/q10-25.jpg

• Test 1: Target quality of 25kB : Original (716KB),  JPEG@q10 , WebP@q5, AVIF@q19

Measurement protocol

• We display the images one by one in a Chrome browser on a real device (Samsung Galaxy S10).
• We use Greenspector tools to measure energy consumption and other metrics (CPU, performance…).
• We perform a measurement throughout the display of the image and this 3 times to have stable measurements.
• The measurements are made under different Wifi, 3G and 2G network conditions.

Results

On image 1 for test 1, we obtain the following energy consumption measurements:

If we observe more closely the behavior in WiFi, we can better appreciate the differences in consumption with the confidence interval.

In Wifi, the consumption is relatively similar between the types of image. JPEG consume little more than other format. It is followed by WebP format and then by AVIF.

In 3G and 2G, the difference in consumption is noticeable and AVIF consumes less energy than Webp.

These behaviors are explained by the smaller file sizes in AVIF and Webp.

On image 2, the behavior is the same:

In image 3, there is almost no difference between the formats. The image is small and we find ourselves in an operation close to wifi (fast transfer):

The behavior is the same with image 2 which is at 45kB:

This is the same behavior for image 3:

It is necessary to monitor the new formats (JPEG XL, Webp2…) as well as the optimization of the algorithms because even if the gains in size are significant, the decoding processing could potentially gain even more efficiency. Indeed, here is for example the CPU processing for image 1 on test 1, where AVIF consumes more CPU than the other formats.

Recommendations:

In any case, it is necessary to compress images with lower quality, regardless of the image format. A quality >85% is useless. Energy consumption is reduced by a factor of 2 for qualities that remain high, and reduced by a factor of 6 for low qualities.

Even if the energy consumption is relatively similar between the formats, the gain provided by AVIF and Webp is much greater for less efficient connections. The choice of AVIF and Webp will be preferable because the users are not connected with broadband! In addition, the gain in terms of data exchanged will be interesting to limit the overall size of the site.

The choice between Webp and AVIF is not easy and will depend on the type of images and visitors. Additionally, Google is working on WebP version 2, and formats like JPEG XL are coming to compete with AVIF. However, considering the benefits of Webp other than the environmental impact, we recommend the use of WebP more.

For information, here is the taking into account of the AVIF format in the browsers:

As well as the Webp format:

In any case, optimize your images, compress, reduce the size and lazy-load!

Olivier PHILIPPOT

Digital Sobriety Expert
Books author «Green Patterns», «Green IT – Gérer la consommation d’énergie de vos systèmes informatiques», …
Speaker (VOXXED Luxembourg, EGG Berlin, ICT4S Stockholm, …)
Green Code Lab Founder, ecodesign software national association