Maybe separate load function into separate static and server functions?

[thesyedbasim]

We have a load function which runs live, in a server, or at build time.

But what if I need to run a function only at build time?

The solution is to use adapter static...

But apparently this will make the whole site static.

But what if I need some pages to be prerendered and some to be run on each request by the server?

Maybe there is already a solution for this, but I am not aware of it.

Another way which is more reasonable is to provide static, and server as separate functions (like getStaticProps() and getServerSideProps() in nextjs) instead of a single load function.

I initially thought to open an issue but considering this problem might already have a solution, I am starting a discussion.

Thank you in advance

[benmccann]

If you want to only prerender some pages, you need to use a different adapter than adapter-static. You will need to choose what host will be rendering the non-prerendered pages. You can can then prerender a single page with export const prerender = true: https://kit.svelte.dev/docs/page-options#prerender

[RykGitProjects]

I wanted to create separate topic, but probaby this is what I am also looking for:

My project has a page: /product/[slug]

Information about product (name, description, graphic url) are stored in database (Supabase)
My page shows information about product. Currently using +page.server.js
I found out, that I am waisting a lot of time (~300 ms) to retrieve page document (first row in browser Network)

Moving all data code into +page.svelte script tag makes it MUCH faster. Document load takes only ~50 ms ! It is great!

However this way prefetch does not work, so when user hovers over my product it does not gather data from Supabase to display next page much faster

The question is how to make prefetch work, when I retrieve data in +page.svelte script tag ?

Tried using prerender. However build for 2000 urls' took 50 minutes, so it's not an option.

Kind regards,
Richard

[infovore]

Honestly: I think the solution here is improving the database query efficiency, because that's a slow turnaround for a single item, and it's forcing you into suboptimal solutions (querying onMount) which stop you being able to prefetch efficiently. Here's the issue:

• if I've understood the docs correctly, prefetch will prefetch both the markup/components for the page, and any data returned by a page endpoint.
• By moving your Supabase query into the in-page code, the code will be prefetched, but the data query won't, because you've got it running onMount. Very quick, but missing page data.
• meanwhile, because the data is no longer returned from the page endpoint, it can't be prefetched.
• 50 minutes to build 2000 urls is incredibly slow, and a sign that the query to generate a page is slow/inefficient - or, alternatively, that the latency to Supabase is very, very high.

Alternatives include caching/memoizing the data returned from Supabase, perhaps using a store, so you're not making those queries on every page, because prerendering+prefetch is probably the fastest way to speed this up. (Eg: do a "select all" to load everything into a store, then filter that store by id on the individual pages, pushing your latency into a single initial store-population query and just doing everything in memory whilst you build the site).

[RykGitProjects]

Thank you for your answer!

My next point is working on Supabase, maybe I still lack something. I already created indexes. So not sure how to speed it up here. Will work on it.

Regarding onMount - why do I need to get data in onMount, and not in <script> itself adding $: for the promise(url), so it will recall it every time url changes. This way it will be faster than onMount, as it will not wait for DOM

Regarding prefeth I found half solution to that which is adding rel="prerender" to all a tags. It does not always work. If I hover over first link to a folder (/product/1) it will prerender a page, however if I hover over another link (/product/2) it will not prerender it. Interesting that rel="prerender" makes browser to not only get all info from next page but also renders it in "hidden tab"

Regarding SvelteKit/Vercel prerender - You are probably right, that 50 minutes for 2000 ulrs is too long. What would be normal time? Still probably not a solution for me as I have too many urls

From theoretilac point of view I do not fully understand why "+page.js" works as it does. Shouldn't there be "+page.noserver.js" file type for loading data only which would:

• be only on front
• run when URL changes
• download data asynchroniously with page loading and start as soon as possible

In such case there would not be waste of time waiting for document, as is currently with "+page.server.js" or "+page.js"

Because even if I can improve Supabase connection and decrease it from 300 ms to 80 ms it it still ~30 ms wasted (tested it and without "+page.server.js" getting document takes ~50ms). So I do not understand why there is no faster way to connect to database. By faster I mean to start connection simultaniously with loading page itself. Btw. everything which I am talking in here is very first connection to page. And it is how:

• most user visits page from SEO
• google bot visits page
  So it seems crucial to decrease first visit time, not only user experience when he/she is exploring a site and you are able to make prefech

[infovore]

Ignore my red herring with onMount, I had misunderstood how you were loading data.

I can't speak to the design of SvelteKit because I'm only an end user, but: +page.js is specifically designed to run once, before the route loads; it is the 'prerequisite' for the page. If you want to load something asynchronously, surely you could just do that from inside +page.svelte, just fire it off when the page component mounts - and it'll be ready whenever. But, again, that data won't be prerenderable, because data only is pulled in on component mount. I also think this is a particularly fiddly architecture - 'load data alongside the rest of the page, and the page must handle data-present as well as data-absent states'; it prevents you from just returning a nice 404 for something that isn't found - every page 200 OKs to load the front-end, and then says 'nothing found' if it's a bad lookup.

As for "what's a better compile time" - well, all comes down to what's acceptable to you; I just think that 2000 pages in 50 minutes doesn't meet my definition of 'acceptable build time'. My site with about 3500 prerendered urls is about 4mins build time, which I find acceptable. (I was, originally, pre-rendering all 12000 pages, but owing to inefficiencies, that was pushing build time to about 17-18 minutes. So I just made the long-tail of the site server-rendered, as those pages were unlikely to be hit much).

I can't speak to Supabase, I don't know it well, but I think bending your front-end architecture in weird direction to work around db performance issues smells all kind of funny, and fixing things in the right places is probably the way to go - otherwise this will trip you up again, later, further down the line.

[RykGitProjects]

Thanks for all your answers!
I think I know what to do:
1)Work on Supabase

2)Try to just download data in onMount for example like this: https://www.sitepoint.com/svelte-fetch-data/ or this: https://languageimperfect.com/2021/02/17/data-fetching-in-svelte.html
OR
3)Create a promise in standard <script> and in onMount creating function to run after promise is resolved <- Not sure about it thou

Thanks for all your answers! I think with onMount my page will be faster by ~300 ms which is great!

[infovore]

I think with onMount your page will initially load quicker, but you will still be waiting 300ms for your data to arrive. Remember, you can't just remove latency; it can only be moved somewhere else. In this case, you'd rather the user saw an empty or unpopulated page with a spinner faster, but wait for the content. Some people think that's a better option; I think it's a poor user experience, not to mention a poor HTTP experience.