Eco-design at MobileThinking
 
Front or Back ?

29.07.2025

Second team, new challenge : better distribution of efforts

In the previous episode, we tackled unnecessary images, videos and fonts to make our pages more streamlined.

But behind every click, every display, there are also... calculations.
And these calculations are done somewhere.

📍 Sometimes on your device (the front end, browser side)
🖥️ Sometimes on our servers (the back end, infrastructure side)

So where should treatments be placed to reduce their impact?

Answering this question? It's a mission tailor-made for Fabien and Jody, who rolled up their sleeves to shed light on these invisible mechanics.

Initial findings 🔎

Each digital service relies on a series of operations :
  • Search for information
  • Sort results
  • Transform data
  • Paginate a list...
These are everyday actions in our projects, but they are rarely questioned from the perspective of digital sobriety.

And yet, depending on where they are carried out, energy consumption can range from single to double.

Issues identified 🤔

One of the key rules of eco-design is to avoid unnecessary transfers.

Based on this premise, here are the main questions examined by our dynamic duo :
  • When should processing be delegated to the server?
  • Should all data be sent at once, or should multiple targeted requests be made?
  • When the transformation is complex, is it better to manage it on the back end?
  • How can the real impact of these technical choices be measured?

What we tested 🧪

The team based their work on a real-life example : the ‘Projects’ page on our website.
  • Comparative tests of full sending vs. progressive loading
  • Measurements of API response weight
  • Analysis attempts with Lighthouse, WebPageTest, and Scaphandre (still inconclusive at this stage)
  • Review of best practices and feedback from similar projects

Areas for improvement

🌿 Here are some of the first lessons learned from their tests :
  • If the volume is low and stable → front-end processing
  • If the volume is high, variable or difficult to control → back-end processing
  • It is better to have several small, well-targeted requests than one large, unnecessary response
  • Complex transformations → back-end
  • Simple adjustments → front-end
  • And as soon as possible : cache it!
💡 Case study : By adding a suitable resource and cache, the API response went from 85 kB to 38 kB → 55% lighter, while loading more content.

What we'll keep in mind

Properly distributing processing between the front and back ends is not just a matter of technical optimisation. It is an approach based on restraint, responsibility... and clarity about what we are processing and calculating.

It means asking yourself : ‘Is this processing useful here, or am I doing it out of habit?’ And if I can do less, while maintaining the same quality of experience... then why not?

To be continued… ✨

We now know how to optimise images and how to better distribute processing between the front and back ends, but the server is still running too loudly.

This is probably because everything that happens behind the scenes also matters!

In the next episode, we'll explore what goes on behind the curtain :  
  • Where is the data stored?
  • What happens when you click?
  • And how can we make it faster and more eco-friendly?
Spoiler alert : it's not just for network engineers 🐝