The famous answer is: it depends.
And honestly, this could be the end of the article.

But in reality, this question is very often answered too quickly - and usually in only one direction.

A very simplified view of how HTTP works

Before deciding whether frontend or backend is the problem, it helps to remind ourselves how an HTTP request actually works.

  1. Connection - the browser connects to the server
  2. Request - the browser requests a page (for example, a category page)
  3. Processing - the server processes the request
  4. Response - the server sends back the HTML
  5. Connection closes (or stays open via keep-alive)

Everything up to the delivery of the HTML is the part of the request/response cycle where backend and infrastructure have the biggest impact on performance.

Where frontend starts

Once the HTML is delivered, the browser takes over.

This is where:

  • HTML is parsed
  • CSS is applied
  • JavaScript is executed
  • Images, fonts and other assets are loaded
  • The page is rendered into something usable

This is the frontend part of performance.

The real question

The real decision is not “Should we optimise frontend?”
It is much simpler:

Where is the website actually slow?

Backend? Frontend? Both?

If you pick the wrong one, you can easily spend weeks optimising the part that isn’t the problem.

Guessing is expensive. Data is cheaper.

Real user data: CrUX

One of the most useful data sources here is Chrome UX Report (CrUX).

CrUX is based on real users browsing the web in Chrome. Given Chrome’s global market share (around 71% in November 2025), this data is good enough to base real decisions on. It’s also the source of Core Web Vitals that Google uses as a ranking signal.

For browsing CrUX data, I usually use treo.sh.
The free tier shows site-wide data, the paid tier goes down to individual URLs.

After entering a URL, you’ll see several performance graphs.

Example 1 - when frontend won't save you

CrUX data showing poor TTFB with 1.8s response time

The first metric I always look at is TTFB (Time To First Byte).

  • TTFB around 1.8 s - red numbers, clearly bad
  • The difference between TTFB and FCP is ~400 ms
  • The difference between TTFB and LCP is ~600 ms

You’ll also notice that these metrics move together.
They are not perfectly correlated, but in real projects the pattern is usually very clear.

What does this tell us?

  • The browser renders the main content in ~600 ms once rendering starts
  • But it takes almost 2 seconds just to receive the HTML

In this case:

  • Frontend rendering is already quite fast
  • The backend response time is the bottleneck

Example 2 - backend work that actually paid off

CrUX data showing improved metrics after backend optimisation

In another case:

  • TTFB is still not perfect
  • But FCP and LCP are already green

The client invested just a couple of days into backend optimisations, and that alone made a noticeable difference.

No redesign. No framework switch. Just addressing the actual problem.

From a client’s point of view, this is usually the best outcome.

Example 3 - when both sides are the problem

CrUX data showing both TTFB and LCP in red

And then there are cases where:

  • TTFB is red
  • LCP is bad as well

Here it’s obvious:

  • Backend is slow
  • Frontend isn’t helping either

In this scenario, frontend optimisation does make sense - but only as part of a broader performance effort, not as a standalone solution.

There is no silver bullet

This is the part people don’t like.

There is no universal recipe for web performance.

Yet in practice, frontend replacements are often presented as a clean, all-in-one solution. Sometimes that’s true. Very often, it’s simply the most visible - and easiest to sell - option.

The job of a developer or architect is:

  • to understand where the bottleneck really is
  • to explain it clearly
  • and to spend the client’s money where it actually brings value

A Magento reality check

This perspective is heavily influenced by my experience from real Adobe Commerce / Magento 2 projects:

In most projects I've worked on, the backend ended up being the bigger performance bottleneck than the frontend.

That doesn’t mean frontend isn’t important.

For new projects, I’m convinced that in most cases, starting with Hyvä is the right decision.

But when you’re working with an existing website, frontend should never be the default answer. It has to be justified by data.

Pro tip

If an agency tells you that replacing the frontend is the best thing you can do, without doing any performance audit first…

Run.