In the previous guide I explained to you what a PWA is and how to create one , now I would like to go deeper into the technical aspects of the requirements.
On this page you will find the official Google checklist, in English. Since the guide in Italian was missing, I thought of translating the original one, making it even more digestible .
Progressive Web Apps (PWAs) are reliable, fast, engaging and scalable. There are indeed many technical details that can elevate a PWA from being a basic model app (Baseline Progressive Web App) to a complex app (Exemplary Progressive Web App). A complex PWA provides a more meaningful offline experience, very fast interactivity and is cared for down to the smallest detail.
Below you will find two checklists, one basic with the minimum requirements and another advanced with the optimal characteristics that a PWA should have.
Index:
- Checklist for basic PWA
- Complex PWA Checklist
- Indexability and social
- User experience
- Performance and loading times
- Caching functionality
- Push notifications
- Additional features
Checklist for basic PWA
The Lighthouse tool can automatically check many items on this list and can come in handy for easily testing sites.
The site is served over HTTPS
How to test: Use Lighthouse to verify that pages are served over HTTPS .
How to fix: Implement the HTTPS protocol . You can check on letsencrypt.org to get started.
The pages have a responsive design, suitable for tablets and mobile devices
How to test:
- Use Lighthouse to verify that the website is optimized for mobile devices. It might also be useful to check manually with devices at your disposal.
- Check with the mobile optimization test
How to fix: Try to implement responsive design or adaptively serve a site compatible with mobile devices.
All app URLs are uploaded offline
How to test: Navigate various pages of the PWA while your smartphone is in airplane mode. Make sure the app has some content even offline. Use Lighthouse to verify that the start URL responds with status code 200 when offline.
How to fix: Use a service worker .
The metadata for the “Add to Home screen” installation banner
How to test: Use Lighthouse to verify that all requirements are met to ask the user to add the PWA to the Home screen .
How to fix: Add the Web App Manifest file to your project.
Fast first loading even on 3G
How to test: Use Lighthouse on a Nexus 5 (or similar) to verify that the time it takes for the page to become interactive (time to interactive) is less than 10 seconds , for the first visit on a simulated 3G network. This audit identifies when a page appears to be ready enough for the user to interact with it.
How to correct:
- There are many ways to improve performance .
- You can better understand your performance using Pagespeed Insights (target for score> 85) and SpeedIndex value on WebPageTest (aim for <4000 as first view on Mobile 3G Nexus 5 Chrome).
- Some of the best practicesinvolve reducing the scripts to load. Make sure the script is loaded, where and when possible, asynchronously using <script async > and make sure you avoid render blocks due to CSS dependencies .
- You can also use the PRPL model and tools like PageSpeed Module on the server.
The site works cross-browser
How to test: Test the site in Chrome, Edge, Firefox, and Safari
How to fix: Fix problems that occur while running the cross-browser application
Fast page transitions
Transitions from page to page should be snappy at the touch of the screen, even on a slow network. This is a key feature to optimize perceived performance.
How to test: Open the app on a simulated very slow network. Whenever you tap a link / button in the app, the page should respond immediately, via:
- Immediate transition to the next screen and display a placeholder loading screen waiting for content from the network.
- A loading indicator is shown while the app waits for a response from the network.
How to fix: If you are using a single page application (client-side rendered), immediately move the user to the next page and show a skeleton screens (a blank version of the page currently loading) and show any content as a title or thumbnail already available when loading content.
Each page has a specific URL
How to test: Make sure that individual pages are URL linkable and that URLs are unique for purposes of social media shareability. Check that the individual pages can be opened and accessed directly through the new browser windows.
How to fix: If you create a single page application, make sure the client-side router can rebuild the page the user expects from a certain URL.
Complex PWA Checklist
Many of these checks have to be done manually, as they have not yet been implemented in Lighthouse.
Indexability and social
For more information, see the social optimization and social discovery guide .
The content of the site is indexed by Google
How to test: Use the View as Google tool to preview how Google will see your site when crawled.
How to fix: Google ‘s indexing system runs JavaScript but some issues may need to be addressed to make the content accessible. For example, if you’re using new browser features like Fetch API , make sure they don’t prevent the app from working in unsupported browsers.
Schema.org metadata is provided only when appropriate
Schema.org metadata can help improve your site’s appearance in search engine results.
How to test: Use the test tool to make sure that the title, image, description, etc. are indicated and available.
How to fix: Insert markup into content. For example:
- A recipe app must have Recipe type markup for Rich Cards .
- A news app should have NewsArticle type markup for Rich Cards and / or AMP support .
- An ecommerce app should have Product type markup for Rich Cards.
Social metadata is provided where appropriate
How to test:
- Open a representative page in the Facebook crawler and make sure it is validated.
- Check that the Twitter Cards metadata is present (eg <meta name = ”twitter: card” content = ”summary” />) if you think it is appropriate.
How to fix: Enter Open Graph markup as recommended by Twitter .
Canonical URLs are provided when needed
This is only necessary if your content is available on multiple URLs.
How to test:
- Check if there are identical pages on two different URLs.
- Open both of these pages and make sure they use the <link rel = canonical>tag in the <head> section of the HTML to tell search engines the canonical version.
How to fix: Add the canonical tag to the <head> section of each page, indicating the canonical source document. See Google’s help for more information.
Pages use the History API
How to test: For single page apps, make sure the site is not using _escaped_fragment_ . For example after the #! in https://example.com/#! user / 26601 .
How to fix: Use the History API instead of escaped_fragment_.
User experience
The content design remains stable while the page is loading
How to test: Load various pages into the PWA and make sure the content or user interface doesn’t “jump” as the page loads.
How to fix: Make sure all content, especially images and ads, has a fixed size in the CSS or inline on the element. Before uploading the image, you may want to show a gray square or a blurry / small version (if available) as a placeholder.
Pressing back from a detail page maintains the scroll position on the previous list page
How to test: Find a list / list view in the app. Scroll down. Tap an item to go to the details page. Scroll to the details page. Press back and make sure the list view scrolls to the same spot it was before the detail link / button was pressed.
How to fix: Reset scroll position in lists when user presses ‘back’. Some routing libraries have this feature.
When selected, text input areas are not covered by the on-screen keyboard
How to test: Find a page with a text input area (a contact form). Scroll to place the input area as low as possible on the smartphone screen. Tap the input area and make sure it’s not covered by the keyboard.
How to fix: Use features like Element.scrollIntoView () and Element.scrollIntoViewIfNeeded () to ensure that when tapped, the input area is always visible on the screen.
The content is easily shareable from standalone or full screen mode
How to test: Make sure, from standalone mode (after adding the app to the home screen), that you are able to share content, if appropriate, from the app’s UI.
How to fix: Provide social share buttons or a generic share button within the UI. If you use a generic button, you can directly copy the URL to the user’s clipboard when tapped, offer them social networks to share or try the new Share Web API for integration with the native sharing system on Android.
The site is responsive across all screen sizes on your phone, tablet, and desktop
How to test: View the PWA on small, medium and large screens and make sure it works sensibly on all of them.
How to fix: See Google’s official guide on implementing responsive user interfaces .
Don’t over-request to install the app
How to test: Verify that the PWA is not using an interstitial banner for app installation when loaded.
How to correct:
- There should be only one install bannerpresent in the app, either top or bottom.
- After the PWA has been added to the user’s home screen, all top / bottom banners must be removed.
The request to add to the home screen is recognized by the browser
How to test: Verify that the browser does not display the A2HS (Add To Home Screen) banner at an inappropriate time, for example when the user is in the middle of a stream that should not be interrupted or when another prompt is already displayed on the screen.
How to correct:
- Listen for the beforeinstallpromptevent and postpone it.
- Chrome manages when to activate the prompt, but in certain situations this may not be ideal. You can defer the prompt later in using the app. It might also help to dim the screen, as recommended to request permissions below.
Performance and loading times
Fast first loading even on 3G
How to test: Use Lighthouse on a Nexus 5 (or similar) to verify that the time to make the app interactive is less than 5 seconds, for the first visit on a simulated 3G network (as opposed to the 10s target for PWAs of base)
How to correct:
- Check out the performance section of WebFundamentals and make sure you follow best practices.
- You can better understand your performance using Pagespeed Insights (target for score> 85) and SpeedIndex value on WebPageTest (aim for <4000 as first view on Mobile 3G Nexus 5 Chrome).
- Some of the best practicesinvolve reducing the scripts to load. Make sure the script is loaded, where and when possible, asynchronously using <script async> and make sure you avoid render blocks due to CSS dependencies .
Caching functionality
The site uses the cache-first system
How to test:
- Set the network emulation to the slowest setting and browse the app.
- Then, set the network emulation to offline and continue browsing the app. The app shouldn’t seem faster when offline than on a slow connection.
How to fix: Use cache-first responses where possible. It also examines the set of service worker libraries that make it easier to implement these types of templates.
The site appropriately informs the user when he is offline
How to test: Emulate an offline network and verify that the PWA provides an indication that the user is offline.
How to fix: Use the Network Information API to show the user an indication when they are offline.
Push notifications
This checklist only applies if push notifications are implemented . Adding push notifications is not a requirement for an advanced progressive web application.
Provide context to the user on how notifications will be used
How to test:
- Visit the site and find the opt-in (activation) of notifications
- When the browser asks for permission, make sure that context has been provided to explain what the site is requesting permission for.
- If the site asks for page load permission, be sure to provide very clear context at that time as to why the user needs to enable push notifications.
How to fix: Check out the guide to creating easy-to-use notification permission flows .
The UI that encourages users to activate push notifications doesn’t have to be overly aggressive
How to test: Visit the site and find the opt-in for push notifications. Make sure that if you ignore the push notification, it is not requested a second time within the same session.
How to fix: If users say they don’t want a certain type of notification, don’t repeat the reply for at least a few days (for example, a week).
The site blanks the screen when the authorization request is displayed
How to test: Visit the site and find the push notification opt-in. When Chrome shows the permission request, make sure the page “obscures” (by superimposing a dark overlay) any content that is not relevant to explain why the site would like to send push notifications.
How to fix: When using Notification.requestPermission darkens the screen. Reset visibility after user choice.
Push notifications must be timely, accurate and relevant
How to test: Enable push notifications from the site and make sure the push notifications use cases are:
- Timely – a timely notification appears when users want it and when it’s important to them.
- Accurate – An accurate notification is one that has specific information that can be acted upon immediately.
- Relevant – A relevant message is about the people or individuals that the user imports.
How to fix: See the guide on creating great push notifications for advice. If your content isn’t timely and relevant to this user, consider using email.
Provides controls to enable and disable notifications
How to test: Enable push notifications from the site. Make sure there is a place on the site that allows you to manage notification permissions or disable them.
How to fix: Create a user interface that allows users to manage their own notification preferences.
Additional features
The user is logged in on all devices via the Credential Management API
This only applies if your site has a login flow.
How to test:
- Create an account for a service and make sure you see the save password / account window displayed. Click “Save”.
- Clear the cookies for the site (by clicking on the lock or Chrome settings) and refresh the site. Make sure you see an account collector (eg if there are multiple saved accounts) or they’ll automatically reconnect you.
- Exit and refresh the site. Make sure you see the account selector.
How to fix: Follow the Credential Management API Integration Guide .
The user can easily pay via the native user interface and Payment Request API
This check only applies if your site accepts payments.
How to test: Run the payment flow. Instead of filling out a conventional form, verify that the user is able to pay easily via the native user interface activated by the Payment Request API.
How to fix: Follow the API integration guide for payment requests .