OYO on a User Experience Quest with AMP ⚡

OYO AMP Pages

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).

Look for a lightening-bolt icon for a lightening-fast experience

“Why did we go for AMP?”, You Might Still Ask

  • Brings instant rendering to web content, cached by Google.
  • Resources are lazy loaded.
  • All JavaScript is async — does not block the page.
  • 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

AMP pages do not allow custom scripts. Which means that now we don’t have the JavaScript playground we so clumsily exploit to our will. For styling, only internal CSS is allowed on an AMP page, that too with a cap of 50,000 bytes maximum. Also, for many popular elements of a web page, like images and forms, you will have to switch over to well-defined AMP elements and practices.

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.

AMP-Lightbox to the rescue

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.

In our analytics, we started seeing around 400 pages listed as “invalid AMP” by Google. The reason: User-authored JavaScript found on those pages.
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).

The puzzle of peculiar AMP stats!

Of-course, no scripts were there from us. But then, who was the culprit?

After a series of mails to Google AMP Discussion Groups and thorough debugging, it was found that Akamai, CDN provider, inserts a custom javascript for a small percentage of URLs. That unpredictability of the bug was making it even more difficult to reproduce! But we the bunch of Sherlocks here finally got around that mystery.

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.

Designing it similar to the PWA — A step in the right direction

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.

Mic Drop…

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.