Eco-design at MobileThinking: Front or Back?
Second team, new challenge: better distributing 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 performed somewhere.
🗺️ Sometimes on your device (the front, browser side)
🖵 Sometimes on our servers (the back, infrastructure side)
So then, where should we smartly place the processing to reduce their impact?
Answering this question? It’s a mission tailor-made for Fabien and Jody, who have rolled up their sleeves to shed light on these invisible mechanisms.
Initial observation 🧐
Every digital service relies on a series of operations:
- Searching for information
- Sorting results
- Transforming data
- Paginating a list…
These are daily actions in our projects, but rarely questioned in terms of digital sobriety.
Yet, depending on where they are executed, energy consumption can vary from one fold to the next.
Identified issues 🧐
One of the key rules of eco-design: avoid unnecessary transfers.
Basing ourselves on this postulate, here are the main questions studied by our dynamic duo:
- At what point should a process be delegated to the server?
- Should we send all the data at once or make several targeted requests?
- When the transformation is complex, is it better to manage it on the back end?
- How can we measure the real impact of these technical choices?
What we tested 🧪
The team relied on a real case: the “Projects” page of our website.
- Compared tests of full submission vs progressive loading
- Measured the weight of API responses
- Attempts at analysis using Lighthouse, WebPageTest, and Scaphandre (still inconclusive at this stage)
- Review of best practices and feedback from similar projects
Our improvement pathways
🌳 Here are some initial lessons learned from their tests:
- If the volume is low and stable → front-end processing
- If the volume is high, changeable, or difficult to control → back-end processing
- It's better to have several small, well-targeted requests than one large, unnecessary response
- Complex transformations → back
- Simple adjustments → front
- And as soon as possible: we cache!
💡 Concrete case: Thanks to the addition of an adapted resource and caching, the API response dropped from 85 kB to 38 kB → 55% lighter, while loading more content.
What we take away
Properly distributing processing between the front and back end is not just a matter of technical optimisation. It is an approach of sobriety, responsibility… and clarity about what we are circulating and calculating.
It's about asking: “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 deprive myself?
To be continued… ✨
We now know how to optimise images, we know better how to distribute processing between the front and back… but the server is still purring too loudly.
It's certainly because everything that happens behind the site matters too!
In the next episode, we will explore the other side of the curtain:
- Where is the data stored?
- What happens when you click?
- And how to make all of this faster and more environmentally friendly?
Spoiler: it’s not reserved for network engineers 🧑💻
