How to make WebGL run smoothly on cheap phones

You make a WebGL website run smoothly on a cheap, old phone by testing on one from the first week, and letting it overrule you. On the Why Zero site for Zero University, we did exactly that. We cut roughly 1.5 GB of source assets to under 10 MB, and the site holds 50 to 60 FPS on a four year old budget Android.

Below is how we did it, step by step. It is written for the people who commission ambitious sites and for the developers who build them.

Why does it matter if a WebGL site only runs on expensive phones?

WebGL is the technology that lets a browser draw real time 3D graphics. It can make a website feel like a film you move through. It can also make a website unusable on the phones many people actually own.

For Zero University, this was not a side issue. Their audience spans every income level in India. A great many of those visitors hold inexpensive, ageing phones.

The site argues for a different kind of education, one about access. A site that only worked on flagship hardware would have contradicted its own message. So “runs on every phone it was written for” became part of the brief, not a nice extra.

The client also arrived with a genuinely cinematic vision and roughly 1.5 GB of models and textures. The task was to keep the vision and lose almost all of the weight.

Why do WebGL sites stutter on budget phones?

A phone draws each frame of a 3D scene on its GPU, the graphics chip. FPS, or frames per second, is how many frames it manages each second. When that number drops, motion stutters.

Budget phones often use Mali class GPUs. These chips are designed around energy efficiency. In our testing, noise based shader work degraded on them in ways that were immediately visible. A shader is a small program that runs on the GPU and decides how each pixel looks.

So the effects that look richest on a powerful laptop are often the first to break on a cheap phone. Heavy files make it worse. Big textures take longer to download.

“The benchmark phone was chosen in week one, and it was allowed to veto decisions for five months.”

How do you choose a benchmark phone for a WebGL project?

Choose the least forgiving device your audience realistically uses. Then keep it on the desk for the whole build.

We borrowed a four year old budget Tecno Pova running a Mali class GPU. It sat on our desk for the full five months of the project. It is still there.

The important part is timing. We set the benchmark in the first week. From then on, the phone could veto decisions. A beautiful effect that ran badly on the Pova did not ship in that form.

Speed work is usually left until the end, when very little can still change. Testing from day one turns performance into a design decision rather than a clean up job.

How do you shrink 1.5 GB of 3D assets to under 10 MB?

There was no single trick. The saving came from treating every type of asset on its own terms: models, textures, type and sound.

Prepare every model in Blender first

Every asset passed through Blender before it reached the browser. Blender is a 3D modelling tool. We used it to decimate models, which means reducing the number of polygons, the small flat faces a 3D shape is built from.

We also baked the lighting. Baking means working out the light and shadow ahead of time and storing it in the texture. The phone then shows the result instead of calculating it live.

Compress textures properly, and test every size

A texture is the image wrapped around a 3D model. On Why Zero, the isometric city map arrived as a 24K texture weighing 500 MB.

We tried it at 16K, 8K and 4K. At 8K, visual detail and file size genuinely balanced. We routed it through a WebP intermediate, then converted it into the KTX container using ETC1S compression. KTX is a file format made for textures. ETC1S is a compression mode within it.

That single texture now ships at roughly 4.5 MB.

Turn type into a sprite atlas

Text in a 3D scene usually uses a method called MSDF, which draws letters from font data. We could not use it here, because every piece of type needed its own bespoke animation.

Instead, each type element was rendered as a sprite, a flat image, and packed into shared atlases. An atlas is one large image holding many small ones. The complete type set for the whole experience ships as a single 4K atlas, well under 1 MB.

Keep audio small too

Sound is easy to forget. The site uses eleven to twelve audio files, and together they come to 1 to 1.3 MB.

Why build your own texture compression tool?

Standard KTX compression runs through command line tools. You convert blind, write the file to a folder, open it, and judge it afterwards. A loop that slow tends to make people accept the first tolerable result.

So we spent a week building an internal dashboard before compressing anything. It shows the source on the left and the converted output on the right. Both views zoom together, so detail loss shows up instantly at any magnification.

Resolution, compression level and output format are all adjustable live. It covers JPEG, PNG, WebP and the full range of KTX formats.

At the time, that week felt like a detour. It turned out to be the most valuable week of the project. We have used the tool on everything we have made since.

How does a WebGL site adapt to a slow phone on its own?

The visitor should never have to pick a quality setting. The site should find its own limit.

On Why Zero, the site watches its frame rate continuously against a buffered threshold. A lasting drop, not a brief dip, steps the renderer down one quality tier. A quality tier is a preset level of visual detail.

Each step changes several things together:

• device pixel ratio, which is how many screen pixels the site draws per layout pixel
• particle counts
• texture resolution
• certain features, which are switched off entirely

On Mali class hardware, the multi tap blur is dropped altogether.

Switch render passes per scene

A render pass is one full drawing step the GPU performs to build a frame. The site uses five to seven of them. Each one is switched on or off per scene, so no scene pays for work it does not use.

Let the test phone shape each effect

The blur is a good example of how the benchmark phone worked. It started at nine taps, meaning nine samples per pixel. It was optimised to seven. It is then disabled on lower tiers. That is three decisions about one effect, and the benchmark phone prompted each of them.

Effects can stay ambitious under these limits. The Glass shader was the most demanding of the four custom shaders. It needed believable refraction on falling shards while staying cheap enough to draw in quantity on a low end mobile GPU. You can see it in context in the Why Zero case study.

What is a practical method for fast WebGL on budget phones?

Here is the method we followed, in order.

1. Pick a hard benchmark device in week one. Choose an old, cheap phone your audience really uses. Ours was a four year old Tecno Pova with a Mali class GPU.
2. Give it a veto. Agree with the client that anything which fails on that phone changes or goes.
3. Prepare assets before the browser sees them. Decimate models and bake lighting in Blender.
4. Test textures at several sizes. Try each large texture down through the sizes, as we did with 16K, 8K and 4K, and ship the smallest that still looks right.
5. Compress into a texture format. We used KTX with ETC1S compression via a WebP intermediate.
6. Pack type and small images into atlases. One atlas can replace many separate files.
7. Build quality tiers that switch themselves. Watch frame rate, ignore brief dips, and step down detail on sustained drops.
8. Turn off what each scene does not need. Switch render passes per scene.
9. Make the feedback loop fast. If a step is slow and blind, build a tool so you can see results instantly.

What does this mean if you are commissioning a WebGL site?

Ask when performance testing starts. If the answer is “near launch”, expect a slow site or a cut back one.

Ask which phone will be the benchmark. A named, cheap device is a far stronger promise than “it will be optimised”.

Ask how the team and your asset producers will work together. On Why Zero, optimisation could not be a handoff. Neither side knew in advance how far a model or texture could be pushed before it visibly broke. So the work ran as a constant exchange between production and compression, asset by asset, for the whole build.

The result held its ambition. The site has six narrative stages, four custom GLSL shaders and five to seven render passes, and it still fits in under 10 MB. The full story, with video of each stage, is in the Why Zero project. You can read more about how we take on this kind of build on our services page.

If you are planning an ambitious site and want it to work on the phones your audience actually carries, we would be glad to talk it through. Get in touch and tell us what you are making.