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?
