Performance problems are almost always decided early and discovered late. By the time someone complains, the causes are in the rendering strategy, the data access pattern and the dependency list, all of which are expensive to change.
Set the budget before the design
A budget is a set of numbers agreed at the start: how long until the page shows something useful, how long until it responds to input, how much JavaScript ships, how large the largest image is, and how many network requests the first view makes.
Agreeing that before the design is what makes it real. A design that requires four web fonts, a full screen hero video and a carousel has already spent the budget, and discovering that after the design is approved means either shipping something slow or redoing the design.
Measure in the conditions that exist
Three things distort every internal measurement.
The device. Developers have fast machines. Customers do not. Measure on a throttled mid range mobile profile, because that is where a heavy page falls apart.
The connection. Office broadband hides transfer cost. Throttle it.
The data. A list that renders instantly with fifty seeded rows behaves differently with fifty thousand. Seed production scale data before measuring anything, because the query that scans a table is fine until it is not.
The third is the one teams skip, and it is the one that produces the worst surprises, because the failure appears months after launch when volume has grown.
Averages hide the problem
An average response time below half a second can coexist with a minority of requests taking several seconds. The mean does not show which users wait or whether their delays occur on the most important actions.
Watch the slow percentiles. The ninety fifth and ninety ninth tell you what your least fortunate users experience, and they are usually the users with the most data, which frequently means your largest customers.
Where the time actually goes
In practice a small number of causes account for most problems.
Doing work in the browser that belongs in the database. Loading a table into memory to filter or sort it. Push it down: filter, sort and paginate in SQL against indexes that exist, and use keyset pagination for long lists so page four hundred is as fast as page one.
Shipping JavaScript for pages that do not need it. Content pages should be static documents. Interactivity should be a per route decision rather than a default.
Images. Unbounded dimensions, wrong format, no declared size. Declaring width and height also prevents layout shift, which is a separate and equally visible problem.
Fonts. Each weight is a download and a render decision. Two weights with a sensible fallback is usually enough.
Third party scripts. The ones nobody remembers adding are frequently the largest single cost, and they execute on the main thread while the page is trying to become interactive.
Sequential data fetching. A page that fetches A, then uses A to fetch B, then uses B to fetch C pays for three round trips in series. Parallelise or denormalise.
Static where possible
The fastest response is a file served from a location near the user with no computation involved.
Marketing pages, reference content, documentation and product listings can all be generated at build time. Only the genuinely personal parts need to render per request. Making that decision per route rather than per application is the single largest structural lever available.
Keep it from regressing
Measure in the pipeline against seeded data, and fail the build when a budget is exceeded. Without that, performance decays one small addition at a time and nobody can point at the change that did it.
Measure real users too. Synthetic measurement tells you about a controlled case. Field data tells you about the devices and connections your customers actually have, which is the number that matters.
The honest position
Speed is a discipline rather than a technology. A custom build is not automatically faster than a platform, and a modern framework is not a performance strategy. What makes a site fast is deciding the budget, measuring against real conditions, and refusing the additions that break it.
Separate the first visit from a repeat visit
A cached page can hide an expensive first load. Record whether the browser cache, service worker and server cache were warm for each run. Test an ordinary first visit with no existing cookies or downloaded fonts, then test a return visit separately. Do not mix them into one unexplained score.
For a form or dashboard, measure the action after the page loads as well. A page can paint quickly and still block when the user opens a filter or advances a step. Watch for a large collection imported into a client component, synchronous parsing on the main thread or a filter that rerenders more rows than the viewport can show.
Use production output when comparing changes. Development tooling changes compilation and runtime behaviour, so its timing is not a release benchmark. Keep the device profile, route, build identifier and audit version with the result. Run repeated measurements when a change is close to the threshold, and investigate variation rather than selecting only the best score.
If the page misses the budget, identify the limiting resource before changing the design. Network transfer, script execution, layout work and a slow upstream request require different repairs. Removing an image will not fix a long database lock, and adding a cache will not fix an inaccessible loading state.