Understanding Progressive Web Apps and AMP for Advanced SEO

AMP and Progressive Web Apps are all the rage these days. They are light-weight, SO fast, mobile-first and new-er technologies.

In this blog, I will breakdown what AMP and PWA (progressive web apps) are and how to best implement them onto your site (and of course cover SEO)

Chances are, you’ve heard the words “AMP” and “PWA” thrown around a lot these days.

Both are big news for businesses and the mobile web, and each has plenty to offer in their own right.

But they’re most effective when they work together.

In this article, I’ll cover everything you need to know about AMP and PWA, and how to integrate the two for an enhanced mobile web experience.

First, I know many people come to this blog for SEO, so I am going to jump ahead and cover this first. We will dive into the full article after.

A Quick Note On AMP, PWA and SEO

One thing that is important to note, is that AMP and progressive web apps are very new and their technical SEO implementation is evolving.

Right now, here is what you need to know.

1. AMP pages are rel canonical to another page in 99% of cases. This means, Google does not rely on them for ranking. If you have a responsive design site, the AMP page will canonical to that URL. If you have a mobile subdomain, it will canonical to the mobile domain.
2. There are some AMP only websites being built now. In this case, they are being indexed by Google. So there is no canonical. And sure, these pages can rank and basically operate under the same principals as normal HTML pages. They need all the same stuff.
3. Progressive Web Apps are starting to get picked up better by Google, but it is still a little hit or miss. If you do want the content to get indexed by a PWA for SEO ranking purposes, its a good idea to either have an HTML base and load the progressive web app over that, use a tool like prerender.io and/or pushstate.
4. Just having an AMP and a PWA based site is possible, but for SEO purposes, you want to make sure the AMP has similar qualities to a normal high functioning SEO site.
5. Best case scenario at the moment is to have a lightweight CMS that delivers HTML elements, PWA elements loaded over that but not to the point where there is cloaking and AMP installed on the pages that are news related or have limited functionality.

 

Diving Deeper – Progressive Web Apps and AMP: What is PWA?

A Progressive Web App (PWA) is a web app that uses modern web capabilities to deliver an app-like experience to users.

According to Wikipedia, “progressive web apps are a hybrid of regular web pages (or websites) and a mobile application. This new application model attempts to combine features offered by most modern browsers with the benefits of mobile experience.”

In layman’s terms, it’s technology that helps a website behave more like a mobile app, thereby improving the overall user experience. It connects the experience of an app with the reach of the mobile web.

It works like this: When you visit a PWA page on your mobile device, it will start as a normal webpage in your browser. As you explore the page, you’ll soon be given a prompt “Add to Home Screen.” Once accepted, the page will live on your home screen and can appear as an app.

Why use a PWA? Because businesses can no longer rely on users to download their apps. In fact, over 50% of America’s smartphone users download zero Apps a month, and 80% of user’s time is spent in their top 3 apps.

For businesses, that translates to dollars spent on advertising, etc. with little return.

That, and PWA’s promise to make their take on apps more reliable, fast, and engaging.

To be considered a PWA, an app must be:

• Progressive – Work for every user, regardless of browser choice, because they are built with progressive enhancement as a core tenet.
• Responsive – Fit any form factor, desktop, mobile, tablet, or whatever is next.
• Connectivity independent – Enhanced with service workers to work offline or on low quality networks.
• App-like – Use the app-shell model to provide app-style navigation and interactions.
• Fresh – Always up-to-date thanks to the service worker update process.
• Safe – Served via HTTPS to prevent snooping and ensure content has not been tampered with.
• Discoverable – Are identifiable as “applications” thanks to W3C manifests and service worker registration scope allowing search engines to find them.
• Re-engageable – Make re-engagement easy through features like push notifications.
• Installable – Allow users to “keep” apps they find most useful on their home screen without the hassle of an app store.
• Linkable – Easily share via URL and not require complex installation.

Progressive Web Apps and AMP – Why Integrate PWAs With AMP?

Part of PWAs appeal is its ability to provide fast load times to users within in app.

But here’s the catch: that speed doesn’t kick in until the second load.

PWAs work througha  technology called Service Worker, a client-side proxy that only kicks in after the second request.

That means the first time a user loads a site, it could load slow.

And as we all know, the slower the site’s load time, the higher the bounce rate:

• A 100-millisecond delay can reduce conversion rates by as much as 7%
• A two-second delay in page load time can increase bounce rates by more than 100%
• 53% of mobile users will leave a page that takes longer than 3 seconds to load

Unfortunately, most sites don’t come close to those numbers: the average page loading time is 19 seconds, with 77% of mobile sites taking 10+ seconds to load.

That spells trouble for mobile sites – even those using PWA. But don’t worry; there’s a light at the end of this tunnel. All PWA users need to do is increase that initial load time.

And that’s where AMP comes in.

AMP stands for accelerated mobile pages, and it’s designed to make web pages load fast. Really fast.

Those who view AMP pages see the same relevant content as desktop users, but it’s on a page with a much more simplistic design that allows it load much more quickly.

As Google notes, the two were previously working in conflict. But if the two were integrated, it would allow them to “deliver fast initial loading and reliable second-visit performance, as well as advanced features like offline reading and richer UI treatment.”

Here’s a brief breakdown of each:

• AMP
  • Reliable, instant delivery
  • Optimized discovery
  • No Javascript
  • Static content
• PWA
  • First delivery can be slower
  • Not easily embedded
  • Access latest web APIs
  • Support dynamic content

The two are obvious compliments, as each supply features that the other lacks.

The two work well on their own, but they’re undeniably stronger together. That’s because they deliver what customers want: fast load times and seamless experiences.

