A fast page load does not guarantee a fast route change
In a single-page app, clicking an internal link often changes the view without requesting a new HTML document. That can avoid some work, but it does not make navigation instant. The app may still need to download code, fetch data, update state and render a large part of the interface. If any of those steps takes too long, the click can seem to do nothing.
Treat route changes as a separate performance task from initial page loading. Pick one common journey, such as moving from a list to a detail page, and describe what the user should see after clicking: an immediate pressed state, a loading indicator, useful partial content or the complete destination. This gives you a clearer target than asking whether the app is generally fast.
Trace the work from click to usable screen
Start a browser performance recording before clicking the link, then stop it once the destination is usable. Look for the click event, network requests, long JavaScript tasks and rendering work. Record the same journey more than once: a first visit may need to download a route’s code, while a repeat visit may use cached files. Test with a slower device or simulated network conditions if those reflect the people you serve.
A route-change timeline helps separate three different delays. First, did the app respond to the click promptly? Second, when did destination content become visible? Third, when could the user interact with it without waiting for another update? A loading spinner can make the first step clear without improving the later ones. Conversely, content may appear quickly but remain unresponsive while JavaScript continues to run.
Keep notes about the route, device conditions and whether the destination was visited earlier. Comparing recordings made under similar conditions is more useful than comparing one cold visit with one warm visit and attributing the difference to a code change.
Check requests and dependencies before changing code
Open the network panel and identify requests triggered by the click. A route might wait for a code bundle, then request data, then make another request after receiving that data. This sequence matters: even individually short requests can create a noticeable wait when later work cannot begin until earlier work finishes. Look for requests that are essential to the first useful view and distinguish them from information that could arrive afterward.
Where appropriate, start independent requests together rather than one after another. Consider whether a small amount of destination data can be prepared when navigation is likely, but avoid preloading every possible route or fetching private data without a clear need. Prefetching trades bandwidth and server work for a potentially faster future action; it is most useful when the destination is reasonably predictable.
Also check what happens when a request fails or takes longer than expected. A destination that leaves the old screen frozen offers little explanation to the user. A stable page structure with a clear loading state and a useful error message can make navigation understandable even when the network is slow.
Look for JavaScript and rendering bottlenecks
If requests finish early but the new view appears late, examine the browser’s main-thread activity. Parsing a newly downloaded route bundle, transforming a large response or rendering many components can occupy the thread before the browser can paint. A long task near the click may also delay the click handler itself. The recording should help you decide whether to reduce downloaded code, simplify data processing or limit the amount of interface updated at once.
Avoid assuming that every re-render is a problem. Focus on expensive work that occurs during the route change and affects what the user can see or do. A large table, for example, may benefit from showing a manageable first portion while the rest becomes available through pagination or another deliberate interaction. If a panel is not needed for the initial view, it may be possible to render it later without hiding the page’s primary content.
After each change, repeat the same navigation test. Check not only when the destination first appears, but also whether controls respond and the layout stays stable. An optimization that displays a placeholder sooner while postponing all useful content may improve the appearance of speed more than the experience itself.
Make the improvement repeatable
Choose a small set of representative routes: one with a code download, one with substantial data and one that is used frequently. For each, note the conditions and the time from click to a useful screen. You do not need a universal target to make progress; a consistent test can reveal whether a change helps the journey you intended to improve.
Finally, preserve the basics of navigation. Links should behave like links where possible, including opening in a new tab and working with browser history. Clear focus handling and visible status changes help people understand where they are during a transition. The best route optimization is not merely a shorter trace: it is a destination that becomes useful promptly and behaves predictably.
