![Web App Performance](https://static.frontendmasters.com/assets/courses/2023-07-30-web-app-performance/thumb.webp)
Check out a free preview of the full Web App Performance course
The "Fetch Priority" Lesson is part of the full, Web App Performance course featured in this preview video. Here's what you'd learn in this lesson:
Max introduces the fetchpriority attribute and explains how it signals high or low-priority image fetches. This can be useful when applied to <img> elements to signal images that are "important" to the user experience early in the loading process.
Transcript from the "Fetch Priority" Lesson
[00:00:00]
>> For each priority. Now, what if we make a change in our go? What if we finally convince our manager that we have to change our architecture. So this idea that the HTML needs to wait for a JavaScript to download the JSON to parse the JSON to actually know what's in the first at least in the LCP.
[00:00:29]
So we convince the manager, that's a bad idea. So the best idea which is making a server side render, somehow, next say yes or something like that. Just a few minutes ago, I saw a tweet from Guillermo Rauch. We can even look at that tweet so you can see it.
[00:00:50]
So we're from some minutes ago. He's the CEO of Vercel. He's the creator of Next.js, and Vercel. And he tweeted about, where is it? Should be here. This one. The biggest product of the past 20 years, ChatGPT, is a website built with Next.js, which is saying that the biggest, the largest, like ChatGPT is using Next.js.
[00:01:17]
And what's Next.js? It's a library to use react components, but server side, no clients side. And typically that leads to performance, okay? And so the idea here is that, well, ChatGPT so fast because it's based on Next.js. So it's not client based JavaScript. It's server based JavaScript. So if you like React, it's okay, but maybe making those React components being rendered only client side, it's not really the best of the ideas.
[00:01:50]
>> Just one thing I didn't really fully understand with that was because with React, it would be just re-rendering a specific DOM section. But then with Next.js, it's like re-rendering the whole page, right?
>> Not really. So Next.js is not re-rendering all the time the same page. So it's a mix, it's hybrid technology.
[00:02:09]
So even it has several names. So sometimes it's not just like classic server-side with PHP or ASP classic. So it starts from the server, but then it can continue client-side. So it's not completely server-side, so it's a mix. The idea of the first rendering should be server-side. It's actually the best idea for performance, why?
[00:02:36]
Because if not, we have the problem here. Our content, we just see a logo. What do we have in our HTML? A logo, that's all, and an empty main element. For rendering the content, we need to wait for JavaScript to download, execute it. And in our case, that JavaScript was also going to a JSON file.
[00:02:55]
So then we have a sequence of downloads that cannot be done in parallel. Yeah, I could add a preload also to the JSON. So then we also download the JSON. So when JavaScript needs the JSON, it's already there. But the best idea here is that maybe what we need is at least for the first item.
[00:03:18]
I can just for now, I can do this really quickly. I can take the article, right click, and I can copy this as HTML. Copy the element of the outer HTML. So and somehow, let's say server side with a build process. We just paste the article. So if we do that, then this is going to be as fast as possible because yeah, we don't need to wait for JavaScript.
[00:03:42]
We don't need to wait for the JSON to appear. Now we will have that twice. We should skip it in the JSON, but and now look at this. Now that we have the image here, maybe the preload is not necessary because we don't need to actually discover it.
[00:04:00]
It's going to be discovered automatically. So I can get rid of that now. However, wait a minute. So if I run this now. It looks better. Yeah, I have two Ancient Greek, I should remove the second one. But I'm not sure if you realize that it's getting kind of a little better, okay?
[00:04:20]
The LCP, it's getting a little better. But when we go back to the network and try to find the image here, the Ancient Greece, that one. Now, it's not, actually it has two for some reason. This is the other one, okay? Although I think that was the preload because I didn't reload.
[00:04:46]
This is the one from the script is still here. So we still have a gap there. So what is that? Remember that when I started showing you this, I right click on the columns. And from here, there are a lot of columns that we can add. And I can add Priority.
[00:05:09]
With priority, you can see the priority of some resources based on the type. This priority was set by the browser. And we have highest, high, low. For example, the script.js is low. And now when you think about this, no, I don't think it's low. So I'm the author of the website.
[00:05:33]
I think it's important because that's the one that is rendering the content. So no, why low? Well, other images are also giving, having a low priority. Well, there is a new aspect now, fetch priority, where you can override the default priority. And you can use it on rel preload and also directly over images.
[00:06:00]
So for example, that means that for our LCP image, the one that we know, that is the most important one. I can change the fetch priority. So I can go to this img. And I can search, say, fetch priority high. So now I don't rely on browser's algorithm.
[00:06:25]
I say no, no browser, this is high priority. Next question is what happens if I add high priority on every resource? Well, again, if everything is important, nothing is important, so don't do that. Be smart, and pick the ones that you prefer, that you need. Does it make sense?
[00:06:47]
And this will improve a lot LCP, mostly when it's image-based. So remember, 75% of LCPs are actually image based, not text based. For example, I could change also fetch priority on the preload. If I feel that that font is important, I can also change the fetch priority and say high.
[00:07:07]
And if I see that my browser is setting high on something that I don't think is important. For example, aristotle, I can add low. So I can change the default priority. But I can help the browser make a right decision to improve the user experience based on my content on how my content looks like.
[00:07:33]
Does it makes sense? Have in mind that fetch priority was called Priority hints before. In fact, all my previous workshops and talks on web performance, I call that Priority hints. So now it's called fetch priority. So when the standard specs discuss the idea, they changed the name and also they changed the name of the property.
[00:07:55]
Okay, before it was called importance, importance equals low or high. Well, now it's fetch priority.
Learn Straight from the Experts Who Shape the Modern Web
- In-depth Courses
- Industry Leading Experts
- Learning Paths
- Live Interactive Workshops