How to reduce loading time of r3f api?

[Franckapik]

I am looking for the ways to reduce the loading time of my r3f page (game).

I have now in my mind may be two options :

• using webcache for ressources like textures, materials, … For this, i should use UseMemo, isn’t it ?
• reducing png texture image … (or using jpg instead?) I use matcaps.

Is there a way to see what’s going in web cache ? If i use the debug tool from chrome i can see differences between using or not webcache, but i don’t really know how to understand theses numbers…
Someone could suggest me improvements ? What could be usefull in the debug tool to diagnose time latency ?

Thank you again for your help !

[drcmda]

it's using browser cache anyway. for textures three executes a regular fetch request. you can preload textures in v5, look into the release notes. but most likely your textures are too large. 160mb for a website is crazy. also compress your gltfs with gltf-pipeline and dracos highest compressionlevel.

[stephencorwin]

You should serve your assets/textures over a cdn where you can set the appropriate cache-control header. This does not happen by default for chrome/firefox and will significantly reduce loading times on subsequent visits. Considering your website is a game, it is expected to have repeat visitors.

[Franckapik]

Thank you for yours answers !!

@drcmda So i see that i could use useLoader.preload(GTLFLoader, url of the cdn) to preload texture before entering the game.
Should i have to stop using suspense and lazyloading finally ?

I don't know if i can use jpg texure instead of png for matcaps...
Maybe an alpha channel is necessary. In this case, i should use better compression for png files.

For .glb files, is it better to save buffers/textures as embedded or separate files? Probably separate file because i import them with r3f ?

@stephencorwin , when you say "This does not happen by default for chrome/firefox", what are you talking about ? Web Cache ?
It's interesting to use CDN, i will have a look on this tonight!

I have to find a way to display video content with low size and maybe only when visitors ask .

Thank you !!

[stephencorwin]

@Franckapik what I mean is just that browsers don't work that way by default. They don't automatically determine to cache and never download a resource again. They must be informed via a header such as cache-control. This can only be done from the location/server the assets are being served from. If you want to run a headless static site, a typical solution is to use a cdn such as Cloudflare. Otherwise, you will need to leverage something like express in order to add the cache-control header on the request of certain assets.

This has nothing really to do with react-three-fiber and more to do with just the nature of the web. It's a good thing really. If browsers decided to cache by default, then you could go weeks without seeing updates to sites you visit. This would be especially problematic if one of those updates fixed broken behavior.

[stephencorwin]

In my game, I actually have 288 MB being loaded, but it loads almost instantly on subsequent visits due to proper caching.
Notice how only 567 Bytes are actually being transferred. Also notice that the size is marked as (disk cache) instead of a number.

If I click on one, you can see the value of the Cache-Control response header from the server.

[Franckapik]

Thank you so much for your clear answer!
Because I am using express now, I will first have a look on cache header on static file requests.
I am curious on your game. The visitors have to still download 288MB on first visit ? It should be a long preload ? Or I missed something with cache and CDN ...

And just to know ... (then I stop bothering you) , is this better for performance to have multiple glb files instead of just one ? Or this is just a way to be more organised ?

Thank you again!

[stephencorwin]

I am shipping my game as an Electron app. Folks will download it ahead of time either directly or through Steam. There is still a loading time the first time they boot up the game, but it is fairly quick since it isn't over the network at that point. Every subsequent load is fast.

As for UX, it is best to preload a minimal amount of assets needed for the player to start interacting and progressively preload whatever else you need before they need it. As a fall back, using suspense works well, however it is a bit jarring to see assets suddenly "pop in". So I prefer to preload when possible even if it means a longer period where the player is unable to interact. React-three-fiber (and drei) has built-in tools to support both strategies. However, you may find that you need to roll your own logic depending on your use case (I did).

then I stop bothering you

No need to worry about bothering me. I am one of the maintainers for this ecosystem, so that is what we are here for :)
If you want to talk strategy more, there is a whole community waiting for you on our discord server. Come say hello!

[Franckapik]

Thank you very much for this help! It's so nice to be able to share knowledge and skills on github.
I ask one last question here before I could have time to work on my game this weekend. ;)

Assuming I have a fps view and a all scene like this:

One idea with regard to loading could be to create areas that the visitor could gradually discover. In this way, we would have a first load with the main textures of the game and then discrete loads before the visitor discovers the different areas?

So for example I could associate each zone with a glb file, loading silently while the visitor is already interacting in the game. Is it an example of loading strategy you were refering to ?