Tools for Fast Angular Applications | Minko Gechev

[Music] all right hello everyone my name is Mika ketchup I'm an engineer in the angular team at Google today I'm going to be talking about a couple of tools that we have been working on over the past few months which aim to help you build faster and your applications so let us start with your gender we're going to discuss what is network performance I believe most of you are already familiar with this but we're also going to introduce a couple of tips and tricks which you can directly take from this presentation and introduce in your applications in order to make them faster after that we're going to discuss how we can efficiently deploy and your applications to production just by using the angular CLI so network performance network performance is a time required for your application to get downloaded in the browser pretty much so we can optimize the network performance of our app just by reducing the number of bytes that were transferring over the wire and reducing the number of network requests that we're also sending a couple of tools that we have been working on they aim to help you ship fewer bytes of JavaScript because it turns out that javascript is more expensive than some other assets for example I'd use money in his survey the state of JavaScript he shown that shipping 170 kilobytes of JavaScript is much more expensive than shipping 170 kilobytes of a jpg image about 20 times more expensive because of the overhead of parsing and right after that executing this JavaScript code and compiling it so native so a couple of practices are of course minification and that code elimination this is something that we have been building in the angular CLI and introduced units it's for its early days so we are already doing unification we are eliminating all that codes after ahead of time compilation and we are making sure your apps execute as fast as possible but something new that we have been working on together with MAO from the community to interview and which we are going to introduce as part of version eight is differential loading so this is a feature that I'm particularly excited about especially because of its performance benefits and our users who are on modern browsers that are no longer need have to pay the penalty for shipping just getting polyfills for older browsers so here is how differential loading is going to work we're currently building to type two times your application once for older browsers and once for newer browsers we're going to build es five bundles for your users who are on legacy browsers and years 2015 bundles for users who are on leading-edge browsers so there are a couple of benefits of this first of all we need to shift your polyfills right and on top of that will not have to down level the modern syntax which is not only going to make your bundles more but it is also going to make them faster to execute because well the JavaScript engine can take advantage of the more expressive and more powerful syntax which has been introduced recently we noticed some performance improvements in a couple of applications and we buy very early measurements we can see that we're hitting about 65 kilobytes less polyfills and from two to ten percents more bundles or even more this depends completely on how modern syntax how modern and expressive syntax you're already using in your application here is how differential warning works so first the browser sense of course requests to the server the server delivers the HTML where there are two script tags one for modern browsers and one for legacy browsers from there the browser depending on its supported capabilities it chooses one of these script tags it downloads the Associated JavaScript and right after that executes it that's it here is how the index.html file looks like here are the two script tags one of them is with type module which is associated with the Year 2015 bundle and we have a script tag with attributes no module this is just a hint for newer browsers to not download this bundle if they already have es m equal to 2015 module support so why did we choose differential load link instead of doing some magic on the server well first of all it simplifies deployment a lot the browser makes the decision which which bundle to download and we don't have to cover our server with any complicated logic which is related to parsing the user agent and deciding what JavaScript is supported by the users browser at all and on top of that there is a proposal which aims to make differential loading a first-class citizen in modern browsers so this is two very early stage it may even not ever get standardized but it's pretty exciting to see that people are working in this direction so currently differential warding we're restricted to in shipping two different versions of JavaScript yes five and year 2015 with this new standard will be able to ship multiple JavaScript versions so that the browser can download the most recent one depending on the support syntax it has a summation forget to introduce this as part of angular CLI version 8 you can already experiment with this feature with our our C 2 which is on NPM so yeah please give it a try and so let us know how much we shrink we shrunk your bundles how you can control differential loading so we have 2 properties in the angular CLI which allow you to set the minimum supported version that you would want us to ship to provide for you and the maximum one you can set the targets in his config dot JSON to years 2015 and you need to set the minimum browser support minimum supported browsers in your browser browser list in order to make sure that you're shipping yes 5 so that your application is not only compatible with all the other browsers but also C SEO friendly all right so now let us go to even more exciting part which is called splitting cost rating in general one technique which is a sub of larger set of practices called lazy loading with lazy loading we just ship the minimum amount of assets which are required for the user a given points you might have seen this on medium where you see pretty much all the images which are currently visible in the viewport and once you start scrolling more and more visible more and more images get visible get downloaded from the server and visualized in the browser so to the two specific practices for lazy loading JavaScript our component level and route level code splitting with component level code splitting let's say that we have a very heavy ecommerce platform which has even heavier widgets chat widget there like chat support widget which is something like slack in the browser and we know that's only about 2% of user engage with this user only about 2% of users are actually using it so does this mean that we'll have to introduce this part of our initial bundle so that everyone is paying for the price of this widget even though they are not using it at all no we can just lazy load it we can put a placeholder there and once the user starts interacting with this widget we can send a request over the network we can download the corresponding Java scripts and bootstrap the chat widget completely so this has been a little bit hard to achieve with the Angels view engine but there are a couple of modules community modules which are going to let you do that for example we have ng a explodable which on about 2 points 2 kilobytes of JavaScript will allow you to do that we also have lazy AF from era Frost who developed this widget this module and it's providing the same the same functionality so it's pretty much depending on your own preferences which one you're going to use both of them are well developed rod level code splitting so this is something that I hope pretty much everyone is already doing it right how many of you are using crowds that will cause bleeding with the angular router right I hope I hope I will encourage you to use it even further around right now because this is probably the most efficient way to shrink your bundles with trout cooked with route level course splitting we can have our let's say in this case our article feed page our article this page so once the user opens the articles list they're only going to go they're only going to download the articles list module so the JavaScript associated with this particular page and once they navigates to settings let's say they're going to download the settings module that's it pretty simple and we can already use this in angular by using the loads children syntax the load children property in the route declaration in version 8 we want to enable more and we want to take advantage of modern standards so we want we enabled dynamic imports which can let you do pretty much the same thing but by using the years 2015 module syntax dynamic import syntax but there is one problem with lazy loading it introduces some latency between navigations because the browser needs to go that go to the network downloads the associated with the page JavaScript and bootstrap it on slow networks this could be quite annoying and that's why we are actually building single page applications because we want to provide a very responsive user interface and by introducing this latency well we're not going in the right direction so here I have throw todo Network and introduced 3,000 milliseconds latency so that when the user clicks on the settings page they'll have to wait for three seconds until anything gets visible so as you can see that's not ideal experience and depending on the users connection this could be the experience could be even worst that's why we have techniques such as prefetching with prefetching in the background we can download the jealous people associated with pages that we suppose that the user may need next and just after I provide them from the browser's cache once the user actually used them went once they navigate to these pages so there are different strategies for achieving prefetching or pre-loading for example in angular we have the preload o strategy which is going to preload all the different modules your application but of course if you have hundreds or even tens of module this might be not the most efficient way because you're going to drain the users data and on top of that you may even block the main UI thread so that's why we usually try to be precise in what we're prefetching we want to prefetch only what is supposed to be used next and I've noticed that as developer I usually try to guess what the user is going to use and do next similar to this wages I'm trying to put myself into the users shoes and trying to guess where the user may supposed to go but they usually don't do that exactly I think so there are a couple of more efficient prefetching heuristics that we can use instead for example we can prefetch only the visible links on the page because if the user is going to navigate somewhere it's very likely that so that they click on a visible link right we can use predictive prefetching this is something that I'm particularly excited about and I'm going to discuss in a little bit or we can prefetch a link like the JavaScript associated with a specific router link on mouse-over let's start with fetching the visible links first so let's suppose that we have this blank page which has a bunch of links we have a modern API called intersection observers which is going to allow you to observe on the elements and once this element becomes visible to a certain percentage we're going to get an event so we can perform an action so here for example we are scrolling down this page team gets visible so we're downloading The Associated JavaScript contact and the ball gets this ball as well so we do the same this is a valid pre loading strategy that you can use with the angular router to the ages by installing the NZXT quick link module right after that you need to introduce it as part of your routing configuration in your pre loading strategy and finally you need to import the quick link module from injects quick link introduced in your imports and exports in your shared module so I'll definitely encourage you to take a look at this module but sometimes it can be a little bit too aggressive in terms of prefetching as well imagine we have Wikipedia like page where from one page particular we can go to $100 so does this mean that we're going to download a hundreds JavaScript bundles this might be quite inefficient also well we may even never prefetch the actual JavaScript that the user is going to need because well the browser can just fetch maybe five or six can process five or six single origin requests per time at given point instead we can use predictive prefetching so this is related to a project that was announced on Google i/o last year by from the chrome team so we have been working with them quite actively in order to provide predictive like predictive even machine learning driven user experience which to code gasps yes basically we can consume your data from Google Analytics we can download your Google Analytics report after rats because we're getting individual pages and how the user navigates between them we need to map them to actual JavaScript bundles corresponding to your routing declaration from there we can build a Markov chain or a recurrent neural network depending on how fancy we want to be just this is just a predictive model that we can use at runtime in order to guess where user may go next so that we can prefetch the Associated JavaScript right after rats gives us bundles a tiny piece of JavaScript in your main bundle and once the users start navigating across the application we are predicting where they may go next so we go to the network prefetch this and push it into the browser's cache we can think of it in the following way we have this Wikipedia like application we have tens of links on it and based on our Google Analytics data we can rank each individual link so we can give it a cost and depending on how how high its cost we can preload only the ones which are very likely to be visited next so this is - in an early preview although we can also already give the triangular it's available on github but github.com large gets yes so yeah this means this could be some very cool things like differential loading lazy loading we're using predictive prefetching we're using some statistical models in order to predict where the user may go next based on some heuristics but in the same time if we just have a broken import we can rack half of node modules as part of our initial bundle and we can completely destroy the user experience so that is why we have performance budgets in the angular CLI the performance budgets are going to let you set constraints and set the minimum the maximum bundle size for your application so this way if your bundle size exceeds the limits that you have set your build is just going to fail and this is not going to let you proceed this is a great opportunity to introduce performance budgets as part of your CI so that you can track each individual PR and what is the cost of your PRS on top of your bundle size I'll definitely encourage you to take a look at performance budgets and we have documentation on the angular io in the build section for the CLI alright so there is one more thing that we have been working on in order to make sure that you're shipping very fast web applications we notice that there are some very low-hanging fruits that people are usually not taking taking advantage of for example more than 27% of angular applications are not using content compression for their static assets for example for SVG images or JavaScript and even higher is the percentage of angular applications which are not using CD ends and CDN is an extremely convenient way to provide your static assets from the most geographically close location to your users for example in the u.s. here if you're building application for our users in Europe we can just directly push them to the CDN edge there and our users latency is going to be much lower compared to downloading these assets from the US in order to encourage people to use these practices even further we're working very closely with cloud providers in order to provide automated deployment from the angular CLI for example this is a demo of using angular CLI with firebase with angular fire which is going to allow you to have automated deployments here we're first adding the angularfire module to angular CLI version 8 GRC this is going to download the angular fire module this is going to do some modifications in your configuration files these need to download a few other dependencies such as far these tools let's say and right after that it is going to show prompt so you can pick your firebase hosting project where you would want your application to be deployed to once you run ng run the name of your application call and deploy we're going to run the production build of your application here we're going to do all the magic of ahead of time computation we're going to do tree shaking we're going to get rid of that codes and specify your codes in a most efficient way we can once we're done with this we're going to delegate the execution to firebase so firebase is going to take your static assets and directly deploy them to firebase hosting finally we're going to provide the URL where you can preview your application directly as I mentioned we're working very closely with Google Cloud for firebase hosting we're working very closely with Asia since recently we're talking to a bio s notify and sites so we're going to provide you a way to deploy your applications to any platform convenient for you and on top of that based on the anchors Bueller's api you can implement deployments to your favorite cloud platform if there aren't already existing builders for this purpose so just a quick recap today we saw how we can reuse the bundles of your applications by using differential loading excuse me after we have to discuss how we can use lazy loading per component or routing level and how we can use be loading or prefetching by based on quick link or predictive prefetching with gauges and finally we saw how we can import deploy your applications automatically from the CLI and make sure that you're following best practices so that your users are going to get the best possible experience that was it and thank you very much for your attention [Applause] [Music] you

Channel: ng-conf

Views: 35,660

Rating: 4.9430051 out of 5

Keywords: angular, angularjs, javascript, ngconf, ng-conf, programming, angular conference, ng conference, angular javascript, angular tutorial, javascript tutorial, programming tutorial, computer programming, google angular, google programming, ngconf 2019

Id: 5VlBaaXO6ok

Length: 20min 16sec (1216 seconds)

Published: Thu May 02 2019