The #ChromeDevSummit site is live, happening Nov 12-13 in San Francisco, CA Check it out for details and request an invite. We'll be diving deep into modern web tech & looking ahead to the platform's future.
Progressive Web App Checklist
Progressive Web Apps (PWA) are reliable, fast, and engaging, although there are
many things that can take a PWA from a baseline to exemplary experience.
To help teams create the best possible experiences we've put together this
checklist which breaks down all the things we think it takes to be a
Baseline PWA, and how to take that a step further with an
Exemplary PWA by providing a more meaningful offline experience,
reaching interactive even faster and taking care of many more important details.
Baseline Progressive Web App Checklist
The Lighthouse tool is able to automatically verify many items
on the this list and may prove helpful in easily testing sites.
Fix issues that occur when running the app cross-browser
Page transitions don't feel like they block on the network
Transitions should feel snappy as you tap around, even on a slow
network, a key to perceived performance.
Open the app on a simulated very slow network. Every time you tap
a link/button in the app the page should respond immediately, either by:
Transitioning immediately to the next screen and showing a
placeholder loading screen while waiting for content from the
A loading indicator is shown while the app waits for a response
from the network.
If using a single-page-app (client rendered), transition the user to
the next page immediately and show a
skeleton screen and use any content such as title or
thumbnail already available while content loads.
Each page has a URL
Ensure individual pages are deep linkable via the URLs and that URLs
are unique for the purpose of shareability on social media by
testing with individual pages can be opened and directly accessed
via new browser windows.
If building a single-page app, make sure the client-side router can
re-construct app state from a given URL.
Exemplary Progressive Web App Checklist
Many of these checks must be performed manually, as they are not yet
implemented in Lighthouse.
Fetch as Google tool to preview how Google will see your site when
it is crawled.
may need to be fixed to make content accessible. For example,
if you are using new browser features like the Fetch API, ensure that they are
polyfilled in browsers without support.
Schema.org metadata is provided where appropriate
Schema.org metadata can help improve
the appearance of your site in search engines.
testing tool to ensure title, image, description etc. are available.
Load various pages in the PWA and ensure content or UI doesn't
"jump" as the page loads.
Ensure all content, especially images and ads, have fixed sizing in
CSS or inline on the element. Before the image loads you may want
to show a grey square or blurred/small version (if available) as
Pressing back from a detail page retains scroll position on the
previous list page
Find a list view in the app. Scroll down. Tap an item to enter the
detail page. Scroll around on the detail page. Press back and ensure
the list view is scrolled to the same place it was at before the
detail link/button was tapped.
Restore the scroll position in lists when the user presses 'back'.
Some routing libraries have a feature to do this for you.
When tapped, inputs aren't obscured by the on screen keyboard
Find a page with text inputs. Scroll to put the text input as low on
the screen as you can make it. Tap the input and verify it is not
covered when the keyboard appears.
Content is easily shareable from standalone or full screen mode
Ensure from standalone mode (after adding the app to your home screen)
that you are able to share content, if appropriate, from within the
Provide social share buttons, or a generic share button within your
UI. If a generic button, you may want to directly copy the URL to the
user's clipboard when tapped, offer them social networks to share to,
or try out the new
Web Share API to integrate with the native sharing system on Android.
Site is responsive across phone, tablet and desktop screen sizes
View the PWA on small, medium and large screens and ensure it
works reasonably on all.
Check the PWA doesn't use an app install interstitial when loaded
There should only be one top or bottom app install banner
After the PWA is added to the user's home screen, any top/bottom
banners should be removed.
The Add to Home Screen prompt is intercepted
Check the browser doesn't display the A2HS at an inopportune moment,
such as when the user is in the middle of a flow that shouldn't be
interrupted, or when another prompt is already displayed on the screen.
Intercept the beforeinstallprompt event and prompt later
Chrome manages when to trigger the prompt but for situations this
might not be ideal. You can defer the prompt
to a later time in the app's usage. It may also help to dim the screen,
as advised for requesting permissions below.
First load very fast even on 3G
Use Lighthouse on a Nexus 5 (or similar) to verify time to interactive
<5s for first visit on a simulated 3G network (as opposed to the
10s goal for baseline PWAs)
Review the performance
section of WebFundamentals and ensure you're following the best
You can understand your performance better by using
(aim for a score >85) and SpeedIndex on
(aim for a score <4000 on the first view on Mobile 3G Nexus
A few tips are to focus on loading less script, make sure as much
script is loaded asynchronously as possible using <script
async> and make sure
render blocking CSS is marked as such.
Site uses cache-first networking
Set the network emulation to the slowest setting and browse around
Then, set the network emulation to offline and browse around. The
app should not feel faster when offline than on a slow connection.
Use cache-first responses wherever possible. Also review our set of
service worker libraries
that make implementing these kinds of patterns easier.
Site appropriately informs the user when they're offline
Emulate an offline network and verify the PWA provides an
indication that you are offline.
UI encouraging users to turn on Push Notifications must not be
Visit the site and find the push notifications opt in flow. Ensure
that if you dismiss push notification, the site does not re-prompt
in the same way within the same session.
If users say they don't want a certain kind of notification, do not
reprompt for at least a few days (for example, one week).
Site dims the screen when permission request is showing
Visit the site and find the push notifications opt-in flow. When
Chrome is showing the permission request, ensure that the page is
"dimming" (placing a dark overlay over) all content not relevant to
explaining why the site needs push notifications.
Provides controls to enable and disable notifications
Enable push notifications from the site. Ensure there is some place on
the site that allows you to manage your notifications permissions or
Create a UI that allows users to manage their notification preferences.
User is logged in across devices via Credential Management API
This only applies if your site has a sign in flow.
Create an account for a service and ensure you see the save
password/account dialog show up. Click "Save".
Clear cookies for the site (via clicking on the padlock or Chrome
settings) and refresh the site. Ensure that you either see an
account picker (e.g. if there are multiple accounts saved) or
are automatically signed back in.
Sign out and refresh the site. Ensure that you see the account picker.