AMP vs. PWAs: Which is Better AMP or Progressive Web Apps?

AMP vs. PWAs: Which is Better AMP or Progressive Web Apps?

We all know that mobile use is growing and changing the face of digital publishing. Platforms like Google won’t let us forget it. This has led to the development of a handful of new technologies designed to deliver visitors faster, richer mobile experiences. This includes things like Google’s AMP (accelerated mobile pages) and PWAs (progressive web applications).
Here, I’ll dive into a recent presentation from Google’s, Ben Morss. Ben spoke about AMP vs. PWAs at Pubtelligence — which was hosted at Google offices in New York in early 2018.
Ben discussed the differences between these two emerging mobile technologies and highlighted where there may be room for them to potentially co-exist.
I’ll break down his presentation and summarize:

1. The differences between AMP and PWAs
2. Which is better for your website
3. How they could work together
4. How to put one or both into action on your site or blog

READ OUR UPDATED STUDY COMPARING AMP VS. REGULAR MOBILE PAGES

What’s the difference between AMP and PWAs?

A quick refresher, AMP is short for accelerated mobile pages and is the technology produced by the AMP Project — an open source experiment started (and largely led) by Google.

AMPs are just web pages.  They differ from other web pages in a few different ways, They simplify typical HTML by requiring rules to be followed for AMP validation including:

• ban inline JS
• the AMP web components provide JS as part of AMP library
• CSS can only be 50K
• Google caches the content on a Google URL for quick access

This means that AMP pages actually live on a Google URL, for now. Google has recently said they plan to provide the ability for publishers to cache content on their own URLs in the future. Although, this guy says that a lot of the speed of AMP is actually in Google’s cache.
PWAs stand for progressive web apps. People often call them PWA apps even though this repeats the word app twice, technically (sorry, pet peeve).

PWAs are mobile web pages enhanced with features that provide an immersive, fast, app-like experience. This includes:

• the ability to access content while offline
• the ability for publishers to send push notifications to mobile devices
• more app-like interfaces (full-screen option)
• faster experiences/transitions between pages

Users access PWAs via URLs just like they would with normal mobile browsing, but load the page in the background; allowing them to save it as an app icon on their mobile device. It also allows them faster browsing between pages if they are returning to the site or navigate beyond the first page.

Will PWAs replace regular mobile apps?

Honestly, in my opinion, it’s totally possible in a lot of cases.
There has long been a debate for all mobile property owners, not just publishers, of whether or not app development would be worth it.

Even with app development costs going down, it still is a debate of, “whether or not it is even worth the time”?
Will visitors even use an app? Does the publisher want to take the time to maintain it and manage mobile marketing through it?
PWAs essentially make all of those questions easy to answer. A PWA provides both a typical mobile page and an app all-in-one. You can manage all of it together as one while giving all user the choice of how they want to interact with your property on mobile devices.

How do PWAs work, and why do we even have mobile apps?

In order for web apps to earn a place on home screen, we need to make them reliable, even when the network isn’t.   

This has been one of the things holding back the web as an app platform. We’ve become conditioned to think that web app equals something that only works with a live network.
A service worker is JavaScript that runs separately from your webpage. It can cache resources. It can intercept web requests.  And since it’s running even when the browser isn’t up, it can do push notifications.

The traditional web model has been that the browser goes to the network to look up the web server and ask it for a page and its resources.  
The browser has an HTTP cache, but if the network is down — you get a visit from our friend the “downasaur”.
The experience can be even worse with flaky connectivity.
BUT with service workers, you don’t necessarily need to traverse the network every time.

PWAs can have the power of most apps, but you don’t have to install them. They combine the reach of the web with the capability of apps.

The idea is spreading.  Google and  Microsoft have both announced that they’ll automatically index PWAs within their respective App Stores now too.
Service Worker is in Safari Tech Preview already along with the Cache API — and many other features that are already in place.

This means that this technology is spreading across browser, devices, and platforms. These are the early signals of a technology that is likely to succeed.

Should I choose AMP or PWA?

According to Google, you may not have to choose. There are some ideas and proposals about how to make PWAs and AMP technologies work together.
A lot of them seem to stem from Google trying to find ways to build on the growing popularity of progressive web apps.

To this point, it has been a bit of a mixed bag for publishers and AMP.
Publishers are keen to explore the enhanced mobile functions of PWAs and are enticed by the agility they offer for mobile marketing.
Being able to connect with audiences offline, through a mobile app on their phone, and to push them notifications helps publishers lessen reliance on platforms like Google and Facebook. This has become a big deal recently and is one of the reasons why PWAs are gaining steam.

How do PWAs and AMP work together?

One way that Google proposes publishers leverage AMP and PWAs together is to start fast and stay fast by leveraging AMP to start the user session.

