Lesson Description
The "Zoneless Angular" Lesson is part of the full, Advanced Angular: Performance & Enterprise State course featured in this preview video. Here's what you'd learn in this lesson:
Alex explains how going zoneless in Angular removes zone.js to improve performance. He demonstrates zoneless change detection, removing the polyfill, and using signals to trigger updates for faster page loads and runtime efficiency.
Transcript from the "Zoneless Angular" Lesson
[00:00:00]
>> Alex Okrushko: Now, zoneless, zoneless removes the Zone.js out of the equation. How does it help? Well, first of all, Angular now is just telling the scheduler that something might change, it might not have changed, and again, it does it by, if we have like an async pipe that did something, inputs change, button clicks, or signal changes. But we'd have nothing that patches the set timeouts, the requests, any things like that, right?
[00:00:39]
So those are out of the equation. It actually speeds up the application because we don't have to deal with the third party to be doing something. Our schedule will schedule the tick, and it will also check this has child use to refresh instead, just dirty checking. Very powerful. So some of the benefits of going zoneless, first of all, initial page load becomes faster because we are not shipping Zone.js as part of the payload.
[00:01:16]
We're going to remove this. Secondly, even the Bootstrap application is faster because we don't have to patch all these events. Some of these things might not affect, you know, a 20-megabyte enterprise application if you're shipping it that way, but those things. Why do extra work whenever I have to do extra work? So again, improves runtime and improves initial load as well.
[00:01:49]
All right, so now, let's get back to our application and here we have it running. We have this application in dev mode, and let's do something here interesting. So I'm going to turn the Lighthouse on. And Lighthouse is one of those built-in tools now that allows us to generate reports, see how we're doing overall on the application, both performance, accessibility, best practices, SEO optimizations.
[00:02:20]
Those are like four major categories that it does analyze. I'm going to do in the desktop mode, you can do in mobile as well, right? I'm going to do the desktop mode. So let's analyze the page, see where we are right now if we do the Lighthouse report. It reloads the page, checks what's going on, and it creates the report for us. It's really fast.
[00:02:48]
As we can see, our performance isn't great. Our best practices are okay, accessibility is pretty good as well, but performance is not good. And yes, and that Lighthouse is part of the Angular dev tools? No, Lighthouse is part of the Chrome. Oh, Lighthouse is part of the Chrome, so they have a performance stat which is even more in-depth performance.
[00:03:08]
You can see flame charts and things like that, and Angular did some improvements there too. But you can see as well that the Lighthouse is a very fast way, and it provides fairly good descriptions of what exactly is happening. As far as accessibility, how would you compare Lighthouse's ability versus say something like the WAVE extension? Do you know?
[00:03:31]
Accessibility here, I think it analyzes pretty well. Some of those tools came before the Lighthouse was part of the Chrome, so they're still around there. Maybe they can do different suggestions. I typically rely just on the Lighthouse. Historically, before some years ago, I was also using the aXe tool that was running, it was part of the CI.
[00:03:57]
We were making sure that the components that we're adding still were meeting the bar for the accessibility. That's some time ago. Now you can also invoke the Lighthouse as part of the purpose submits as well, but that's outside of the this one's topic. But yeah, accessibility is pretty good here. You can see it will tell, right now I know exactly where the issues are, basically my like and remove buttons are not meeting the color contrast.
[00:04:31]
That's the only thing that's harming this application. We've got a web performance fundamentals course by Todd Gardner that really dives deep into a lot of performance-related topics including Lighthouse, and then John Cooperman's got a web accessibility course and Marcy Sutton has a couple accessibility courses too, and one of hers kind of focuses on web app accessibility that has more of a JavaScript app focus on making sure you're building more interactive accessible apps.
[00:05:01]
Yeah, thank you. The rule of thumb is, if you have a topic in mind, Frontend Masters probably have a course for that. Okay, so let's take a look at the performance, not very deep right now, but you can see there's a lot of issues, right? It shows you the tree map of how things are loaded and a lot of things that we can improve. We're going to start with slight improvements.
[00:05:42]
Let's start with getting zoneless first. So I'm going to push this here, and you go here, so in our config in our app, app config, right now we're using the zone change detection. And by the way, are there any questions about onPush? Is it pretty clear? Is everybody using onPush already? No, okay, and again, you see, app works, app works. It's just we can do things even better, even faster.
[00:06:18]
All right, so let's push this a little bit to the side here. Okay, so let's first thing first, we'll provide zoneless change detection. And if you're not on Angular 21, I think Angular 20 introduced to provide zoneless. I think before that, it was provide experimental zoneless change detection. It's no longer experimental, it's there, it's helping many apps.
[00:06:47]
So this is the first thing we have to do is provide zoneless change detection. The other thing we need to do is we're going to need to go to our JSON, angular.json file, and this is the one that I talked earlier. It provides the polyfill for Zones. And if you see the build right now, let me just start the fresh build. You can see the polyfills here also bring, that's the Zone.js is bringing.
[00:07:40]
So let's remove that as well. Okay. Let's restart the app. Oh, you see no polyfills anymore. So that's gone. So now our application is zoneless. Our application is ready to be zoneless. There are some caveats that I'm going to show in a second, but what we've been doing so far, we've been relying on signals extensively. We've been using the signals exclusively.
[00:08:12]
So that makes our app ready for zoneless immediately. Let's see again, our application loads, everything works, navigation works. You know, all fine, we can get tickets if we want to. Admin works. So let's see if we have any improvements right now, it's 65. Let's see if it improves. So I can do analyze the page. Hey, we've got some improvements.
[00:08:52]
Not much, not much, because we have some other things to improve, but we already have some improvements because we're not bringing Zone.js. We, our Bootstrap is a little bit faster, we're not patching any events. So here's already some improvement. There are certain things to be aware of. For example, let's see, because we're not patching those events, let me just do the event list, so we have this upcoming events label here, right?
[00:09:42]
There it is. Let's change this label to be a variable. But we can see title, right? Something like that and this variable, say it's not signal at all, right, like this is what we've been doing a lot pre-signal time, right? It's basically just properties in here, and again, let's just do constructor and a constructor will set the timeout and after two seconds going to change this.
[00:10:22]
I'm going to update this title. The title of, see, I'm very... There's already a habit to do the set. It says not upcoming events, but we'll say all events or something like that, right? So we'll save it. Let's see this upcoming events. All events, all right. Let's see again, upcoming events, okay, so this changed because we have the data came in.
[00:11:03]
Let's do not two seconds, but five seconds. All right, so it got refreshed because we have the data came in that updated the signals, but right now you see the upcoming events didn't change. Why did it not change? Why did it not change? Any ideas? So timeout isn't patched. Yeah, so timeout is not patched. We're in the zoneless app, timeout is not patched, and we didn't have any signal changes, right?
[00:11:38]
So it basically, like, I'm ignoring the, nothing's patched, nothing's notifying Angular like, hey, do the change detection. Now, if we change this title to signal, right, we change this to signal, and then we need to do the parentheses here because that's how we read the signal. And then in here, instead of assigning, we're going to do the set.
[00:12:10]
Right, let's see this again in action. All events, so this changed. Why did this change? Signal notified the scheduler like, hey, I got a new value, and it got all the way up and rechecked everything and updated this value, and we have this component. This one wasn't onPush, it's just zoneless, but it doesn't really matter because we removed the Zone.js out of the equation now.
[00:12:58]
Unless there's a signal change, input change, or there's an event coming outside of this component, it won't do anything. All right, so I'm going to change it back. This was just some demonstration. All right, I'll revert it back as it was. Okay, so this works great. So I hope you see how the zoneless can improve things, but you have to be aware of certain things as well.
[00:13:14]
For example, if you do lean in heavy on signals in the application, it would just work. Moreover, you can automatically add onPush to all the components. They will also know that things need to be updated.
Learn Straight from the Experts Who Shape the Modern Web
- 250+In-depth Courses
- Industry Leading Experts
- 24Learning Paths
- Live Interactive Workshops