=Background=
We have multiple tasks for increasing the performance for the mobile web, Lets look at the background why it is super important to have a site that is fast for users with slow (2G) connections.
==2G usage in the world==
First lets look what kind of connections people uses in the world. Almost no one have 2G in North America but the rest of the world the situation is different.
{F2885377, width=600}
Then it becomes really interesting by looking at the same numbers but scaled by market size:
{F2885379, width=600}
==Next 5 years==
This graphs shows us what the growth will look like for smartphones:
{F2885381, width=600}
The growth will happen where there's a lot of 2G users.
==Proxy browsers?==
But what about "proxy" browsers? A proxy browser is a browser where the content is prepared on the server side like Opera Mini, UC or Chrome with data reduction turned on. These browsers are mostly used where the connection type is slow and make the browser experience better. The numbers I've found doesn't perfectly add up but it seems like these browsers are still a fraction of the internet traffic. The first image shows percentage by OS where proxy browser are in the **others**.
{F2887818, width=600}
And this chart show how much is actually by individual proxy browser:
{F2887822, width=600}
The proxy browser users are a fraction of the total browsers.
All the graphs are taken from Tim Kadlecs talk [[ https://speakerdeck.com/tkadlec/better-by-proxy-at-velocity-ny-2015 | Better By Proxy ]] and Maximiliano Firtmans talk [[ http://www.slideshare.net/firt/extreme-web-performance-for-mobile-devices-54478615 | Extreme Web Performance for mobile devices ]].
=Conclusion=
The majority of the mobile users in the world uses a 2G connection, the growth will happen in the countries where the 2G usage is highest. And proxy browsers usage is low so it doesn't solve the problem. We need to have a site that is fast on 2G.
=Actions=
There are a couple of things that needs to be done to make the mobile experience faster (high level):
* decrease the size of HTML sent to the browser (send a small chunk first so the browser can start render and then lazy load the rest)
* inline the most important CSS so that the page can start render with only HTML (and lazy load the rest)
* decrease the image sizes (higher compression) and lazy load images
When we have that, we can look at changing the inlined data:image encoded images to be real images because they halt the rendering + takes extra CPU to create for the browser.
An alternative is also to look at the possibility to mark IP:s as slow and serve a specific version of the site to slow networks.