AMP, PWA or PWAMP? – optimising for the mobile-first index
Nope, we haven’t had an acronym meltdown. These are all ways that you can optimise your website for Google’s mobile-first index.
As we all know; speed matters. For the majority of sites, mobile-first indexing has already arrived and for those sites, speed on mobile is more crucial than ever. If you have yet to make any changes to your site to optimise for mobile, it’s time to take your head out of the sand and put a plan in action to prepare for this seismic shift in search.
But let’s back up a little bit first.
What is the mobile-first index?
If you’ve had your head in the sand for a while, you may have missed the fact that Google has shifted the way that websites are ranked. Previously, the way your pages were ranked on both mobile and desktop was calculated using the content on the desktop version of your site. This, however, has all changed for the majority of sites on the web.
Way back in November 2016, Google announced that they were going to be moving to a mobile-first index. This means that the way your site is ranked is no longer taken from the desktop version of the site but from the mobile version.
Why has Google moved to mobile-first?
Well, this one is a bit more obvious. Mobile search has overtaken desktop search in the past couple of years so it makes sense that the way your site is ranked is based on the content you are serving to users on a mobile device.
Google is also working extremely hard to improve the mobile web. For some time, they have been pushing us to deliver faster sites that focus on the user experience. By moving to a mobile-first index, they have forced webmasters, designers and developers to start thinking and acting mobile-first which should ensure their plan of creating a better mobile web is achieved.
Preparing for the mobile-first index
If you haven’t already, you need to start preparing for this shift now.
For many people, there may actually be little to do. If you have a fully responsive site, where the mobile content is a 100% mirror of the desktop content, the move to the mobile-first index will have had little impact on your rankings. If, however, you have an m.domain.com site, where you serve users a pared down version of your desktop site on a mobile device, you need to get to work.
Whether you are running a responsive site or an m.domain.com site, we recommend carrying out a parity audit to see what content Google is crawling on desktop and mobile. We recommend using the awesome Screaming Frog tool to analyse both versions of your site. Simply crawl your site using the different user agents within Screaming Frog and then analyse those results to see where any potential gaps exist. Moz published an awesome blog post on conducting parity audits that will talk you through the process.
Focussing on speed
Whilst there are a number of ways to prepare for the mobile-first index, at Digital Hothouse, we’ve been focussing on speed. Fast loading sites on mobile tend to be more engaging. In a 2016 article, Think with Google suggested that mobile sites should load in under 3 seconds. They found that the average e-commerce site in the US was taking 6.9s to load. Clearly, there are improvements that can be made here and site speed and UX are two clear areas where improvements can be made.
3 ways to speed up your mobile site
Speed has been a ranking factor since 2010, however, it plays a very small part in the ranking of a website. So why focus on it?
Well, there are other associated benefits of having a faster loading mobile site that will provide a bigger boost to your rankings including:
- Improved conversion rates
- Customer retention
- Reduced bounce rate
Whilst these may not be direct ranking factors in Google’s core algorithm, SEO Guru Larry Kim believes they are indirect signals that impact on your rank. As well as that, the speed of your site helps to massively improve the user experience on your site – something that Google is pushing so hard to achieve.
For us, speeding up your mobile site is a no-brainer.
Whether you have a mobile-responsive site or an m.domain.com site, speeding up your mobile experience is something you should be working towards. Here are three ways in which you can achieve a faster loading mobile site.
1. AMP (Accelerated Mobile Pages)
Example of an AMP Carousel. Credit: http://searchengineland.com/googles-amp-carousel-working-seo-insights-kanye-west-266412
The Accelerated Mobile Pages (AMP) Project is an open source initiative to improve the mobile ecosystem. Thanks to the pared-down HTML that is used by AMP, it allows you to load your web pages much faster than regular HTML.
Google also caches your content on their own cache to speed up load time even more. All this results in a much faster, sleeker user experience and should, in turn, lead to improved visibility in the search results.
Read more about the AMP Project here.
|Improved UX – early case studies have shown that sites moving to AMP are reporting lower bounce rates, more time spent on page and crucially, increased conversions||Time – however you choose to implement AMP, it is going to take time. Whilst there are some great plugins available, you still need to put in the time to get the most out of them|
|Ad visibility – after some early teething problems, Ads on AMP site are now delivering higher viewability, higher CTAs and higher eCPMs than non-AMP site||Google Caching – content on an AMP site will be cached by Google meaning you may have some restrictions on the analytics data you are able to pull. Google is working on this but if you rely on detailed analytics, be sure you can get what you need before investing the time|
2. PWA (Progressive Web App)
PWAs are a great alternative to moving to AMP. They are also a great alternative to the traditional native mobile app. If you were planning on launching a new app this year, or even updating your current native app, you may want to consider a PWA. They are relatively easy to manage and don’t require an installation by the user as they are essentially just web pages.
You can read more about PWAs here.
|Quick loading – service workers allow your app to load nearly instantly no matter what kind of network connection you have. Content can also be made available offline||Compatibility – not all browsers support PWAs including IE, Edge and Safari as well as some custom and proprietary browsers. Safari has close to 50% of the mobile browser market which is restrictive|
|Presence on homepage – similar to native apps, a PWA can have a web app install banner giving users quick and easy access to your content. You can also implement push notifications||Not all functionality is supported – PWA support is limited on Android devices and features like home screen shortcut prompting and notifications are not supported on iOS|
|SEO friendly – since PWAs are essentially just web pages, they are discoverable using search engines due to their W3C manifests, giving them an advantage over native apps||No download store – if you are thinking of replacing your current native app, be aware that there is no central download store which could make discoverability more tricky|
3. PWAMP (Progressive Web App with Accelerated Mobile Pages)
The final option for speeding up your mobile website is a combination of numbers one and two. Coined by Google’s Gary Illyes at SMX Advanced in Seattle back in June 2017, PWAMP is a hybrid mix of a Progressive Web App and the code that drives Accelerated Mobile Pages.
A PWAMP site would essentially use the pared-down AMP code within a Progressive Web App. The result? A fast-loading super-site.
Sounds too good to be true right? Well, as with AMP and PWA, there are of course some pros and cons.
|Super-fast loading – as PWAMPs take all the best bits from AMP and PWAs, they are super-fast loading and should deliver web pages to the end-user in less than 1 second||Non-validating AMP pages – depending on how you set them up, your PWAMP site may not validate as AMP pages as it is likely that you will break the AMP rules elsewhere on the page. It is possible to use a feed to ensure your AMP pages do validate in a PWAMP site though (see example below)|
|Search engine friendly – a PWAMP site would be discoverable by search engines meaning your fast-loading content should rank extremely well, ticking a lot of boxes in the mobile-first index||Compatibility – as with PWAs, compatibility is perhaps the biggest issue for PWAMP sites. As more sites move towards PWAs, it is likely that giants such as Safari will have to jump on board with support|
When we attended SMX Advanced back in June 2017, there was a lot of chat about PWAs vs native apps and the possibility of creating PWAMP sites. One thing that was apparent was the issues with validating PWAMP sites and certainly issues around validating the AMP code within a PWAMP site.
It seems, however, that there is a workaround for this which has been highlighted on the AMP Project website. ShadowReader is a PWA that is built to pull in AMP pages. The PWA, which you can access here, was built from scratch and uses real-world feeds and AMP pages from The Guardian. This PWAMP site is super-lightweight at less than 10kb (or less than 200kb once you pull in Guardian web fonts and AMP).
Credit: Amp Project – https://www.ampproject.org/
For us, this is a super-exciting development and it gives you the opportunity to see if a PWAMP site will work for you.
It is our belief that the mobile-first index will represent a seismic shift in the way that digital marketers need to operate. Whilst many people have talked about ‘thinking mobile-first’ for some time, the mobile-first index will actually force people to ‘act’ mobile-first which can only be positive for users.
There is, of course, lots of reading out there when it comes to preparing for the mobile-first index. This awesome summary post from Moz does a great job of covering off all the key questions and areas you need to tackle.
We believe that site speed is one of the key areas that need to be addressed by site owners. We see too many sites that are slow to load on a mobile device and if those issues are not tackled, you risk being left behind.