Why Web Games Run Slower on Mobile

The GPU Architecture Gap

Desktop GPUs from NVIDIA and AMD use an immediate mode rendering architecture. The GPU receives draw commands and processes them straight through the vertex and fragment pipeline, writing results directly to a framebuffer in dedicated video memory. This dedicated VRAM sits on the graphics card itself, connected by a wide, fast memory bus. A mid-range desktop GPU in 2026 offers 200-400 GB/s of memory bandwidth to its VRAM, which means it can read and write enormous amounts of texture and framebuffer data every frame without breaking a sweat.

Mobile GPUs from Qualcomm, ARM, Apple, and Imagination Technologies work completely differently. They use tile-based deferred rendering (TBDR), an architecture designed around the reality that mobile devices share their system RAM between the CPU and GPU. Shared RAM bandwidth on a mobile device typically falls between 30 and 50 GB/s, roughly one eighth of what desktop VRAM provides. To compensate, the mobile GPU divides the screen into small tiles (commonly 16x16 or 32x32 pixels) and processes each tile entirely within a small, fast on-chip memory buffer. This avoids the bandwidth cost of reading and writing the full framebuffer for every pixel operation, but it adds an extra binning pass where the GPU must first sort all scene geometry into the tiles it overlaps.

This means that operations which are cheap on desktop can become expensive on mobile. Switching render targets forces the GPU to flush the current tile buffer back to system memory and load a new set of tile data, which consumes bandwidth that the desktop GPU would never need to spend. Reading back pixel data from the GPU, something that some post-processing techniques require, is especially costly on TBDR architectures because it breaks the deferred nature of tile rendering and forces the GPU to resolve tiles early.

The raw compute power gap is also significant. A desktop GPU might have 5000+ shader cores running at 1.5-2.0 GHz, while a flagship mobile GPU has 500-1000 cores running at 600-900 MHz. The thermal and power envelope of a phone simply cannot sustain the same clock speeds and parallelism as a desktop card plugged into a wall outlet. Budget Android phones, which still represent a large portion of the global mobile market, have even fewer shader cores at even lower clock speeds.

Memory Bandwidth Is the Real Bottleneck

Developers who are new to mobile optimization often focus on shader complexity or polygon counts, but the actual bottleneck on most mobile devices is memory bandwidth. Every texture sample, every framebuffer read, every vertex buffer fetch consumes bandwidth from the shared system RAM bus. When total bandwidth demand exceeds what the memory subsystem can deliver, the GPU stalls waiting for data, and frame times increase regardless of how simple your shaders are.

Consider a concrete example. Rendering a full-screen quad with a post-processing shader that reads from two input textures (say, the color buffer and a depth buffer) at 1080p resolution involves reading roughly 16 MB of texture data per frame. If you chain three such post-processing passes, that is 48 MB of reads plus the writes for each pass's output. At 60 fps, that single chain of post-processing consumes about 5-6 GB/s of bandwidth, which is 10-15% of the total bandwidth budget on a typical mobile device. On desktop, the same chain would consume less than 2% of available bandwidth.

This is why rendering resolution matters so much on mobile. Reducing the game's internal rendering resolution from 1080p to 720p cuts the number of fragments by roughly 55%, which directly reduces both the GPU compute load and the bandwidth consumed by framebuffer reads and writes. On a high-DPI phone screen, the difference between rendering at native resolution and rendering at 70% is often imperceptible, but the performance improvement can be the difference between a playable game and a slideshow.

The Browser Adds Layers of Overhead

Running a game in a native mobile app is already harder than running it on desktop. Running it in a browser adds further overhead that widens the gap. On most platforms, the browser translates WebGL calls through ANGLE (Almost Native Graphics Layer Engine) before they reach the native graphics driver. On Android, ANGLE converts OpenGL ES calls to Vulkan or the device's native OpenGL ES driver. On iOS, the browser translates WebGL to Metal internally.

Each translation step adds CPU time. A WebGL draw call must be validated by the browser's security layer (to prevent one tab from reading another tab's GPU memory), translated by ANGLE, and then processed by the native driver. The cumulative cost per draw call is typically 2-3x higher than the same call made from a native app. This means that a mobile web game has a significantly lower draw call budget than a native mobile game on identical hardware.

JavaScript execution also carries overhead compared to native code. While modern JavaScript engines (V8 in Chrome, JavaScriptCore in Safari) are remarkably fast, they still run interpreted or JIT-compiled code that cannot match the performance of pre-compiled C++ running through a native game engine. WebAssembly closes much of this gap for compute-heavy logic, typically running at 70-90% of native speed, but the boundary between JavaScript and WebAssembly adds its own overhead if crossed frequently per frame.

The browser's compositor takes a slice of the GPU budget too. Mobile browsers use GPU-accelerated compositing for smooth scrolling, and the game's WebGL canvas is one layer in the compositor's output. Compositing the game canvas with any browser UI overlays (address bar, tab strip, system notifications) costs 1-3 milliseconds per frame on typical mobile hardware. In a 16.6 ms frame budget (60 fps), losing 2 ms to compositing represents a 12% tax that native apps do not pay.

Thermal Throttling Punishes Sustained Workloads

Desktop computers have heatsinks, fans, and sometimes liquid cooling systems that can dissipate hundreds of watts of heat indefinitely. A desktop game can run at maximum GPU utilization for hours without any performance degradation. Mobile devices have no active cooling. They rely on passive heat dissipation through metal chassis and glass screens, and their thermal design power is typically 3-7 watts versus 150-350 watts for desktop GPUs.

When a mobile game pushes the GPU and CPU hard, the device heats up within minutes. The operating system monitors junction temperatures on the SoC and starts reducing clock speeds when they exceed safe thresholds. This is thermal throttling, and it can reduce both CPU and GPU clock speeds by 30-50%. A game that initially runs at 60 fps can drop to 35 fps or lower after five minutes of continuous play, with no change in scene complexity.

This makes sustained performance a different problem than peak performance. A mobile device can briefly burst to high clock speeds when a game loads a new scene or triggers an explosion effect, but it cannot sustain those speeds. Game developers must design their rendering budget around the sustained performance level, not the peak, which means targeting a lower baseline frame rate or using less of the GPU's capacity to leave thermal headroom.

Memory Limits and Browser Tab Pressure

Desktop games routinely use 2-8 GB of RAM for textures, geometry, audio, and game state. Mobile browsers allocate each tab a much smaller memory budget. On Android, a browser tab typically gets 150-300 MB before the OS begins applying memory pressure. On iOS, Safari is more aggressive, often killing tabs that exceed 100-200 MB. These limits include everything the tab uses: JavaScript heap, WebGL textures, WebAssembly linear memory, audio buffers, and DOM elements.

Exceeding the memory budget does not produce an error message. The browser simply terminates the tab and the player sees a "page crashed" or "page reloaded" screen. There is no graceful degradation or warning. This makes memory management a critical concern for mobile web games. Texture atlases must be carefully sized, audio should be compressed aggressively, and assets should be loaded and unloaded dynamically based on what the current scene requires.

The combination of all these factors, weaker GPU, lower bandwidth, browser translation overhead, thermal throttling, and tight memory limits, explains why mobile web games run slower than the same game on desktop. Each factor alone might cause a 20-30% performance reduction, but their compound effect can easily result in a 3-5x performance gap between desktop and mobile for the same game code.