In early 2016, Google launched Accelerated Mobile Pages (AMP) for publishers who wanted to have their content loaded in a flash on mobile devices at a much faster rate.
At the point of writing this article, 65% of all traffic in Asia (and this is higher for developer countries) is on the mobile. A bulk of these users are on mobile data networks which may not be as fast as a steady broadband connection.
What Google did therefore was to launch a series of initiatives, Weblight and now AMP that would help the search engine load the publisher’s content faster for the user.
Google is focusing on the user
The rationale that Google gave to publishers was that it focused on the user’s experience. If a user is doing a Google search on a choppy data connection, the search results might be presented in the blink of an eye, however, because the publisher’s site was taking too long to load, the user would get a bad experience … or worse, the user would say that Google is too slow!
With Google Weblight, what the organization did was to load the content on an interim site (which was Weblight) and display the content there. This created two problems –
- Publishers lost traffic, and Ad Revenues
- Publishers lost control on the format of their content and their style guides
Both reasons were strong enough for a lot of publishers to stay away from Weblight.
AMP gets introduced in the mix
To give some control of the content formats back to the user and also to incorporate both analytics and ad scripts into the publisher’s content, Google created another mark-up language. This is AMP.
AMP allows the publisher to present the content on their own site, in a style that’s acceptable to the publisher. It may not have too much flexibility, but at least the publisher is free to design that style instead of the Weblight approach.
This may not be an ideal situation, but atleast it ensures that users are shown the content they are search for the fastest.
Have people embraced AMP?
Well, it’s a bit hazy there. For those of us who were on existing Content Management Systems (CMS) such as WordPress or Joomla it was much easier to transition. It just meant having to install some plugins and do the configuration.
However, the folks who have made their own web apps and products, they are completely clueless as to how to go about implementing AMP.
The sad part is that a lot of the product developers that I have spoken to, are of the opinion that AMP is just a new thing that “SEO folks” have to do. Add to the mental model of SEO being perceived as a much lower the value chain task – that pretty much means that developers are simply not aware about the benefits of AMP.
What irks me is that people’s individual bias is used to mask their ignorance about how to make their products perform better on search.
So, if you are leading a product team or are working on building products, then definitely head on to the Accelerated Mobile Pages project.
As a publisher who has embraced AMP, how does that impact me?
It surprisingly does not help me much with acquiring more traffic. The website is shown a bit differently in the search engine results, and that perhaps is getting me a bit higher click through rates. However, the numbers are not significantly high enough for me to assess based on the data provided.
One major problem with all new initiatives that Google is doing with Search is their stubbornness on keeping things completely opaque.
Not a single publisher is in the loop when it comes to knowing what was the exact payoff of any of the optimization activities they did. It is left for these teams to dig in and figure it out themselves before they are able to attribute the success of this activity. I believe that’s a major deterrent for a lot of product managers to make this choice of embracing AMP.
The web is not Google
I am coming back to this post after 6 months, found this on the internet – the AMP Letter. This is pretty much what I wanted to say about how this is shaping up.
