Why you should use AMP together with PWA (for SEO)

AMP (Accelerated Mobile Pages) is a new keyword in the world of Front End together with PWA (Progressive Web Application). AMP was acquired and PWA is created by Google. Nevertheless they don’t want AMP to be associated with the company because it is an open-source project. In this article I will try to explain why I will use AMP in combination with PWA for almost every application I make from now on.

Explaining AMP and PWA

There’s nothing more annoying than waiting 15 seconds on poor 3G/WIFI, to read an article in less than 10 seconds opened from any search engine. Accelerated Mobile Pages, not so mobile anymore, are new HTML-elements combined with JavaScript to support other classic HTML5-elements used to speed up your page load. These components are prebuilt to use together with the CDN of AMP. So it’s just HTML? Yes, it’s just HTML, so you can’t use JavaScript anymore! It’s the same as going back to the basics: you just have to make your web applications in HTML & CSS without JavaScript! It’s supported by Google but you can’t use Angular, React or some other fancy framework ;).

While a Progressive Web App is used to upgrade your whole web application experience with offline caching, push notifications, manifest options,… to give the user a more native application feeling. It’s meant for engagement without the need of downloading the entire native app onto your phone. If you are having doubts about making your application native or hybrid, go with PWA! It’s the future of native & hybrid apps! Back to AMP now!

After following the AMP team for over a year, I had to see the AMP-roadshow in London. I had two questions on my mind and was desperate to ask them. I saw the keynotes of the different developer advocates in the morning followed by questions and answers with some experienced developers of Irish and British publishers. Hearing them talk about their web applications raised questions why AMP was so special for them. They were eager to tell everybody about the conversion rates they got from using this feature: the first page load time decreased, users stayed longer. The more they were saying the first page load went down, the more I wasn’t getting the reason why you should use AMP for the first page load and (maybe) not the second or the third!

There is also a reason why they invited more than one publisher on the stage. It is because the articles of these publishers are making it into the Google’s Top News Carousel. This carousel is visible when you enter the keywords of a news article in the Google Search bar. The developers of these articles are combining AMP with the schema.org feature which leads to a featured item in the Google Top News Carousel together with the AMP-logo right by the title. All these articles with an AMP-logo are prefetched by the Google AMP Cache, so they are super fast. The page is pre cached before it’s even shown to the user. Together with a stable page height during loading, the user is getting the conformable look in a blink of an eye. So page load is fast and you’re ending up at the top of the Google Ranking, great!

This is why you shouldn’t use it for all projects

One of my questions was if AMP was useful for making the fastest landings pages on the web. The answer is yes, it is useful… but there’re some limits. During this event there were a lot of questions from the audience about how to use AMP for their website. The AMP-team served them with honest answers. “Should I use AMP for my e-commerce website?” Yes! “What about SEO?” Is your page organically built with Angular or React? Yes! Then you maybe shouldn’t use AMP. If it’s not, it’s fine for SEO reasons! But why are publishers using it? The publishers on stage didn’t say it out loud but they were maintaining two websites asynchronous: an AMP-version and a non-AMP version of their website. The AMP-version is shown directly from the Google Search. Google is prefetching AMP-websites, so your website (on mobile) isn’t shown from your servers. It is shown from their servers and the url will look like this: www.google.com/amp/www.your-website.com. This is not what you want for your Google ranking! So there are two scenarios:

• It is possible you have one website running just on AMP. No need to take actions, just place the canonical URL to itself so Google will fetch this one.
• You can also have a second website with the same content running on non-AMP pages (for JavaScripts purposes). Then you have to tell the AMP page the canonical URL is the one without AMP and vice versa. The search engine won’t index the AMP version but if you use ShadowDOM, it will index the content from the non-AMP version of your website. When the user comes back or shares the URL, not the one from Google, they start from the cached (possible PWA) web application and the cached content. It’s extremely important to set the canonical URL to the right content so Google can fetch it right.

“Can I still use my API calls?” Yes, of course!

Here are my 6 reasons why I’ll make almost every webpage into an AMP-page from now on:

1. It’s only HTML and CSS. So it’s fast!
2. The AMP-team has a lot of prebuilt components ready to use. No worries, you can still make your content dynamic and fetch some JSON, with amp-state.
3. You can make it interactive on click events, with amp-bind.
4. You can use POST calls, with amp-form. After this you can fetch your content, with amp-live-list.
5. You can track every mouse-click, with amp-analytics.
6. You can even make super smooth animations, with amp-animation.

For some developers this isn’t enough. They can’t do complex math functions or merge data from two calls into one observer. But at the end, you have to think about the user and they have to find their way back to your page! Believe me, AMP is making developing cleaner and easier!

Combining AMP with PWA

When you’re thinking about making an AMP-version of your website, there’s no need to use PWA for fast loading. But if you do want to use native application-features such as offline caching, push notifications,… you can add certain elements from the PWA Checklist.

When you’re required to maintain 2 websites, just like these publishers do, you have to go with AMP together with PWA. AMP will be responsible for caching the first page view, while the service worker from the PWA will be responsible for caching the content source of the non AMP-version.

What with (SSR) Server Side Rendering AMP?

The AMP-team worked on an amp-publisher-sample, but they aborted it because it was still using JavaScript (React). At the roadshow, they promised they’ll come with a (better) server side rendering-solution. But for big applications it’s just not recommended to use AMP. There are a lot of possibilities to speed up your page load without AMP.

My personal opinion

I wrote a lot about the publishers, but you can use AMP for every web application. It makes your website fast, and that’s what we all want. I advise you to use AMP as much as you can for B2C, because it’s increasing the conversion rate. With some UX, you can satisfy plenty of people coming from the Google Search engine or from Cloudflare* hosting. But don’t use it for every web application. In my opinion it depends on for who you’re building it, for B2B or B2C. If you can use it, don’t hesitate to take a look at the AMP projects together with PWA, to take your UX to the next level!

*I didn’t write anything about the Cloudflare hosting, it uses the same principles as Google AMP Cache. Their CDN will load your website faster from the cache, same as coming from the search engine. Find more about Cloudflare on https://amp.cloudflare.com/.