How a new HTML element will make the Web faster (Part 1)

Diem Do

Soon, you won’t need to be the Flash for quicker Web browsing.


The Web is going to get faster in the very near future. And sadly, this is rare enough to be news.


The speed bump won’t be because our devices are getting faster, but they are. It won’t be because some giant company created something great, though they probably have. The Web will be getting faster very soon because a small group of developers saw a problem and decided to solve it for all of us.


That problem is images. As of August 2014, the size of the average page in the top 1,000 sites on the Web is 1.7MB. Images account for almost 1MB of that 1.7MB.


If you’ve got a nice fast fiber connection, that image payload isn’t such a big deal. But if you’re on a mobile network, that huge image payload is not just slowing you down, it’s using up your limited bandwidth. Depending on your mobile data plan, it may well be costing you money.


What makes that image payload doubly annoying when you’re using a mobile device is that you’re getting images intended for giant monitors loaded on a screen slightly bigger than your palm. It’s a waste of bandwidth delivering pixels most simply don’t need.


Web developers recognized this problem very early on in the growth of what was called the “mobile” Web back then. So more recently, a few of them banded together to do something developers have never done before—create a new HTML element.


In the beginning was the “mobile Web”


Browsing the Web on your phone hasn’t always been what it is today. Even browsing on the first iPhone, one of the first phones with a real Web browser, was still pretty terrible.


Browsing on a small screen back then required constant tapping to zoom in on content optimized for much larger screens. Images took forever to load over the iPhone’s slow EDGE network connection, and then there was all that Flash content. That didn’t load at all. And this was the iPhone; browsing the Web using Blackberry or other OSes crippled mobile browsers. It was distinctly worse.

It wasn’t necessarily the devices’ fault, though mobile browsers did, and in many cases still do, lag well behind their desktop brethren. Most of the problem was the fault of Web developers. The Web is inherently flexible, but developers confined it by optimizing sites for large desktop monitors.


To address this, a lot of sites started building a second site. It sounds crazy now, but just a few years ago the going solution for handling new devices like the Blackberry, the then-new iPhone, and some of the first Android phones was to use server-side device detection scripts and redirect users to a dedicated site for mobile devices, typically a URL like


These dedicated mobile URLs—often referred to as M-dot sites—typically lacked many features found on their “real” desktop counterparts. Often, sites didn’t even redirect properly, leaving you on the homepage when you wanted a specific article.


M-dot websites are a fine example of developers encountering a problem and figuring out a way to make it even worse. Luckily for us, most Web developers did not jump on the M-dot bandwagon because something much better soon came along.


Responsive design killed the M-Dot star


In 2010, Web developer Ethan Marcotte wrote a little article about something he called Responsive Web Design.


Marcotte suggested that with the proliferation of mobile devices and the pain of building dedicated M-dot sites, it might make more sense to embrace the inherently fluid nature of the Web. Instead, he argued, let’s build websites that were flexible. Marcotte envisioned sites that used relative widths to fit any screen and worked well no matter what device was accessing it.


 Ethan Marcotte’s original responsive demo site at roughly phone, tablet, and desktop screen sizes.


Marcotte’s vision gave developers a way to build sites that flex and rearrange their content based on the size and characteristics of the device in your hand. And while responsive Web design wasn’t perhaps a panacea, it was pretty close.


Responsive design started when a few more prominent developers made their personal sites responsive, but it quickly took off when Marcotte and the developers at the Filament Group redesigned the Boston Globe website to make it responsive. The Globe redesign showed that responsive design worked for more than developer portfolios and blogs. The Globe redesign showed that responsive design was the way of the future.


While the paper’s re-do was successful from a user standpoint, Marcotte and the Filament Group did run into some problems behind the scenes, particularly with images. Marcotte’s original article dealt with images by scaling them down using CSS. This made images fit smaller screens and preserve the layout of content, but it also meant mobile devices were loading huge images with no intention to ever be displayed at full resolution.


For the most part, this is still what happens on nearly every site you visit on a small screen. Web developers know, as the developers building the Globe site knew, that this is a problem. Yet, solving it is not as easy as it seems at first glance.


That dilemma is what led to today. Solving this image problem required adding a brand new element to HTML.

Part 2


Share the news now

Source :