More effective - Viewport prefetching

[HenrijsS]

What I noticed instantly in Sveltekit compared to Next.js is that the initial page-load whilst navigating is faster on next.js due to one thing: Viewport prefetching.

Next.js does not only prefetch on hover but when the actual button to the link is visible in the current viewport.
I don't know if it's possible to implement this in Sveltekit, but it sure makes the navigation seem and feel 100x quicker.

Don't get me wrong, the performance is still unbelievable, but page navigation doesn't feel as snappy as it could be.

One other thing could be that the viewport prefetching only works when the output is static (As I'm only currently testing it for static sites), but that doesn't mean it couldn't be achievable for SSR.

The idea:
Upon freeing the overall network request (window load), fire off requests for subsequent page content currently available in the viewport.
And after navigation is completed to another page and the main thread is freed up - Then load the content for then visible pages in the viewport.
To get the available links, just attach an observer to all visible <a> tags.

This method improves the snappiness of the page thousandfold.

To sum it all up, here's the information from the official Next.js docs:
https://nextjs.org/docs/api-reference/next/link
Adding a prefetch prop to their custom <Link> component does the following:

`prefetch` - Prefetch the page in the background. Defaults to true. 
Any <Link /> that is in the viewport (initially or through scroll) will be preloaded. 
Prefetch can be disabled by passing prefetch={false}. When prefetch is set to false, prefetching will still occur on hover. 
Pages using Static Generation will preload JSON files with the data for faster page transitions. Prefetching is only enabled in production.

This should replace the current sveltekit:prefetch that's available for <a> tags.
Or if the observer has some sort of performance penalty, then maybe add another option like sveltekit:viewprefetch.

Note: I initially noticed this in svelte.dev and kit.svelte.dev
Everyone's providing the benchmarks for the speed of Svelte, but I believe that this feature is the most slept on.

[HenrijsS]

Looking up the announcement of prefetching for Nuxt.js in a blog post, it seems like they were inspired by Google's quicklink library..

[bluwy]

One issue with this is that we don't know when the data is stale. If it appears in the viewport, and we only click it after 5 seconds, during that time the data could be outdated and we'd need to re-prefetch again. I'm not sure how next handles this, maybe through some option to estimate the stale timeout, or a stale-while-revalidate mechanism. But for sveltekit, I think keeping it simple through anchor hovers is the best way (for now).

[bluwy]

That makes sense. If the target page has const prerender = true, then we could automatically prefetch when it enters the viewport. I'm not so sure if we should give the user a choice of sveltekit:viewprefetch though, what would be the behaviour if they use sveltekit:viewprefetch on a non-prerendered page.

---

Tangentially related, I think naming it as sveltekit:prefetch="viewport" or sveltekit:prefetch="eager" would read nicer. The default behaviour would be hover/lazy.

[HenrijsS]

This seems to be the best case scenario.

And I mean you could apply the prefetch to dynamic pages, just know that your data could become stale.
That's why it's a choice and there's an option to prerender.

[HenrijsS]

@bluwy Just wanted to bounce back and ask if this is somewhat in consideration yet?

[bluwy]

I've brought this discussion up in the last maintainer's meeting. We were generally onboard with multiple prefetching strategies. And could possibly configure it in some ways. Implementation-wise may be tricky since unlike Next.js that uses a Link component, we work on normal anchor tags.

I'll go ahead and make a new issue for this so we can keep track of it, and shed some light on some of the discussion we had.

[bluwy]

Made a new issue: #3633