 Hello and welcome. My name is Steven Fluen. I'm a developer advocate on the Angular team here at Google. My job is really fun because I get to help developers be successful with Angular and I get to spend a lot of time listening and engaging with the community so we can reflect your needs onto the team. One of the things that we've learned, having worked with a lot of developers across the world, is that staying up to date is really, really important. And so today's talk is all about how to keep your application as fast as possible and as fresh as possible using Angular. We're going to be diving into some of the best practices that you should be following as an application developer and we'll take a look at live code and see how you could actually go in and debug and build your application out. So let's actually get started. So if we take a look at what we've got here, this is a application that I've built using the Angular CLI. So it's a very, very basic application. This should look very, very familiar. It's basically we ran ng new and then we installed something called Angular material. And so if you take a look at the app component, I've put in an app dashboard and so if we ran a command like ng serve, what we would see is a normal dashboard of an application that's coming from Angular material. So we've got a few dependencies installed. We've got a few other things installed and all of that should just be coming to you kind of automatically. So here we go. This is just the default blank dashboard. And so even though we haven't written a ton of code, we've got an application up and running and it's pulling in a ton of code, right? We're pulling in the features of Angular necessary for these animations, for these menus, for these dialogues, as well as for all of this content around this dashboard that a user could interact with and engage with. And so the first thing I want to do in order to make my application fast as possible is I really want to understand my application. And so we're going to make a couple changes within our build configuration in the Angular.json file. So what we're going to do is we're going to find the Angular.json file. You're going to find this directly in the root of your application. And what we're going to do is we're going to find in the production build settings, we're going to change two settings here. We're going to say source map. I'm going to change that from false to true, as well as in our named chunks, we're going to turn that onto true. What source map does is this will actually take my application and map all of the generated JavaScript that comes out of the build and map it back into the code that that JavaScript came from. And so if some of the generated code came from Angular material, we'll see that. If it came from Angular itself, we'll see that. And we'll even see things like the generated JavaScript being mapped back to my HTML and into the application code that I'm writing for all of the components that I'm creating. So source maps are a really great way for you to understand what's going on in your application and the relationship between what happens in the code you write in the IDE and the code that's being delivered to your users. And so there's a lot of steps that we end up taking along that way, right? There's the Angular compiler that takes that HTML and turns it into JavaScript. But there's also other steps that we do like optimizations where we'll change some of the property names. You've got bundling so that we get all of this JavaScript coming down as a single kind of cohesive bundle that makes sense to browsers. And so source map allows us to follow that path, follow that process and give us really good insights. And so what we can do is having made these two changes, we can actually now go and run a ng build dash dash prod. And what that will do is that will create a production build of our application, which is normally what you ship down to browsers. But because we've turned on source maps and we've turned on name chunks, we'll actually see the JavaScript and be able to analyze those chunks. And so we're also going to be using another tool today called source map explorer. There's a bunch of other tools out there that developers use to analyze bundle size and chunk size. But what we on the Angular team actually really strongly recommend is you only use source map explorer because there are tools out there like webpack bundle analyzer that categorically misrecognize some of those steps within our process. And so we've done that production build. And now whenever you want to actually take a look at what a source map looks like, we can just run source map explorer. If you don't have this installed, you can just install it globally, yarn global add source map explorer, or you can install it local to your project, whichever makes sense to you, just go ahead and do that. And what we'll do is we'll run source map explorer. And we will pass it in the JavaScript file that we want to analyze. And so we can see that we've got our disk folder here. And we're going to look at the ES 2015 version of our JavaScript. So if we run that, it's going to pop up in a web browser, and we're going to see this visual interactive story about our application. So we can see our overall bundle size in terms of minified but not compressed JavaScript. So it'll actually be a little bit smaller when it goes over the network. We have about 452 kilobytes of application. And what's really, really helpful here is that you can see where that bundle size is coming from. So you can see animations is 64 kilobytes. Angular material is about 56 kilobytes. We've got things like HTTP, where we might actually need these things. And we might not even know that they're in our bundle. We might have forgotten it some point along the way. So you can see I'm pulling in forms and HTTP. If we actually go into our application, we now that we know that those things are there, we can say, hey, I don't actually need that for this dashboard. If we look at the content that I'm showing here, there's no form data here. There's no data coming from the internet. And I can go into my app module and I could pull those out. So I'll just comment these out because we don't need HTTP or forms. And what should happen is when I do my next production bundle, all of that code is going to be left out. And so we're going to be able to see that our bundle size will come down from around 450 kb to a little bit less than that, which is really, really nice. And it should actually be exactly leaving out the size of the HTTP bundle and the size of the forms bundle. And so source maps are one of the best tools in your toolbox. And we really recommend that every developer be using source map for using this on a regular basis to understand your application, especially when you're doing any sort of performance optimization. Now, let's say that you are looking at your bundle and you're saying it's still too big, but I need all of those features. I need all of those capabilities. Fortunately, the Angular CLI offers a lot of really smart capabilities. One of those capabilities is being able to take an application and build out lazy loaded modules. And so let's actually go ahead and do this. And so I'm going to use the CLI here, and I'm going to say ng, which is the Angular command, and I'm going to say generate module. And I'm going to give it a root module that it's going to connect back to. So what we're going to do is we're going to create a separate part of our application where we can pull in the features that we need and just leave all of that code outside of the main bundle. And so we're going to generate a module here, and I'll just link it back to the module known as app module, which is the root of my application. And now I'm going to give it a route. And so what this does is it automatically wires up this module to be lazy loaded whenever a user hits that route. And so we'll just make, for example, an about page. And so what this is going to do, it's going to generate a module called about module. It's going to be able to route to it. And then it's going to give me an about component. So we can see all of that in our source code. So let's just close all these files. And we're going to see it created a new about folder with our new module and our new code. And so if we do another production build, what we'll actually see, because we turned on named chunks, we'll actually get out now, not only a main chunk, a main module, we're also going to get out an about module, we can see and independently verify the size of that module and independently verify what the dependencies of that module are doing to the overall bundle size of our application. And so what you'll see is that by default, an Angular module is really, really small. It's very, very thin. It doesn't add a ton of bundle size to your application. It's almost always the dependencies that you are pulling in as a developer, the features that you are reaching out for. And what you will do was intelligently based on the where you do the imports will lazy load and split that code. So if you remember, we pulled HP and forms out of our main chunk, we can actually now pull that in. And so you can see we've generated a, let's just clear this out. Let's take a look in our disc folder here. You can see we've got a main chunk. And now we've got this nice new about module. And so you can see in the ES 2015 version, our about module is only about 1.1 K of code. So it's just that about component because it doesn't have any dependencies. But if we add back in more dependencies into that chunk, if we wanted to pull in, for example, Angular material into that about module, then it's going to pull in that code. But it's going to do it very, very intelligently. It's going to lazy load all of that code. So if you haven't set up lazy loading before, it's really, really easy just generate a new module with that command that I showed where we generate a module. And we hang it onto the routing structure of our application. All right. Next up, I want to talk a little bit about what happens after we build an application, after we've been building it out, and we've added more and more features. It's very, very easy to backslide. One of the things that the Chrome team has seen consistently is that even applications spend a ton of time building great performance into their apps tend to backslide because we as developers, we want to add more features. We want to push more functionality to our users, and that often comes with more dependencies, which sometimes we don't realize is negatively affecting our bundle size. And so one of the features that's built into the Angular CLI is called bundle budgets. And so again, if we go back into our Angular JSON, so we'll just search for that, we can see this nice little budgets section. And what this does is it allows you to set several different budgets for your application. And by default, we give you two out of the box. We give you an initial budget. So this is the JavaScript that it takes to load the initial page of your application. So right now, we are warning at two megabytes. So we'll see a warning as part of our build if our application is over two megabytes. And our build will actually error out if it's more than five megabytes. And so those are very, very conservative defaults. We recommend you turn those as small as you can to really just give yourself a knowledge of when you're increasing your bundle size. It's a conscious choice rather than an accident. You'll see we also have a few other types of budgets, including any component style. So what this says is that any scoped styles to a component, we want to keep those under six kilobytes and we are going to error out if they become above 10 kilobytes. And there's a few more that you can see if you just take a look in your ID, you've got all scripts. So that's just what is the total sum of all the scripts in my application, any scripts or any individual script should be bigger than this, the whole bundle overall, all those sorts of things. So we've got a whole bunch of different features that allow you to really take control and understand and prevent bundle size increases. So that's a really, really helpful tool. So those are some of the top things that you should be doing to keep your application as fast as possible. But one of the best things you can do that doesn't take a lot of work is actually staying up to date with Angular. So if we jump back to the terminal here, what we'll see is that I actually created this Angular application on an old version of Angular. It is running version eight. So version eight is not the latest version, version nine as of this filming is the latest version and version 10 is coming out. But it's always the same. So if you are on an out of date version of Angular, your bundle size is going to be bigger and slower than it needs to be. Because what happens is over time, every time we do a release, the Angular team is looking at what can we do better. With the release of version eight, we actually made a huge step forward by automatically doing something called differential loading where because we have this opinionated control of the entire tool chain, we understand how to make your production bundles. And so what we did is we said, hey, modern browsers are capable of loading JavaScript differently than legacy browsers that don't support something called ES modules. And so using that knowledge, you can actually conditionally force modern browsers to load modern JavaScript and legacy browsers to load legacy JavaScript. And this is a really nice schism that allows you to have two bundles that really gives you the best of both worlds, where you can ship the smallest, fastest JavaScript to modern browsers that support the most recent capabilities, like classes, like modules, all those sorts of things. And you can leave an older legacy bundle for browsers that don't have that kind of support. And so we actually did this out of the box by default. So you notice when we were doing those builds, we were actually getting the two JavaScript bundles for each of the files. So we had an about module 2015 and we had an about module ES five. And so again, this is one of the changes that the Angular team did behind the scenes without having to make you change any of the code in your application. And this is something we do every single release. And so what we're going to do now is we're going to make our application as fresh as possible. So we're going to update to the latest version of Angular. And we're going to automatically get more improvements to our bundle size. This is something that just happens every time you keep your application up to date using Angular. And so we're going to again use the ng CLI command. And we're going to use ng update. And we're going to update our application in a couple of stages. First, we're going to update the Angular core packages. So core and the core package, as well as the CLI package. And then what we're going to do is we're going to go and update our dependencies. So we're going to do as two steps to make sure that we don't accidentally enter a mistake or an error where application is no longer compatible with one of those dependencies. So let's go ahead and get this started. So I'm going to run ng update. And what we're going to do is we're going to pass it Angular CLI and Angular core. Now, if you were on an even older version, what we do is we recommend that you go one version at a time just so we can apply things cleanly. And if you want to do that, for example, if you were on version six, you want to go to version seven, you can just say at seven. And that will just do that for you. But we're going to go all the way from version eight up to version nine, which is the latest. So I'm going to run this command. And theoretically, things should work. There's a few places where this might fail. If your repository isn't clean, then what should happen is we're going to throw this warning, which is what we're seeing right now. Repository is not clean. Please commit. Because what we want is we want you to have a very clean history so that you actually know what the Angular update process did. Because this isn't like a normal ng update where we're just modifying the node modules of your project. We're actually making changes to your application so that you stay compatible with Angular. And the reason we're able to do this is because the Angular team at Google, we have thousands of projects across Google that are not run by our team that are using Angular. And it's actually, according to Google policy, our responsibility for keeping those applications working as we make breaking changes to Angular. And so the only way that we could scale this at Google is to build really great automation and really great tooling. And so what we did is we baked that same sort of tooling into the public world into this ng update command. So whenever we need to change a method name, whenever we need to deprecate something, we're going to try and update your application as best we can. And so that's why we always make sure that you want to have a clean history. So we'll just get add everything. Commit that. And now we should be able to run our update command. So again, what's happening behind the scenes is it's going to be downloading and installing the latest version of Angular CLI. And then it's going to be updating the packages in my application and changing my code where needed. And so if there's any sort of migrations, what should happen is while you're doing the update process, it's going to report what migrations it's doing. So you can see in your workspace migration. So it made a few changes to the workspace layout. So you can see it updated my Angular JSON fellow to my tsconfig.app. It updated the package JSON. So it's making all of these migrations, even ones that don't really have any changes to my app. It's still double-checking all those things so that we know that my application is going to keep working. Now, there's a couple other places that you can look for the latest information. You'll notice here at the very, very bottom of the update, it actually says, for more information, please see this link. And so we actually have guides on what changes we're making behind the scenes with every version of Angular. So you can know about things like deprecations. You can know about things like removals and changes to the way that APIs work. The other one that I want to point you out to would be update.angular.io. So behind the scenes when you ran ng update, we made a lot of changes to your project. And so if you actually wanted to see what you need to do, you can just go to the update guide, you can say, show me how to update. And we'll say, oh, make sure you're on the latest version here, make sure you're using this version of Node. It walks you through the changes that are going to affect you as a developer. And you can even tune this based on the number and amount of features and the depth and complexity of your usage of Angular. Because most applications don't need to care about all the changes we're making out of the hood. But let's say you have a large application. Maybe you have several hundred components. You have component libraries. You're using things like Universal. You can check these boxes. And what we'll do is it will show you all of the information about the update, all of the changes we're making behind the scenes so you can have a full, complete understanding of what's going on. The other way you can do it is if you just take a look at the Git history, you can now go in and see what all the changes we made were. So for example, when we moved to version nine, we turned on ahead of time compilation by default. So that's going to make your build a lot faster. You can see that we've installed all of the dependencies and not just on Angular. We've also installed things like RxJS to the latest version. We've updated your components so that they actually continue working as we make changes to Angular. So this is really, really powerful. And then we can actually do a test to see if this works. So let's just run on ng serve. And we can say, yes, let's let Google Analytics track some of our CLI usage anonymously. And what will happen is when we return back to the browser window, we're going to get the latest version of Angular and our app is generally just going to keep working. And then the way that this really affects you is not only keeping you up to date as a developer, making sure you're using best practices, but again, it's also going to improve the performance of your application. One of the things that you're going to see is that every time we make an update to Angular, we're trying to look for ways to make Angular more tree-shakeable, to make your build system better. And so there's lots of experimentation, lots of ideation going on there because the state of bundlers in JavaScript are not static. Webpack keeps getting better, rollup keeps getting better, cursor keeps getting better. And these tools are changing and they're evolving and the way that they relate to each other is changing. And so what we do is, as the Angular team, we're trying to stay on top of that for you. And so let's go ahead and refresh. And if we take a look in the DevTools, we should see we are now on the latest version of Angular. So 919 at the writing. But whenever you use ng update, it's just going to move you to the latest version. It's going to do that automatically for you so that you are staying up to date, staying fresh, staying fast. So once you've updated Angular and you've updated the CLI by core and come, now what I'm going to do is I'm going to go and update all of the other packages. So if you take a look, for example, we did not in our package, Jason, we didn't update the CDK or we didn't update Angular material. And so we're going to do one more ng update command to update Angular material and Angular CDK. You can do this with any of your dependencies. A lot of dependencies are starting to support these automatic migrations. This is something we've been pushing very hard for in the ecosystem. All right, let's just run that ng update Angular material and Angular CDK command again. And again, it's fetching the latest version of those packages. It's updating their dependencies in your package, Jason. And then it's going to execute any migrations that you need to be on the latest version. And I think we're going to run ng serve one last time and we will see that our entire application kept on working. And our bundle size should have gotten a little bit better. And again, it's doing a little bit of compiling ahead of time. Generally, this is a temporary thing that you're going to see with Ivy and with version nine, is that we do this extra compilation. That's really to offer the latest version of Angular and the latest features of Angular while still staying compatible with the rest of the ecosystem. So this is just a extra compilation step that Angular team does to optimize things. All right, as soon as this compilation is complete, what we're going to see is we're going to be on the latest version of Angular. And again, we updated the package, Jason. So just all of the dependencies, including removing things like HammerJS, and our application should just keep working. Yep, there it is. We have a great dashboard, just like we had before right in the beginning, everything works, everything animates. We're now in the latest version of Angular. We're now in the latest version of Material in the CDK. And our application is as fast as we can be because we're budgeting. We're making sure that we're understanding our application, making sure it doesn't grow over time. We're analyzing the application bundle size with source maps. And we're doing things like laser loading so that we only make users pay for the features that they're using at the current time. That's going to be it for us. Thank you so much for watching and have a wonderful day.