“A Progressive Web App uses modern web capabilities to deliver an app-like user experience.”– Chrome Dev Team
With the support of more and more of the HTML5 spec and advancement in JavaScript, We have now come across some really fascinating culture of web & That’s what we call the Progressive web Apps ( PWA).
The really exciting thing about Progressive Web App is:
1) They could make app development less necessary.
2) Your mobile website becomes your app.
EX: Flipkart, largest e-commerce site of India, decided to combine their web presence and native app into a Progressive Web Application that has resulted in a 70% increase in conversions.
“We know that everyone needs to build mobile-first experiences. With Flipkart Lite, we’ve developed a powerful, technically-advanced web app that performs as well as our native app. We now feel we have the best of both worlds.” said CEO of Flipkart.
Here is the screenshot of Flipkart’s PWA.
How Progressive Web Apps Work?
Progressive Web Apps (PWA) has been developed with very fast load times and reduces the steps required to access a specific information directly from a website. They also have built-in intelligence that evaluates user’s behaviour and preferences so the app can deliver a more personalized experience.
Progressive Web apps do not require any installation or downloads and can be accessed from a browser tab. User can simply put on their personal data for logging & build relationship with the apps. In return, the app will send push notifications for easy re-engagement. When a Progressive Web App is published online, it is completely linkable and deployed to a host that supports HTTPS. The app will work when the user is online or offline, using the data that was cached when the user was previously online.
In many cases, the mobile version of the website becomes the PWA itself since it allows for a condensed user experience on any type of screen with a variety of features accessible with a screen tap, swipe, or mouse click.
Major Benefits Of PWA
– User-friendly: Push notifications that allow the user to get a quick summary or snapshot of updates or messages instead of receiving an email update or waiting to log in to check.
– Engaging: Offline functionality that allows the app to continue running in the background and “take notes” on the user’s behaviour and activities without the user having to interact with the app directly.
– Responsive: Highly responsive layout and easier navigation than the full desktop website on a mobile device.
– Flexible Support: All types of hardware access, including Geo location, camera and microphone and screen orientation access.
– Accessible: Accessibility to all internet users, since the requirement to download the app or pay for the app is completely eliminated. It has lower data usage, especially important for users in areas with slow or limited internet access.
Most Appropriate Website Case For PWA
PWA is most appropriate for the following type of websites where:
– Content that regularly updates, like stock tickers, rapidly changing prices or inventory levels, or other real-time data.
– A chat platform, requiring real-time updates and push notifications for new items coming in.
– An audience likely to pull data and then browse it offline, such as a news app online courses & those publishing many articles a day
– A site with regularly updated content which users may check in to several times a day.
– Users who are mostly using a supported browser
Key Services:
– Push notifications, for telling a user that something has happened, such as receiving a new message, or that the page they’re viewing has been updated
– Background sync, for updating data while a user isn’t using the page/site
– Offline caching, to allow a for an experience where a user still may be able to access some functionality of a site while offline
– Handling geo location or other device hardware-querying data (such as device gyrpscope data)
– User experience & engagement.
SEO RECOMMENDATIONS FOR PW
1) Don’t cloak to Googlebot:
According to Google:Cloaking refers to the practice of presenting different content or URLs to human users and search engines. Cloaking is considered a violation of Google’s Webmaster Guidelines because it provides our users with different results than they expected.
Some examples of cloaking include:
- Serving a page of HTML text to search engines, while showing a page of images or Flash to users
- Inserting text or keywords into a page only when the User-agent requesting the page is a search engine, not a human visitor
If a site gets hacked, it’s not uncommon for the hacker to use cloaking to make the hack harder for the site owner to detect. Read more about hacked sites.
Also known as IP delivery, Cloaking basically means delivering content tailored for specific users who are identified primarily by their IP addresses, but also by user agent (browser, crawler, screen reader…) names, etc.
It’s important that the developer uses the feature detection and progressive enhancement technique so all users have access to the content.
It’s also not a good idea to redirect to an unsupported browser page.
2) Use rel=canonical when serving content from multiple URLs so that you aren’t guilty of duplicate content violations.
Let’s assume you have two versions of the same page. Exactly 100%, the same content. They differ in that they’re in separate sections of your site and because of that the background colour and the active menu item differ. That’s it. Both versions have been linked from other sites, the content itself is clearly valuable. Which version should a search engine show? Nobody knows.
For example’s sake, these are their URLs:
http://qodemedia.com/services/link building/
http://qodemedia.com/services/seo/link building
This is what rel=canonical was invented for. Especially in a lot of e-commerce systems, this (unfortunately) happens fairly often.
A product has several different URLs depending on how you got there. You would apply rel=canonical as follows:
You pick one of your two pages as the canonical version. It should be the version you think is the most important one.
If you don’t care, pick the one with the most links or visitors. If all of that’s equal: flip a coin. You need to choose.
Add a rel=canonical link from the non-canonical page to the canonical one. So if we picked the shortest URL as our canonical URL, the other URL would link to the shortest URL like so in the <head> section of the page:
<link rel=”canonical” href=”http://qodemedia.com/services/link building/”>
That’s it.
What this does is “merge” the two pages into one from a search engine’s perspective. It’s a “soft redirect”, without redirecting the user.
Links to both URLs now count for the single canonical version of the URL.
3) AVOID Using # in URL structure
Googlebot will not index URLs with “#” n them. Many Progressive Web Apps use the hash symbol in their URL structure, which means the search engines will drop everything beyond the #.
Ex: http://www.sample-domain.com/ajax.html#key=value
The only way around this is to implement a URL structure using traditional SEO rules.
This may be tricky for some sites and companies, but it’s a necessary step as we move forward.
4) Avoid the AJAX-Crawling scheme on new sites
The AJAX crawling scheme is a method by which Google and other search engines crawl websites that provide dynamically generated content. Google has used this procedure since 2009. However, on October 15, 2015, Google announced that this crawling scheme was no longer recommended and deemed obsolete (depreciated). Instead, Progressive Enhancement and the possibilities of HTML5 (history API) is meant to be utilized to ensure accessibility of certain content to crawlers.
AJAX-based Web applications generate content to be displayed with asynchronous data transfer between the browser and server. This makes it possible to perform HTTP requests using JavaScript and XML (HTTP Request) during a browsing session in order to load content from the server or from a database, but without having to load the HTML site again. This means that parts of the content and the user interface can be loaded by the browser without the need of further HTTP communication between server and browser, as is the case with static HTML webpages. Thus the browser can get data that was already entered in a form, or data can be changed if they have to be up to date (such as dates).
5) Test to see how Googlebot sees the page
You can make use of Google Search Console’s Fetch and Render tool to see your site exactly the way Google sees it.
6) Make sure required resources aren’t blocked by robots.txt.
Here, We can clearly see that no resources are blocked by robots.txt.
7) Reduce the number of embedded resources in the page (especially the number of JavaScript files required to render the page), since these might not be fully loaded.
8) Use an accurate sitemap file to signal any changes to your website when using Accelerated Mobile Pages (AMP).
9) Remember that some search engines and web service providers accessing content may not support JavaScript or might support a different subset.
CONCLUSION
Progressive web App is a wonderful and exciting thing for Responsive web development. Google has been recommending for PWA to business owners.
At the same time, You should also consider the proper SEO approaches so that your new web app would not hurt your ranking & prove to be an Asset for the business.