Implement client side preloading for imports

[Kingdutch]

Follow-up to #86

[zth]

Ok, a brain dump of what I think about client side preloading of imports.

My qualms with shipping a regular manifest to the client:

• The manifest file grows for each route added in the app. In medium to larger apps, that size is probably going to be non-negligible. I have an app with ~70 routes (and growing). We can benchmark how large the file gets for that and see if it's acceptable.
• Any change to a route will invalidate the entire manifest. Even any change to any file will invalidate the manifest because hashes will change etc.
• If we do "deferred sub trees", we'll need potentially complicated logic for splitting and loading the corresponding parts of the manifest deferred as well, or we loose a lot of the benefit from doing deferred sub trees all together.

Things we can do/explore instead:

Bake the manifest into the already generated RouteDeclarations.res

It'd mean that each route also gets its part of the manifest inlined. This would be good because:

• RouteDeclarations will also always be invalidated on every change, so invalidation doesn't matter for that sake.
• Deferred sub trees and code splitting those things will automatically work, because it'll be baked in to the very thing we code split.

Dedicated server endpoint that returns what to preload

In an edge-world, this might be efficient and fast enough. Essentially, ask the server what assets to preload for url X. Haven't thought too much about this, but maybe it could be an alternative. Doesn't work for CSR only though.

There, a brain dump. Eagerly awaiting your comments 😄 .

[Kingdutch]

Good brain dump! I don't want to discount the standalone manifest directly for its simplicity.

I have an app with ~70 routes (and growing). We can benchmark how large the file gets for that and see if it's acceptable.

If you have the ability to run the transform on your manifest.json and see how much comes out then this would be good info to have. Especially since I don't think our manifest scales linearly with routes. Instead it scales with JavaScript bundles and assets.

Any change to a route will invalidate the entire manifest. Even any change to any file will invalidate the manifest because hashes will change etc.

While I do think it highlights a flaw in our current naming scheme (since we can't easily cache-invalidate the current manifest because it has no hash), I don't think this is a problem persé. On high volume sites the amount of times the manifest is downloaded would still be negligible even if redeploys happen multiple times a day.

If we do "deferred sub trees", we'll need potentially complicated logic for splitting and loading the corresponding parts of the manifest deferred as well, or we loose a lot of the benefit from doing deferred sub trees all together.

I'm not sure this reasoning is correct? It's true that we ship some metadata to the router about the entire application that we don't split up. However, the manifest itself is based on chunks, so we still only actually load files when we start loading a deferred subtree (and then know exactly what we load).

Bake the manifest into the already generated RouteDeclarations.res

While I think it's interesting to more closely couple what we load to where we're going, I do see some challenges:

1. That means that dynamic loading only ever works for route related things. The current system will work for anything. Even if some in-page optional widget decides it performs a dynamic import. I think that's a very powerful feature
2. From an implementation standpoint we only ever have the preload data at the end of Vite's build. I'm very hesitant to do even more post-processing on the compiled code to go and replace special strings with bundle names.

Dedicated server endpoint that returns what to preload

One other thing I was thinking about is maybe preload headers when requesting a resource. However, that would quickly make CDNs very cumbersome (i.e. I can't just upload a bunch of static files). The additional request also feels like not preventing waterfalls in the way we want (e.g. if the request is slow due to intermittent connectivity or fails completely then we have a problem).

Optimizing the manifest

Before declaring a separate downloadable manifest as problematic I'd like to benchmark whether this is truly the case. Beyond that I'd like to examine what we put in the manifest to see if the data structure can maybe be optimized.

I copied the current manifest for our example application to: https://gist.github.com/Kingdutch/fcb4740a13b11131b703293b5769fde0#file-routermanifest-json

One immediate way to make the manifest smaller would be to remove file object fields that only have an empty array. The trade-off would be that every lookup might be slightly slower because it needs to check nullability. So that may not be worth it.

Another thing to look at to evaluate whether downloading the manifest is actually a problem is how well it compresses. When looking at the manifest we do see a lot of data that we could deduplicate. However, when taking into account gzip/brotli compression then the deduplication doesn't actually yield us anything beyond complexity.

Using https://www.giftofspeed.com/gzip-test/ I looked at the size and compressability of the original router manifest and one where I removed react and relay from everything that requested index (since index itself already requires react and relay).

The unmodified routerManifest showed the following properties:

Original Size: 1.79 KB
Size (compressed): 1.13 KB
Compression %: 36.86% could have been compressed

The deduplicated routerManifest showed the following properties:

Original Size: 1.5 KB
Size (compressed): 1.13 KB
Compression %: 24.97% could have been compressed

As you can see, even though the modified version is 20% smaller on disk, it's not actually cheaper to download because compression is already really good at deduplicating.

Finally I tried removing the space from routerManifest which actually decreased compressed size minimally in return for losing readability for humans.

Original Size: 1.32 KB
Size (compressed): 1.11 KB
Compression %: 16.32% could have been compressed

I'm curious to see how the routerManifest develops with your application that includes many more routes :)