Angular In Depththe feed
Forms

Angular SPA: Why Single Page Applications?

In this post, we are going to cover the main benefits of adopting an SPA Architecture while building our Angular Applications, and answer some very common questions regarding SPAs in general. This post is part of the ongoing Angular for Beginners series, here is the complete series: * Angular For Be

Angular SPA: Why Single Page Applications? — Forms article by Angular University on Angular In Depth
Angular SPA: Why Single Page Applications? — Forms article by Angular University on Angular In Depth
On this page · 13 sections

This article walks through the core reasons for embracing a Single Page Application (SPA) style when crafting Angular projects, and clears up a few recurring questions about how these applications behave.

It belongs to the ongoing Angular for Beginners collection, listed here in full:

What Drives the Choice for SPAs?

Let's tackle the initial question: what makes Single Page Applications worth it? These apps have existed for a while, yet they haven't become the standard across the public web.

What's the reason behind that?

There's a straightforward explanation for the current state, along with a more compelling reason why things could shift soon.

In recent years, SPAs have become a staple for the private, logged-in areas of SaaS platforms and various online services, plus for data-heavy enterprise and form-centric tools.

Does Angular force you down the SPA path, then?

Not at all—Angular doesn't require it, but it opens up that possibility, which is attractive given the advantages the approach offers. That leads to a pivotal question:

What's the Appeal of Making an App a SPA?

It's easy to take this for granted. Everyone seems to be building this way, but what's the real payoff? Surely there are a few standout features that justify the trend, correct?

Let's begin with a benefit that often flies under the radar: how it handles Production Deployment.

Examining the production perks of SPAs will also directly address the core question:

Defining the Single Page Application

Sometimes, the terms we use in Software Development aren't the most descriptive, which can cause confusion. That's hardly the case with SPA: a single page application truly has just one single page! 😊

To see this in action, feel free to head over to the AngularUniv https://angular-university.io and try clicking around the latest courses on the landing page and the navigation at the top.

As you browse, you'll notice the browser never does a full reload—only fresh data travels over the network as you move through the app. That's the hallmark of a single page application.

Here's a breakdown of the benefits of this design and the mechanics behind it.

With Chrome Dev Tools, we can take a look at the index.html that AngularUniv sends down for the home page (or any other route, if you navigate and then refresh).

That downloaded page is the first request you'll see in the Chrome Network tab—this is, quite literally, the Single Page of our Application.

One observation stands out: this page is mostly bare! Apart from the tag, there's not much else in here.

Note: on the actual website the page downloaded also has HTML that was pre-rendered on the server using Angular Universal

Pay attention to the CSS and Javascript bundle file names: all the styling and the complete application script (including Angular itself) is not sourced from the same server as the index.html—it's coming from a separate static host:

In this case, the two bundles are actually coming from an Amazon S3 bucket!

You might also spot that the bundle names include a version identifier: they carry a timestamp marking when the build that produced this particular app version was deployed.

The Production Deployment Perks of SPAs

The situation above highlights a genuinely neat advantage of single page applications:

Single Page Applications are super easy to deploy in Production, and even to version over time!

Compared to traditional server-rendered apps, deploying a SPA is incredibly straightforward: it boils down to a single index.html file, alongside one CSS bundle and one Javascript bundle.

These 3 static assets can be placed on any static content server, be it Apache, Nginx, Amazon S3, or Firebase Hosting.

Naturally, the app will still need to talk to a backend for data, but that's a separate service that could be built with a totally different technology, like Node, Java, or PHP.

Actually, if we were to construct our REST API or another backend in Node, we could also write it in Typescript, allowing us to use the same language across the frontend and backend, and even share certain code modules.

Versioning a SPA in Production

Another benefit of deploying our frontend as a SPA is how simple versioning and rollback become. All that's required is to keep track of versions for our build output, which generates the CSS and JS bundles highlighted in yellow above.

We can set a parameter on the server hosting our SPA to dictate which specific frontend build should be served—it's really that straightforward!

This kind of setup has great scalability: static content servers like Nginx can handle massive numbers of users.

It's important to note that this deployment and versioning approach applies only to the frontend portion, not the backend server. But that doesn't diminish its value as a significant advantage.

Is production deployment the sole benefit? Absolutely not—here's another key one:

SPAs and the User Experience

If you've spent time on a web application that reloads everything from the server with nearly every action you take, you know it can feel clunky due to:

  • the constant full page reloads

  • the frequent network requests back and forth to fetch all that HTML.

A single page application sidesteps this problem with a fundamentally different architecture:

After the initial load, a SPA doesn't send any more HTML over the network. Instead, it simply requests data from the server, or sends data to it.

So, while a SPA is running, only the data itself crosses the wire, which is far quicker and lighter than constantly shipping HTML. Let's consider what a typical network payload looks like in a SPA.

For instance, in the AngularUniv SPA, clicking on a course won't trigger any HTML transfer. Rather, an Ajax request comes back with a JSON payload containing all the course info:

Compared to a plain JSON object, the HTML version of a course would be significantly heavier due to all the wrapping tags. Also, there's lots of duplicated HTML if you're continually loading similar pages.

Take headers and footers as an example—they're sent to the browser again and again, even though they haven't changed at all.

