A web 3D showroom gets laggier after switching a dozen rooms, but a refresh smooths it out — is VRAM not being released?

Conclusion: When a web 3D showroom switches rooms repeatedly on a touchscreen, it gets laggier with each switch, but refreshing restores smoothness. Based on typical 2026 delivery experience, the cause is usually not an overly high model polygon count or outdated hardware, but GPU-side resources not being released during switching: textures, geometry, materials, shadow maps, and render targets keep accumulating until they hit the VRAM limit the browser sets for a single page, at which point frame drops begin. The typical clue is that the initial-screen frame rate is normal; after switching a dozen or more times, the frame rate drops noticeably; refreshing the page immediately returns it to normal.

Why “a refresh fixes it” is usually a sign that resources are not being released

WebGL resources fall into two layers: object references in JavaScript, and the buffers and textures that actually occupy GPU VRAM. Setting an object to null only handles the former; the latter must be explicitly released by calling dispose. For stability, browsers generally will not reclaim GPU resources that are still referenced by the page on your behalf; if the page keeps creating without releasing, usage will climb steadily.

So the “refresh fixes it” behavior is key — refreshing destroys the entire WebGL context and clears GPU-side resources in one go. If performance immediately recovers after a refresh, the problem is most likely in resource lifecycle management, not GPU performance or the model being too heavy.

• Textures: Creating a new texture every time a scene is entered and not disposing it when leaving is a common number-one leak source.
• Geometry and materials: Reloading the same model repeatedly causes vertex buffers to be requested repeatedly.
• Render targets: RenderTargets used for post-processing, shadows, and mirrors are not released; their footprint is usually larger than ordinary textures.
• Event listeners and timers: Failing to unbind them keeps old scenes participating in computation, which shows up as getting slower the longer it runs.

Determining whether it is a VRAM problem: compare with a “three-stage baseline method”

A single frame-rate reading tells you little. Comparing three states together — initial screen, after repeated switching, and after a refresh — is what distinguishes a model that is inherently heavy from resources that are not being reclaimed. This is also a relatively efficient approach for on-site troubleshooting.

1. Stage one, initial baseline: On first entering the page, record the frame rate, draw call count, and the number of geometries and textures in the renderer.
2. Stage two, switching pressure: Switch scenes back and forth ten to dozens of times following real usage habits, then record the same items.
3. Stage three, refresh comparison: Refresh the page, re-enter the first scene, and record again.

The criterion is: if stage three is close to stage one while stage two has clearly dropped, it can basically be judged as resources not being released; if the initial screen itself does not meet the target, then first look at model polygon count, texture size, and material count — do not immediately suspect a memory leak. In the browser’s task manager you can usually see a GPU memory entry; tracking the trend is more meaningful than looking at the absolute value.

On delivery: texture precision, shadows, and event listeners are often hidden amplifiers

A common situation in projects: the client hands over a full set of 4K textures at once, and neither budget nor schedule allows a redo. The usual approach is to downgrade uniformly before ingest — compress diffuse textures to within 2K, keep normals separately, and split folders by scene. This usually brings switching pressure down. The trade-off is that if a few textures’ dispose calls are missed in the code, frame drops will still start after ten-plus minutes of repeated switching, and you will eventually have to go back and add resource-reclamation logic, which by typical experience range usually adds 1 to 3 working days.

Shadow maps and real-time reflections are also often overlooked: to make the visuals look good, a scene is fitted with three or four real-time shadows, each with its own render target; if you forget to release them when switching scenes, the footprint doubles. On delivery, first verify whether shadows have caching enabled and whether reflections have a degradation strategy, then decide which resources are allowed to stay resident.

A reusable resource management checklist: “register — reuse — expire — reclaim”

The reason for dividing it into these four steps is that one-off destruction easily deletes shared resources that are still needed, while ignoring them entirely usually leaks. Using reference counting to explicitly track “who is still using it” is what allows safe reuse across multiple scenes.

