Publishing gate

Run the WebGL scene health check

Use the checklist to score assets, camera behavior, rendering, mobile performance, loading states, and fallback content before publishing.

Run Scene Check Compare lab tools

Progress is part of the scene

Three.js pages often load models, textures, HDR environments, decoder scripts, and example code. If all of that happens silently, users may see a blank rectangle and assume the page is broken. A small loading status can turn uncertainty into patience.

LoadingManager gives loaders shared callbacks for start, progress, load, and error. It does not make every percentage perfect, but it centralizes the message. That is enough for most static tool pages.

Do not block the whole page

A guide page should remain readable even if a demo asset is slow. Render the article first, then hydrate the WebGL example. The loading indicator should sit in the demo area, not cover the entire document. This keeps the site useful on slow connections and friendlier to crawlers.

For a full-screen tool, blocking the tool panel may be acceptable, but the message should still be specific. 'Loading model.glb' is more useful than a generic spinner. If an asset fails, say which one failed and what the user can try next.

Progress numbers need humility

Some assets report total bytes; others do not. A percentage can jump, stall, or represent only the files that expose useful progress. Avoid pretending the number is more precise than it is. Pair the percentage with plain text such as 'Preparing textures' or 'Decoding model.'

If you cannot provide accurate progress, use a staged status instead. The goal is confidence, not fake precision.

Error states are content

A failed load should not leave a blank canvas. Show an inline message with the asset path, a short explanation, and a retry action if possible. For user-provided files, explain supported formats and likely causes such as missing external texture paths.

These error states improve tools and strengthen the content page. They show that the site understands real user failure modes instead of only the perfect demo path.

When this guide is the right tool

Use this guide when the problem is specific enough that a broad Three.js tutorial would waste time. The focus here is LoadingManager in a real browser page: what to check first, what to measure, and what to avoid before the scene becomes harder to reason about.

The practical rule is simple: Use LoadingManager callbacks to centralize asset progress. If that sentence describes the scene in front of you, treat the article as a checklist. Read the explanation, copy the smallest useful code pattern, then test the result in a narrow mobile viewport and a wide desktop viewport before adding more polish.

Common mistake to avoid

The common mistake is treating Three.js loading progress with LoadingManager as a visual tweak instead of a scene-system decision. Three.js problems often look like one broken line of code, but the actual issue is usually a chain: asset assumptions, renderer settings, camera math, material setup, interaction state, and page layout all meet inside the canvas.

That is why the safest fix is incremental. Start from a known-good scene, change one variable, and keep a visible diagnostic while testing. Keep article text and basic UI available while demos hydrate. When the scene works, remove temporary helpers and leave behind only the checks that make sense for users.

Publishing check

Before publishing, run the scene through three questions. Does the page remain useful if WebGL fails or the asset loads slowly? Does the same scene still read clearly on a phone? Can another developer understand the important settings without reverse-engineering the whole file?

The last pass should be boring on purpose: verify canvas size, console errors, mobile performance, source links, internal links, and the related guide path. Show failure states that tell users which asset failed. If any answer is fuzzy, fix that before introducing a new effect or a larger asset.

Shared loading manager

const manager = new THREE.LoadingManager();
manager.onStart = (url) => setStatus(`Loading ${url}`);
manager.onProgress = (url, loaded, total) => {
  const percent = total ? Math.round((loaded / total) * 100) : 0;
  setStatus(total ? `Loading ${percent}%` : `Loading ${url}`);
};
manager.onLoad = () => setStatus('Scene ready');
manager.onError = (url) => setStatus(`Could not load ${url}`);

const textureLoader = new THREE.TextureLoader(manager);
const gltfLoader = new GLTFLoader(manager);

FAQ

When should I use Three.js loading progress with LoadingManager?

Use it when your Three.js scene has a focused LoadingManager problem and you need a practical checklist before adding more visual polish.

Is the code snippet production-ready?

Treat the snippet as a clear starting point. Test it in your scene, adapt naming and paths, and verify behavior on mobile hardware before publishing.

What should I check after applying this guide?

Run the scene through mobile sizing, console errors, loading states, source links, and related guide paths so the page remains useful even when assets or WebGL fail.

Sources and further reading

Related guides

8 min read · environment map Three.js environment maps for GLB viewers Environment lighting often does more for PBR materials than another direct light. 8 min read · mobile Three.js mobile performance checklist Mobile WebGL quality comes from budgets: fewer pixels, fewer surprises, and graceful fallbacks. 7 min read · screenshot Three.js canvas screenshot export for tools A screenshot feature should export the scene the user sees, not an old frame, empty buffer, or accidental UI state.