Let's look at these in turn.
When presented with HTML, browsers can parse and render it even whilst it is being downloaded/generated. Indeed this is the fastest way to display data from the underlying service layers; there is no need to wait for all the data to be available before any of it can be consumed. Sending HTML over the wire (instead of JSON), allows the browser to do so with very little effort. Related assets like stylesheets, images, etc. are automatically downloaded as references to them are streamed in, and are downloaded with the relevant priority. Browsers truly are very clever on their own.
Browsers can navigate from page to page by following
<a href> links. They can provide feedback to the server through form
GET, following redirects as necessary. Backward/forward navigation is natively supported, and cached in most instances. Provided the markup is semantic, accessibility is also a first class citizen.
However, in recent times, many web applications are littered with
With variable mobile network conditions, there is increasing need for web applications to tolerate intermittent network failures. A user on a train, for example, can experience random dropouts in connectivity as they are travelling. Connectivity may be lost in one interaction, but by the next interaction, it could already be restored. Web applications can smooth out the jarring experience with service workers.
The service worker cache is an additional network-independent layer that can be used to pre-cache critical or previously visited resources. Judicious use of it allows graceful fallbacks to be presented when the network is temporarily unavailable.
Note, this is not a performance optimisation technique. In principal, it is no different to clever use of
<link rel="preload"> to pre-warm a cache. More on performance shortly.
Finally, web applications can be installed, much like native applications can be. To achieve this requires the Web Application Manifest . This is a JSON file that specifies application descriptors like colors and iconography. Having web applications thus installed provides convenience to the user and can result in increased re-engagement.
To provide further integration to the OS, there are several other optional APIs. For example, the Notification API allows web applications to display OS native notifications. Note that this doesn't require that the application to be installed, it can send notifications with it running in a background tab too. It does however, require user consent to work.
The Push API allows services to push notifications to installed clients. It is usually combined with the Notification API mentioned earlier.
Various other APIs to use device capabilities can also enhance the experience.
The corollary to progressive enhancement is graceful degradation. Virtually all web applications function fine without having to be installed. They also function fine if the service worker functionality isn't available (provided the network is functioning correctly).
It is a myth that PWAs increases performance. More likely performance improvements due to any rewrite is due to the removal of cruft and rethinking old bottlenecks than the PWA itself. Service workers pre-cache resources. While this saves on the network transfer of said resources, at a network level, it is no different to judicious use of
I repeat, service workers help smooth out the intermittent network, it does not offer any real performance improvements.
To deliver real performance improvements, you need to consider how you load your data. Complicated data lookups require multi-table or multi-service joins. If the client resolves these long chains of dependencies, every chain involves a network hop and is very expensive. If the server resolves these, then pass the data for the client to render, there is possibly nothing to show until everything is ready to show.