This brings us to the second major benefit of a SPA: a markedly better user experience, thanks to fewer full-page reloads and enhanced performance from reduced bandwidth consumption.

So Why Isn't the Whole Web Using SPAs?

Given all these benefits, what's holding back wider adoption on the open internet? There's a solid explanation for that.

Up until somewhat recently, search engines like Google struggled to index SPAs correctly. What about today, though?

Some time ago, the advice was to use a particular Ajax Crawling Scheme, which has since been deprecated. So, is Google fully capable of rendering Ajax now?

In an official announcement, we have the information that Google search is now generally able to crawl Ajax, but there are some reports that it's yet not completely able to do so.

The modern recommendation leans towards Progressive enhancement. With that in mind, is it feasible to use SPAs on the public web right now, or is it still premature?

Can SPAs Be SEO Friendly?

It's entirely possible to combine the performance and UX of a SPA with solid SEO: the Angular Universal pre-rendering engine makes this achievable by letting us:

  • pre-render an application on the backend
  • ship the HTML to the browser together with Angular
  • and have Angular bootstrap on the client side and take over the page a SPA

Will SPAs Gain More Traction Going Forward?

Picture an SEO-friendly version of Amazon that skips the page refresh on each click, offering better performance and a smoother experience: it would likely have a big positive impact on the time customers spend on the site!

So the technical benefits of SEO-friendly SPAs are substantial, even more so on mobile devices, and we'd expect these kinds of SEO-friendly SPA apps to appear more often on the open internet in the future.

But we still have one lingering question from this section to address. After reading the last few parts, you might be wondering:

If the server sends only a tiny bit of HTML initially, how does the page manage to change over time?

This brings us to the final question of this section, and perhaps the most critical one:

How Does a Single Page Application Actually Work?

Indeed, how can they function at all when we've only loaded a small amount of HTML? Once running, only data goes over the wire. So where does the new HTML originate?

Because there has to be new HTML generated somewhere, as that's the only way the browser will update what it displays, right?

The answer is straightforward, and it hinges on how SPAs differ in their operations from traditional server-based apps.

In a classic application (which covers most of today's public Internet), the conversion of data to HTML, also known as rendering, takes place on the server side.

Single page applications, by contrast, do things quite differently:

In a SPA after application startup, the data to HTML transformation process has been moved from the server to the client – SPAs have the equivalent of a template engine running in your browser!

With that in mind, let's wrap up this section by pulling together the main points about single page applications.

Section Summary – SPA Benefits and the Core Idea Behind Their Functioning

Developing our app as a SPA brings with it many noteworthy benefits:

  • We will be able to bring a much-improved experience to the user

  • The application will feel faster because less bandwidth is being used, and no full page refreshes are occurring as the user navigates through the application

  • The application will be much easier to deploy in production, at least certainly the client part: all we need is a static server to serve a minimum of 3 files: our single page index.html, a CSS bundle, and a Javascript bundle.

  • We can also split the bundles into multiple parts if needed using code splitting.

  • The frontend part of the application is very simple to version in production, allowing for simplified deployment and rollbacks to previous version of the frontend if needed

It's important to remember that this is only one possible way to deploy SPAs in production.

Alternative Production Methods

Other approaches might involve pre-rendering most of the app and uploading everything to a static host, caching only certain pages in memory on the server, or managing versions through DNS, among others.

Creating SEO-friendly SPAs is now easier than ever, which suggests they'll see increasing adoption in areas where they haven't been commonly used.

The Inner Workings of SPAs

The strengths of single page applications come from how they operate internally:

  • After the startup, only data gets sent over the wire as a JSON payload or some other format. But no HTML or CSS gets sent anymore over the wire after the application is running.

The core principle for grasping how these apps function is this:

instead of converting data to HTML on the server and then send it over the wire, in a SPA we have now moved that conversion process from the server to the client.

Since this conversion happens right at the last moment on the client side, we're able to offer the user a significantly smoother experience.

I hope this clarifies why SPAs are advantageous. If you see it differently, feel free to let me know why so I can expand on the points more thoroughly.

At this stage, I'm eager to show you some code. Let's build a small Hello World SPA in Angular and go from there. We'll see how the ideas we've talked about map onto this little application.

I hope this post has been helpful in explaining the key advantages of SPAs, and that you found it enjoyable!

This post is part of the ongoing Angular for Beginners series, here is the complete series:

I invite you to subscribe to our newsletter to get notified when more chapters come out:

If you are just getting started learning Angular, have a look at the Angular for Beginners Course:

Angular SPA: Why Single Page Applications? — figure 1

Have also a look also at other popular posts that you might find interesting:

AU
Angular University

Writes about RxJS, Components, Signals. Active 2015–2026.

All 79 articles →

More by Angular University

Angular Mocking With HttpTestingController (Complete Guide)Testing · Apr 16, 2026Modern Angular Testing with Vitest: The FundamentalsTesting · Feb 26, 2026Angular linkedSignal: Missing Link in Signal ReactivitySignals · Mar 14, 2025
← NewerAngular For Beginners Guide - Getting Started (Setup Environment) Older →Angular Architecture: Container vs Presentational Components Pitfalls