Google's Ben Morss on AMP and PWAS

We had the opportunity to interview Ben Morss about AMP, Progressive Web Apps, and mobile site speed. Ben is a frequent speaker at industry conferences on these topics, and is a Developer Advocate at Google.

Prior to Google, he worked at The New York Times and AOL, and as a full time musician. He earned a BA in Computer Science at Harvard and a PhD in Music at the University of California. Rumor is that he still runs a band called Ancient Babies.

Our conversation was informative and enlightening. Ben’s insight has value for any developer or web professional.

Eric Enge: Can you provide an overview of AMP?

Ben Morss: AMP is a library that you can use to build websites that are faster and easier for users. It’s often faster and easier for developers too. AMP is an initiative that was started by Google about three years ago, in collaboration with a group of publishers.

Originally, it was designed for static sites such as news sites, but now it’s more full-featured. Key components have been added that weren’t there before, such as <amp-list> and <amp-bind>. These let you make sites that are more interactive.

AMP provides restrictions that developers need to agree to abide by, and the result is faster sites for users. For example, CSS needs to be 50 KB or less. And AMP restricts how you use JavaScript, although that will loosen up a lot when <amp-script> gets released.

On the other hand, it provides you with web components that do most of the things JavaScript would do. If you follow the validation rules, web crawlers will find your pages and serve them from AMP caches. Google and Microsoft have these. Pages often render from these caches in less than one second.

AMP was created because it was felt that most web sites were too slow and complicated. It may not be as important if you’re in the US on a costly phone and a 4G connection, but in many situations and especially some countries, a 3G connection is the best you get. AMP also doesn’t allow intrusive ads, and it also prevents content jumping around on screens because you describe the size of all the objects in advance.

By the way, 40% of the world’s connections are actually on 2G. For these people, the traditional web is not even that usable at all. Lastly, AMP was originally designed for mobile, but now works just fine on desktop as well.

Eric Enge: Can you describe what Progressive Web Apps (PWAs) are?

Ben Morss: PWAs are a collection of technologies and best practices to make sites better for users. For example, a PWA should still work when a user is offline or has a poor connection. Users can also add your site to their phone home screen. A PWA keeps an app shell present at all times, so there is no full-page load when you go to a new page. Content from new pages gets served into that shell, and that helps with overall speed and user experience. A PWA can be full screen on your phone (i.e. no URL bars as you see with a web site).

Generally, PWAs feel more like an app on your phone. They’ve also been arriving on desktops running Windows or Chrome OS. Many of these features are made possible by a web standard called Service Workers. The service worker preloads commonly used elements and caches them before users call for them. Since it can cache content, a PWA can work offline. Service workers also run apart from the browser, making it possible to send users push notifications. And, of course, as new HTML5 features get into browsers, it’s possible to access more and more phone features from the web.

All of this enables new features for your site, but you don’t have to use everything. Pick and choose the PWA features that are useful for you. For example, push notifications can be an irritant to users if you overuse them, so use them with care.

Eric Enge: What is a Document Object Model (DOM)?

Ben Morss: A DOM is a representation by the browser of what’s on your web page. HTML is the text that you use to define your page. The browser looks at that HTML, parses it, and builds a DOM. So that DOM is just a representation of the HTML. JavaScript can use that DOM to modify things on the page.

Eric Enge: What is a Shadow DOM?

Ben Morss: It’s a bit of a weird concept, but once you get it, it’s quite powerful. A Shadow DOM is a DOM that lives inside an element of another DOM. Essentially, you can embed another web page entirely inside an element of another page.

Eric Enge: What is a Shadow AMP?

Ben Morss: This lets an AMP page live within another page, existing entirely inside a DOM element. It’s like having an entire universe in one molecule of our universe! It’s similar to an iframe in concept. You might do this to have a portion of a page be in AMP, though the rest of the page might be more elaborate. Or if you’ve already got AMPs on your site, and you want to reuse them in some other context.

Basically, AMP is an embeddable content format. For example, Google is working on embedding AMP functionality in Gmail and within the Google Assistant. It lets you embed and reuse web content in other contexts, and also lets you embed a bit of the web in other applications.

Eric Enge: What is a PWAMP?

Ben Morss: PWAs make websites better, and AMP makes web pages better, so why not combine them? That’s the idea behind a PWAMP.

Eric Enge: There are multiple scenarios for implementing PWAMPs. Can you describe them?

Ben Morss: Sure. Scenario 1 is where you have AMP pages within a PWA. That’s the Shadow AMP model we were just talking about – where you use Shadow AMP to embed those AMP pages within a PWA.

In Scenario 2, your AMP also has PWA features. Your AMP pages also load a service worker. This uses the AMP component called <amp-install-serviceworker> So the AMP code IS the PWA. And although it’s less natural to use JavaScript within AMP to reload content within an app shell, you can use the same app shell on every page, and the service worker can cache that.

Scenario 3 is the most popular PWA/AMP model on the web today. The first page users get to is AMP, since that’s usually the quickest way to get a user onto your site. Then, as the user gets into the site, they transition to PWA pages. Ideally, the AMP page installs a service worker which preloads the PWA, so the user gets plunged into the PWA automatically and immediately on the next click. So the site has some pages that are AMP and others that are PWA.

To see a nice example of Scenario 1 – AMP within PWA – check out our demo at https://amp.cards. It’s called the Shadow Reader. We took AMP articles from The Guardian and re-purposed them into a high-quality PWA viewer.

In the Shadow Reader, the first page load is AMP. That’s what is best for speed, and better for search. The reason why you don’t start with a PWA is that PWAs often use JavaScript to pull in content. And web crawlers don’t always execute JavaScript well – or at all – so this could make your content invisible to Search. Google tries to handle JavaScript the best it can, but it’s not always as perfect as it should be.

So, if you’re a user, your first page load is AMP. While you’re looking at that first page, the PWA is getting preloaded by the service worker, and on the next click, the user is brought immediately into the PWA. If you’re a web crawler, you don’t have a browser history or cookies store, so every view is like a first view. So a web crawler always gets the AMP, and your content, and it can index it.

Eric Enge: Why implement a PWA instead of a native app?

Ben Morss: One of the main reasons is that you only have to write code once instead of writing code several times. This is because your web site is the app. With Native Apps, you need to write one version for iOS and one for Android, in addition to needing to implement and support your web site.

Also, users have to decide to install your Native App in order to access it. This is not the case with PWAs. The user gets access to it as soon as they go to your website. These factors make PWAs a lot easier to maintain.