By Joe Levi | December 19, 2013 3:22 PM
Last week Stephen Schenck brought us news about some changes coming to the Google Chrome Beta channel, specifically the elimination of an artificial 300 ms lag. Why would anyone deliberately add almost 1/3 second delay to interactions with web pages? Believe it or not, there’s a legitimate reason behind it — but it’s one that Google intends to remove — when applicable.
One of the major challenges Apple, Google, Microsoft, and others faced when creating their mobile operating systems was the development of a web browser to include on their devices. It doesn’t sound all that difficult, but web browsers on a desktop PC often occupy hundreds of MB on disk and can consume several times much that in RAM. It’s not terribly difficult to see why it’s been so difficult to put a fully-functional browser into a mobile device.
It doesn’t stop there. When smartphones were starting to take off, most websites were built around a screen resolution of 800 x 600. Rather, sites were developed so they could be properly displayed in a browser windows that fit on screens running at that resolution. This led some to strive for “pixel perfect” implementations of site designs — something that is a literal impossibility due to the almost infinite combination of screen sizes and resolutions, browser versions, operating system versions, color depth, browser window size, and more. These are considerations that I have to work with every day as a web developer, but are particularly troublesome once you take mobile platforms into consideration.
Since there were few “mobile-friendly” websites back in those days, mobile browsers had to scale content to fit on their smaller screens, and allow for some way to zoom in on specific areas. Apple adopted the pinch-to-zoom metaphor, but Android and others originally used a double-tap to zoom in.
Since there is no such thing a “double-click” in web development, mobile browsers were able to add their own interaction layer on top of the page and capture this event to handle taps — whether on links, or to zoom in or out.
Programmatically, what’s a double-tap?
From a programming standpoint, a double-tap is simply two taps separated by a short amount of time. In order for the mobile browser to determine if you are single-tapping or double-tapping, it has to wait a little while after the first tap to see if you’re going to tap again.
That delay is almost universally 300ms — essentially 1/3 of a second. During that time the browser just sits there and waits to see if you’re going to tap again. This gives the user the impression of “slowness” or “lag” if they’re not double-tapping.
The delay isn’t necessary anymore
Now that web developers have had a chance to see how popular and powerful mobile devices are, they are coming around to the idea of writing for mobile first — and for desktop and laptop second. Marketing managers are seeing traffic from mobile devices trend upward, and by most estimates, that’s where the bulk of all web traffic is going to come from before long.
As such, developers are gradually converting the web to a mobile friendly experience, one site at a time. Once they’ve done so, they add one “magic” line of code to their pages:
The “viewport” is the window in which the web page is displayed. The other part says that it’s designed to fit inside whatever the width of your web browser is — mobile or not. In other words, if the developer added that line to the web page, the browser can rest assured that the page is designed to work on your mobile device — without scrolling or zooming.
On those pages, that 300 ms delay is no longer needed, and is simply one more thing that makes people think that HTML5 web apps are “slow” or “laggy. To take advantage of that, Google is now rolling out a beta version of their Chrome browser for Android that will bypass the 300 ms delay on sites that don’t need it — which speeds them up considerably.
Check out this video, which illustrates the concept:
Source: HTML5 Rocks