Every Feature I Add Makes the App Slower

The first version was fast. Three months and fifteen features later, the dashboard takes four seconds to become usable and every new addition seems to cost another two hundred milliseconds. Nobody shipped anything obviously slow. The app just got heavier in a way nobody can point to.

That pattern — steady, feature-proportional degradation — is diagnostically useful. A single slow feature produces one slow page. Degradation that tracks feature count means the cost of each feature is being paid by every page, which only happens when features share something: a bundle, a layout, a page load's worth of queries, a context provider at the root.

Find what they share and you find the problem. There are usually four candidates, and most apps in this state have three of them.

Measure before you optimize

Guessing at performance is a reliable way to spend a week making the wrong thing faster. Two measurements settle it in twenty minutes.

Load the app with the Network tab open and throttled to a slow connection. Note the total JavaScript transferred and the number of requests before the page becomes interactive. If the bundle is measured in megabytes or the page fires thirty requests before it can render, your problem is on the client.

Profile one real page server-side. Log the number of database queries a single page load issues and the duration of each. If a dashboard makes forty queries where it should make four, the problem is on the server and no amount of frontend work will fix it.

Those two numbers tell you which half of the app to work on, and they are the baseline you will measure improvements against. Without a baseline you cannot tell an optimization from a placebo.

Candidate 1: the bundle everyone pays for

The most common cause in AI-generated frontends. Every feature imports a library — a chart package, a date utility, a rich text editor, an icon set — and those imports land in the main bundle because nothing is code-split. A user who opens the settings page downloads the charting library, the PDF generator, and the editor they will never touch.

Three specific offenders show up over and over: importing an entire icon or utility library instead of the pieces used, importing heavy components at the top of a file rather than lazily where they render, and shipping several libraries that do the same job because different features were generated at different times.

Run your bundler's analyzer. The output is usually blunt: a handful of packages account for most of the weight, and one or two of them are needed on one route. Route-level code splitting plus lazy loading for heavy components is a day of work and frequently cuts initial load in half.

Candidate 2: the query count that grows with the feature list

On the server side, the equivalent of bundle bloat is a page that accumulates queries. Each feature adds "just one more" fetch to the dashboard — a count here, a lookup there — and each is fast in isolation. Thirty of them, sequential, at twenty milliseconds each, is six hundred milliseconds of pure waiting.

Worse is the N+1 pattern, which generated code produces almost by default: fetch a list, then loop over it fetching a related record for each item. Ten rows is eleven queries. A hundred rows is a hundred and one, and the page that felt fine during development becomes unusable exactly when the customer's data grows. That growth curve is the subject of why apps get slow with real data.

The fixes are unglamorous and effective: batch related lookups into a single query with a join or an IN clause, run independent queries in parallel rather than sequentially, add indexes on every column you filter or sort by, and paginate anything unbounded. Query count is the number to watch — hold a page to a fixed budget of queries regardless of how many rows it renders.

Candidate 3: state that re-renders the world

If the app feels sluggish while typing or clicking rather than slow to load, you are looking at render cost, not fetch cost. The usual structure: one large context or store at the root holds everything, every feature reads from it, and any change to any part of it re-renders every consumer.

Open a React profiler and interact with the slow surface. If a keystroke in a form re-renders a component tree that has nothing to do with that form, the state is scoped too broadly. Split it — separate stores or contexts per concern, state colocated with the component that owns it, derived values memoized rather than recomputed on every pass.

The same profiler will show you the other classic: a list rendering thousands of rows at once because nothing virtualizes it. That one is a library swap, not a redesign.

Candidate 4: architecture that never got one

If all three of the above are true at once, the real answer is that the app grew by accumulation. Each feature was added where it was easiest to add rather than where it belonged, so shared logic got copied, components grew to hundreds of lines with a dozen responsibilities, and there is no layer boundary anywhere to stop the next feature from doing the same.

This is what technical debt actually feels like day to day — not a dramatic failure, just everything getting slightly harder and slower. The technical debt guide covers how to size it, and refactoring AI-generated code without breaking it covers the safe order of operations for undoing it.

What to fix first

Work top-down by payoff per day. In most apps in this state, code splitting and query batching together recover the majority of what was lost, and neither requires a rewrite. Caching comes after — a cache in front of a badly shaped query hides the problem rather than solving it, though it is the right move once the query is sane. Caching strategy for an AI-generated app covers where it genuinely belongs.

Stop the trend, not just today's symptom

Fixing the current slowness without changing how features get added means you will be back here in three months. Two guardrails do most of the work.

A performance budget enforced in CI. Set a maximum bundle size and fail the build when a pull request exceeds it. The conversation then happens at review time, when the fix is easy, rather than at customer-complaint time.

A query budget on your heaviest pages. Log the query count per request in development and treat a jump as a bug. A dashboard that goes from six queries to eighteen in one pull request is a review comment, not a mystery for next quarter.

Add real user monitoring so you learn about regressions from data rather than from a founder's impression, and the whole class of problem changes from creeping to visible. If you want the broader checklist of what makes a page slow in the first place, why is my website so slow covers the fundamentals.

Frequently asked questions

Should I rewrite the app instead of optimizing it? Almost never for performance reasons alone. Slowness that tracks feature count is caused by specific, findable patterns — unsplit bundles, N+1 queries, over-broad state — and each has a targeted fix. A rewrite discards working product logic to solve a problem that a week of measured work usually solves.

Why is it fast for me and slow for customers? You have a warm cache, a fast connection, a small test account, and the app already loaded in a tab. Customers have none of those. Test on a throttled connection, in a private window, against an account with realistic data volume, and you will see roughly what they see.

Can I just add more server capacity? Bigger servers help when you are genuinely CPU or memory bound. They do nothing for a five-megabyte bundle, an N+1 query, or a re-render storm — those are structural, and paying more to run them faster gets expensive long before it gets effective.

---

If your product is heavier every month and nobody can name the feature that did it, the cause is a compounding pattern rather than a single mistake. SprintX profiles AI-generated and hand-built apps, fixes the bundle and query problems that cause most of the loss, and leaves budgets in CI so it stops recurring. Send us your repo or a slow URL.