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
User terminals: the high environmental impact of the manufacturing phase
User terminals are now the biggest contributors to the environmental impact of digital technologyand this phenomenon is set to increase. This trend is mainly explained by the increasingly important equipment of households with smartphones, by a reduced lifespan of this equipment, and by the fact that it has a significant environmental impact. An impact mainly due to the smartphone manufacturing phase. The Ericson brand announces, for instance, an impact in use (i.e. linked to recharging the smartphone battery with energy) of 7 kg eqCO2 out of a total impact of 57 kg eqCO2, or only 12% of the total impact. The total impact takes into account the different phases of the smartphone life cycle: manufacture, distribution, use, treatment of the smartphone at the end of its life.
Hence the interest that manufacturers work on this embodied energy by eco-designing but also by improving the possibility of increasing the life of the equipment through repairability but also durability.
Regarding all these observations, it could seem unproductive from an environmental point of view to reduce the energy consumption of smartphones. In any case, the simplistic approach would be to put that impact aside. But the reality is quite different and the electrical flows that are involved in the use of mobile devices are much more complex than one might think.
Explanation of battery operation
Current smartphones are powered by batteries with Lithium-ion technology. On average, the capacities of the batteries on the market are 3000 mAh. The trend is to increase this capacity. The battery can be thought of as consumable, just like a printer cartridge. It wears out over time and the original capacity you had when you bought the smartphone is no longer fully available. That is, the 100% indicated by the phone no longer corresponds to 3000 mAh but to a lower capacity. And this initial capacity cannot then be recovered.
Battery wear is primarily created by a full charge and discharge cycles. A recharge/discharge cycle corresponds to an empty battery that would be recharged to 100%. I leave home in the morning with a phone 100% charged, the battery drains, I charge my phone 100% in the evening. A complete cycle in one day therefore!
If you charge your phone more often, you can cycle more (several incomplete cycles are ultimately equivalent to one complete cycle).
The more the number of cycles increases, the more the remaining capacity decreases. This wear leads to the end of battery life. Current technologies allow up to 500 cycles.
At the end of the cycle, the battery capacity is only 70% of the initial capacity. Beyond this annoying loss of autonomy, the battery suffers from certain anomalies, such as a rapid drop from a battery level from 10% to 0%.
Note that this effect will be reinforced by the intensity of the battery discharge: if the phone consumes a lot (for example during video playback), then the battery wear will be greater.
Impact on obsolescence
The loss of autonomy is a cause of renewal by users: 39% in 2018. This phenomenon is reinforced by the fact that the batteries are increasingly non-removable, which leads to a complete replacement of the smartphone by the user. In addition, even if the decrease in autonomy is not the only replacement criterion, it will be added to the other causes to create a set of signs indicating to the user that he must change his smartphone (marketing effect, power, new features…).
We can therefore easily make the link between the mAh consumed by the applications and the kg of CO2 due to the production of CO2. By reducing these mAhs, we would greatly reduce the wear of the battery, the life of smartphones would be extended on average and therefore the initial CO2 cost would be more profitable. The smartphone mAh has a much greater cost on the embodied energy of the smartphone (manufacture) than on the impact of energy to recharge it.
For example, for a classic smartphone, we have 0.22 mgCo2 / mAh for the recharged energy compared to 14mgCo2 / mAh.
Technological solution
Solving this problem can always be seen through the technological axis: increase in capacities, fast loading … If we take the case of fast loading, this will not change the problem, on the contrary, it will worsen its potentially increasing cycles. It is not by increasing the fuel tank of cars that we will reduce the impact of the automobile. Improving battery technology is beneficial, however, reducing the consumption of smartphones would be even more beneficial for the environment and the user.
Note that the CO2 impact is not only to be taken, indeed the manufacture of batteries is overall very expensive in environmental and social terms. Not to mention strategic resources with geopolitical impacts such as cobalt or lithium. Extending battery life is critical.
Everyone is talking about digital sobriety. From web agencies to politicians, including ESNs, all communicate on the subject, on the explanation of the impact, on good practices, on the willingness to go there. But what is it really?
We have been working on the subject within Greenspector for 10 years and we can in all modesty give our opinion on the real situation of the actors and especially on the barriers that will have to be overcome to really do eco-design and sobriety.
We have educated developers, students, and leaders. We have supported teams, applied good practices. We measured apps and websites. It took motivation to stay in the race. Because the context is different, and we are happy to see so much communication and actors involved. However, we believe that all is not won! Here are some tips and analyzes from veterans in the field, grouped into 7 mistakes to avoid!
Associate digital sobriety only with a department
In many actions that we have carried out, an important component was necessary: the consideration of the problem at all stages. Developer, Designer, Product Owner, decision-maker. And Customer… Without it, the project will not get far. An unfunded project, optimization research needs not wanted by the devs, technical improvements not accepted by the Product Owners … At best, the improvements will be made but with only a few little gains.
The solution is to engage in a shared approach. It takes a little longer (and more!) But allows the project to be understood by all and accepted.
Focus only on coding practices
The miracle solution when you think of digital sobriety is to tell yourself that if the developers respect good practices, everything will be fine. We can talk about it. We started an R&D project (Green Code) more than 8 years ago on this axis. It was necessary but not sufficient. Indeed, it is also necessary to work on the functionalities, the design, the contents, the infrastructure…
The establishment of a repository will be an important axis but more initially to initiate an awareness process. It is important not to say to yourself that it will be necessary to apply 115 best practices on almost all of a site because the effort will be enormous and the results will not necessarily be there.
Do not use professional tools
Many tools have emerged to evaluate websites. Indeed, it is quite simple on the web to monitor some technical metrics such as the size of the data exchanged on the network or the size of the DOM and to model an environmental impact. This is great for raising awareness and for identifying sites that are far too heavy. On the other hand, the system on which the software works is not so simple and the impact can come from many more elements: A JS script that consumes, an animation…
Taking action with this type of tool makes it possible to start the process but to say that the software is sober because we have reduced the data size and the size of the DOM is at the limit of greenwashing.
We are not saying this because we are publishers but because we are convinced that it is necessary to professionalize actions.
Fighting over definitions and principles
We have lived it! We have been criticized for our approach to energy. The birth of a domain leads to the establishment of new principles, new domains, new definitions … This is normal and often requires long discussions. But do we really have time to debate? Are they necessary when there is agreement that we all need to reduce the impact of our activities? The complexity of digital and obesity is there and can be felt at all levels. It is time to improve our practices overall, all wishes are good, all areas need to be explored.
Look for heavy consumers
The findings on the impact of digital technology are increasingly shared. However, teams may be led to look for excuses or responsible and not make corrections that seem more minor. Why optimize your solution when bitcoin is a consumption abyss? Why reduce the impact of the front when the publishers of libraries do nothing? Prioritization is important but it is often a bad excuse not to seek gains in your field.
ALL the solutions are way too heavy. So everyone is stuck on slowness. Everything is uniformly slow. We stick to that and all is well. Being efficient today means achieving a user experience that corresponds to this uniform slowness. We prune things that might be too visible. A page that has had more than 20 seconds to load is too slow.On the other hand, 3 seconds, … is good. 3 seconds? With the multicore of our phones / PCs and data centers all over the world, all connected by great communication technologies (4G, fiber …), it’s a bit weird, isn’t it? If you look at the debauchery of resources for the result, 3 seconds is huge. Especially since the bits circulate in our processors in nanosecond-level units of time. So yes, everything is evenly lent. And it suits everyone (at least, on the surface: The software world is destroying itself, manifesting for more sustainable development.)
Now let’s start optimizations by not looking for culprits!
Think only about technological evolution
We are technicians, we are looking for technical solutions to solve our problems. And therefore in the digital field, we are looking for new practices, new frameworks. And the new frameworks are full of performance promises, we believe them! On the other hand, it is an arms race that costs us resources. This development is surely necessary in certain cases but it is not necessary to focus only on this. We must also invest in cross-cutting areas: accessibility, testing, sobriety, quality … And on the human because it is the teams who will find the solutions for sober digital services.
Do not invest
Goodwill and awareness are necessary, on the other hand, we must finance change. Because digital sobriety is a change. Our organizations, our tools are not natively made for sobriety. Otherwise, we would not currently have this observation on the impact of digital. It is, therefore, necessary to invest a minimum to train people, to equip themselves, to provide time for the teams in the field. Just doing a webinar and training is not enough!
Let us have commitments related to the issue and the impacts of digital technology on the environment!
This study was carried out by Greenspector, a company specializing in the impact of digital technology, and EVEA, specializing in analyzes of the environmental impact of products. This study is based on:
a calculation methodology initiated as part of the CONVINcE project on the energy consumption of video. A project involving several players such as Orange, Sony …
energy and resource consumption measurements carried out on the myCANAL application to support hypotheses
collection of data on the use and infrastructure of Canal +
a bibliographic study to identify and correlate emission factors and energy consumption
The functional unit of this study is defined as follows: “Watch 1 hour of video, live or in a replay, on the Canal + interfaces”.
Disclaimer: The purpose of this study is to estimate, by orders of magnitude, the carbon impact of playing a video on Canal + interfaces. To date, it is based on reliable and robust sources and is intended to be representative of the reality of the Canal + infrastructure. However, this is not a complete Life Cycle Assessment (LCA). We rely on LCA methodologies but, for example, we have not performed a sensitivity analysis that would allow min-max deviations on the values. However, this study made it possible to formalize an analysis benchmark for the carbon footprint of a video service, and it could be used to monitor the evolution of the carbon footprint over time. And all this in no way detracts from the consistency of the data for its primary use.
Means of access to services
We have listed different ways to access myCANAL video services. Depending on this type of access, it is necessary to have more or less material (s). This inventory is needed to assess the impact of accessing video services. We have classified the means by category:
Canal + decoder
FAI TV Box
TNT Box
Game console
IP TV (Android TV, Samsung TV)
PC / Mac Multimedia Gateway with ISP Internet Box
Smartphone / Tablet with ISP Internet Box or GSM access
For Decoder, TV / TNT Box, Console, and Multimedia Gateway access, it is necessary to add a TV. We have ruled out all special cases of viewing considered as anecdotal compared to other accesses such as:
Display of the PC stream on a TV,
Multiroom viewing
Regarding the link between the terminals and the Boxes, we will consider that the Wi-Fi connection and the wired connection (Ethernet) have no impact on the consumption of the terminals (PC and TV).
Definition of visualization
Visualization quality influences end-to-end power consumption. We have taken the following 3 main definitions:
SD (Simple Definition)
HD (High Definition)
UHD / 4K (Ultra High Definition)
The definition depends on 3 factors:
compatible program availability
material compatibility in terms of quality
the quality of the connection (the quality of myCANAL videos is adapted according to the connection speed).
Greenspector’s exploratory measurements on myCanal show the impact of SD, HD, or UHD video consumption on smartphones, and then on laptops:
Bibliographic sources were used for the consumption of other platforms such as Consoles (Source 1), TV (Sources 1 and 2), Set-Top-Box (Sources 1 and 2). The consumption of Canal + decoders supplied by Canal + was also used.
Depending on the different equipment configurations, we obtain energy consumption which varies from 1.3 to 108 Wh / h, i.e. a ratio of 1 to 80:
Technologies
Several parameters were taken into account in the calculations because they influence the consumption:
Streaming technology: IPTV (Technology among ISPs), OTT (Over the Top), and Peer To Peer
Linear (Live) or Non-linear (Replay / VOD) signal
Broadcasting (Hertzian, Satellite, IP)
Means of connection to the network
To access the services, the infrastructure considered takes into account: the user’s equipment (Box among others), access to networks (GSM, Fiber, etc.), and the heart of the IP network.
We used calculation methods that are widespread in the scientific literature and standardized by ETSI. The principle is to take an “energy / typical use” ratio in Wh/Go. Although the network infrastructure has a fairly fixed consumption and does not depend on the use, this calculation method makes it possible to assign a global impact to a use (here one hour of video). In addition, it allows to study the improvement of networks in terms of efficiency. Beyond the search for improved energy efficiency, it also makes it possible to assess pressure on the network and to take into account the improvement in the capacity of the infrastructure.
As explained in the CONVINcE report:
“As we are looking for an order of magnitude in energy saving, we suppose that decreasing by 30% the traffic volume in the core network induces a decrease of same ratio in network dimensioning and consequently a decrease of 30% in energy consumption in the core IP network.”
We have studied the literature and listed metrics ranging from 1.3Wh / Go (figure for FTTH fiber) to 600Wh/Go. These factors fluctuate depending on the infrastructure assessment date, method (Top Down or Bottom Up) and technology. It is clear, however, that the efficiency improves over the years.
We have taken:
13 Wh / Go for the core network (source CONVINcE)
30 to 40 Wh / Go for the fixed network
150 Wh / Go for the GSM network (source CONVINcE)
For TNT and satellite, there are few data. However, we based ourselves on a BBC study for TNT.
Content Delivery Network
Content Delivery Networks (CDNs) are servers used to limit the load on “Top of Head” servers (serving videos) and to provide a flow as close as possible to the user. Canal+ uses CDN providers on the market but also uses its own infrastructures.
The methodology for estimating the energy intensity per GB is to bring the estimated consumption of the data center down to throughput during peak periods. Canal+ indeed knows the number of physical servers, their types as well as their speeds. As the servers are hosted by a host, certain assumptions have been made to estimate the actual consumption: among other things, an assumption of PUE (Power Usage Effectiveness) of 2, consumption per server of 250W, and a server load of 50%. The consumption of routers and storage is considered negligible compared to the consumption of servers. (Sources 1, 2 , and 3)
The energy intensity obtained is 0.13 Wh / Go, with a different value between VOD and Live. Note that this value is calculated in the event of a peak (football match for example). It can be lower (use of the total capacity of the data center) or higher (during periods of low traffic).
For lack of data, the hypothesis of the same energy intensity (Wh / Go) was taken for CDNs outside Canal + (50%). For comparison and verification, the studies listed display values from 0.04 to 1 Wh / GB. These differences can be explained by various factors:
– Improving the efficiency of data centers, old studies, therefore, lead to higher figures,
– Top-Down approaches that have a higher estimate than Bottom-Up studies (like this estimate on CDNs).
AWS application servers Excluding video: using Mycanal (catalog presentation, authentication, etc.) and watching videos involve requesting services hosted on servers (rights management, etc.). The APIs used are hosted on AWS instances.
Canal+ rents AWS instances and knows the number of VMs. A part of these VMs is purely dedicated to providing ancillary services to video.
It is difficult to know the power consumption of AWS instances because no communication or information is provided by Amazon. According to an expert, we took a value of 20W (taking into account a PUE of 2) (Source: Interview of experts on virtualization from the company Easyvirt).
We have assumed a uniform distribution of consumption concerning the number of hours visualized and we obtain a value of 0.14 Wh / h.
Video encoding servers
The “Headend” servers allow you to format videos, “package” them to the user’s format … For the OTT, up to 150 packages may be available for a single video. Here is the workflow for the OTT.
The most consuming parts are video encoding and decoding. The workflow is distributed over specific servers (for encoding) and classic servers (for formatting and packaging).
We took the figures from the CONVINcE project (considering Harmony servers identical to those used by Canal +) to estimate the energy, as well as the Canal + server data:
For IPTV: 0.09 Wh for one hour of video
For the OTT: 0.30 Wh for one hour of video
This difference is explained by the fact that OTT is encoded in several formats, unlike IPTV which is encoded in a high definition format.
CO² emission factors
For energy, we used the values provided by the Open Data Networks Energies database (Work of distributors such as RTE and ADEME). We used intermittent usage which corresponds more to video usage in terms of the period (evening), ie 60g CO2eq / kWh. Part of the broadcasts for the rest of the world has been added taking into account the fact that some users are outside France.
For terminal and server manufacturing emission factors, we used factors provided by Shift Project / IEA.
These factors were brought to the time of viewing by taking into account the lifespans associated with each material.
Note: Regarding the impacts of DTT and satellite, there is a lack of data on infrastructure and emission factors. However, we have integrated this part to understand the orders of magnitude of the impacts. Certain analyzes were carried out only on the IP part in certain cases (for comparison with other studies for example).
Likewise, the impact of the data center manufacturing phase outside of the servers and the network infrastructure was not taken into account as it was considered to be shared and low given the lifespan of the buildings.
Results – global projection
The supply of renewable energy to AWS infrastructures and Canal + CDNs hosted by Interxion has not been taken into account.
In one hour, on average, here are the flows that pass through the network:
500 000 hours of video
900 TB of data
3.6 GB / hr average throughput
The number of viewing hours for Canal+ subscribers has been broken down according to the parameters listed above.
The unit data obtained previously are then projected on these uses to obtain the overall consumption. By taking these results, we can obtain the usage intensities of each part (Terminal, Network, Server) to check the consistency of the overall consumption.
Intensity analysis
The usage intensities obtained can be compared to the Shift Project and IEA studies. This intensity is calculated by taking the distribution of devices, the use of Canal +, and keeping only the IP transfer part (without Satellite or TNT).
It is clear (and shared by the IEA) that the Shift Project study overestimates grid consumption. For servers, we have a fairly low value but are quite confident considering that it is based on data from a known infrastructure (with the uncertainty from Amazon servers and third-party CDNs). The estimate of the terminal part of the Shift Project seems to us to have been underestimated (shared by IEA). It seems that the IEA also underestimated many parameters and seems not to have taken into account the influence of the definition on the consumption of the terminal, certain elements such as boxes, and the consumption of new TVs that consume more. The CONVINcE study and the Sauber/Koomey analysis also validate the consistency of our study.
Impact of playing an hour of video
Across the Canal+ fleet, the average end-to-end consumption is 214 Wh per hour of video. For comparison, the IEA study announces consumption between 120 and 240Wh per hour. The breakdown is as follows:
The impact in average CO2 equivalent by type of access is as follows (with the assumptions specified in the paragraph CO2 emission factors where the manufacture of Satellite, DTT, network and server hosting infrastructures has not been taken. into account)
By taking the type of connection:
The impact ranges from 20 to 66 g CO2 eq, it depends on several parameters:
the more or less energy consumption of the device (for example Smartphone vs TV),
embodied energy and material life,
the means of access to the network (for example GSM access has a greater impact than wired access),
the viewing quality which will influence above all the share of the network (depending on a cost per Wh / Go),
the number of materials to access the service.
By taking real uses (see the end of the document), the average is 28g CO2eq. If we take only the IP part, the average value is 37g CO2eq.
For comparison, the IEA study (2020) announces 8g CO2eq for France (for the use phase only). Another study for the US (2014) announces 360g CO2eq on the use phase (and 420g CO2eq with manufacturing). If we take a US energy mix, we get 202g which brings us closer to this study. The lower value can be explained by the differences in assumptions, in particular on the energy intensity of the network. For example, if we take for our study a TV with 4K reception, IEA announces 20g CO2eq while we rather estimate 14g (37g with the manufacturing phase).
If we look at the usage / manufacture ratio, in some cases the use has more impact (UHD in particular), while in others it is the manufacturing (IP TV or PC in HD for example).
In this same study, the estimate of the purchase of a DVD is 400g EqCO2, which therefore leads to the impact of watching a 2-hour video. 5 times less than that of buying a DVD in France and equivalent in the US.
Consumption and overall impact
The result of the total energy consumption of viewing Canal+ videos over IP is 900 GWh per year with a greenhouse gas impact of 159,000 tonnes CO2eq.
For comparison, annual French consumption is 473 TWh per year (Source RTE) and France’s 2017 carbon footprint (national emissions + imports) is 749 Mt CO2 eq (source: Haut Conseil pour le Climat – 2019 report). The consumption of the Canal + fleet by IP is therefore 0.18% of energy consumption and 0.016% of the French carbon footprint.
The end-to-end distribution is as follows:
Most of the consumption is on the user’s premises (terminal and part of the network access). Indeed, it is necessary to have the equipment (TV, Box, Smartphone …) which is not shared like the servers.
To validate the consistency of this projection, we took the consumption of CDNs specific to CANAL as well as to suppliers. We have a consumption of Canal + CDNs of 2.6 GWh (and estimated at 7 GWh for suppliers) excluding video head-ends which are not at Interxion. We get 12 GWh with the projection, which validates the model.
If we look at the distribution of the impact in greenhouse gases, we have the following distribution:
A large part of the impact comes from the manufacture of user terminals. On the network part, the manufacture of Boxes (FAI, Satellite …) also has a significant impact.
Areas for improvement to limit the impact of services
General strategy
As we have seen in the network part, efficiency improves. The same is true for terminals. But on the other hand, 4K will become widespread, networks will continue to increase their capacity and therefore increase the overall impact of consumption. By taking one of the hypotheses of a 30% improvement in network efficiency (according to the trends set out in the studies listed in the Networks section of this report) and an increase in average throughput of 20% over 3 years as well as of 20% of the hours viewed, as well as a transfer of 75% of the hours viewed from all interfaces to that of the OTT, we estimate an increase in the energy consumed by 39% and the impact of greenhouse gases greenhouse by 23%. This simplistic projection allows us to approach a more realistic consumption in 3 years.
To offset this increase, and optimize the impact of video playback, we examined the impact of the following projects carried out by Canal+:
Switching from H264 encoding to HEVC
Switching to multicast for live
Switch audio encoding from AAC to AC4
Strengthen bitrate downsizing
Improve the interface and the software layer
Help the user on their digital impact
These projects are not exhaustive. Other possible areas for improvement have been identified which could be launched subsequently by Canal+.
The measurements, estimates, and models that allowed us to obtain the overall impact were used to quantify the estimated gains.
Note on optimizing video servers:
The energy consumption of video servers is very low, as is their impact, as the hardware has a high lifespan (10 years). Several optimizations are under study (video passage Just-in-Time among others). However, these optimizations provide very little end-to-end gain. They are however necessary to optimize management and reduce storage size (impact not taken into account in this study because it is low). Optimizations such as switching to HEVC have a stronger impact (this is confirmed by the CONVINcE study).
“The “Just In Time Transcoding” approach will allow to reduce the number of video representations stored in the CDN and thus its power consumption. This is an end-to-end approach to be compared to the global abovementioned one consisting of reducing the bandwidth of the network by using the most efficient encoding technology (HEVC/AVC).
On CDNs in the same way, even if the impact is low, certain actions such as increasing the rate of use of Canal + infrastructures (using a transfer of flows from supplier CDNs to own CDNs) will improve the efficiency.
Switching from H264 encoding to HEVC
The HEVC video codec is about 20% more efficient than the H264, and a large number of devices are now compatible. For a 3-year projection of consumption, we have taken an increase in the market share of HEVC compatible devices (Box, Smartphone, etc.).
For users who are on 1080p 5Mbits to date (34% of users currently) as for users restricted to 720p for technical reasons (for example a limitation of the network), a 20% drop in consumption is expected. For other 1080p compatible users, there is no decrease in consumption, but an increase in quality with superior grip.
A new even more efficient format begins to appear (AV1), saving an additional 20%. However, very rare equipment is compatible: the transition is largely premature, we would hardly gain anything to date because the fleet is almost zero.
Switching to multicast for live
Broadcasting in hybrid multicast / unicast adaptive streaming for the OTT will greatly reduce the use of bandwidth, and therefore power consumption.
Usable only for live stream, it ensures that a single stream is sent for all customers to the final delivery point. This project will be accompanied by other ancillary projects such as the switch to CMAF packaging. The CMAF audio/video packaging format allows you to have exactly the same video files for all platforms.
Switch audio encoding from AAC to AC4
Currently we mainly use AAC audio, from 96kbits to 128kbits.
The EAC3 + is widely compatible to date and improves audio quality at equivalent bitrate while allowing 5.1. Switching to EAC3+ would be at a fixed rate, without hoping to save bandwidth (while 20% more efficient than EAC3 +).
On the other hand, the new AC4 format is 50% more efficient than the EAC3 + and would allow the audio bit rate to be divided by 2. Even if the share of the video is greater, the gains at the global level are not negligible.
Strengthen bitrate downsizing
To date, except in Africa, or on a cellular network (so as not to empty the customer’s subscription), the quality of the video is adequate . On PC, quality adaptation is possible but access is not necessarily easy.
Making the possibility of reducing the size more accessible by different means (improvement of the interface, communication, etc.) would make it possible to redirect some of the users to a lower but sufficient quality.
Taking into account the increase in video quality and that of network performance, quality caping by users of Canal + services should represent in 3 years a gain of 20% in average speed compared to that generated by uncapped use.
In this axis, several elements have not been included in the gain projection but are possible to help the user in his impact. For example, the Greenspector mobile measurements show that it is better (under favorable conditions such as wifi) to use downloading rather than streaming. Indeed, here is the comparison for a 45mn video (with 5mn download):
This is partly explained by the fact that when viewing the downloaded video, the radio cell is not used while it is much more during streaming.
Improve the interface and the software layer
Part of the impact of viewing an hour of a video comes from the interface. Indeed, viewing the catalog, managing subscriptions (via APIs), processing playlists … are necessary functions. Greenspector measurements showed that this could represent 10% of terminal consumption:
Improving the interface on all platforms (smartphone, PC, etc.) would therefore make it possible to obtain significant gains. It would also allow, beyond reducing the impact, to limit the exclusion of certain people as well as the obsolescence of platforms.
Among the actions identified:
Switch to the dark mode
Reduce the overall impact of the software layer
Improve UX
Limit the integration of third-party libraries
Help the user on his digital impact
Much of the impact of video playback is not directly related to video playback. Canal +, through its large audience, can act by making users aware of the impact of digital technology. If some of the users take these actions into account, the impact can be reduced. Among these actions:
Extending the life of the user’s equipment,
Use Ethernet rather than Wifi, rather than 4G,
Extinction of equipment out of use.
Results
Here is the projection of the various energy gains:
The improvements compensate for the increase in energy consumption and even allow a gain of 14% compared to the current situation. For the greenhouse gas impact, we obtain a gain of 8%.
There are many ways to reduce the carbon impact of streaming activities for Canal + by 30%, and the actions put in place will make it possible to make a gain of 26% on the environmental footprint of services and in particular -31% for the consumption in OTT only.
Conclusion – to remember
This study has uncertainties on future use, on the emission factors of each element as well as on the potential gains. However, the objective is to challenge the choices or even to rule them out (some actions not listed in this document have, for example, already been discarded), if they had no gain. One of the first actions is to be able to measure yourself in order to improve. This is the goal of this phase. Now comes that of improvement.
The environmental interest of the sites identified by Canal+ has been confirmed. Their implementation will make it possible to offset the effects of the growth in uses, or even more, in the years to come.
The conclusions of this evaluation evolve with many technological parameters but in summary:
Work on video and audio compression formats while taking into account new formats optimized by manufacturers.
Optimize the consumption of user functions to access the content.
Involve/guide users in the choices according to the context of use (streaming, type of network, device screen format, etc.) and lead them to extend the life of the equipment to reduce the impact.
Implement hybrid multicast / unicast adaptive streaming for OTT to dramatically reduce bandwidth usage and power consumption.
Pursue end-to-end measures to avoid future decisions that shift the impact without reducing it
– How does this assessment and improvement process fit into the Group’s strategy?
CANAL+ is anchored in its time. We have decided to become more involved in a major issue of our time, dear to our subscribers and users of myCANAL: the protection of our environment. CANAL+ was very early on as a pioneer in eco-responsible approaches. first. In addition to the rental model of decoders, which is very virtuous from the point of view of the circular economy, Canal+ organized in 1988 the recovery of old decoders to ensure their return to service or their recycling. Moreover, as a publisher, We have produced eco-responsible productions including series that have been exemplary on this subject, Baron Noir, L’Effondrement, and more recently OVNI (S).
-What main lessons/contributions do we draw from this work (on the design of services)?
This work allows us first of all to identify the technical projects to prioritize to minimize the carbon footprint of myCANAL video consumption as much as possible. At the same time, the lessons guide us on the awareness messages to relay to our users, throughout our future developments. This commitment to cooperation between our technical developments and our users is the key to consumption that has less impact on the environment.
– What role do users play?
Protecting the environment is a priority for them. Their role is central to our approach. Our challenge is to offer them a platform offering the best content and the best video quality adapted to their equipment and their reception capacities to reduce the effects on the environment. By raising their awareness and supporting them in responsible actions, they too will be able to get involved, as they do in other areas for a more eco-responsible society.
Third-party service integration makes it easy to quickly add functionality to a site such as a video or social network integration (see the case of Twitter integration). The providers of these tools have worked to make technology integration quick and easy. And the technique is there. But at what cost?
Energy consumption of the third-party service Youtube
We observe an increase in this type of third-party service on our measurements and abnormal overconsumption. This is the case with many sites and even government websites.
The YouTube integration is a good case study to explain this effect. In just a few lines, it is possible to display a video on any site:
But what is the result in terms of user impact? Here is the result we get in terms of power consumption on a Nexus 6 smartphone:
Reference: Phone discharge speed in uAh / s (OS, Browser …) Loading: Speed of the first 20 seconds of loading Idle Foreground: Inactive site speed in the foreground Scroll: Speed when the user scrolls down the page Idle Background: download speed when the browser (and therefore the site) is in the background
This is a government website. Discharge rates exceed our thresholds for many steps. For loading, the speed is more than 2 times that of reference. For the idle foreground or phase of inactivity in the foreground, the consumption should be identical to that of reference. This consumption is abnormal for a site that seems quite light.
We see that Chrome’s CPU process goes up to 10% every second. This explains the overconsumption of energy. By profiling the JavaScript calls in the development tools, we observe processes from base.js which are from the YouTube framework:
Note that this processing also impacts scrolling and loading. Is this an expected operation? A bug or a bad implementation? We haven’t been that far into the analysis.
When we look at the page loading, on 1.2MB, nearly 600KB is used for the YouTube plugin. 50kb of CSS and 550kb of Javascript. To the necessary processing, add the heavy CPU usage to parse and run scripts.
Significant point: No video appears on this page. The integration of the plugin is surely necessary for another page. This makes the waste even more critical, it is all the more annoying that the French tested website is public and widely used: Impots.gouv!
Best practices for integrating a video
1 – Directly embed video without third-party services
It is possible to use free solutions without plugins. Integration via HTML5 is native.
2 – Embed an image
Display an image with the same rendering as the video allows to reduce to 1 request. If the user clicks on the video, then the scripts will be loaded and the video launched ultimately lazy loading.
We also did the exercise on a page of our Greenspector website:
On one of our “Case Study” pages was embedded a YouTube video. We replaced this integration by displaying an image (opposite) representing the old integrated video. This modification allowed us to go from a Greenspector ecoscore from 59/100 to 75/100 characterized by an energy gain of -12% in the loading stage, -10% in Idle and -15% in scroll.
Page with embedded video Page with image
3 – Integrate the plugin only on the desired page
A solution that is not ideal, but preferable to the existing one, is to only use scripts when the page requires a video.
What will it save?
First of all the performance. A large portion of processing related to site wait times is dedicated to third-party services. This is even more true for the YouTube plugin. On the audited site, the size can be reduced by 2, and the loading time reduced by at least 30%.
Power consumption will also be reduced and even more important than data size or performance. In fact, in addition to saving energy from charging, consumption in idle or inactivity phase will be reduced.
Bonus: user privacy
The other problem with this type of project is the use of tracker and user data recovery. Not integrating a third-party service resolves potential issues of data leakage and GDPR non-compliance. By the way, the YouTube plugin seems to allow version without cookies via the call to the URL: https://www.youtube-nocookie.com.
Like any third-party service, it is not that simple. Even with this no-cookie integration, user data is stored:
The audited site is therefore not GDPR compatible! To manage this, you must ask the user for consent explicitly:
The solution of a hosted video or static image will also manage this.
Conclusion
If the integration of a video is necessary, think about it quietly and consider the impacts on resource consumption and GDPR. There are technical solutions more respectful of the user, they are initially perhaps a little more complex to set up, however, the solutions will naturally become simpler and more widespread.
The web browser is a main tool on a mobile device. Not only for websites but also for new applications based on web technologies (progressive web app, games, …).
In our 30 most popular mobile apps ranking, among the mails, direct messaging, social networks, browsers categories, web browsing and social networks are on average more consuming than games or multimedia applications. The ratio would be 1 to 4 between the least and most energy consuming applications.
Decreasing the environmental impact of the digital life and increasing the autonomy of phones go in part through the choice of a good browser. Just as if you want to reduce the impact of your mode of transport, it is important to take the most efficient vehicle.
Last year we published the 2018 ranking of the least energy-consuming browsers, we made a new edition for 2020, more complete, made with our GREENSPECTOR App Mark.
Overall Ranking
The average rating is 36/100 which is pretty mediocre. It can be explained by low notes for each of the metrics. The three least energy-consuming browsers are: Vivaldi, Firefox Preview, Duck Duck Go.
Overall energy consumption (in mAh)
The median is 47 mAh and a large part of the browsers are in this consumption level (8/18 are in the 2nd quartile). Note that the last 3 browsers in the ranking are recognized by a consumption 75% higher than the median. Firefox, Qwant and Opera Mini are indeed very energy intensive.
Energy consumption of navigation (in mAh)
The last 3 browsers of the global ranking (Opera Mini, Firefox and Qwant) as well as Mint consume much more than the average (between 20 and 35 mAh against 16 mAh).
It is sufficient to say that for most browsers (apart from the previous exceptions), pure navigation is not going to be the reason for the difference in overall consumption. This is mainly due to the use of visualization engines. Most browsers use the Chromium engine. For Opera Mini, the specificity is that a proxy is used and can compress the size of the sites. It seems that this proxy is not good for the energy, in fact the decompression on the user’s phone consumes a lot of energy.
For the Firefox app, over-consumption of energy is a known and shared thing, this is one of the reasons why Mozilla is under development of a new browser. Internal code name is Fenix and public one is Preview. The measures in this ranking are rather encouraging on consumption (in the average). For Qwant, this is due to the use of the Firefox engine! The measurements between Qwant and Firefox are indeed very close.
Power consumption of features (in mAh)
The main feature that is browsing the web also requires other important features: new tab opening, enter an address in the taskbar … Indeed, when we open a new tab, each browser offers different features: mainly used websites, latest news, …
On pure navigation, browsers differ little, there are significant differences in energy consumption on other features with a ratio of more than 3 (between 4 mAh and 12 mAh).
Note that the first 3 (Firefox Focus, Firefox Preview and Duck Duck Go) have a simple homepage. The consumption of the browser in Idle (inactivity) is then very low. Functional sobriety pays the consequences!
When launching browsers, the energy consumptions are quite similar to each other. Note, however, that opening a tab and writing a URL are actions that are performed several times. If we take a daily projection of 30 new tabs and 10 URL entries, we can still see the difference between browsers and the large advance of Firefox Preview and Focus!
The basic features are not insignificant in the overall consumption.
Projection of autonomy (in number of hours)
If we take this energy data and project it for a navigation of several websites, we identify the maximum time that the user can navigate to the complete discharge of his battery:
Data consumption (in MB)
The difference in data consumption between browsers (8 MB difference) is explained by the pure navigation and the different features.
On the navigation, we explain this difference:
some applications do not manage the cache at all for reasons of data protection and confidentiality (Firefox Focus)
proxy usage that optimizes data (Opera Mini)
a difference in the implementation of cache management. It is possible that some browsers invalidate the cache and that data is loaded while they are cached.
additional data consumption continues in the background (idle tabs, background data not blocked …)
download performance differences that increase the duration of the measurement. Indeed, if a browser is powerful, the counterpart is that many more data are potentially loaded in the background.
The difference in overall consumption can also be explained by the data consumption of the basic functionalities:
Many browsers are very consuming. We note the 3 MB of Qwant that seem abnormal! It can be considered that for browsers, this consumption should be close to 0. Indeed, the main feature of a browser is to display a website, any feature (and associated consumption) can be considered as “over-consumption”. In this context, many browsers consume data when writing the URL. This is mainly explained by the URL proposal features. There is indeed exchange between the mobile and the servers, either directly by the browser or by the associated search engine.
For example, for the Yandex browser below, the details of data exchanges when writing a URL show more than 400 KB of data exchanged.
In contrast, below, trading for Brave is frugal with less than 2 KB.
Browser performance (in seconds)
The measures allow us to evaluate the performance of the key features:
Launching the browser
Adding a tab
Writing a URL
Removing the cache
Mozilla Kraken Bench
NB: This study does not evaluate the display performance of websites. However, the Mozilla Kraken benchmark allows this in part by evaluating the functionality of browsers.
Efficiency of browsers (in mAh/s)
We can evaluate the efficiency of browsers by taking the performance of the Mozilla Kraken benchmark and the associated energy. Efficiency is the energy consumption per unit of time:
Samsung, Opera Mini and Opera are the most efficient browsers. This ranking is different from that of overall energy consumption. For Samsung Internet, this first place in terms of efficiency on a Samsung hardware can be explained by the optimized link that can have the manufacturer with a pre-installed software. The Opera browser has a good positioning (2nd for overall consumption and 3rd for efficiency).
Track of improvements
It is possible to improve the consumption of navigation.
For the user :
Choosing an efficient browser
Use bookmarks or favorites to avoid going through the entry bar
Configure the energy saving options of browsers (mode or dark theme, data server …)
For developers of sites:
Eco-design their site
Test and measure on different browsers to identify different behaviors and take them into account
For browser editors:
Measure energy consumption and efficiency
Eco-design features
Reduce resource consumption of recurring features (url write, new tab …)
Make the homepage as simple as possible.
Measurement protocol
The measurements were carried out by the laboratory GREENSPECTOR App Mark on the basis of a protocol Standardized: Samsung S7 Smartphone, Android 8, Wi-Fi, 50% brightness. Between 4 and 8 iterations were carried out and the value used is the average of these measurements. Measurement campaigns follow a scenario that evaluates browsers in different situations.
Evaluation of features
Launching the browser
Adding a tab
Writing a URL in the search bar
Remove tabs and clean the cache
Navigation
Launch of 6 sites and wait for 20 seconds to be representative of a user journey
At launch (this allows to evaluate the homepage of the browser)
After navigation
After closing the browser (to identify closing problems)
For each iteration, the following tests are performed:
Deleting the cache and tabs (without measurement)
First measure
Second measure to measure the behavior with cache
Remove cache and tabs (with measure)
System shutdown of the browser (and not only a closure by the user to ensure a real closing of the browser)
The average measurement therefore takes into account a navigation with and without cache.
The main metrics analyzed are: display performance, power consumption, data exchange. Other metrics such as CPU consumption, memory consumption, system data … are measured but will not be displayed in this report. Contact GREENSPECTOR for more information.
In order to improve the stability of the measurements, the protocol is completely automated. We use an abstract GREENSPECTOR test description language that allows us to fully automate this protocol. Browser configurations are the default ones. We have not changed any settings of the browser or its search engine.
Rating
A notation out of 100 makes it possible to classify the browsers between them. It is based on the notation of 3 main metrics:
Metric
Definition
Unit
Performance
Duration required for a test step
seconds (s)
Energy
Battery discharge rate found on the device during the test step, compared to the battery discharge rate of the device before the application is launched
Measurements in uAh / s, then classification in multiples of the reference discharge velocity
Data
Total data volume (transmitted + received) during the test step
kilo-bytes (kB)
A weighting ratio is applied to the 5 step levels (from 5 for dark green to -1 for dark red) as described in the following example table:
The score of this application is then calculated at 61/100 for the energy metric. Once the score of each of the three metrics obtained on 100 points, the total score of the application is calculated with equal weighting of the three metrics: Total Score = (Performance Score + Energy Score + Score Data) / 3
Browsers evaluated
Browser name
Version
Brave
1.5.2
Chrome
78.0.3904.108
Duck Duck Go
5.32.3
Ecosia
39632
Edge
42.0.4.4052
Firefox
68.3.0
Firefox Focus
8.0.24
Firefox Preview
2.3.0
Kiwi
Quadea
Lilo
1.0.22
Maxthon
5.2.3.3241
Mint
37290
Opera
54.3.2672.502
Opera Mini
44.1.2254.143
Qwant
37714
Samsung
10.1.01.3
Vivaldi
2.7.1624.277
Yandex
19.10.2.116
Some browsers were discarded because they did not allow the tests automation. For instance, UC Browser and Dolphin browsers could not be measured. Beyond automation, this is a symptom of a accessibility issue of the application. To improve the accessibility of applications for people with visual impairments (among others), it is necessary to set up buttons labels. The automation that we realized is based on this information. In the end, these browsers do not appear in the ranking, but we can consider that accessibility problems are in all cases a crippling problem.
Note : The 2020 ranking is hardly comparable to that of 2018. Indeed, our protocol having completely evolved, the tests are thus more advanced and automated.
In a previous article on this blog, we introduced you the 5 keys to success of a mobile application. We present today the 12 rules by business indicator to respect that will make the success of your application.
The application should not require a recent OS version like Android to be used. Some users do not follow updates, either voluntarily or because of their platform that does not allow them. According to our “PlayStore Efficiency Report 2019“, only 70% of apps on the store are compatible with all versions of Android.
The application must comply with the accessibility rules and must not exclude users with disabilities.
The app should work well on older phones too only on recent and latest models. This criterion will be degraded if you do not respect that of sobriety. 1/4 of the Google PlayStore applications are 10% of the oldest mobiles. (Source: PlayStore Efficiency Report 2019)
The application must limit its resource consumption (number of CPUs, memory occupied, data exchanged) in order to avoid any slowness or pollution of the other applications (for instance because of the memory leak). 50% of Google PlayStore apps continue to process after the app closes. (Source: PlayStore Efficiency Report 2019)
The application must limit its network consumption in order to not involve any load on the data centers and thus avoid the additional costs related to the unnecessary congestion of the servers.
Performance
The first launch of the application must be fast: otherwise, it is possible that your users won’t go further, the inclusion criterion will not be respected either.
The loading times of the application must be acceptable in all network situations.
Discretion
The application requires few or no permission. Do you really need to consult the list of contacts of your user? It’s all the more important to optimize this since the more permissions there are, the more the application consumes resources. This will therefore negatively influence the performance criterion.
The application has little or no tracker. The integration of a large amount of trackers implies a greater consumption of resources but can also cause bugs. This observation is even more true that the connection is degraded. On average, adding a tracker causes an over-consumption of resources of 8.5%.(Source : PlayStore Efficiency Report 2019)
According to our “PlayStore Efficiency Report 2019“, trackers, analytics and permissions are ubiquitous (44% applications have more than 5).
Ecology
The application must respect the sobriety criterion, the CO2 impact linked to the use is lower as well as the pressure of the resources on the components of the equipment of the user (battery obsolescence, loss of performance). As a result, the user is less likely to renew their equipment, which reduces the risk of obsolescence of his material. Our latest study shows that mobile apps contribute at least 6% of CO2 emissions digital.
Some tracks for the improvement of its GREENSPECTOR App Mark score
Directly improve the application
Several metrics are evaluated by the GREENSPECTOR App Mark and can be directly improved.
Minimum SDK version: Allow Android older versions to avoid the exclusion of users using older generation platforms.
Number of trackers: the fewer trackers the application has, the more it will respect the user’s data as well as the protection of his privacy. In addition, trackers via processing and data exchange increase the consumption of the application.
APK size: the bigger the binary of the application, the more the network is solicited and the less efficient the application. In addition, a large application size will use the limited storage space of some users.
Loaded data: number of loaded data throughout the test run. Limiting this data will reduce the consumption of resources on both the smartphone and the network.
Data loaded in the background: when the application is not used, it must limit its impact and send or receive as less data as possible.
More global metrics
Some metrics are directly related to the impact of the application and its efficiency. It is possible to act on it via the previous metrics, see by other axes (functional optimization, improvement of the source code …)
CO2: the more the application consumes energy, the more the battery is solicited and become obsolete. This may lead to a premature renewal of the battery or even the smartphone and therefore to a higher environmental impact. Let’s not forget that most of the environmental impact of a smartphone is predominant in its manufacturing phase than in its use phase: keeping it longer reduces its overall impact.
Energy Overconsumption: if the application overconsumes, it increases the environmental impact but also creates discomfort for the user especially on the loss of autonomy and generates an additional stress factor.
Performance after the first installation: applications sometimes perform additional treatments during the first launch, so the launch time is sometimes increased. It is necessary to limit its treatments because this loss of performance can be inconvenient for the user.
Performance: the launch time of the application is an important data for the user. It is necessary to reduce it to the maximum while consuming the least possible resources.
3G Performance: in poor network conditions, it is necessary to master the performance to maintain a good user experience. It is even possible that some users do not have access to the application in the case of degraded performance. Having a frugal service that takes into account the constraints of mobility is therefore a key to success.
What about now?
You are certainly wondering how your application is doing on these 5 indicators. Is it rather virtuous? Is there any risk? How is it ranked against its competitors? Do you have quick progress actions? If you ask us, we will tell you! Contact-us, and we will introduce you to your own inclusive, sober, fast, ecological and discreet evaluation – just like your application very soon.
During the Mobile One event, GREENSPECTOR announces a survey of the major mobile consumer trends of the Google Play Store. More than 1000 applications were sifted through for Performance, Sobriety and Inclusion by the measurement tools developed by GREENSPECTOR.
This is a great first for GREENSPECTOR: one of our main solutions is now available in the Apple universe.
Long awaited by our customers, this compatibility with iOS makes it possible to complete the analyzes of type GREENSPECTOR App Scan.
The measures of performance and efficiency on the iPhone complement those on Android. Your applications and your websites benefit from a maximum coverage, representative of the uses of your users, no matter what the underlying technology.
So you can now ensure the quality of user experience across all your mobile devices, under control their performance and efficiency. Note that because of the restrictions imposed by Apple, all the usual GREENSPECTOR metrics are not yet available. But our teams continue to work to offer you, throughout the versions, analyzes always more pointed on your applications.