The idea is simple. The user discovers content from somewhere, which brings them to an AMP page.
The AMP page installs the service worker and gets the PWA warmed up.
On the next click, the user is brought to the PWA.

To make that step as seamless as possible, Google introduced a component called <amp-install-serviceworker>. This component can run on any AMP page and install a site’s Service Worker in the background, even when your page is served from the AMP Cache.
Benefits of this style of blending AMP and PWAs

1. Fast initial load with app shell
2. Fast load throughout the app
3. App-like immersive experience
4. Manifest, enabling add-to-homescreen and fullscreen mode
5. Offline content

What if you’ve already got AMP pages?
But… you want all the great features and mobile marketing elements provided by PWAs. Can you save some time and money and combine these existing elements with new ones?
Sure you can. Ben proposed a nice scenario of how this all works.

AMP becomes the data source:

• • instead of JSON
  • instead of converting JSON into HTML on the client side
  • the rich data source includes layout information

Ben described it as markdown on steroids.
AMP runs JavaScript on a validated set of extended HTML and transforms it according to PWA specifications.
This takes advantage of two now concepts Ben explored during his presentation that I will just briefly touch on; as we are getting a bit into the weeds now.

Shadow DOM is DOM encapsulated in and attached to an HTML element.

This is a way for a subsection of a webpage to be AMP’d.
How do these come into play?
First, the page loads the Shadow AMP JS.
Second, it uses that to attach an AMP to a DOM element.
Note that this library is loaded asynchronously.
Then it uses an asynchronous loading pattern:

• if window.AMP doesn’t exist, create an empty array to take its position”
• push a callback function into the array that should be executed when AMP is ready”

The AMP object then recognizes this array of callbacks. Then, it pulls in AMP content via RSS and uses XmlHttpRequest to get the AMP HTML.

These two concepts of blending AMP and PWAs are essentially what Google calls PWAMPs or progressive web AMPs; I’m still not sure if they’re serious, but it will probably catch on.

Where do I even start with PWAs, AMP, or even PWAMP?

One of my key takeaways after listening to Ben talk at Pubtelligence — and field questions from the audience — was that many of us in this space are operating far ahead of the majority of publishers.

While Ezoic and Google may be talking about the latest in PWA and PWAMP technologies, publishers are still trying to figure out if leveraging AMP is even worth the trouble to begin with.
The truth is that publishers DON’T HAVE to leverage any of these mobile tools. There are plenty of ways to make your mobile site faster without them — if this is something important to you.
The real benefits of exploring the kinds of innovations for publishers come in their abilities to do one of three things:

1. Provide improved objective user experiences
2. Increase quality traffic/pageviews
3. Provide an outlet to directly connect with your audience

PWAs and AMP can typically help publishers do at least 1 or all of those things, but they must be done correctly, or the payoff won’t be there.

How to start with AMP or PWAs

In most cases, the decision to implement these technologies start with understanding what benefit you want it to drive.
As I mentioned above, page speed itself is not the best reason. There are other ways to make your page adequately fast (over obsessing about page speed doesn’t really yield overly impressive results).
However, if you think that user experiences could be improved by faster initial loading, and believe that Google news traffic is relevant to your site, it might be worth exploring something like AMP to increase traffic and improve user experiences.

As we’ve talked about before, most AMP converters and plugins take away the navigational elements of your site and a bunch of other important factors; causing user experiences to be objectively worse. Ezoic’s AMP Converter circumvents all of these challenges and is the best AMP converter option available.
Otherwise, you’re left with developer help as your main option. If you don’t have a development team in-house, it’s likely not worth paying a developer to convert your mobile pages to AMP-friendly pages.

What about PWAs? I want those…

PWAs offer a little bit better value proposition for publishers at this point, in my opinion.
Publishers get:

• pages that load faster between pageviews
• the ability to access audiences directly through mobile marketing (push notifications)
• and app-like functions and features

The problem is that, unless you have an in-house development team, they can be a bit out of reach. The one exception is for Ezoic platform users.

Ezoic customers have early access to Ezoic PWA Converter; which automatically converts mobile websites in full progressive web apps.
This means that they can leverage the PWA converter to:

• Get their mobile site into apps stores
• send push notifications to users
• make their site available in an app offline for visitors
• provide a faster experience to visitors

It’s a free feature available to all Ezoic users. If you want to try it, and currently have your site on Ezoic, you can request Beta access by e-mailing [email protected].

Wrapping it up on PWAs and AMP

They are actually really different mobile technologies. One, or both, offer some benefits to publishers across the board.
Neither is likely the “final form” of mobile page development, but both deliver functionality in the present moment that publishers can use to grow and provide visitors with better experiences.
Questions about PWAs or AMP? Leave them below and I’ll tackle them as they come along.