Adding a 3D canvas to a web page sounds elite until you deploy it and watch a mid-range mobile device turn into a brick trying to parse the render loop.
Three.js and WebGL are heavy by default. A lot of developers open Blender, model an asset, export the GLTF file, and drop it straight into a scene without looking at the geometry complexity or texture memory footprints. If your render loop is constantly calculating unoptimized meshes or failing to dispose of geometries when elements unmount, your frame rate will tank.
For my portfolio, adding spatial depth to the hero canvas meant actively fighting performance loss. I had to explicitly optimize the texture resolutions and write logic to defer initialization until the critical content loaded. I also had to build an explicit toggle to disable WebGL completely for older hardware.
If your custom web experience requires a high-end desktop GPU just to look at your resume, you did not build a good website. You built an unoptimized asset.
Portfolio: ahmershah.dev
GitHub: ahmershahdev
The render loop is a dangerous place to put unoptimized logic. Running heavy calculations on every single frame instead of caching values or using web workers is the quickest way to drop your frame rate from 60 to a stuttering 15.
Everyone tests their Three.js builds on a high-end M-series Mac or a gaming rig. The real test is opening that canvas on a three-year-old budget Android phone over a patchy 4G connection. If it fails there, the implementation failed.
We’ve reached a point where people use Next.js for static, five-page brochure websites. It’s architectural overkill. If your data doesn't change dynamically at runtime, you don't need a heavy virtual DOM or complex hydration strategies; you just need clean HTML and CSS.
Sagar Kumar
3D on the web should be an enhancement, not a barrier to entry. If the core user experience is locked behind a massive loading screen and a heavy GPU tax, it’s bad UX, no matter how impressive the shaders look.