Code can be art. Whether it's in clever syntax, elegant data structures, or refined interactions, there’s beauty only programmers see—and that’s fine.
But code can also create something visually stunning, something everyone can appreciate. This is where tools like ), you’ll need optimizations. Here are three practical techniques to keep performance in check.
Originally posted on , which detects when an element enters the viewport. Here's how I handle it in
After soft-navigation to another page: 28.6MB (even though that page was static HTML).
Why? Because Three.js objects weren’t being disposed of properly. And despite extensive research, I couldn’t find a reliable way to fully clean up memory in modern frameworks.
Here’s the simplest solution I found: force a hard-reload when leaving pages with Three.js scenes. A hard-reload lets the browser:
- Create a new page context.
- Perform garbage collection on the old page (leaving cleanup to the browser).
In
SvelteKit, this is easy with data-sveltekit-reload. Just enable it for pages with scenes:
homepage's +server.page.ts
CODEexport function load() {
return {
sveltekitReload: true
}
}
For navigation links, pass this value dynamically:
CODE<script lang="ts">
import { page } from '$app/stores';
</script>
<a href="/docs" data-sveltekit-reload={$page.data.sveltekitReload}>Docs</a>
If you use a generic
<Link>component, you only need to implement this once.
This approach isn’t perfect—it disables smooth client-side routing for specific pages—but it keeps memory in check and prevents crashes. For me, that trade-off is worth it.
Final Thoughts
These optimizations have worked well for me, but the question remains: how do we properly clean up Three.js objects in modern frameworks? If you’ve found a reliable solution, I’d love to hear from you!
↗ Original-Artikel auf dev.to lesenVollständiger Original-BerichtAusführliche Details, Code-Beispiele & Hersteller-Stellungnahme auf dev.to.
SOCIAL SHARE CARD GENERATOR