Welcome back to the continuation of this two-part PWA blog series! I'm stoked you guys also found PWA's interesting and I'm here to finish up the topic. For those of you who have not read the intro to PWAs, check it out here:
As promised, I'm going to be diving deeper into what really goes on under the hood of a PWA. So just to reiterate, a Progressive Application is a happy medium between a web and a native app and basically delivering a much more efficient and user-friendly experience.
Let's dive into the main three components of a PWA!
Application Shell
In a nutshell, this is where the content gets placed. You only need the bare essentials like navigation and header elements as this portion of the PWA aren't loaded each time it gets launched by the user. It is instead cached once and then stored to be displayed to the user no matter their internet connection. This is the core component that makes the PWA so fast and efficient.
Service Workers
One of the reasons a PWA is so great is its ability to perform with limited to no internet connection. This is where the Service Worker comes into action. The Service Worker is an independent network script that focuses on the background and determines whether or not the content should be downloaded from the cache or server. This is the fundamental reason why PWA's work offline and are able to organize data. The central requirement for installing a Service Worker is the HTTPS server. The HTTPS server stops performing when idle but re-fires the next time it is needed.
Manifest Files
The Manifest File allows you, the developer to create your custom splash screen. For those of you who don't know what a splash screen it is the default page shown until your app has loaded and provided your user a more native-like experience. For many applications, this can consist of a plain white screen but that's no bueno. You want to engage your user and make it feel like they're using an app, not an unfriendly mobile web page.
Now, let's get into some of the other components:
Push Notifications
PWA Push Notifications are pretty comparable to that of Native Apps, which is really really cool! This all works due to the Service Workers and Push API. Through the Service Worker's Push Manager, the user of the App gets a pop-up suggesting subscribing to push notifications. Once the user has agreed to the terms and conditions, their subscription ID is stored in the database. I mentioned earlier how SW's handle data, but following this order of events, the server takes over and pushes new messages and the SW subsequently fires off the push notification to the specific user device.
Installation Banners
Also referred to as the web app install prompt, it is one of the methods used by PWA's to captivate and engage its users. As modern-day web users, our attention span is quite limited as we bounce back from different applications, activities, etc. so in order to create an engaging experience and reel in the attention of its users PWA's offer for users to save the page to their home screen after about 30 seconds of use. This install prompt is supported by several browsers including Opera v. 32+, Chrome v.31+, Firefox v. 589+, etc. This gives users the experience of having downloaded an app without the hassle of having to actually do it.
Different Caching Strategies
This is super important for creating a seamless experience with a limited internet connection. There are a few different options to consider:
Cache
A cache only PWA is optimal for a completely static site. Here, the data is cached during the installation process and there are no requests sent by the Service Worker to the server.
Network
It's almost self-explanatory. This approach does not use caching, instead, the Service Worker exclusively sends requests to the network and if there's no network response the request simply fails.
Cache First:
Here the Service Worker automatically loads the cached data, without even trying to reach the network. The requests are only sent to the network when there is no cached data available. This approach is actually a great blueprint for stashing static information and App Shell resources. Information will then only be refreshed when the actual app version gets updated.
Network First:
Here, the PWA's strategy is to essentially send requests to the network. If there is a response, the app will render the received data. If not, the Service Worker only renders cached data. This strategy is ideal for apps with dynamic content.
Cache Vs. Network
An instance where you would be interested in this approach is for a device with slow disk access. The PWA will send a simultaneous request to the network and the cache. Normally, the cached data will render first. During this time, the network shoots over the renewed data and saves it to the cache. This data is refreshed in the background in order to not interrupt the rendering data in a cache.
Well folks, there you have it. You now have the basic information you need to determine why you would want to dive deeper into Progressive Web applications and what type of Caching strategy you need based on your own specific app needs. I for one am looking forward to refactoring some of my Flatiron School projects to make them more efficient, but also mobile-friendly! There is so much more to this subject so depending on how my to refactor goes I might have to just keep y'all posted.
Top comments (2)
Good summary of things 👍
Good article I enjoyed it