Speeding up your website with new HTML picture magic.
A new HTML wrapper.
Will it speed up your website?
HTML has served as a backbone for millions of websites over the internet, but there are times when websites don’t deliver content at a fast enough pace. After having encountered a set of issues with current active HTML-based websites, web developers have planned to solve this problem for numerous individuals who’ve invested a good amount of time, money and efforts into building a perfect website, only to see visit rates decrease because it took too much time to load.
Through this post, I’ll be highlighting for you the significance of adding new HTML into an existing portal for improving its overall performance and speed. I’m sure by the end of this post, you will be ready to incorporate additional HTML into your website that will make it better.
Why new HTML?
It was the problem of images that gave birth to the concept of adding new HTML. Out of a total of 1.7 MB web space occupied by the average single webpage, nearly 1MB of that space, or close to 60% of all web space is occupied by images. If you have a fast internet connection, then even an image payload doesn’t pose a problem, but if you’re using a mobile network then a huge image payload can actually slow down how you load the website as a whole. Image tags are also currently set up to deliver all of their contents to a web page, even when it’s not fully needed as in the case of mobile websites. This leads to a huge amount of wasted loading time.
To address this issue, a lot of site owners opted for building a second mobile-only version of their main website. Though this sounds a bit crazy now, just a few years ago, this was actually being done by entrepreneurs whose audience mainly comprised of people using their smartphones for accessing websites. Server-side device detection scripts were being used for redirecting users to a dedicated site for mobile devices, for example m.domain.com. These dedicated mobile URLs of websites were referred to as M-dot sites. Even now, if you go to https://m.facebook.com/, you’ll see the mobile version of the Facebook site—even if you’re on desktop!
Introduction of the picture wrapper
Something had to change.
Although it was convenient to decide there should be a new HTML element to solve the problem, actually navigating the idea through the complex world of web standards was not as easy.
These developers first took their ideas to WHATWG– one of the two groups that oversees the development of HTML. WHATWG serves as a good place for determining how browsers would ship web design/development ideas. WHATWG was, however, displeased when people outside it rendered suggestions as to what it must do. It was due to this that Marquis and his team of developers didn’t manage to get WHATWG interested in the new HTML element.
Then W3C– the second group that oversees HTML standards, launched a brand new idea called “community groups”. These community groups were W3C’s attempt to get outsiders involved in the standard process of working out solutions for slow-loading websites. The developers started their own community group which was further named as the Responsive Images Community Group (RICG).
It was the WHATWG group that eventually overcame its not-invented-here syndrome. With compromises taking place, the RICG rolled out support for a number of web design and development ideas that were set into their proposal for a new HTML element. Since all this wasn’t enough for convincing the WHATWG, the group members started working together with Marquis and RICG for turning their ideas into reality.
The big breakthrough from Opera’s Simon Pieters and Google’s Tab Atkins
Well-known developers Simon Pieters and Tab Atkins came up with a simple yet powerful suggestion of making the picture tag a wrapper for img instead of a separate element altogether. This way, specifying a set of rules for images depending on a set of conditions such as screen sizes was a lot easier, and less confusing—you would rely on the handy old <img> element, but just append conditions to it. The browser would then load whatever images you specified instead of loading one image, and then adapting it to different sizes—cutting down on load time for mobile websites that could now choose to load mobile-friendly images only.
The magic of responsive images has come to life, allowing mobile users to save their data and loading times without lifting a finger—creating better websites that load faster, and foster happier, more engaged users.
Here’s an example of what the code looks like:
"<img sizes="(min-width: 40em) 80vw, 100vw" srcset="examples/images/medium.jpg 375w, examples/images/medium.jpg 480w, examples/images/large.jpg 768w" alt="A giant stone face at The Bayon temple in Angkor Thom, Cambodia">"
In this instance, the sizes indicator specifies screen sizes where transitions are made between a medium sized image at 375w (anything below 80 vw) to a large image at 768w displayed at anything below 100vw to above 80vw.
vw is a CSS size unit that corresponds to the size of the viewport, or what is displayed to the end user. 100vw means 100% of the viewport’s width. Em is a similar sizing unit that corresponds to the height of your font in inches.
While work goes forward on deploying it in all major browsers, you can play around with the new setting at, and test it out yourself—http://scottjehl.github.io/picturefill/.
The web is constantly evolving. With this new HTML picture magic, you can make sure your users only load what they have to access your content. As communities of thinkers and developers advance new technologies, the way forward becomes quicker, better, and more powerful for all.
About the Writer:- Samuel Dawson is an expert writer/blogger. He has written many research articles on converting HTML to WordPress theme website. Besides all this, he is working for Designs2html Ltd. – A leading PSD to WordPress conversion service company. This article relies heavily on http://arstechnica.com/information-technology/2014/09/how-a-new-html-element-will-make-the-web-faster/ for source research.