Prefetching Page to Boost Load Times in InertiaJS 2

In This Lesson

We'll take a look at the new prefetching feature in InertiaJS 2. We can use this feature to load the next page's data before the user even clicks on the link.

Created by: @tomgobich
Published: 1 year ago

Join the Discussion 0 comments

Be the first to comment!

Transcript

Another new feature that enters with Inertia 2.0 is prefetching. Prefetching allows us to improve the speed perceived
by the user when visiting brand new pages inside of our application. We add on a prefetch prop to the Inertia link component,
and then Inertia will then prefetch the page's data prior to the user actually performing the click operation on the link itself. For example, inside of our application,
a place that we may want to use this is within our main navigation, between our courses, difficulty statuses, and access levels. If a user hovers over one of these links,
chances are they're destined to end up clicking on it, traversing to that page. By adding the prefetch prop onto these links, whenever we hover over it for more than 75 milliseconds,
Inertia will send out a prefetch request for that page's data, cache it on our browser by default for up to 30 seconds, and then if the user clicks on that link
within that 30 second time span, it will use that prefetch data for the page itself. And all of this is configurable to our liking as well. So over here on the left-hand side,
we have our navigation component open, and we are looking at our desktop navigation links. In order to add prefetching onto these,
all that we need to do is add the prefetch prop, and Inertia will now prefetch our course page data whenever we hover over our courses link inside of our navigation.
Let's go ahead and add this to the other three links that we have here as well. So prefetch there, go down to our statuses, we'll add it there, and then let's also add it to our access levels as well.
Okay, let's give this a save, jump back over into our browser. Let's go ahead and right-click on our page, inspect, and dive into our network tab. We really only care about XHR requests,
so we can get filters specifically to those. All right, let's go ahead and refresh our page to make sure that we have that change. And now let's go over to one of our navigation links and hover over it.
You see a request go out almost immediately, 75 milliseconds is not a lot of time, so it's gonna seem almost instantaneous, but it's still quick enough to kind of miss going over navigation items like that,
where you're clearly going for something else. So what this request did is it went out and got our pages information. So we hovered over our access levels,
and you can see that this looks the exact same as though we had already clicked on the link. It just hasn't actually taken us to this new page yet. So Inertia got all of the pages data
and it stored it in memory for by default, 30 seconds. So by now it's now stale and will not be used if we actually go back and click the page.
In fact, if we go back up to that link, you'll see another request go out. And now if we click on the link, you'll see that the only request that happened is we got a two for that fetch request
that we added to our app layout a couple of lessons ago. Whenever we actually visited the page, Inertia used that prefetch link that was still cached inside of our browser.
So it used all of this prefetched response data for the page whenever we actually went back and clicked on its link. Let's go ahead and clear all of our requests back out. And let's take a look at that one more time.
So if we now hover over our statuses link, click on it, we're now at our statuses page, but it only made that prefetched status request. Same thing here for our courses.
If we hover over it, click on it, you'll see only that prefetched request ends up occurring. Improving the perceived speed traversing from our statuses over to our courses page or to our difficulties
or access levels pages, because our user no longer has to wait for that fetched information to return. Inertia has already prefetched it on our behalf. Now, as I said, most of this is gonna be pretty configurable.
So if we wanted to change how long the duration that Inertia will cache the prefetched request for, we can do that by adding in a hash or prop on the link
and specify a time. So if we wanted to do five seconds, we can do 5,000 milliseconds as a number value, but this also supports the human readable versions as well.
So you could also do 5s for five seconds and pass that through as a string. So if we give that a save now and we go back over into our browser, I'm gonna go ahead and refresh here.
And we're currently on our courses page. So hovering over, it's not gonna do anything. Let's go over to our difficulties page. And now if we hover over our courses, wait one, two, three, four, five,
go ahead and now click on it. You'll see it fetched brand new fresh information for the page whenever we actually clicked on it because Inertia is only caching this page's information for five seconds.
Anything beyond that five second range, it will consider that information stale. It won't use it and it will instead fetch brand new information for the page for the user's visit.
You can also change when Inertia will actually prefetch the information as well. As we said earlier, by default, it's whenever the user hovers over a link for more than 75 milliseconds.
But we could also switch this to whenever the user actually mouses down on the link itself by setting the prefetch value to click. Now there's a difference between click and actual mouse down.
Mouse down will happen immediately whenever we press the mouse pointer down on a link. Currently, I haven't actually let the link up. I'm still holding down on it. Now I've let the link up
and we've actually traversed over to the page. So an actual click won't happen until the user lets their mouse up as that's when the click event is fired. Mouse down happens immediately
whenever the user puts their mouse pointer down on a link and then the click event fires whenever they let that mouse down up. So the mouse down event's going to be great
if you still want to prefetch information but you're not confident that the user's actually going to traverse through to that page. If you are, however, super confident that a user's going to traverse through to a page,
you can instead set the prefetch to mount to prefetch this link's information when the current page is actually mounted.
So if we give this page a refresh, this page is now mounted, but we've already prefetched information for the status's page. So now if we visit the status's page,
you'll see no additional requests goes out and we're able to traverse straight over to the status's page because the information for this was fetched whenever we mounted the actual difficulties page.
And you can combine these two strategies as well by providing them as an array of strings with click and mount as the values
to both prefetch the information when the component is mounted in conjunction with when the link is moused down on and Inertia will use its cache to decipher
which of those two needs to apply. So that I don't have to wait 30 seconds to show this, let's set the cache four to five seconds for this one here as well. Give that a save, jump back into our browser, refresh.
You'll see that we immediately prefetched our difficulties information, but we've now waited more than five seconds. So if we go back up to this mouse down,
I'm still holding, we haven't actually gone to the page yet. It's done another prefetch because the mounted information was invalidated and stale. So it got fresh information on that mouse down event.
And then the mouse down event, I held for more than five seconds. So it invalidated itself there and got brand new fresh information on the actual click event.
So you can see the cascade going on there is still ensuring that the user's going to get fresh information, depending on how long you set the cache duration for on the link itself.
And then there's programmatic access for all of this as well. We can go ahead and import Inertia's router from Inertia View 3. And there is a new prefetch method that we can call off of this.
The first two arguments that we pass into this method are going to be the exact same as the visit method. So the first one's going to be the href for the page that we want to prefetch.
So we could do something like our access levels page here. And then the second is going to be the options or the request itself. And one thing that prefetch requires
is that we set the method to get, as well as all of the other arguments that that visit method accepts it. And then the third one is going to be the prefetch specific options,
which is just the duration to cache the prefetch for. So we could set that something like five seconds here, the same as we did inside of our link component. Okay, let's go ahead and break this down
onto new lines to clean it up a little bit. Now, one thing to be cognizant of with this is we are using server-side rendering. Since we're using server-side rendering and we don't have this presently wrapped
in something that will limit it to just running on the client side, it's going to attempt to send out on our server. So for example, if we give this a save, nope, just redid my formatting,
and we go back over into our browser and refresh to get the server-side rendering, we're going to get an invalid URL due to this prefetch trying to go out. So what we need to do is wrap this in something
like a click event or any other events, or we could also perform this action when our component is mounted, which is a Vue.js lifecycle hook. So if we give that a save there,
now this will behave the exact same as our mounted request for our statuses page. So if we refresh, we now see that both our statuses and our access levels are prefetched
when the component for the page is mounted. Now, there is also a use prefetch composable that we could use, but the options for this,
I think are currently bugged, as there's no way to actually specify what the href that we want to prefetch is. You'll see that I get squigglies here for the second two arguments. This is exactly how they have it currently
in the documentation, but if we command click into it, take a look at the one option set that it accepts. We have visit callbacks, which are the callback handlers.
So on cancel, on before, on start, so on and so forth. But then we also have the visit, and the visit has no way to specify an href.
So note that this is an option, but I don't think it currently works. But what this would do is give us some additional ways
to get information about what was prefetched and when. So we get back when it was last updated, whether or not it is prefetching, whether or not it is prefetched,
and then a way to manually flush the cache there as well. So we'll go back to our router prefetch there, and off of the router, there is also a flush method directly,
as well as you saw there a flush all, which we can use to flush specific cache pages. So if we wanted to flush our access levels, we could do that like so, and then specify the method there as get.
And now this will flush the prefetched cache for that specific page. And in this case, it will essentially invalidate our prefetch immediately, since they happen back to back.
Lastly, I'm gonna go ahead and get rid of that flush there as it invalidates the prefetch altogether. There is stale while revalidating. So if we come back down to our links,
we can pass an array into our cache for consisting of two times. So we can keep our five seconds,
but then also pass in something like one minute. So the time here that we have at our zero index of our array is when the prefetched information will be considered stale.
We know that when we only specify one time into the cache for after it's considered stale, Inertia will not use the information and it will instead fetch fresh information when the page is actually visited.
Whenever we pass in two as an array, the second time that we pass in at the first index of the array is how long Inertia is allowed to use
that stale information for. So our prefetched information here will be considered stale after five seconds, but that stale information can be used for up to a minute with how we presently have the set.
So let's save, refresh to have all of that apply. If we hover over our courses, it's now been prefetched. And if we wait five seconds, but still under a minute,
go ahead and visit that page. You'll see that even though this information has been considered stale, it was still used whenever we actually visited our courses page.
And then had we waited longer than a minute, Inertia would have fetched brand new fresh information as our stale data would then be expired after that one minute time mark.
So a lot going on there and at your disposal to improve the perceived speed for your users of your site using prefetching.

Building with AdonisJS & Inertia

91 Lessons

14h 3m

Getting Started

The Basics

Working with Forms

Database & Project Scaffolding

Authentication & Onboarding

The User's Organizations

Difficulties, Statuses, & Access Levels

Courses

Modules & Lessons

Settings

Organization Members

Authorization

InertiaJS 2

Stop losing your best ideas!

Use our integrated note feature to capture and organize your key insights. Take a note at any timestamp and jump instantly back to that moment in the video with a single click.