If you've inspected your Framer site's network requests and been surprised by the JavaScript payload size, here's what's actually in there and why it's not something you can meaningfully trim from inside the editor.
What's actually in Framer's runtime bundle
Framer's client-side JavaScript isn't just "your site's interactive code" — it's a general-purpose runtime capable of rendering any Framer site's design, handling the full breadth of Framer's component variant system, animation engine (with real spring physics, not just CSS transitions), responsive breakpoint logic, and — notably — the machinery that makes Framer's own visual editor work in preview/edit contexts. Your specific site only exercises a fraction of that capability, but the bundle ships the general-purpose engine regardless, because Framer's build process isn't (as of today) tree-shaking the runtime down to only the features one particular published site actually uses.
Why "just remove what I'm not using" isn't available to you
This is a platform-level architecture decision, not a per-site configuration option. You don't get a settings toggle for "I'm not using variant-based interactions, ship a smaller runtime" — the same bundle serves every Framer site, regardless of how simple or complex that particular site's actual interactivity is. A site with zero custom interactions beyond basic scroll reveals still ships essentially the same runtime weight as one making heavy use of Framer's full interaction system.
What this means practically
If JavaScript payload size is showing up as a real Lighthouse Performance flag, editor-level optimization (image sizing, font choices, reducing animation count) genuinely helps at the margins, but there's a floor set by the runtime itself that no amount of in-editor optimization gets you below. That floor is a fixed cost of staying on Framer's hosted runtime.
The only way past that floor
Removing the runtime entirely — a static HTML or JSX-based Next.js export that doesn't ship Framer's JS at all, reproducing the interactions your specific site actually uses (appear/scroll animations reliably, other interactions with varying fidelity — see our other posts on exactly what does and doesn't survive) with lightweight, purpose-built code instead of the general-purpose engine. This is the single biggest lever available if JS payload size specifically is your performance bottleneck, and it's structurally unavailable from inside Framer's own editor, by design.