It is already a high time for every tech company out there to provide their services flawlessly on mobile devices, and so the world is exploring light-weight and lightening-fast ways of serving mobile websites. One such way is Accelerated Mobile Pages (AMP). Some time ago, the AMP party was joined by a new member: OYO Rooms, the technology-driven largest hospitality company in India.
Accelerated Mobile Pages in Two Sentences
AMP is an open-source set of web development guidelines, which encourages you to display only the contents that matter on a page and get rid of all the elements that take a toll on performance.
If validated as AMP standard, the page will find its place in Google AMP cache and will be served blazingly fast from the search results (differentiated from other search results by a special AMP tag symbol “⚡” in the SERPs).
“Why did we go for AMP?”, You Might Still Ask
- Brings instant rendering to web content, cached by Google.
- Resources are lazy loaded.
- Inline (and limited) use of stylesheets. One less HTTP request!
- Even more…
The whole idea is to shred (or else, modify) the excess functionality which in-turn gives a boon of speed. Hence, AMP was decided to be piloted on the SEO pages of OYO website.
Basically, the OYO “SEO Pages” are Search-targeted pages which act as a bridge between users and their bookings! For example, the Hotels in Delhi page will contain the list of OYOs in Delhi for presenting the choice of moving forward with one of them to the user. Since they target users coming from search engines, it is highly impactful to convert them to AMP, so that the pages come served from Google’s cache in a blink of the eye.
Challenges We Faced with AMP
We reckon what AMP is trying to say by all that is “less code == good code”, which by the way is true! Through all these restrictions imposed, what we ultimately saw is that AMP is quite resourceful even in its minimalistic approach. There is a rich set of AMP-standard components that are available and can satisfy the lack of scripts on a web page.
That was our way to salvation, as we shall see in the following section…
Using AMP Components & Making Stuff Work
As it turns out, AMP Components can be utilised for a wide range of UX operations — from showing an accordion to submitting forms! For popping up the necessary modals, there was AMP Lightbox ready to help. For tracking and analytics, we took the services of AMP Analytics component. So on and so forth.
Coming to the CSS part, we trimmed down any included libraries to only the parts that were specifically needed to style the AMP page. We also recognised that some script-based components and actions can be easily changed to being handled by CSS itself.
The Mystery of the Invalid AMP Pages
After the launch of AMP, a rather mysterious issue appeared in front of us.
The mysterious part was that we were watertight sure that no invalid practice was there on our AMP pages, let alone some custom scripts, which was definitely an AMP-sin. Those pages even showed as a valid AMP when testing AMP-validation on our side (which can be done by appending a #development=1 to the URL).
Of-course, no scripts were there from us. But then, who was the culprit?
Reaping the Benefits
Firstly, let’s address how AMP helped us on the one aspect it so proudly shows-off — speed.
Getting rid of unnecessary components and leveraging the Google cache simply guarantee that users meet the content as soon as possible.
In fact, the loading speed of these pages was reduced from 2.2 seconds to 250 milliseconds (on wifi internet) and from 7.5 seconds to 800 milliseconds (on slow networks) on average, showing a whooping improvement of more than 90%.
Some brownie points for layout & design of these pages which came in sync with the OYO PWA theme, which was necessary for a good user-experience.
As a cherry on the cake, we got our service worker preinstalled on the AMP pages (thanks to the AMP-Install-Serviceworker component) for a faster PWA experience when the user steps into that territory.
Sure, there have always been some misconceptions and some genuine criticism about AMP. But, as Bjarne Stroustrup once so famously put it,
“There are only two kinds of languages: the ones people complain about and the ones nobody uses”.
At the end, it all boils down to one thing — the everyday quest of serving a better user experience than it was last night. The frameworks will have their ups and downs; Tools & guidelines will come and go… What matters the most is the ability to embrace the change (and revert, if it isn’t working for you).
That is what we focus upon the most here, and eventually strive to build experiences that are truly inn-oyo-vative.