eg. Facebook or Google Analytics
Example of hte page load speed on an AMP page vs non-AMP page

Paul Thornton - Friday 14th December 2018


AMP, PWAs and PWAMP – what do they mean for your SEO Strategy?

The web is changing, and we need to keep up. Acronyms are on the attack! But don’t worry, we’re here to help.

Google has stated that speed is of the essence – in 2016, Gary Illyes of Google stated: “Speed is the biggest factor driving engagement on the mobile web”. There are, what feels like, an infinite number of studies linking page speed with engagement and conversion metrics, many here on the Hubspot blog, so I won’t go into that now, but take it from me and the many industry professionals talking about it – it’s a big deal!

Google feels that it’s a big deal too. Starting earlier last month (July 2018), Google released the speed update which brings Page Speed as a ranking factor in mobile search. Currently, it only impacts a small number of queries and only affects the slowest pages, so unless your website is seriously slow, then you don’t have too much to worry about.

However, it’s a statement of intent and, like all things Google, don’t expect it to continue to affect just a small number of pages. Because of this, I recommend you get proactive. Here’s how you can.

AMP

AMP stands for Accelerated Mobile Pages. It’s basically a stripped back version of the page. When Google launched AMP, they were originally targeting them at news and recipes – they were initially created for static and semi-static content, rather than say a product search results page, reliant on database calls. However, the net has been widened and many pages can now be marked up as AMP, indexed and served by Google. As a result, eBay, Overstock, Ali Express and more are marking up with AMP in the quest for increased page speed.

See the difference in page speed from AMP and the regular landing page below:

Example of hte page load speed on an AMP page vs non-AMP page

Original Image

It has 3 features:

  1. AMP HTML – which is standard HTML with a number of restrictions,
  2. AMP JavaScript – which has a limited and restricted set of JavaScript
  3. AMP Caching – these serve and validate AMP pages and they significantly assist with serving the page faster.

I mentioned restrictions twice above – this is done for a couple of reasons. Firstly, because there’s a limited amount of code to choose from, it cuts down any inefficient code which helps speed the page up. Secondly, because the content from AMP is cached (and compressed and minified) within Google’s cache, the cache doesn’t need to get it from your site due to the code being standardised, – it can just pull the content and build it internally.  This means that the content can be served directly from Google significantly quicker than your server will likely be able to*.

(* Caveat – it is possible to create a site that is as quick as AMP, but will likely require significantly more development time than choosing from the AMP standard).

Other than the obvious advantage of page speed, there are also additional advantages of AMP pages. The main one is the AMP carousel and promotion of AMP using the lightning icon. You can see from the following image how many of the results are AMP:

AMP Carousel SERP Feature Screenshot

(link to big image)

In addition, there have also been studies to show that AMP has improved engagement with lower bounce rates, more time on page, and the main thing that most people are looking for – increased conversions.

If you’re a publisher, there is also evidence to show that Ads on AMP are delivering higher viewability, higher clickthroughs and higher CPMs than ads on normal HTML websites.

WordPress and AMP

Here at Digital Hothouse, we build the majority of our websites in WordPress.

What’s that got to do with anything, I hear you ask.

Well, there are a number of WordPress plugins that can help to make implementing AMP easy – we use the Accelerated Mobile Page for WordPress plugin – along with ACF for AMP (useful if you use Advanced Custom Fields in WordPress) and AMP Custom Post Type. It has allowed us to create AMP pages relatively quickly and easily without much development assistance.

If you are going to create AMP yourself, then there are a couple of things to remember. You need to ensure that your standard HTML page links to the AMP page from your normal HTML page and, importantly, your AMP page needs to canonical back to the main page. So for example, on your main page you would have:

<link rel=”amphtml” href=”https://www.digitalhothouse.co.nz/amp/seo”>

On the AMP page, you would have:

<link rel=”canonical” href=”https://www.digitalhothouse.co.nz/seo”>

This way you are telling the search engines that you have an AMP page and when they visit your AMP page, you’re telling them that the main version of the page is on your main site. One final word is that the content of your full site and the AMP site must match for Google to see them as compliant and to be indexed.

PWAs

A PWA, or Progressive Web App, is basically a normal website that uses JavaScript to make a smoother and engaging App-Like experience (Cindy Krum). A PWA is intended to replace a native iOS and/or Android app by giving the same experience that the native app can, but doesn’t need to be downloaded or installed.

Why do we need this?

Well, first off, studies confirm that the average smartphone user has 36 apps on their phone and only 4 are used daily. In addition, 1 in 4 apps are downloaded and never actually used. This suggests a dwindling reliance and usage of native apps.

In addition, the other main advantage is that because a PWA is essentially a website with a couple of additions (we’ll come to this later), it can be crawled and indexed by the Search Engines. It pays to remember that once a user downloads the app, and loads the native app, they are away from Google’s ecosystem (using Chrome or Google Search for example) and this is no good for Google displaying ads, so Google would really prefer to keep people within the browser window, rather than a separate app where they have no influence.

The first PWA example, premiered at Google I/O was a Washington Post demo. You can see an example here:

https://www.youtube.com/watch?v=15OeAaqM0H8

The main difference though is how Users react with PWAs – they love them. Just 4 top stats are:

  1. 3x More Time Spent on Site
  2. 40% Higher Engagement Rate
  3. 70% Higher Conversion Rate (for those users that add them to their homescreen)
  4. 3x less data to render the website (which means quicker page speed!)

How is a PWA different from a native app?

