Progressive Web Applications — Core principles
- A user opens the application for the first time.
- Service Worker fetches resources needed to display the web application and caches them.
- The next time the application is opened, Service Worker intercepts network requests made by the browser to download resources needed to display the page (including initial server call for HTML file) and can respond with the cached version if necessary.
PWAs don’t have to display anything meaningful when the user is offline, simply displaying a message to the user that the network is down can be sufficient. Depending on the applications offline support could mean much more than that, e.g.:
- news app could cache the most important articles or those that are relevant to the user whenever the app is opened and allow the user to read them whenever the connection is offline,
- messaging app could store recent messages as they arrive and allow the user to browse them while offline.
- collaborative spreadsheet app could store recent documents and allow users to view them and make changes that would be synchronized when the connection is brought back online.
As you can see, offline support is not limited to using Service Workers and starts at the design time when designers and product owners think about the application is offline.
Slow network conditions
PWAs are expected to work on slow network conditions. Navigation inside the app should be smooth regardless of bandwidth and latency as this would be the case for mobile apps. Again, Service Workers can help in such scenarios, e.g. by caching lazy-loaded routes. Additionally, when network resources are required to display resources, skeleton screens can be used to show an indication of progress.
Performance is a very important metric of any web application. Google reports that:
Performance engineers at Google have developed a universal model for measuring performance called RAIL. RAIL is a user-centric model that was created by researching human interactions with computer programs. Goals set by the RAIL model can be applied to any user-oriented software program, e.g. websites, mobile and desktop applications, and video games.
RAIL is an acronym that describes key performance metrics:
- Respond — respond to user input in 100 ms,
- Animate — animations should run in 60fps,
- Idle — maximize idle time,
- Load — display some content to a user under 1s and become interactive under 5s.
Applying the PRPL pattern can greatly help in achieving the goals mentioned before.
PRPL stands for:
- Push critical resources for the initial URL route.
- Render initial route.
- Pre-cache remaining routes.
- Lazy-load and create remaining routes on demand.
Performance measuring tools
- Lighthouse can automate the process of performance testing and even run on CI servers,
- Performance Budgets, e.g. Webpack has built-in tools to support this
PWAs should feel like native apps and have the capabilities of native apps.
On all major mobile platforms, PWAs can be installed on the user’s home screen and open without displaying any browser controls. On desktop platforms, PWAs can be added to taskbars and docks, shortcuts can be added to the desktop, however as of now they still open in a browser.
Web platform has grown very much and provides APIs for features like:
- location services
- push notifications,
- native platform payments (e.g. Apple Pay, G Pay),
You can visit What web can do today? for a list of notable features available in modern browsers.