Prefetch Strategies to Boost the Performance of Your Vue.JS App

Welcome everybody to my vue.js talk. My talk is called prefetching strategies and how to boost the performance of your vue.js app. So a little bit more information about me. My name is Aleksandr Gekuv. I'm an ICT and software engineering student. I have also been working as software developer at Axiom Biosystems. I have about three years of professional experience. Originally I'm from Sofia, Bulgaria, but currently I'm studying and working in Eindhoven. Recently I've also started creating content about vue. So you can check out my blog and my YouTube videos. And I'm also trying to be more active on Twitter, so you can say hi there as well. So today we'll be talking about performance. Why does performance matter? Web performance and the network. How does the browser work? optimization techniques. Some examples in vue. I'll shortly mention a cool library called guestjs. And then some final thoughts. And let's start with why performance matters. So people love fast websites. In today's fast-paced world where people have less and less great attention spans, it's really important that we as developers make our websites fast. One of the downsides is that slow websites frustrate users. And that may lead to users who are more likely to abandon these websites. And that can really hurt the business and also the seo as well, because when search engines see that a lot of people leave a website, then these websites rank lower on the search results. There are five fundamental user needs that we need to account for. So the perfect websites are usually functional, reliable, usable, pleasurable, and last but not least, performant. So a few studies in order to showcase why it's important. A famous research by Google proved that the probability of bounce increases 32% as page load time goes from one second to three seconds. So it directly impacts the end users whether they see the content fast or not. Another research is by the Pinterest team. So they found out that rebuilding Pinterest pages for performance resulted in a 40% decrease in wait time, a 15% increase in seo traffic, and a 15% increase in conversion rate to signup. So all this is very important. And if we need to give a definition to web performance, I would put it simply as making websites fast and responsive. If you need a more poetic answer to that question, I asked ChatGPT and it answered that web performance is the art of crafting a lightning-fast masterpiece where developers dance with code to create a symphony of speed that enchants and delights. So a crucial part of web performance is actually optimizing for the network because essentially websites are files and these files need to get somehow through the network to us. So a crucial aspect of web performance is minimizing this network latency and bandwidth because they play a significant role when talking about user experiments and website performance and responsiveness. We already do a lot to optimize the network. For example, we compress our images, we minify our JS, we bundle everything together, we perform code splitting, and we do lazy loading where possible. But we also do one more thing, and that's we anticipate. So we can anticipate what the user can do, and later on I will show you some tips on how we can actually improve performance by anticipation. But before that, we need to understand how the browser works. So browsers are single-threaded by nature, just as javascript, and that means that when they have tasks, they complete them sequentially, so they need to wait a task to finish until they start the next one. And when we open the browser and put in something in the URL at the top, the first thing that the browser needs to do, because it does not remember which domain relates to which IP address, it needs to ask the DNS server for that. So the DNS server basically acts as a map, so it has this data about which domain relates to which IP address. So we send those two requests and get an IP address back. The DNS server will also cache that, and for later use, we will also be able to use the cached version of that IP address so that it goes faster. But usually this process takes between 20 and 120 milliseconds, and it can be even slower on mobile networks. So that is the first step, and the next step is to actually have the TCP handshake, and if the website is secured, we also need to have the TLS negotiation. So the TCP handshake basically sends synchronized acknowledgements between the browser and the website, and basically what this means is that we have a lot more going back and forth requests until we actually can do something. So the total is that we make eight round trips, and at the least 300 milliseconds before we are actually ready to do any kind of HTTP request. So the first request is done after that, and you can imagine what happens when people have a slower connection or are on mobile. So there are multiple ways we can optimize this. One thing that is new is HTTP 2 multiplexing, which basically allows us to have multiple actions and tasks executed at once. Another thing is CDNs, content main distribution networks, which basically help move the servers closer to the end user. And the last thing is caching, and it's directly related to resource hints, and we'll have a look at it right now. So the browser usually does a good job estimating on its own which resources are high priority and are critical in order to render the current page, but there are ways we can influence the browser's decision making in order to improve the performance. So resource hints are basically hints and instructions in which we can prioritize resources that need to be fetched before or at earlier than the browser can actually see that it needs them. And we'll be looking over at DNS prefetch, preconnect, preload, and module preload, prefetching, and prerendering. So DNS prefetch, you can see that all of the resource hints are implemented by the link html element. One thing to mention is that they can also be specified in the headers, but that is not supported in every browser and is less used. So you can see on the example, basically as the name implies, with this one we tell, hey browser, can you please do the DNS lookup procedure as soon as possible so that when we actually go to that page, at least the first step is done and we know the IP address. Here is the browser support. It's pretty well supported. And moving on, we have the preconnect. So the preconnect is similar to the DNS prefetch, but it also includes in itself the TCP and TLS, TCP handshake and TLS negotiations. It saves time by eliminating the around trip latency when doing this TCP and TLC connections. One thing that we need to keep in mind is that we need to use it sparingly because as you can see in the milliseconds, it does take some time. So if we need something critical, then maybe we use preconnect for that, but for other stuff we can use DNS prefetch. We can also have a fallback. So if for whatever reason, preconnect doesn't work, we can also specify in the same attribute DNS prefetch, and then the browser will know if the preconnect doesn't work, it will default back to DNS prefetch, which is at least something and will help with the performance. So moving on, here is the browser support. And then we have the preload and module preload. So this is good for fetching late discovered resources needed for the current page view. And it's mainly used for fonts and images that are not coming from the document itself, but are coming from the css or javascript. And that's why the browser finds them only when it passes through the javascript or css, but that can be a little bit too late. So if we know that we will use this, we can use the preload or module preload accordingly to actually fetch it in advance. And as you see here, there is this as attribute, and that is also important because it specifies the type of the resource. The type of the resource can be many different things. So as I mentioned, most often fonts and images. And this is important because it influences the content security policy. So if we have some domain, we can specify that from this domain, we can expect only fonts or only a certain type of resource. And this can help with security. And here is the browser support for the preload. Next up, we have prefetching. Prefetching is different from the other resource hints as it does not try to fetch something crucial for the current page. It instead tries to fetch non-critical sources that may come in handy in the future when the user decides to navigate to that page. So here you can see basically we will load this next page css whenever the user goes to that page. And the browser automatically sets prefetching resources as low priority so that they don't influence the critical resources needed for the current page. One thing to mention before we move on, there are also different types of prefetching, let's say strategies. So it can be influenced by the user and it can be influenced also by whether the mouse stays at some point over, like near some link. And the browser can also fetch that specific link. And one use case of this is, for example, if we're in the login page, while the user is typing their password in email, we can use this time and bandwidth to actually prefetch the necessary resources for the page that comes after the login. And that way, once they click in the sign in, some of the resources will already be fetched and the experience will be faster. Here is the browser support as well. As far as I've seen, only Safari has some problems with prefetching, but otherwise it's pretty good. And next up we have pre-render, which is the most expensive type of resource in because it renders a whole page in the background. And if the user navigates to that page, it will be the fastest. But one caveat is that it can unnecessarily waste bandwidth and make actually the experience slower. So you need to be very careful with pre-render. Here is the browser support. And one thing that I want to mention, Chrome actually has this no state prefetch when we use pre-render in that browser, because in order to minimize the memory, they've made it so that an initial render is initialized to loop over the resources and sub-resources. And what it basically means is that when we use pre-render in Chrome, it actually acts more as a prefetch in order to save a bit of memory. And the typical way we use these resource hints is that we put them in a link tag in our head, in our index html or somewhere, but you may be asking what about vue? So vue CLI and vite have some sort of prefetching automatically for chunks that are code-splitted by them. But another way we can actually influence and do our own stuff is with a cool library I found, which is by UnifiedJS team, and it's called Unhead. It was made by Harlan Wilton. He's also a prominent vue open source contributor. And basically this lets us use a composable use head, which we can then later specify links, meta tags, and whatever else we want to have in our head tag. So we can just install it, and then I'll show you now how we can actually use it. So if we go into VS Code, here I have a simple vue application. And as you can see, I have like two pages, and here I've already installed it and I'm using head. So we can basically specify title and we can also specify links. So here I've already specified that we have a link to my blog that we want to prefetch. And if we go to the website, here you can see it. If I just refresh, and here you can see that it actually prefetches it and it has the lowest priority. That means that whenever, if there's a link to that page and we navigate to it, it will load faster. One way I can also show this is by going to elements and you can see here in the head, it has injected it correctly. So it's prefetched and then whatever resource that we have. So that's one way we can influence it. Going back, there is also another library that I wanted to mention, and that is GetJS. It was made by the angular team and essentially what we've been doing now is speculative prefetching. So based on our own intuition, we decide which resources to prefetch, but a better way would be to use predictive prefetching. And predictive prefetching is based on data. So it's data driven and we get that data from Google Analytics. So based on Google Analytics and the user's behavior when clicking links, the way it works is it makes a Markov chain and a Markov chain is basically simply a model which has the probability between going from one state to another. But what that means for the user is that based on the data that we have, we can actually conditionally prefetch whatever is most likely the user to go to. As far as I know, there is a next module for GetJS, but it also, I think it needs webpack. I'm not really sure and I haven't really gone that deep, but you can also do your own research and I would love to hear if you already have experience with this library and view. So final thoughts in conclusion, performance is a critical factor for the success of any web app and nowadays users have high expectations and they will not tolerate slow and sluggish applications. By using performance optimization techniques, minimizing the network latency and bandwidth and using these resource hints, so predictive prefetching, we can improve the perceived performance of our website and give the user what they need and also a better user experience. Thanks for listening. I'll be, I think, in Discord waiting for your questions. In the meanwhile, you can also find me on Twitter. You can check out my blog on dev.to and you can also follow me on YouTube for more videos about vue and frontend. Thank you. Bye bye.