Chapter 8 of 15

Mobile First

More than half the web is on a phone

Since mobile surpassed desktop in late 2016, the majority of time people spend on the web is from mobile devices. As of 2026, mobile accounts for roughly 62% of global web traffic, and in regions like India and Africa that number is over 70%. For many websites, mobile is the default and desktop is the exception.

This won’t be true for every website. npm’s website, for example, was only about 8% mobile users — but that makes sense, because the only thing you can really do on npmjs.com is read package documentation. The 8% of mobile users were developers coding on a laptop who didn’t have enough screen real estate, so they opened the docs on their phone. Apparently this is how some people code.

But for the majority of websites, you have to consider the mobile case, and you have to consider it first.

Phones are convenient but limited

The thing about phones is that they’re super convenient but kind of terrible as web browsers. They have slow and unreliable internet connections. They don’t execute JavaScript as fast. If 80% or 90% of your users are coming in on a phone, making a rich web app is a terrible idea — because you’ve just added five or ten seconds to their load time.

People on phones do not have five or ten seconds to give you. According to a Google study, 53% of mobile site visits are abandoned if the page takes longer than 3 seconds to load.

So if your cool rich web app takes four seconds to load on a phone, you’ve just thrown away more than half your users. If the only way to get your information loaded in two seconds is to send them flat HTML — do that. It’s better than any possible alternative that takes longer.

Design for the phone, enhance for the desktop

Most of the time, what you’re building is a web app that’s going to be used on a phone. Occasionally, if people really, really like what you’ve built, they’ll do the horrible work of getting up, walking ten feet to a larger screen, and using it there. But the phone is the default.

This means: design for the smallest screen first. Make sure it works, makes sense, and loads fast on a phone. Then add enhancements for larger screens. Not the other way around.

Designing the for device people are actually using is the tip of a larger iceberg that is accessibility.