Why Your Load Functions are Slow

in this video I'm going to demonstrate how you can improve the performance of your load functions in spell kit so this is what your typical load function might look like you may be waiting for multiple different promises to resolve your fetching data from various sources and everything seems normal but is there a better way that we can do this well I'll tell you with this example right now there absolutely is so first things first what I want to do is I want to actually demonstrate that this is in fact more performant so what we're going to do we're going to measure the amount of time that it takes our page to load and we can do that on the server side by simply going into our hooks here and if you recall if you're familiar with the handle hook this is what's responsible for generating the response back to the client so we can do is we can set up a console.time and we'll say handle and then we'll do a console.time end and this will just console log how long this takes to run so let's go ahead and save and it should run and we can see that it took 3.017 seconds right and that makes sense because we have one second one second one second three seconds total and if we wanted to break this down a bit further we could say starting a and we could do that so we can see that we're starting a starting B starting C and then our load function is done and the page is available to our user so here's the page that I'm on at the moment so if I refresh this page you're going to see that it's going to be spinning there for quite some time right now obviously this is a bit dramatic and I hope that your requests aren't taking a second or more to complete but this is just an example and a way to visualize this so a better way to do this is with promise unwrapping and if we look at the soil kit documentation it says that top level promises will be awaited which makes it easy to return multiple promises without creating a waterfall and again the emphasis on top level promises so if we look here this is the object that we're returning from our load function promise.resolve is what I'm going to demonstrate here in just a second but you can see that they have this C property here with a value and a promise here when it gets to that page that promise is not resolved yet it's still in the form of a promise however A and B are so that's something important think about when you're setting up your return data structure so let's go back into our application and let's refactor this a bit so instead of doing this here I'm going to actually turn this into a function an asynchronous function and I'm going to return await set timeout and then I'll just move console log starting a here and then I'm going to do the same thing for the rest of these and when I save this page you're going to see that we're getting some errors now in our console it says data return from load while rendering is not serializable so what we have to do is we actually have to return this as a promise and we can accomplish that by just calling these different functions here so we look here this returns a promise so now when we do that and we save the page if I scroll down we can see that the handle took 1.017 seconds so even though we still have three different one second timers here it only takes one second and if I bump one of these up to two seconds we see that it takes two seconds so the weakest link is how long it should really take is going to impact your performance the most but we can see that even though this one takes two seconds all of them start at the same time so as soon as I save this page it's going to reload my auto refresh browser page here which is going to call this load function so if I save this again you're going to see starting a starting B and starting C start at the exact same time and I can also demonstrate that by just throwing a date dot now in here foreign we can see that we had starting a starting B and starting C almost all at the same time right of course this is like a one trillionth of a second off or whatever this number is but you can see that they all start at about the same time and it only takes until the weakest link for the page to resolve all the way and the same thing would apply for a layout as well so if we just move this down for a second I'm going to copy all of this and I'm going to create a plus layout.server.ts I need to change this to a layout server load and we'll need to change these as well so we'll just make this D E and F okay so I just save that and we can see here in our console because the page reloaded and this is the layout all of these have the exact same start time right and even though there are six functions or six promises being resolved the maximum time it's going to take is whatever the slowest one is so if this one is three thousand SEC or three thousand milliseconds they all start at the exact same time but the page isn't finished rendering until the slowest one is done now obviously this is an ideal situation and let's just say that you needed something from D before you could even start ease request well even still you should wrap this in a function so instead of you know doing this here we could just say let's just move D down here we'll just say oh wait set timeout for D here and then we can get rid of D and then we need to obviously remove this from our return statement and when I save it now Let me refresh the page we'll see that we had d f a b c and then we had e of course because it was waiting within the same function so this was blocking this from running and the total time was four seconds because this one single call here took a total of four seconds if this was bumped down to one then the total time would be two seconds now the same concept applies to the plus page.ts as well so if I just comment all of this out and then I'm also going to comment this out as well and then I'm going to remove the timer on my hook here because we're going to visualize this another way what we can do is we can just say await Fetch and I'm just going to get gonna hit a dummy endpoint here and then if I open up my browsers Network tab let me zoom in a bit so you can see this when I hover over child page is where that page.ts is it's going to go ahead and pre-fetch the data required for that page so when I hover over it here you're going to see that I made two fetch requests right and they were done in a waterfall fashion right so they weren't made at the same time you can see that this one had to wait for this one to finish so the total time was these two summed together so if I go here go back again clear this out and then hover you're going to see it a little bit more distinctively there it took 90 milliseconds to run to the page each request taking about 40 some milliseconds and then if we come back to our load function here and we do the same thing except we wrap these in a function then I come into my browser again when I hover over a child page you're going to see that now they're both running at the exact same time so the total time to render the page wasn't the sum of these two requests it was the greater of these two requests what everyone took the longest so that's going to include this video on improving the performance of your load functions in Smoke kit if you got value out of this video don't forget to like And subscribe it greatly helps the channel out a lot and I will see you all in the next video [Music] foreign

Channel: Huntabyte

Views: 17,676

Keywords: sveltekit, sveltekit tutorial, sveltekit crash course, sveltekit form actions, sveltekit forms, sveltekit actions, form actions sveltekit, api route svelte, svelte routes, layouts, advanced layout sveltekit, sveltekit icons, sveltekit extensions, sveltekit productivity, svelte search, svelte react, svelte searchbar, svelte filtering, svelte stores, how to add search to svelte, search data svelte, svelte data search

Id: Ymk22rD8Lb4

Length: 8min 24sec (504 seconds)

Published: Fri Jan 13 2023