Rendering is an integral part of Angular's structure. Because of its nature as a framework, the default way of doing things can be a bit slower than needed. As an engineer and as you get to understand the framework better, you will find that there are performance boosts baked into the framework to increase your app's speed. Rendering within Angular is definitely sits in the performance category. Let's dive into the different ways of rendering on the web so we can bring that over to Angular.
SSR: Server-Side Rendering - Rendering a client-side, or universal app to HTML on the server
CSR: Client-Side Rendering - Rendering an app in a browser, generally using the DOM.
Pre-rendering: Rendering a client-side application at build time, to capture it's initial state as static HTML.
TTFB: Time to First Byte - seen as the time between clicking a link and the first bit of content coming in.
FP: First Paint - The first time any pixel becomes visible to the user.
FCP: First Contentful Paint - The time when request content (body, header etc.), becomes visible.
TTI: Time to Ineractive - The time at which a page becomes interactive (events wired up, etc.)
Setting Proper Frame of Mind - When Rendering Happens
When trying to understand how rendering worked, awareness of when things happens can help decrypt the mystery. When I was able to put into perspective that it happens in two scenarios:
Server rendering will generate all of the html for page based on navigation. It's important to keep in mind the two scenarios above, and that server side rendering only happens for the navigation side of things. Events will still have the client side render changes.
This will produce a fast first paint, and a fast first content paint. In addition, it allows for a fast time to interactive. The one draw back with regards to this approach, is the Time to First Byte. Being that we have to generate all of the content in the server first, it takes longer than usual to generate the page. Within the Angular context, it has something called Universal, which is a bit of a mix and much between server and client.
Static rendering, is where we generate the full set of html content ahead of time. This checks all boxes with regards to performance i.e.
Fast TTFB, fast FP, fast FCP, fast TTI.
You might be familiar with tools like Jekyl, Gatsby, or Hugo that accomplish this. The main drawback with this approach, is that if we have dynamic content that we don't know ahead of time what the html page is going to look like, static sites are not able to accomplish this task.
Server vs. Static Rendering
So let's say that you are coming across a situation where you cannot use static rendering. But you would like to use static rendering. The only issue in this is that your page is dynamic. The server side rendering is not an end all be all solution. There will need to be some sort of caching solution offered in this regard, for server side rendering to be truly effective.
Client Side Rendering
Client side rendering is what usually happens by default in an Angular application.
One of the more notable downsides is as follows:
- Performance concerns for mobile
Universal Rendering - Server + Client Side
Up and Coming Technologies
There are some technologies that are on the horizon that are useful to keep an eye on. There are two in particular, streaming server rendering
- progressive rehydration.
Streaming Server Rendering
This allows for you to send HTML in chunks, so that the browser can progressively render as it's recieved.
Subscribe to the Razroo Angular Newsletter!
Razroo takes pride in it's Angular newsletter, and we really pour heart and soul into it. Pass along your e-mail to recieve it in the mail. Our commitment, is to keep you up to date with the latest in Angular, so you don't have to.