WebGL Performance Tips for Mobile 3D Sites

Write down the limits before you tune the scene. Measure startup, steady-state rendering, scrolling, interaction, and the moment the page becomes useful.

For the first pass, track:

• JavaScript and model transfer size before and after compression
• Number of draw calls, triangles, active materials, and texture memory
• Main-thread tasks during load and interaction
• Frame time while the camera moves, not just an idle frame
• Largest Contentful Paint (LCP), the time until the largest visible content renders
• Context loss, out-of-memory errors, and failed asset loads

web.dev recommends an LCP of 2.5 seconds or less for at least 75% of page visits. Treat that as a page-load target, not a promise that a heavy 3D scene will be ready at that exact moment. Put useful HTML content on screen first, then bring in the scene.

Test at least one recent iPhone or iPad, one mid-range Android phone, and one low-power Android device. Record the browser, operating system, screen size, device pixel ratio, connection type, and battery state. A desktop GPU cannot stand in for a phone GPU.

Fewer draw calls usually give a mobile WebGL scene more room to breathe. A draw call asks the browser and GPU to bind state and render a batch, so a scene with many small objects can spend time changing state instead of drawing.

Group objects that share geometry, material, and texture. Use instancing for repeated meshes such as cards, particles, foliage, or product components. Use texture atlases when several objects can share one texture so a texture change does not split the batch.

MDN recommends batching draw calls and gives 1,000 sprites in one draw call as an example of the idea. Do not treat 1,000 as a universal limit. Profile the scene you are shipping and find the point where frame time rises on your slowest target.

In Three.js, inspect renderer.info.render.calls, triangles, and points during the flows people actually use. A lower call count is useful only when the resulting materials, shader work, and memory fit the device.

Texture work often improves both loading and rendering. Use appropriately sized source images, mipmaps for textures viewed at different scales, and GPU compressed formats rather than sending large uncompressed images to every phone.

KTX2 with Basis Universal is a strong delivery path for a cross-device asset pipeline. MDN explains that Basis Universal can convert to common compressed texture formats at load time. The browser still needs a supported GPU format, so test the transcoder and its fallback on real devices.

Do not compress every map the same way. Color maps can accept a lossy format more easily than normal, roughness, or coordinate data. A texture that looks small over the network can still consume significant GPU memory after upload.

Mipmaps add about 33% memory overhead for square textures, according to MDN's WebGL best practices. That cost is often worth paying for a texture that is frequently viewed from a distance. Skip mipmaps for a resource that is never downscaled, and confirm the result with a memory profile.

Progressive loading makes the page useful sooner and avoids asking a phone to decode the whole experience at once. Start with a poster, a small model, or a low-detail mesh. Replace it with a higher-detail level of detail (LOD) asset after the first interaction or when the asset is near the camera.

Split the scene into routes or camera zones. Load only the geometry, textures, animations, and environment maps needed for the current zone. Dispose of objects when a zone is gone. Removing a JavaScript reference is not enough if the renderer still owns geometry, material, texture, or render-target resources.

Keep the first useful action independent of the full scene. A user should be able to read the headline, open the menu, or reach the next section while 3D assets continue loading. This is a better fallback than a blank canvas with a spinner.

Mobile screens can ask a renderer to produce far more pixels than the layout needs. Set a pixel-ratio ceiling and lower it when frame time exceeds your budget. Keep the canvas CSS size separate from its drawing-buffer size so you can trade sharpness for steady interaction.

MDN recommends rendering to a smaller back buffer as an easy quality and speed trade. Do not multiply the canvas by devicePixelRatio without a cap and assume the result is safe. High-density screens can turn an otherwise modest effect into a large fragment workload.

Resize from the actual device-pixel size when the browser supports device-pixel-content-box, and update the viewport before drawing. MDN's WebGL guidance notes that changing the canvas size clears it, so coordinate resize work with the render loop.

Use requestAnimationFrame() for visual updates and make the callback time-based. MDN notes that callbacks generally follow the display refresh rate, and warns that animation runs faster on high-refresh screens when code ignores the callback timestamp.

Pause rendering when the page is hidden or the scene is outside the viewport. MDN documents that browsers pause most requestAnimationFrame() callbacks in background tabs, but your own visibility and intersection logic should still stop asset work, physics, and input processing.

Move expensive work out of the hot path. Avoid synchronous WebGL queries such as repeated getError(), getParameter(), shader status checks, and CPU readbacks during interaction. MDN lists these calls as possible synchronous stalls. Gather diagnostics in development, then remove or throttle them in production.

Use fewer lights, shorter post-processing chains, and simpler fragment shaders on small screens. Work done per fragment can multiply across the entire drawing buffer, so reducing resolution and shader cost together is more effective than changing only one.

Use capability detection and a short warm-up, not a device-name blacklist. Choose a quality tier from available WebGL features, texture support, screen size, measured frame time, and memory pressure. Let users switch to a lower tier, and remember that choice for the next visit.

A useful tier model looks like this:

The fallback is part of the design, not an error screen. MDN recommends checking extension availability and adapting when an extension is missing. Apply the same thinking to WebGL itself, context loss, failed downloads, and reduced-motion preferences.

Run a repeatable test route on each target device: cold load, first useful content, first scene interaction, sustained camera motion, scroll through the heaviest section, background and return, then a reload from cache. Capture a performance trace and save the scene metrics beside it.

Compare real-user data with lab data. web.dev explains that CrUX and real-user monitoring show what visitors experience, while Lighthouse helps diagnose causes. A desktop Lighthouse score is not evidence that a mobile GPU can sustain the same scene.

Set acceptance thresholds before the review. For example, you might require no visible frame drops during the primary interaction, no context loss in a ten-minute route, a capped drawing buffer on low-tier devices, and a useful HTML fallback when WebGL fails. Those are project decisions, not universal WebGL limits, so record the device and test conditions with each result.

• MDN WebGL best practices: batching, texture compression, memory, resolution, and compatibility guidance.
• MDN requestAnimationFrame(): refresh timing, timestamps, and background behavior.
• web.dev: Optimize Largest Contentful Paint: mobile LCP target, field data, lab data, and loading diagnosis.