Tim Kadlec: Better by proxy

Tim Kadlec was talking about proxy browsers at Mobilism, these are my notes from his talk.

In the west we have a very picturesque view of the web - we have good technology and connections. This skews our view of the web, how we experience it is detached from how most people experience the web.

Lots of 'modern' web technologies don't work in proxy browsers. We're used to the places where 'modern' technologies aren't well supported. If we want to cater to the emerging global market we need to think about how they access the web. Technology used is "good enough".

In the west we typically have 10x the bandwidth of developing nations. Pakistan started rolling out 3G in 2014. It's going to take a while for this to catch on. Iran had 0.1% 3G penetration after two years. Authorities often throttle connections to control information - speed is a weapon in this battle. Our internet is not their internet.

The power of the web is its reach, universal access is a fundamental principle protected by the UN. Its capabilities are increasing rapidly - we respond to this by throwing more stuff at things. This doesn't scale, the cost of the data required to load average website can be a significant proportion of daily income in some area.

Proxy browsers are a response to this: UC has 35% of market share in China. Opera has 168 billion pages transcoded in a month. Puffin is the top 5 tablet browser in 40 countries.

Conservative to aggressive scale for proxy browsers.

Typical browser requests assets from the server, constructs the DOM and CSSOM to create a render tree before layout and then paint. Requests are network constrained, the render is device constrained. Proxy browsers focus on optimising both of these to different degrees. Conservative browsers focus on the network, aggressive does both.

All requests get routed through another server that actually makes the request over a low latency, high bandwidth, network. It can then alter the request before sending it through the mobile network back to the device. They will do gzip, minification, image minification - users can change these in preferences. They can optimise the images to the best format.

Conservative proxy browsers do all the things developers should be doing anyway, they now behave fairly well and give you HTTP request headers. Comments get stripped - don't rely on them (or use Cache-Control: no-transform <- don't do this¹). Images can be removed - use alt text. Data savings can be good - claimed to be up to 50%. Real data suggests it's about 55% in practice.

Aggressive browsers are effectively remote browsers. The page is rendered on the server and something is passed back to the client on your device. The client isn't a browser, it's a viewer for a propitiatory data format. Any interactions that need to use the network have to go back to the server which re-renders the page and sends a new snapshot. All interaction requires a trip to the server, they aim to minimise data transferred so a lot of events are disabled, mostly input and interactions but also timeouts, intervals, Ajax. UC mini makes Opera mini look good in this regard. If you turn speed mode off in UC it's just a WebView rather than a proxy browser.

Puffin has a permanent connection that only passes back the diff between two states of server rendering. They can provide more of a traditional interaction with more events being responded to.

Proxy browsers are based on traditional rendering engines:

• Opera: Presto
• Puffin: Blink (C30)
• UC: WebKit fork

However, they have features disabled - don't think of them as the same as the rendering engine they are based on.

Browser compatibility issues

UC mini

• no icon fonts
• claims to support SVG but doesn't
• has a different UA string on client and server
• claims to support localStorage but doesn't when you try and use it.

Puffin

• has a "desktop" mode that sets the viewport to 1024px but also has a whitelist that is manually managed by Puffin for wider than 1024.

Single column view

• used by Opera mini and UC - puts the entire page into a linear layout based on source order.
• Opera mini will respect handheld styles.
• UC mini is a little nuts. Sets 1024px viewport, applies media queries and then turns it back into 320px viewport.

Data savings can be up to 90% on these aggressive browsers.

These browsers are ideally suited to low power devices on IoT devices.

• Progressive enhancement
• Responsive design
• No heavy JS frameworks
• Cut the mustard

This is the same as building for a robust web. Give up the control we never had.

Footnotes

1. The note saying "don't do this" was mine, not something Tim said. My reason was that I could see a cargo cult in the making so didn't want people (my future self included) thinking this was a good idea.

   The reason we would set the no-transform header is to prevent our content being transformed by a proxy server. However, we should be building websites in such a way that it doesn't matter if the content is being transformed by a proxy server. Of course there will be irresponsible proxy servers who do break things during transform but - fundamentally - that's their problem, not ours. However, by using this header to guard against irresponsible first or third parties we penalise responsible second parties (our users) who would benefit from content transformation.

   The cargo cult situation I was trying to head off is that if it started getting around that adding this cache header was an "easy fix" for dealing with proxy browsers then it would start getting added to boiler plates meaning it would be used when it wasn't required (i.e. nearly all of the times it was used) and proxies would then stop respecting it as it was effectively meaningless. (If that seems like an implausible scenario then consider that we're still dealing with the accessibility fallout from people advocating adding maximum-scale=1.0 to viewport declarations to "fix" the way the iPhone handled orientation change long after that behaviour changed.)

   Anybody (my future self included) who knows enough to ignore my warning will do so but, for the rest of us, the sensible default should be to not use this cache header. ^{^}