Angular Universal and why you need it.

In-case you haven’t heard of the Angular Universal project, it’s an awesome technology built by those clever folks at Google which allows your Angular application to run in a variety of different contexts outside of your standard browser.

What is Angular Universal and why do I need it?

When a web app loads, initially you’ve got an empty index.html page (blank screen) followed by some CSS and JS assets loading in. Depending on the size of your application, device, browser and networks speeds this could take quite some time.

Angular Universal allows you to do at least some of the heavy lifting on the server so you can present a partial (if not complete) HTML page with all styles and assets to the customer as soon as possible.

Currently in the Universal project there 3 options available to help tackle this:

• App Shell
• Server Side Rendering
• Pre-rendering (JamStack)

App Shell

Ikea search using shells for lazy-loaded content.

App Shells are probably the easiest Universal superpower to talk about, and you’ll have seen them all over the web whether you’re using Facebook, Twitter or even Ikea (to some extent).

The purpose of an app shell is to improve the perceived load time for a web page, even if the final content hasn’t loaded in.

Under the hood, at build time the Angular Universal engine fires up your Single Page Application and visits a single route, all content within that route is then inlined into your index.html file (including all non-global CSS).

This means what when your visitor first hits your site, even if the page hasn’t fully loaded yet, your user will see something immediately.

Pros

• Relatively easy to implement.
• Reduces the customer perception of how long your SPA takes to load.
• Site remains static so can use “serverless” hosting.

Cons

• No dynamic data.
• Regardless of whether the user has been deep-linked into your application, they’ll only see one app shell.
• Increases time-to-interactive as more data gets downloaded.
• There can be a flicker effect once your SPA kicks in.

Conclusion

App Shells can make a huge difference to your customer’s perceived loading experience however I don’t really think they’re a silver bullet / one-size-fits-all answer.

I tend to use an App Shell if I know that my users are always going to be coming in to my app from the same place (like a login screen).

Server Side Rendering (SSR)

Angular Universal running in dev mode.

Server side rendering is, simply put, a way of having the page rendered before it’s sent to the device.

When you break it down, Angular is simply JavaScript running in the DOM and these days we’ve got plenty of ways of emulating a browser — and that’s exactly what the Server Side Rendering engine of Angular Universal is doing with the help of a handy Node script and an Express server.

The request comes in, the server goes off and runs your app and returns the rendered content HTML. It’s great if you’re running with JavaScript disabled and search engines simply love static HTML.

Angular Universal even goes the whole hog and inlines any CSS you’ve got in your components into the page helping you top that lighthouse score.

Of course there’s a few gotchas that come with this (I’ll go in to depth on these in future posts):

• Angular has to guess when your page is ready to render, there’s a few ways to handle this but Universal will wait for the Async pipe to complete its first render.
• When the Server Side Render has delivered your page, the client kicks in and it needs to perform all HTTP requests again. Thankfully we’ve got the Transfer State api coming to the rescue.
• Node can have issues with hosting, threads management, slow APIs or even using Window which causes the Universal Renderer to crash.
• Personalisation isn’t really an option and the Server Side Render doesn’t know who the user is — they’re simply Node. I’ve found it best to leave personalised components as placeholders until on the client.

Pros

• Up-to-date dynamic content can be served.
• Works with JavaScript Disabled.

Cons

• Greatly Increased complexity.
• Requires a Node runtime environment.
• Thread death impacts all users on that thread.

Conclusion

Server side rendering is pretty cool, it’s not without its issues but if you need up to date information in your critical rendering path then it’s certainly worth considering.

A real-world use case would be for an e-commerce where SEO is a primary consideration, but also ensuring that you don’t oversell limited stock.

In part 3, we’ll be going through how to work through the issues I’ve mentioned above, and a few that I haven’t.

Pre-rendering (JamStack)

Angular Universal Prerendering a few pages from a CMS.

Now I’m gonna be straight up and honest here — this is my absolute favourite method, whilst it’s not easy and there’s certainly a level of complexity, there’s a rock solid stability beneath it — it’s like Next.JS or Gatsby but for Angular.

At build time, Angular creates your server side render and then visits each route individually, writing a dedicated HTML file.

You still have to hande the state transfer as with your server side render, but now you’ve got as much of your site as you like statically generated and ready to host — for my personal sites I love to use Netlify and I’d happily use it in many a professional situation too but if you need the “big business” solution then you can always throw these files at an S3 bucket fronted by CloudFront in front of it for super zippy apps.

In part 4 I’ll be going into detail on how this all works.

Pros

• Can be hosted “serverlessly”.
• Search engines love static content.
• Super Fast.
• Rendering issues can be caught at build time.

Cons

• Your critical render can only show static content.
• Increased Complexity.

Conclusion

Pre-rendering your site is great if you’ve got data that doesn’t need to be instantly up to date — most content editors don’t mind waiting a few minutes for content to build and go live.

You can use amazing CMS APIs such as Contentful, Prismic, IBM Watson or even Strapi with hooks to trigger rebuilds.

It’s a solid mid-ground between App Shells and Server Side Rendering and something I strongly believe is the future of the internet.

Just because the content is pre-rendered, don’t be worried about the app feeling static, it’s still a powerful SPA — as you can see in Fretonator (open source), see the code on Github.

Just like with App Shells and Server Side Rendering we’ve got some fantastic real world applications for Pre-rendering, and they’re pretty diverse. I see pre-rendering as the solution ‘du jour’ for brochureware applications and blogs.

Coming Up

In the second part I’m going to talk about how to set up a simple Angular app and build out an App Shell.

In part three we’ll take a deep dive into Server Side Rendering Angular with some API powered content.

And in the final part, we’ll jump feet first into the Utopia of Pre-rendering, and look at some of the Superpowers that Netlify gives us.

If you’ve got this far, thank you.
Speak soon x