From Slow Pages to a Faster Digital Experience: Performance Optimisation for Adecco Group

Adecco Group operates a large digital ecosystem serving users across the recruitment and workforce services industry.

For digital platforms like these, performance is more than a technical metric.

A slow page can affect how users interact with the website, how long they remain engaged and how effectively they can access the information they need.

Adecco Group approached DigitalBee Labs with a clear problem.

Several pages were performing poorly, loading slowly and experiencing low user engagement.

The initial scope focused on optimising four specific pages.

The objective was to identify the technical causes of the performance issues, improve loading behaviour and user experience, and deliver the improvements without changing the existing visual design.

But the engagement came with several significant constraints.

1. Limited Access to the Production Environment

Our team initially had access to the codebase, but not to the actual production database or image storage bucket.

The website was powered by a CMS, but there were no available seeders that could easily recreate the production content locally.

This meant that simply cloning the codebase was not enough.

To properly investigate the performance problems, we first needed to recreate a realistic working environment.

2. Limited Domain Knowledge

The initial requirement focused on only four pages.

Our team did not have extensive knowledge of the broader website, its content structure or all of the other pages that could potentially be affected by changes.

This created an important engineering consideration.

A change that improves one page could potentially affect another page if the underlying code is shared.

We therefore needed to understand enough of the wider application to make changes safely.

3. Shared Components Across the Website

The website used a headless CMS architecture with shared components.

This created another layer of complexity.

A performance improvement to a shared component could potentially affect multiple pages across the website.

The challenge was therefore not simply:

"How can we make these four pages faster?"

It was:

"How can we improve the performance of these pages without introducing unintended consequences elsewhere?"

Because we did not initially have access to the production database or image storage, we needed to recreate enough of the environment to properly test the application.

The team:

• Set up the website locally
• Configured the CMS
• Added the required content
• Recreated relevant media and asset behaviour
• Used MinIO to simulate the S3-compatible image storage environment

This gave us a realistic environment in which to investigate the application and test potential optimisations.

Rather than making assumptions based purely on the source code, we could observe how the application behaved with representative content.

Once the environment was operational, our engineers reviewed the application from a performance perspective.

The analysis covered areas such as:

• Page loading behaviour
• Shared components
• Asset handling
• Image delivery
• Application code
• Rendering behaviour
• CMS-related content loading
• Reusable components
• Potential server-side improvements

The team then categorised potential improvements based on their expected impact and the risk associated with implementing them.

This helped us distinguish between:

High-impact, low-risk improvements

and

Potential improvements requiring broader architectural or infrastructure changes.

Performance improvements should not come at the expense of the user interface.

One of the key requirements was to improve the performance of the requested pages without changing the intended UI or design.

Our engineers therefore implemented targeted optimisations and continuously tested the resulting pages to ensure that the visual experience remained consistent.

This required careful consideration of the shared components used throughout the website.

Where a component was used across multiple pages, we considered the wider impact before recommending or implementing changes.

Although the original request covered only four pages, the investigation revealed that some of the underlying performance improvements could benefit other areas of the website as well.

Because shared components were involved, improvements made at the component level had the potential to improve performance across multiple pages.

This resulted in an important outcome:

A performance optimisation project initially scoped to four pages produced improvements that extended across the wider website.

Rather than optimising each page independently, we addressed underlying technical issues where it was safe and practical to do so.

Not every performance issue could be resolved within the codebase.

Some potential improvements required access to the server or production infrastructure, which was outside the access available to our team.

Instead of ignoring those opportunities, we documented them separately.

Our team provided detailed guidance for server-level improvements that could be implemented by the client's infrastructure team.

This created a clear distinction between:

Fixes DigitalBee Labs could safely implement in the codebase

and

Infrastructure-level recommendations requiring client-side access.

This approach ensured that the client received a complete performance improvement roadmap rather than only the changes we could directly implement.

Before sharing the final pull request with the client, we requested access to the actual database and performed broader testing against the real application environment.

This was an important validation step.

Because the website relied on shared components, we did not want to assume that improvements to the four target pages would have no impact elsewhere.

The team therefore tested the changes across the broader website to identify potential regressions and ensure that the optimisation work did not negatively affect other pages.

Only after this validation was the final PR prepared for the client.

Performance optimisation is often about finding the balance between impact and risk.

A technically attractive change is not necessarily the right change if it introduces instability across a large website.

Our team therefore considered:

• Performance impact
• Development effort
• Component reusability
• Potential regression risk
• Scope of the requested pages
• Broader website dependencies
• Production access limitations

This allowed us to focus on practical improvements rather than pursuing optimisation for optimisation's sake.

The project successfully addressed the performance optimisation requirements for the four requested pages.

More importantly, because several of the improvements were implemented at the underlying application or shared-component level, the benefits extended beyond the original scope.

Key outcomes

Improved website performance
Targeted performance optimisations improved the loading behaviour of the requested pages.

Broader performance benefits
Although only four pages were initially identified for optimisation, the implemented fixes improved performance across the wider website.

UI preserved
Performance improvements were implemented without compromising the intended user interface.

Production impact considered
Broader testing was performed before the final PR to reduce the risk of affecting other pages.

Future optimisation roadmap
Potential code-level and server-level improvements were documented for future implementation.

Infrastructure simulation
MinIO was used to reproduce the S3-compatible storage environment during development and testing.

The most interesting outcome of the project was that the initial scope did not define the full value of the work.

The request was:

Optimise four pages.

The engineering approach was:

Understand the underlying platform and improve the causes of poor performance where possible.

Because the website relied on shared components, fixing the right underlying issues meant that improvements could benefit other pages as well.

This is an important distinction.

We did not simply make four pages faster.

We identified opportunities to improve the performance foundations supporting the wider website.

Real-world software development rarely happens under perfect conditions.

Sometimes you have complete access to the infrastructure.

Sometimes you don't.

Sometimes you know the entire business domain.

Sometimes you are given four pages and expected to understand the wider implications.

And sometimes a seemingly small code change can affect hundreds of other pages because of shared components.

Our approach is to work effectively within those constraints.

For the Adecco Group engagement, that meant:

Recreating the environment when production access was unavailable.

Using MinIO to simulate cloud storage locally.

Analysing the codebase before making changes.

Prioritising improvements based on impact and effort.

Considering the wider effects of shared components.

Documenting infrastructure improvements we could not directly implement.

Testing against the actual database before delivering the final PR.

This is how we approach engineering when the environment is not perfect.