Improve Velo Page Performance with Manual Caching

Show and tell
,
1

Caching helps to significantly speed up a page’s loading time.

Most pages on Wix Sites are cached automatically. However, pages with Velo code or dynamic content may be excluded from automatic caching. In these cases, you can enable caching manually to get the benefits of faster loading times.

We’ve recently published an article which explains in detail about caching in Velo.

We highly recommend reading it in case you have Velo code in your Wix website as this is something you should be aware of.

And please share with us any inputs you might have about this topic or about the article specifically in the comments section below.

Thanks!

7 Likes
2

I’d like to add these 2 things from experience in the situation where it is NOT possible to cache a page (because it has lots of data retrieval) to speed up execution:

  1. avoid 14 seconds time outs. If you do this from the front end:
$w.onReady( async function () {
	await doAllWork(param1, param2);
});

and on the backend:

export async function doAllwork (p1, p2){
	const res1 = await step1(p1, p2);
	const res2 = await step2(res1);
	const res3 = await step3(res2);
	return res3;
}

then the await doAllwork() from the front end will only get 14 seconds to perform all 3 steps.

But, if you do this:

$w.onReady( async function () {
	const res1 = await step1(p1, p2);
	const res2 = await step2(res1);
	const res3 = await step3(res2);
	//do something with res3
});

you will get 14 secs per call, thus 42 in total max.
Now, this might introduce a level of insecurity: you want to do all data access in the backend so you don’t have to return (too revealing) data to the frontend. There are several ways around it, but one is storing results in a temp-collection and return only an _id to the frontend, which is then picked up and sent back to the next step, where intermediate data is retrieved.

  1. warmup system, the poor man’s version
    When you do heavy backend queries using wix-data, a lot of time on a cold load is spent on a)generating the db-token b) spinning up the container. To avoid this warmup time and start with a “warm load”, use a dummy query outside (above) the $w.onReady(). This one gets executed before the callback and good chance it returns its result (nothing) before/during page load. But, if your program then lets make people do a real query, both db-token and container are ready (for 5 minutes) and the query will perform much faster.
    To check if this might work for you: refresh your page and use it as a normal user would do (doing that query). When it returns a result, do it again, maybe even with different input. If the second result returns faster than the first, you will benefit from the above solution: you just re-used the db-token and the container was already spinning.