Accelerated Mobile Pages (AMP) HTML has re-stirred some interesting discussions around everyone’s favourite punching bag: the performance of mobile responsive websites. There are legions of libraries, optimizers, techniques and an almost comparable number of gurus and evangelists out there, who claim to positively affect its performance.
So what is the big deal about it? Well, if you like reading stories about the boy who lived, then the modified HTML tag: <html ⚡> would seem really appealing. Half obvious references aside, let me point out the lines that AMP HTML wants to draw and the promises it makes.
While recovering from that last boulder-hit, let me tell you that AMP does use JS internally for its components. However, it claims that their JS is optimally written and hence would not interfere with the performance. Honestly, these guys have a point. Yours truly has been at the receiving end of the performance circus when multiple JS libraries needed to be included for some UI element or fancy animations. No matter, how optimally one tries coding and testing, third-party libraries just take things out of our control every once in a while.
So, what is the alternative then? How do we get those neat modal popups and floating assessment forms that our designer loves to throw at us? Polymer. X-Tag. Bosonic. These three neat allowable libraries can be used together with custom HTML elements to serve our UI needs. These three are pretty powerful libraries that can rival some of the best third-party JS out there. Just have a look at these sites built with Google Polymer if you don’t believe me. AMP HTML also provides their set of components through a JS library, which has a decent set of tools to play with.
AMP HTML is also very wary about ads and analytics. The scripts that we include for conveying ads or conducting analytics often leads to performance degradation, which can’t be helped if the ads or analytics data is indispensable. So doing away with them can’t be an option and AMP HTML acknowledges that fact. It allows the inclusion of tracking pixels in the document. This means that it supports basic analytics while relaying that information to a more powerful backend. It maintains that JS cannot be a part of the analytics components in the page.
For the purpose of ads, one can use iFrames to embed ads but not have any JS-wizardry-animations happening on the website. The content is also given higher priority while loading the page while the ads are served up later.
Till now, we have seen what all AMP HTML prevents. Now, let us also see some other techniques that AMP HTML uses in its quest for performance optimization.
The resources that one loads in a page must declare up their sizes in the tags. The structure binds resources to these sizes and does not allow any mutation of the same, unless there is a user action triggering it. This is a good way to prevent some innocuous looking script that later downloads a truckload of data and balloons up. Not the best solution, yes. But a good start. And that’s exactly what AMP HTML is admitting to. They are clear on the aspect that their work is far from done and it is going to take a lot more work to make sure that web-pages load well and fast.
Using predictable performance, minimizing HTTP requests, helping browsers pre-calculate resource size, AMP HTML is geared up to possibly made some head way into the mobile-web performance optimization front. And of course, Google is already serving AMP HTML documents through their CDN. They are always there, egging and helping the newer guys to solve their problem.
I am really curious to know how these guys shape up going ahead. What do you feel about this new way of doing good old HTML? Let me know in the comments!