(upbeat music) Okay, we got some pretty big gains on this page by making that online count component memoizable. And we're down to 125 milliseconds. And if we look at the profiler, you should notice that now 249 components are memoized, which is great. And if you zoom in on any slice of this page, you should see a tiny little purple dot that says online count.

you should see a tiny little purple dot that says online count. And that's how long it takes now to render online count. Pretty great. Okay, next lowest component on the page is the option component. It takes 77 milliseconds. And we wanna see if we can get that down a little lower. So here's the option component, but a million times, 49,000 times on a page.

So here's the option component, but a million times, 49,000 times on a page. And then it's source code over here. And you can see that it's a very straightforward component. So with a component, we're always asking ourselves, if it's in the hot path, if it's slow, we're always asking, can we fold it? That's what you ask first. Last time we asked ourselves that question with the online counter,

Last time we asked ourselves that question with the online counter, we said, can we fold this? Can we plaster this value statically in a compiled vop file? The answer was no, it had side effects. It was looking to something global like the database that's always changing, so we couldn't fold it. But we could memoize it. This one, let's ask ourselves that same question. Is this something that we can freeze in time

This one, let's ask ourselves that same question. Is this something that we can freeze in time given the same exact props and slots? If this thing is rendered three times, will it be the same? If it's rendered three times in three pages a week apart, will it be the same? Will the auth user change? Will the current request URL change the component? Will the error bag change the component?

Will the current request URL change the component? Will the error bag change the component? These are all the things you need to ask yourselves. The common culprits are, like I said, if you use something like @error, well, that's changing because that component might have different output if something is in the error bag. If you use something like @guest, any sort of auth type guards, those things could change and those invalidate it.

any sort of auth type guards, those things could change and those invalidate it. But this is a pure component. And I say that word, I think I just invented that term. It's like a pure function, if you're familiar with that concept. This is like a functional programming concept, but it's also a math concept. Or if you have a function like sum and you accept two props like this,

Or if you have a function like sum and you accept two props like this, or whatever you call them parameters, and then you return A plus B, right? This is a pure function, because you could call it, no matter how many times you call it, if they have the same exact inputs, they will always have the same output. That's a pure function. Where if it did this, but it also, like,

That's a pure function. Where if it did this, but it also, like, I don't know why it would do this, but if it also added something from the database or something, that's a side effect. That's not a pure function. That's dependent on the environment. So this component is a pure component. It's simply taking in inputs and it is spitting out an output. Therefore, it is foldable.

It's simply taking in inputs and it is spitting out an output. Therefore, it is foldable. We can say, fold true. That's it. That's the question you need to ask yourselves. If you want something to be foldable, if you want to make something foldable, is it a pure component? Can it be rendered in every environment and spit out the same output?

Can it be rendered in every environment and spit out the same output? Okay, I'm beating the dead horse here. Let's clear the view cache, refresh the page and see if it worked. And it did. It took 49,000 option components, brought it down to 15 milliseconds. Now the page renders twice as fast with 62 milliseconds. If we open the profiler,

Now the page renders twice as fast with 62 milliseconds. If we open the profiler, we now see that we have a bunch of components folded. If we look at this folded, and there it is, 49,000 components folded, 5,000 still optimized in the functional compiler, 249 memoized. That's pretty good. Great. The story with folding,

Great. The story with folding, I wish it were that simple. I wish you could just wipe your hands and walk away by adding fold true, but there are plenty of times where Blaze is unable to actually fold the component, even though you marked it as fold true. And we'll talk about how you can get around those barriers. So we'll see you there.

And we'll talk about how you can get around those barriers. So we'll see you there.