Phones Crash on Memory, Not Bandwidth

A client site we worked on kept crashing on phones. Not loading slowly, crashing: the tab would reload itself or go blank a few scrolls in. The first assumption was hosting. Moving to a stronger hosting plan did not fix it, because the problem was never the download.

Small files can become large in memory

The homepage opened with a scroll-driven animation built from a few hundred still frames. Compressed, the frames were a modest download. But a browser cannot draw a compressed image. It decodes each frame into raw pixels first, and a single full-width decoded frame can take several megabytes of memory. Hold a few hundred of those and a phone's browser simply runs out and kills the tab.

Desktop browsers have far more memory to spare, which is why the same page worked perfectly on a laptop. The bug only existed on the devices most visitors were using.

The fix was to send phones something different

The solution was not to shrink everything for everyone. Desktop kept its full animation. Phones got a single short video, about a megabyte, playing the same motion. One video decoder instead of hundreds of decoded images. The other heavy media on the page got mobile versions too, and only the clip actually on screen was allowed to load.

The page went from asking phones to handle hundreds of megabytes of media to asking them for a few. It stopped crashing.

Test on the device your audience uses

The broader lesson is about where testing happens. Most sites are built and reviewed on large screens with fast machines. Most visitors arrive on a phone, often on a mobile connection. A page is not finished until it has been scrolled end to end on a mid-range phone, repeatedly, without crashing.