DEV Community

Cover image for Frontend Performance Is an Architecture Problem, Not an Optimization Problem
Md. Abu Noman
Md. Abu Noman

Posted on Edited on

Frontend Performance Is an Architecture Problem, Not an Optimization Problem

We often treat frontend performance as something to fix after a page becomes slow.

We optimize images, add memoization, reduce component re-renders, and run Lighthouse audits. These techniques can help—but what if the biggest performance problems were introduced much earlier, during architectural decisions?

In modern React and Next.js applications, performance is influenced by several decisions:

Rendering strategy: When should a page use static rendering, server rendering, or client-side rendering?

JavaScript delivery: How much JavaScript does the browser actually need?

Component boundaries: Which components need to be interactive, and which can remain server-rendered?

Data fetching: Are requests unnecessarily sequential when they could run in parallel?

Caching: Can we avoid repeating expensive work for every request?

These decisions shape the amount of work required to deliver a page and make it interactive.

Lighthouse is useful for identifying symptoms, but improving a score isn't the same as understanding the underlying cause.

I explored these ideas in my latest article:

Frontend Performance Is an Architecture Problem, Not an Optimization Problem

Read the full article: [https://medium.com/@md-abu-noman/frontend-performance-is-an-architecture-problem-not-an-optimization-problem-4455e141aeee?sharedUserId=md-abu-noman]

I'm curious: When investigating a slow React or Next.js application, what do you examine first—rendering strategy, JavaScript bundle size, data fetching, or something else?

Top comments (2)

Collapse
 
101beardo profile image
Tarun Sharma •

To answer the question, I start with the network waterfall. It tells you quickly whether one endpoint is slow or a chain of requests is waiting on each other, which is an architecture problem that no amount of memoization fixes. Bundle size comes second, then rendering. Lighthouse alone often hides the sequential fetch case.

Collapse
 
md-abu-noman profile image
Md. Abu Noman •

Absolutely! The network waterfall is a great starting point because it reveals bottlenecks that Lighthouse scores alone might not make obvious. A sequential request chain can often be an architectural issue rather than a rendering problem. Thanks for sharing your perspective!