How I Reduced a 1.2GB Unity WebGL Build to 68MB and Made It Deployment-Ready in 1 Week

The Context

A PhD researcher approached me with a Unity WebGL project designed as an interactive breast cancer awareness experience.

The project:

1. Used branching decision paths
2. Played different 3D-rendered videos depending on user choices
3. Logged participant interactions for research analysis
4. Needed to be deployed publicly for survey participants

The problem?

The WebGL build size was 1.2GB.

For a browser-based research tool, that was completely impractical.

The Core Problem

The build size wasn’t due to complex gameplay.

It was due to:

1. Dozens of embedded video files
2. Each decision branch triggering a different pre-rendered clip
3. All videos stored locally inside the Unity project

This created:

1. Massive build size
2. Extremely slow load times
3. High risk of browser crashes
4. Increased hosting costs
5. Poor user experience for survey participants

For a research study, this could directly affect data quality.

If users drop before completing the survey, results become unreliable.

Strategic Decision

Instead of “optimizing textures” or tweaking compression settings, I restructured the architecture.

I proposed:

1. Removing all video assets from the Unity build
2. Hosting all videos externally on a CDN
3. Streaming them dynamically at runtime

The client agreed.

The Technical Solution

1. Externalizing Media to Cloudflare R2

1. All video files were moved to a Cloudflare R2 storage bucket
2. CDN delivery ensured low latency and scalability
3. Video references inside Unity were replaced with secure URL endpoints

This immediately removed over 1GB from the project.

2. Runtime Video Handling Logic

Simply switching to URLs isn’t enough.

I implemented:

1. Fallback handling for delayed or failed video loads
2. Graceful error states (no blank or black screens)
3. Loading indicators to preserve UX continuity

This ensured:

1. Stable experience even under poor network conditions
2. No broken survey flows

3. Zero-Backend Survey Logging

The research required logging user decisions.

Instead of deploying a backend server, I built:

1. A lightweight Google Apps Script endpoint
2. Connected directly to Google Sheets
3. Secure front-end calls from the WebGL experience
4. Structured data logging for each user path

This eliminated:

1. Backend hosting costs
2. Deployment complexity
3. Maintenance overhead

The Result

After restructuring:

1. Build size reduced from 1.2GB → 68MB
2. Drastically improved load time
3. Lower hosting costs
4. Stable WebGL performance
5. Reliable participant data logging
6. Deployed successfully within 1 week

Strategic Insight

Most Unity WebGL projects fail because:

1. They treat WebGL like a desktop build
2. Media-heavy content is embedded instead of streamed
3. No architectural thinking is applied before deployment

Optimization is not just compression.

It’s architectural decision-making.

This project wasn’t just about reducing file size.

It was about making a research tool viable for real-world deployment.

If you're dealing with:

• large Unity WebGL builds

• slow load times

• deployment issues

• unstable browser performance

I run technical audits for teams preparing to ship or scale.

Request a Unity/WebGL architecture audit:

Contact Ali Raza about your project