Why a page can change without a new page loading
A single-page app is built to keep one main document open while its JavaScript—the code that makes the interface work—handles navigation. After the initial download, clicking a link can make the app replace the visible content and update the address bar without asking the browser to fetch an entirely new page. That is why moving around can feel immediate: much of the machinery is already on the device.
The first visit pays the setup cost
To make those later transitions possible, the browser first has to download and run the app’s core code, along with the styles and data needed to start. It then turns those files into a working interface. On a slow connection or an older phone, downloading and processing that bundle can take long enough for the app to show a spinner, even if the first screen looks simple.
The tradeoff is not always “everything now, nothing later.” Apps can divide code into smaller pieces or request data only when a particular screen needs it. But each extra request or deferred download can add a pause when someone reaches that screen. Developers therefore decide which parts to prepare early and which to fetch on demand.
A faster-feeling app can have a slower beginning
Once the necessary code and data are ready, the app can reuse them instead of rebuilding the whole page for each move. The benefit is most noticeable during repeated navigation; the cost is concentrated at startup. The experience depends on where the wait lands: a single longer first load may make every later transition feel quick, while poorly timed on-demand downloads can bring the waiting back mid-session.