If you’re considering using a PWA, you’ll want to make sure your initial loads as a quick as possible to reduce your bounce rate.

How to Integrate Progressive Web Apps and AMP

Now that we’ve covered the why, let’s move to the how.

There are three ways to combine PWA and AMP:

1. AMP as PWA
2. AMP to PWA
3. AMP in PWA

AMP as PWA

For sites that have static activity and don’t have much interactivity, you can have an AMP that’s also a PWA.

For example, Mynet, a leading publisher in Turkey, used an AMP page as a PWA and saw the following results:

• +25% higher revenue per article page view
• 4x faster page load speed
• +43% longer average time on site
• +34% more page views per session
• -24% lower bounce rates

But keep in mind, to use AMP as a PWA you’ll have to live within the boundaries of AMP. By using it as a PWA, you’ll still have Service Worker, which will allow users offline access, etc., and still prompt the “Add to Homescreen” banner.

When using AMP as PWA, a user will visit the AMP-supported site. As they click through the site, they will navigate away from the AMP cache to the origin, allowing your site to add a service worker and deliver added functionality, including:

• Dynamic features that require Javascript
• Components that are customized/only relevant to your site

To add PWA to your AMP site, you’ll need to add a Web App Manifest. This ensures that users can install your site on their home screen.

To do so, you’ll first create the manifest:

Then link to it from the head of your AMP page:

Next, you’ll install a Service Worker. To do that, you’ll need to include the service worker script on your page:

Then add the following code to the body of your page:

From there, you can modify the response via the Service Workers fetch to return any response you want.

AMP to PWA

Sometimes, AMP capabilities simply aren’t enough. If you’re looking for a different experience around your PWA, you can still AMP to get there.

Essentially, AMP to PWA uses AMP as an entry point for your site, then “warms up” the PWA behind the scenes so it can switch over. That way, when a user clicks on a site organically in the search results, they’ll be served a fast-loading AMP page. As they navigate the site, the service worker will kick in.

The process involves three steps:

1. User discovers content
2. Service worker installs in the background
3. User is instantly upgraded to PWA

Using AMP to PWA allows:

• All content “leaf” pages (those that have specific content, not overview pages) are published as AMPs for that nearly instant loading experience.
• These AMPs use AMP’s special element <amp-install-serviceworker> to warm up a cache and the PWA shell while the user is enjoying your content.
• When the user clicks another link on your website (for example, the call to action at the bottom for a more app-like experience), the service worker intercepts the request, takes over the page and loads the PWA shell instead.

To set it up, you’ll follow the same steps above to install the service worker on all of your AMPs.

Then, in the service workers installation step, you’ll cache any resources that the PWA will need:

With that in place, you’ll next want to make sure that all the links on your site lead to the PWA. There are two strategies for doing so:

1. If you pair your canonical pages with AMP pages

This is the most common way AMP is used, and means that all the links on your page link to the canonical version of your site. If your canonical site is your PWA, your work is done.

2. If your canonical site is AMP.

This happens when your canonical pages are your AMP pages, and means that the links on your site lead to other AMP pages.

If that’s the case, you’ll need to use your service worker to intercept the browser navigation when someone clicks on a link in your AMP page.

It will look like this:

Google does note that while this approach enables a progressive enhancement to go from AMP to PWA, it also means that browsers that don’t yet support service workers will never actually navigate to the PWA.

But AMP’s one step ahead, and combats the issue with something called a shell URL rewrite. Doing so instructs AMP to rewrite all matching links on a page to go to another legacy shell URL, ensuring that all clicks go to your PWA.

As an example, let’s look at recipe site Rakuten. Using this method, the company saw:

• +50% time spent on site per user
• 3.6x higher CTR within AMP page
• Due to the add to home screen feature, they saw:
• 1.7x more unique visits
• 3.1x more page views

AMP in PWA

This last version uses your AMP pages as a data source to power your PWA.

Traditionally, Progressive Web App is a “single page application that connects to a JSON API via Ajax.”

But rather than use the JSON API, users can simplify the development by using their existing AMP Pages.

Why? Because AMP pages aren’t just web pages; they’re “ultra-portable, embeddable content units that can stand on their own.” Because of that, AMP HTML can power both the AMP and PWA experience.

To do so, Google recommends including a Shadow DOM in your PWA.

1. In practice, the process looks like this:
2. PWA hijacks navigation clicks
3. Fetch the requested AMP page
4. Put content into a new shadow root
5. Call attachShadowDoc

The best part? If you already have AMP pages, you can insert a Shadow Dom in an hour.

The first step is including the Shadow Dom in the head of your page. It should look like this:

Then, once AMP has loaded, you’ll fetch the AMP doc via XMLHTTP request and return a response HTML.

To do that, you’ll render it using Shadow AMP, which means you will:

1. Create a new shadow root
2. Let AMP render the document
3. Return a promise to notify when ready

Shadow AMP can be used to accomplish a number of objectives such as hiding unnecessary information like headers and footers when embedded.

For more information on how to use and set up Shadow AMP, check out these guides.

Or, see it in action with the AMP team’s demo, a fake travel magazine called the Scenic. You can view it on GitHub.

 

Wrapping Up AMP and PWA Integration

We’ve covered a lot of ground here, so let’s take a look at the highlights.

• AMP/PWA is always fast – no matter what
• It has great distribution built in
• Progressively enhanced
• One backend to rule them all
• Less client complexity, fewer deploy targets

Remember, this is all still very new, and we’re only beginning to scrape the surface of what an AMP/PWA integration could mean for businesses.

But so far, all signs point towards success.