@lashman @leadore It seems to be the JS, not the CSS directly? If I load the site with NoScript or uBO in strict mode which blocks all JS scripts, the page is fluid and uses 63MB of RAM, but with JS enabled it does make things worse
I'm not sure what causes that, probably the 3D animated panes when you hover over them. But I found a different issue:
Consider modifying the HERO - orchestrated entrance section in /driftwood/script.js for the page, because if I have esm.sh blocked, it'll set everything to opacity 0, add a listener to whatever framer-motion or motion includes
I think it's the !animate or some other check you've put in place, because with esm.sh blocked it still logs to the console that motion.dev was loaded successfully, despite it being blocked. It's loading motion/*esm from JSdelivr, but there are other components that appear to be loaded via esm.sh, like framer-motion, motion-utils and motion-dom.
It also loads motion/index.mjs from unpkg as a fallback if esm.sh and jsdeliver are blocked π