I am attempting to use threejs (specifically @react-three/fiber & @react-three/drei ) to build some tooling for my community newspaper platform. Here is a a work-in-progress version Mars Hill Voices that sometimes is working 
The initial purpose is to provide the kind of type of navigational abilities for a website that google maps does for the world - where I can go from seeing Mars Hill to seeing Paris. Replacing a hamburger menu.
The target platform is the mobile phone, and because this is rural, much of the internet connectivity is over LTE or something like it. As a result loading times can be dismal. This is not an area that I know well, so I am sure I am just missing parts.
My first attempt was to try to make the bundles as small as possible. I looked at the @react-three/fiber Canvas documentation about importing only small part of three, but in a first experiment was unable to see any savings.
Next I used Vite & Rolldown (not up) to manually create a bundle of just the threejs. My understanding is that I can cache that bundle for a Very Long Time while changing the rest of the code and forcing reloads. I think this works but do not have enough testing yet.
I want to use the same software as a platform for several community newspapers like Mar Hill Voices. And I want to use the same libraries built on threejs for other community software projects.
- I am still unable to reduce the size of the three(s)js bundles. What is the best approach to doing this, if any?
- Should I use a cdn. If I end up having 20 websites that use my threejs, I know all the sites can import the same bundle. Will caching work for all 20 sites (assuming they all refer to the same thing). In other words if my browser has cached a cdn file for one site, and then the same cdn file is used. on another site, will it refetch it.
Thanks for the help. As you can tell, this is not an area I understand well. Unfortunately. 
I am sometimes building “restructuring” the Mars Hill Voices website so things might be broken for a short time periodically.
The structure of the website might be confusing.
- There is a splash screen. Click on it
- There is a word cloud. Click on the word “Stories”.
- The word centers and changes color. Click again (not really needed for most things)
- The page goes to a react page.
- Click on the icon at top left to go to the word cloud.
Would be grateful for any thoughts, suggestions, ideas about any of this.
Some options you can try:
-
Bundle Visualizer - Find what’s actually large before optimizing blind
-
Manual Chunks - Separate Three.js chunk so it caches independently from your changing app code
-
Surgical Drei Imports - Drei is the biggest hidden cost, only import what you use
-
Brotli Compression - 20% smaller than gzip, supported by all mobile browsers
-
Cache-Control: immutable - Returning users never re-fetch Three.js after first visit
Best approach I’d take - PWA(Progressive Web App):
Since your users are rural and on LTE, a PWA is the perfect fit. After first load, a service worker caches your entire app locally , Three.js bundle included , so returning visitors load instantly regardless of connection quality. No app store, no installer, just “Add to Home Screen.” Solves your LTE problem at the root rather than just minimizing it.
Just saw the structure, it’s a unique concept but confusing from a UX perspective without any guidance. A few thoughts:
-
Scroll-based animation would feel more natural than click-based on mobile
-
Touch feedback on the canvas so users know what’s interactive
-
A subtle “tap to explore” hint would help a lot
-
The word cloud nav idea is genuinely cool, just needs clearer affordances
Looks like an early build with solid potential , needs some UX rework but the core idea is interesting. Excited to see it grow!
@Priyal_Khatri . Thank you! That is very helpful. A couple years ago I went down the PWA route for another project and ran into the “Apple doesn’t want you to use PWA because of money” issue. I don’t remember all the issues but at that time Apple avoiding implemented or implemented but broke some important functionality. I’m not sure that is still the case, or if the same issues apply to this case, so I will look at that again.
I think there was some difference in accessing the pwa or accessing the website and how the browser handled things like cookies, storage etc.
@Priyal_Khatri, thank you for the thoughtful comments. I’m exploring the concept - making this up as I go along, so these are just my guesses for the most part.
Fundamentals:
-
I want the capability of a high functionality site. One that is as much for doing as viewing content.
-
I think doing on mobile phones can be problematic, for example on my iPhone the whole “settings” thing is a nightmare. I want to build a site focused on doing and functionality. For example forums. Not the “like-follow-friend” paradigm, but one for discussions that lead to actions. One for example that allows us to talk about a problem, formulate and understanding, make a plan and pass laws.
-
The barrier I see is complexity (the IOS settings thing) and how to navigate it. Can I post an ad to sell my car and post an article on voting rights using webrtc, then another thing. When thinking about navigating all that complexity on a small screen phone the only thing I know of that works is mapping apps like google maps and others.
-
Maps use three dimensions, ergo threejs. I’ve tried a couple ideas before Aroostookian is a previous example that embodies the concept of both cards and a room.
-
The current word cloud (on MHV) is less complex and easier to implement. I am considering changing one/some of the words (“more” for example) into doorways. Or a skybox like google street view?
Replies:
- scroll based. I think scroll based may feel natural, but it breaks 3D. My take is that I need to improve the feedback, help users learn etc. I think it is worth going further down this path. For now.
- tap to explore. Yes
- clearer affordances. Love that word “affordances” but not sure I understand how I would do that.
Really, thank you very much for thinking about this! Great help!
tab at tabraun, with com extension. For more off topic if anyone wants.
Valid concern! Apple’s PWA support has historically been frustrating but things have improved significantly since iOS 16.4+:
-
Push notifications now supported on iOS
-
Better storage persistence
-
Improved service worker reliability
Some quirks remain though, iOS still handles PWA storage differently than Android and Safari’s WebKit limitations can cause inconsistent behavior compared to Chrome.
Worth re-testing since it’s been a couple years, the gap has narrowed a lot. If iOS PWA still feels unreliable, a lightweight Tauri mobile build could be a solid fallback!
Really love the vision! The Google Maps analogy makes total sense, spatial thinking beats flat menus for complex navigation.
On the mobile complexity problem, you’re touching something really important. Most platforms are built around consumption not action, the “like-follow-friend” model keeps you scrolling not doing. Building discussions that lead to actual outcomes is a fundamentally different UX goal and most tools fail at it on mobile. A few thoughts:
-
Progressive disclosure - show only what’s needed at each step, reveal complexity when the user is ready
-
Spatial navigation is your biggest asset, if users always know “where they are” in the discussion-to-action flow they feel less overwhelmed
-
Clear state - showing “this discussion produced this outcome” gives users purpose and progress
On the 3D side:
-
Affordances in practice means glowing edges, subtle pulses, floating labels on tap, basically “this is clickable” without instructions
-
Doorways in the word cloud is a great idea, naturally maps to “entering” a space users already understand from gaming
-
Skybox like Street View could work beautifully and gives that “I know where I am” feeling
You’re essentially building a 3D civic OS for community action, genuinely original idea worth pursuing!
@Priyal_Khatri Thanks again for your thoughts and ideas!
@Priyal_Khatri I finally remembered the IOS pwa problem on Safari that was a show stopper for me:
Apple Safari treats the web storage for a PWA completely separate from the web storage on the actual website. In other words, if you have cookies from the website https://example.com and a PWA for example.com, the cookies are not the same.
Users end up visiting the website and having a different experience than when they access it from the pwa. I ended up quitting in disgust as it seems to me there would be no reason for Apple to implement this strategy except as a way to enforce an anti-fair use policy. Maybe someone else has a better understanding and explanation? Or maybe someone knows of a work around?