PWAs react similar to native apps, with a few small differences (in particular between iOS and Android). If you visit a website twice (that’s a PWA) on an Android device, a dialogue is triggered asking if you want to “Add to Home Screen”. The PWA is then added to the devices home screen, exactly how a native app would be. However, unlike a native app, the download is done almost instantaneous, because all that it is downloading is the app details (manifest, shell info etc), rather than all the framework of a browser or app.

In addition, PWAs use pre-fetching. This is the loading of content before it’s actually requested. For example, if you are on the Forbes homepage and scroll down, as you scroll, the PWA can sense when you are over, or nearing content and it can pre-fetch that content. As you click on the story, the page loads instantly, as the content is already stored in the cache, ready to display once requested.

Like Native Apps, PWAs also can work offline. The PWA caches and pre-fetches content from the server, and that content is maintained in the browser cache meaning that even if you have a slow or intermittent data connection the content is accessible. Content that you’ve never accessed won’t be cached, but anything that you’ve previously viewed will work, even in flight mode.

The other great thing about PWAs is, like Native Apps, the user can also get push notifications. This is great for some websites, such as eBay, Uber and even Tinder – where the user doesn’t need to download and install the heavy Native App. They can use the PWA and when there’s a need for an update they can be notified. Perfect for when your lift arrives, or even more so when someone you like swipes right!

Because PWAs are essentially websites, they can be indexed by Google, but additionally, they have started to appear within the Google Play and Microsoft Stores to be installed.

Implementing a PWA

There are 2 requirements needed when creating a PWA. They are:

  1. ServiceWorker
  2. App Manifest

ServiceWorkers

To ensure that your PWA is indexed properly for the Search Engines, you need to work harder than you do with a ‘normal’ website. The main reason for this is the heavy reliance on JavaScript and ongoing communication from the website to the server to manage the experience. The difference with a PWA is that some of the JavaScript isn’t actually included on the page itself, but in a middle layer between the server and the website called a ServiceWorker.

The ServiceWorker is primarily there to pre-fetch, to load and to cache the content from the server before it is actually requested.

If you want the PWA crawled quickly by Google, register the ServiceWorker with them so that they can register the API and crawl it quicker. A word of caution – because it needs to be crawled and cached, anything that isn’t cacheable won’t get crawled!

App Manifests

The app manifest is a simple file that outlines the basic framework for the app. Similar to a flight manifest on a plane, an app manifest lists all the vital and primary elements of an app. It’s a simple JSON document, similar to a Schema file, that needs to be linked to in the head of the page to tell browsers that it’s a PWA.

PWA Example Screenshot

(Courtesy Ido Green)

 

JavaScript

Because Google still struggles to index JavaScript as well as HTML, indexing PWA content can be hard. It’s generally because content that is displayed based on user behaviour, the content is often not in the HTML, but using AJAX and JavaScript because of what the user does.

However, there’s good news!

Google has updated their mobile webmaster instructions to include JavaScript. The short story is, as long as you use a rel=alternate tag to identify the different versions of the content, they can understand it and index it. For years, SEOs were told that JavaScript redirects were forbidden and couldn’t be crawled, but now they’re endorsed and can be crawled. WIN!

But still, it’s not the easiest thing in the world. Indexing Web Apps, involves HTML Snapshots, XML Sitemaps, HTML PushState (to update the address bar whenever new content is loaded). It may also involve adding preRender.io to your server to help with pre-rendering. Depending on how much of your content is dynamic affects how complicated it can be.

If your website is already on HTTPS, you just need to spend a few minutes creating the App Manifest and the ServiceWorker. There are Wizards & Toolsets to help you do this:

  1. ServiceWorker Toolbox
  2. ServiceWorker Instructions
  3. App Manifest Generator

PWAMP, AMPPWA or Progressive Web AMPs

Now we know that AMP is a reduced version of JavaScript which can be cached by the AMP cache and loaded super-fast to the visitor, but a PWA can prefetch content and load it almost instantly when the visitor visits the website, wouldn’t it be great if we could combine the two?

Well now you can! That’s where PWAMPs come in. A PWAMP is a hybrid PWA and AMP website and can ensure the quickest experience for a user.

There are 3 ways to combine AMP and PWAs and they are (Max Prin):

  1. Enable PWA features for AMP Pages
  2. Use AMP as an entry point into your PWA
  3. Use AMP as a data source for your PWA

It can be implemented in a number of ways, but we suggest that you implement it is using AMP as an entry point into your PWA.

For example, the user does a search in Google and finds product page, such as:

eBay’s DJI Drone Page

When the user visits this page, it loads incredibly fast and gives that almost instant-delivery. Because it’s AMP, a PWA ServiceWorker hasn’t hindered the load time which is great for the user. What you can then do is warm up the PWA with the amp-install-ServiceWorker which, when done correctly, links from any link within the initial AMP landing page to the PWA, which loads an almost instant, PWA page with full functionality that you would expect from a PWA and a responsive fully Ecommerce website.

Now you have a PWAMP and almost instantaneous mobile experience for all visitors. You should expect to get more traffic, make more sales and have a better engaged audience.

You can see a good example of this here:

http://pwamp.shop/

Conclusion

AMP, PWA and PWAMP can be considered confusing acronyms, but they can really help user engagement and the Search Engines. If you can speed up the website for visitors, you’re doing great as far as the Search Engines are concerned.

In addition, you also gain the ability to rank in different areas, such as AMP Carousel and Google Play Store, so you increase your market reach in addition.

There is more work involved to achieve AMP, and in particular, PWAs (and even more so to combine them into a PWAMP) but with the increased traffic on offer, along with the amount of engagement, it could be an extremely valuable exercise and could put your website a cut above your competitors.

Leave a Reply

Your email address will not be published. Required fields are marked *