Emily opened her talk with the suggestion that neither websites nor web apps serve the user needs adequately. Websites need to reload, while web apps have their downfalls too.
She suggests that we need to be focused on progressive web apps (PWAs) instead.
Crawling and indexing
What we can do, she suggests, is render it ourselves, meaning Google doesn’t have to, by using server side rendering.
You need to also have server side rendering, for the user’s benefit, but it’s best to have it render server side and then client side for Google.
Emily’s least favourite option for this is that you only focus on Google (and no other search engines) and you focus on making their rendering the best. Google has stated that their rendering service is built off the Chrome 41 service, so your content needs to render in Chrome 41.
You can use Fetch and Render, but this has issues of sometimes not matching what you would see as a user.
It’s worth noting that if you only focus on Google, other search engines will struggle to crawl it.
This is where we think about making our web experiences a little more app like.
So what does PWA mean? It means it has the ability to prompt the user to install the website onto their homescreen, then when the user decides to launch your app, it can launch outside of the traditional web experience. You can even set it up to send push notifications, like a regular native app.
You can also allow the content to be delivered offline – and with PWA, it can be a different experience for offline users than for online users.
In one example from The Guardian, users were given a crossword instead of the offline dinosaur game when a user was outside of wifi or internet connection.
So how do you do all of this?
The first thing you need is an App Manifest, which is a simple JSON file you link to in your head. It just tells the client what logos to use, how to launch, etc. it tells the system what we need to install when we install a website.
The next thing is a service worker. This is kind of like an air traffic controller for the server. When we request an image, it doesn’t go to the server, it goes to the service worker which reviews the request and works out what to do – e.g. to get the image and also to save it in the local cache. So when it’s reloaded, the user can access the image quickly – and this is also how the offline experience happens too.
The final thing you need is an HTTPS mobile friendly website. It must be HTTPS because service workers are so powerful. You can use it without security in place.
It’s important to measure the effects of these investments.
Page speed is the main one. You’re trying to make your site faster – she recommends Performance Analyser for Analytics as a way of integrating this information.
You should also measure how many people are accessing your progressive web app. You can measure ‘launches’ by tagging up your launch URL. Also think about how to record offline traffic, and measuring push notifications (which is something Emily hopes Google will start building into Analytics).
This post is one of 12 in our Search Love 2017 collection
- Search Love: The Why and How of Creating Video Content for Search – Justin Briggs
- Search Love: Tales from the Charity Frontlines – Cheri Percy
- Search Love: From Website to Web App – Emily Grossman
- Search Love: What To Do When Your Content Fails – Kirsty Hulse
- Search Love: Using Power BI to Bust Silos – Wil Reynolds
- Search Love: Content Distribution – Ross Simmonds
- Search Love: Social Content Masterclass – David Levin
- Search Love: Mobile-First Preparedness – Jon Myers
- Search Love: The New Era of Visual Marketing – Jes Scholz
- Search Love: Reverse Engineering Google’s Research – Rob Bucci
- Search Love: Beyond the Reach of Keyword Targeting – Samantha Noble
- Search Love: Link Building Myths and Fails – Paddy Moogan