How to optimize your Spline 3D export before shipping to web

Spline has become the go-to tool for web designers who want interactive 3D on landing pages without writing WebGL from scratch. The authoring experience is excellent. The exports are not production-ready.

A Spline scene that looks like a few shapes and a background can easily produce a 30–60 MB GLB with 200+ draw calls and 40 MB of uncompressed PNG textures. Ship that file as-is and you will have a landing page that scores poorly on Core Web Vitals, stutters on mobile, and frustrates the users it was meant to impress.

The good news: Spline exports are fixable. This is what to do.

Why Spline exports are heavier than expected

Spline's design-first workflow is optimized for authoring, not delivery. Three things make exports heavier than they should be:

One mesh per object — high draw call count

Every shape, text element, image, and effect in your Spline canvas becomes a separate mesh object in the exported GLB. A landing page hero scene with 50 design elements produces 50+ draw calls. On desktop, that is barely noticeable. On mobile, each draw call is a CPU command with non-trivial overhead — and mid-range phones saturate around 50 draw calls per frame. Above that, frame rate drops noticeably regardless of how lightweight each individual mesh is.

Uncompressed textures at authoring resolution

Spline exports textures as PNG at whatever resolution they were added to the canvas. A single background image at 2048×2048 is 12 MB uncompressed in GPU memory. Add a normal map, a gradient fill, and a few image planes and you are pushing 40–80 MB of texture VRAM — well beyond what a mid-range phone can hold in a single browser tab without crashing.

Spline does not apply KTX2 compression at export time. You have to do it yourself post-export.

Dense geometry on curved shapes

Spline renders curves as smooth NURBS in the editor but converts them to polygon meshes at export. A simple rounded cube, a sphere, or a tube element produces far more triangles than it needs for web rendering. A scene with 20 curved shapes can easily export at 500k+ triangles — 5× more than a typical web experience needs.

Step 1: reduce complexity inside Spline before exporting

Some weight can be removed before you export, which keeps things simple and avoids fighting the post-export tooling.

• Merge static objects. Select objects that share a material and will never animate independently, then group and export them as a single mesh. Each merge eliminates a draw call.
• Remove invisible elements. Design layers, helper shapes, and off-screen elements that were useful for authoring but are not visible in the final experience still appear in the export. Delete or hide them before exporting.
• Reduce subdivision on curved shapes. In the object properties panel, lower the subdivision/detail level on spheres, tubes, and rounded shapes. Halving the subdivision often reduces triangle count by 75% with no perceptible visual difference at web viewing distances.
• Downsize large textures. If you added a 4K background image, resize it to 1024×1024 or 2048×2048 in an image editor before importing into Spline. The authoring canvas will look slightly softer; the export will be dramatically smaller.

Step 2: post-export optimization

Even with the above, most Spline exports need post-processing. gltf-transform is the standard CLI for this — it handles Draco geometry compression, KTX2 texture conversion, and mesh cleanup in one command.

# Install once
npm install -g @gltf-transform/cli

# Optimize a Spline export
gltf-transform optimize spline-scene.glb spline-scene.optimized.glb \
  --compress draco \
  --texture-compress ktx2

Draco compression reduces geometry data by 70–80%. KTX2 with Basis Universal cuts texture data by 70–85% and — crucially — keeps textures compressed natively on the GPU, which is what prevents tab crashes on mobile. A 40 MB Spline export typically becomes 3–6 MB after these two steps.

If the triangle count is still over 150k after compression, add decimation:

gltf-transform optimize spline-scene.glb spline-scene.optimized.glb \
  --compress draco \
  --texture-compress ktx2 \
  --simplify

Step 3: loading optimized GLBs in Three.js or R3F

An optimized Spline GLB (Draco + KTX2) requires the matching decoders to load in Three.js or React Three Fiber:

import { GLTFLoader } from 'three/addons/loaders/GLTFLoader.js';
import { DRACOLoader } from 'three/addons/loaders/DRACOLoader.js';
import { KTX2Loader } from 'three/addons/loaders/KTX2Loader.js';

const dracoLoader = new DRACOLoader();
dracoLoader.setDecoderPath('/draco/');

const ktx2Loader = new KTX2Loader()
  .setTranscoderPath('/basis/')
  .detectSupport(renderer);

const loader = new GLTFLoader();
loader.setDRACOLoader(dracoLoader);
loader.setKTX2Loader(ktx2Loader);

loader.load('/spline-scene.optimized.glb', (gltf) => {
  scene.add(gltf.scene);
});

The decoder files (/draco/ and /basis/) ship with Three.js and should be copied to your public directory. With R3F and @react-three/drei, the useGLTF hook handles Draco automatically; add useKTX2 for texture decompression.

Step 4: measure before and after

Before you embed the export and after you optimize it, run the GLB through MeshGrade's free Spline analyzer. It reports file size, draw calls, triangle count, and texture VRAM — all benchmarked against web and mobile targets with a 0–100 grade. The before/after comparison tells you whether the optimization worked and whether anything remains that will cause problems on mobile.

A production-ready Spline asset for a web landing page should aim for:

• Under 5 MB file size
• Under 50 draw calls
• Under 100k triangles
• All textures KTX2-compressed

Most Spline exports can hit those targets after one round of in-editor cleanup and post-export optimization.

When to hand it off

If you have a complex Spline scene — multiple animated elements, layered materials, high-resolution custom textures — manual optimization can take several hours and requires careful testing at each step. That is where the done-for-you optimization service is worth considering. We take the export, run the full optimization pipeline, verify the result against your target device class, and hand back a GLB that is ready to ship.