Did you know that until recently 40% of websites were not aware of Google’s new mobile ranking signal? Did you know that a typical user downloads zero new apps a month, but visits roughly 100 websites a month? According to Google, after Flipkart (India’s largest e-commerce site recently acquired by Walmart) moved to a Progressive Web App (PWA), users spent thrice as much time on the site, they had 40% higher engagement rate, 70% greater conversion rate among those arriving via Add to Home screen and lowered the data usage to one-third.
Twitter Lite app is a PWA that was about 500-600KB when it was launched (compare this to main Twitter app that has a size of 25MB).
Needless to say, that speed is impressive and even works well on slow 2G data connections. In short, Progressive Web Apps (PWAs) are web applications that are regular web pages or websites, but can appear to the user like traditional applications or native mobile applications.
Offline mode: Yes, PWAs enable a mobile website to work in offline mode. Mobile websites on phones struggle in times of poor or no connectivity. With a native mobile application, the parts of the app that don’t need any new data from the internet can continue to function. For example, if I want to check my stock portfolio and look at how it has done for the last one year I might go online before I board my flight at the airport. However, during the flight I can check my native app and easily browse through the app even without WiFi. The reason is simple. All the data is on my phone. However, if I had visited a website that had my stock portfolio and then been on a flight with no WiFi, I would not have been able to browse through it.
PWAs support the offline mode. There are different patterns we can use to create a great user experience. One of the common patterns is to look for data locally while making a request to the server and only update the local data is the timestamp is newer.
Native-app feel and performance: Did you know 40% of users bounce from sites that take longer than three seconds to load? PWAs have a median load time of less than one second. Why does a native application perform better than a mobile website? It’s simple. Native applications already have the application shell and they only get data from the server. On the flip side, mobile applications have to query for the application shell (HTML + CSS + JavaScript) along with data. That slows down a mobile application. In case of a PWA, the shell can be downloaded the first time and stored locally on the mobile device. After that, the performance should be as good as a native application. Do remember that the one time hit of downloading is the same for native application. However, PWAs are usually a lot lighter than a native application as mentioned above.
Responsive: PWAs are responsive. That means that they can change the layout of the application along with the change in device. Any device like a mobile phone, tablet or a desktop can use the same code with a more convenient layout.
Progressive: Google made sure to remind everyone that one of the core tenets of PWAs is progressive enhancements. That means it will work with any browser or device.
Secure: While designing PWAs, security was important and so everything must be on HTTPS. PWA Service Workers act as liaison between the browser as well as the application server. Service Workers only work on the secured HTTPS protocol.
Add to home screen: In addition to browsing a website, you can also access a PWA just like a native application by using the ‘Add to Home Screen’ option. Once done, it stays on the mobile screen just like another native app and can be accessed from there.
Push Notifications: Push notifications are known to have increased engagement rate. This has always been a challenge on mobile web. Thanks to PWAs, push notifications on mobile websites is now a reality and is fairly simple.
Easy to Update: Imagine adding a new feature to your mobile app. It’s a process. First, you need to publish the changes and then wait for it to approved by the app store. Haven’t you heard some very big applications complain that some app stores have been delaying their apps? Nothing to worry. PWAs are web based. You can push changes whenever you like and there is no third party that has the power to delay you.
Search engine friendly: What do you do when you need to find something on web? You use Google or Bing or any other search engine. Since PWAs are, in essence, nothing more than a website, they are search engine friendly and easy to find.
Distributable URL: How do you allow users to share a native application? The easiest way is to expose a share button for the users. Now what happens if the user doesn’t have the app downloaded. He has to go download the app and the share button may not have a distributable URL that opens the app at the same location you wanted to share? The easiest way is to have a website and share the URL from the website. Guess what? You don’t need to do anything that complex in case of a PWA. Like a simple website you just take the URL and share it. Anyone having access to a browser and internet will be able to access it.
Development effort: It reduces your development effort multi-fold. You can now use the same code base of the website and deploy your app on any device of your choice. In many cases, it eliminates the need of a native application.
What is a PWA service worker? In short, it’s nothing more than a JavaScript file that that acts as a middleman between the web app and the network. In one line of code, we can find out if a service worker is supported on the browser.
The lifecycle of a service worker is described below:
Registration: Once we know that a service worker is supported, we specify the path of the JavaScript file that is going to serves as the service worker to the browser. The installation process starts in the background.
navigator.serviceWorker.register("/service-worker.js", { scope: "/app/" });
Initialization: Next step is installation. Installation occurs not just for new service workers, but also for service workers that may be a new one. Since everything is even driven, the service worker has an install event listener that can perform some work during installation process.
// Callback for install event
self.addEventListener("install", function(event) {
// Our code while installation
});
Activation: After successful installation, the service worker waits until there all the pages loaded by the old service worker as unloaded. This ensures that only one service worker is being used at one time. Activation happens through the activate event.
// Callback for activate event
self.addEventListener(‘activate’, function(event) {
// Our code while activation
});
Non-blocking: Yes, it’s not blocking. A user can continue to browse while the Service Worker makes interactions between the browser and the server. Regardless, it won’t slow down the user experience because it’s non-blocking.
No access to DOM, XHR API and localStorage: This is easy to infer from No. 1. Since, service worker runs in a worker context, it’s designed to be fully async. Therefore, it has no access to DOM and runs on a different thread to the main JavaScript that is used in the application.
No global state: It serves as programmable network proxy that allows us to control and handle network requests from the web application. However, one thing to keep in mind is that it terminates when it’s not in use. That means it’s not something you rely on to store a global state. It’s advisable to use IndexedDB API to persist data that needs to be used across restarts.
Promises and Fetch API: Once the access is granted to a Service Worker, it uses Promises and Fetch API. Both are async in nature and help the Service Worker’s event driven approach that make the user experience better.
HTTPS: HTTPS is a must for the Service Worker to communicate with the server. One exception to this rule is localhost, which could be used during development.
IndexedDB is a NoSQL storage system that also supports transactions. IndexedDB is a low-level API for client-side storage of significant amounts of structured data, including files/blobs. This API uses indexes to enable high performance searches of this data. While DOM Storage is useful for storing smaller amounts of data, it is less useful for storing larger amounts of structured data. IndexedDB provides a solution. Here’s what you may want to know about IndexedDB:
Object store: Object stores to IndexedDB is what tables are to a relational database. Typically, you would store every single entity as a separate Object store. Examples would be product, order, user etc.
Index: What do we do if have an important table with many columns in a relational database and it needs data to be retrieved using multiple different columns? We use an index. In this case too, an Index is a kind of object store for organizing data in another object store (called the reference object store) by an individual property of the data. The index is used to retrieve records in the object store by this property. For example, if your Object store is Customer, you want few different kinds of indexes like name, customerId, age etc.
Database: Generally speaking we create one IndexedDB database per application. However, you can create multiple ones. Like a relational database, a database is the highest level of IndexedDB. It contains the object stores, which in turn contain the data that needs to be persisted.
Operation: An interaction with the database is considered an operation.
Cursor: A mechanism for iterating over multiple records in database.
Transaction: A transaction is a high-level construct that ensures database integrity. A transaction may include an operation or a group of operations. Similar to relational databases, it will either execute all operations or none of them. In case it has executed some operations and one of them fails, it will roll back the changes.
NOTE: All read or write operations in IndexedDB must be part of a transaction. This allows for atomic read-modify-write operations without worrying about other threads acting on the database at the same time.
Our hierarchy of consultants include Principal Consultants, Senior Architects, Senior Managers, Lead Senior Consultants, Senior and Junior Level Consultants and Developers. Our clients trust us to deliver complicated projects within a short delivery time frame. We have saved our clients millions of dollars and have proven multiple times that we can be more economical than even offshore options.
Our experts are adept with skills and years of hands-on experience working on various web and mobile technologies. We provide services like developing custom progressive web apps from scratch, analyze your website on PWA standard adaptability, migrate an existing app to a feature-rich progressive web app, progressive web design, consulting and developing robust application shell architecture, quality assurance testing and much more.
Cazton is composed of technical professionals with expertise gained all over the world and in all fields of the tech industry and we put this expertise to work for you. We serve all industries, including banking, finance, legal services, life sciences & healthcare, technology, media, and the public sector. Check out some of our services:
Cazton has expanded into a global company, servicing clients not only across the United States, but in Oslo, Norway; Stockholm, Sweden; London, England; Berlin, Germany; Frankfurt, Germany; Paris, France; Amsterdam, Netherlands; Brussels, Belgium; Rome, Italy; Sydney, Melbourne, Australia; Quebec City, Toronto Vancouver, Montreal, Ottawa, Calgary, Edmonton, Victoria, and Winnipeg as well. In the United States, we provide our consulting and training services across various cities like Austin, Dallas, Houston, New York, New Jersey, Irvine, Los Angeles, Denver, Boulder, Charlotte, Atlanta, Orlando, Miami, San Antonio, San Diego, San Francisco, San Jose, Stamford and others. Contact us today to learn more about what our experts can do for you.