1. Register: When a scene loads, write the textures, geometry, materials, and render targets it creates into a table tagged with a scene identifier for unified lookup.
2. Reuse: Cross-scene resources such as environment maps, fonts, and shared materials are created only once; when referenced, the count goes up by one.
3. Expire: When leaving a scene, decrement the count; only resources whose count reaches zero enter the pending-reclamation queue, avoiding accidental deletion.
4. Reclaim: Release in the order of render targets, materials, textures, and geometry, then clear the render list, and finally unbind event listeners and the animation loop.

What counts as passing: after switching twenty to thirty times in a row, frame rate and usage can fall back to close to the initial-screen level instead of climbing continuously. Conversely, if usage rises a little after every switch, even if it is not visible in the moment, it will become a problem during long stays on the page.

Full preload or per-scene chunking: how to choose

Both approaches have costs. The key is whether users frequently jump between different scenes. In 2026, the common basis for judgment is two metrics: first-entry time and switch count.

• Full preload: Initial wait is commonly in the 5 to 15 second range, longer on weak networks; in exchange, switching is almost imperceptible — suitable for display pages with few scenes and frequent jumps.
• Per-scene chunking: Initial load can usually be brought down to the 2 to 5 second range, with a 0.3 to 2 second loading gap on switching — suitable for venues with many rooms where users mostly visit only one or two.
• Development cost: Chunking requires more work on loading states, preloading, and resource registration logic, typically 2 to 5 working days more than full preload by experience range.
• Who it suits: For exhibition touchscreens with lower-end hardware, chunking is more stable; for showrooms with high-spec hosts and fixed browsing paths, full preload feels smoother.

Applicable scenarios and boundaries

Resource reclamation is not needed by every WebGL page. The criterion is: “Will scenes be created and destroyed multiple times within the same page lifecycle?” Only when this holds is the investment worth it.

• Suitable: Display pages with multiple rooms, configurations, or versions; projects that stay resident on an exhibition stand or touchscreen without refreshing for long periods.
• Not suitable: Pages with only one scene that never changes after loading; temporary demo pages with a very small total model footprint that are refreshed after use.
• Boundary: If switching scenes is a full page navigation rather than an in-page switch, the browser will naturally release the context, and reference counting is generally unnecessary — forcing it in adds maintenance cost instead.

FAQ

When a web 3D showroom gets laggier as scenes are switched, where should you check first?

Start by refreshing once as a comparison. If a refresh restores performance, first check whether textures and render targets are being released when switching scenes, then check whether event listeners are being unbound.

For a WebGL project with resource reclamation, what is the typical delivery timeline range?

Based on 2026 project delivery experience, a single-scene page is commonly 5 to 10 working days; multi-scene pages with resource management are commonly 10 to 25 working days, depending on model volume.

Where do WebGL project quotes differ, and what share do modeling and rendering each take?

Quotes are mostly ranges: modeling and optimization commonly account for 40% to 60%, rendering and interaction development 30% to 50%, and the rest is device adaptation and on-device debugging.

What files are usually handed over on WebGL delivery?

The usual deliverables include the source project, compressed models and textures, reproduction instructions, and an acceptance checklist verified against platform specifications, to make later maintenance easier.

For the same WebGL page, is it normal for performance to differ greatly between phones and computers?

Yes. Mobile has tighter VRAM and fill-rate limits. It is advisable to set texture sizes and shadow levels in tiers by device model rather than using one set of parameters across the board.

If the page only loads once and does not switch scenes, controlling model tiers and texture sizes is usually enough; only WebGL projects that stay resident long-term and switch scenes frequently are worth doing resource reclamation for according to the checklist above. Before going live, it is advisable to run a three-stage baseline test and keep the initial-screen data on file, so later optimization has something to compare against. When delivering this kind of long-running web 3D display, Xiyue Company usually hands over the resource registration table to the maintenance party as well.