Nmedia - Fotolia


Using progressive web applications to improve the user experience

Learn some of the tips that a cutting-edge web app developer learned from building progressive web apps. Expert George Lawton discusses how to implement this new style of app.

Cloud applications have traditionally been accessed by web browsers or dedicated mobile client applications. The advent of new browser features including service workers, improved caching and new installation options are allowing developers to create progressive web applications that blend the best features of browser-based and dedicated mobile applications. At the O'Reilly Fluent Conference in San Jose, Calif., Dean Hume, CTO of Settled, shared tips for implementing this new style of application.

Settled provides a real estate listing service in the U.K. The company wanted to build a new dashboard for customers using progressive web applications that allowed users to quickly and easily access their information, regardless of their network connection. After implementing progressive web applications, Settled users spent twice as long on the site, consumed one-fifteenth as much data and experienced a three-fold improvement in page load times.

One of the key benefits of traditional mobile applications is that users can run them by clicking on an icon. Progressive web applications take advantage of a manifest file included in the page to provide the same functionality. The manifest file includes a 144 x 144 pixel icon, which can be installed on a user's home screen. The page itself must be using service workers running over HTTPS connections. In addition, the user must visit the site at least twice to have an option to install a link to the application.

Service workers are the backbone of progressive web applications

Service workers process application logic in the background, which allows developers to separate out the client presentation, application logic and back-end communications with the cloud. "Service workers are the key to unlocking the power of the browser," said Hume. "Behind the scenes, they tap requests from the browser and make requests to the server." They can inspect headers, manipulate them before being sent to the server or just respond to front-end requests directly.

We wanted to keep things as lean and mean as possible.
Dean HumeCTO, Settled

Service workers are currently built or planned for all modern browsers. However, they are not yet implemented into Safari. Fortunately, it's easy to fall back to basic webpages on older browsers, Hume said. In the company's experience, over 75% of its user base came from browsers that support service workers. For building progressive web applications, Hume recommends leveraging SW Toolbox that includes a wide variety of code snippets for implementing service workers.

This power to directly manipulate requests could potentially introduce new security vulnerabilities. Hackers could theoretically use them to launch man-in-the-middle attacks that make unintended requests on bank accounts. Consequently, service workers need to use SSL to encrypt and secure data between the client and back-end server. Hume said it is getting much easier for developers to implement SSL using free tools like Cloudflare's CFSSL and Let's Encrypt.

New testing approach required for service workers

New testing approaches need to be taken when building progressive web applications. Traditional testing tools like Google page test focus on how long it takes to download resources from the back end. However, progressive web applications can often pull resources out of the cache. Hume said tools like Google Lighthouse can measure the performance of applications that are more dependent on service worker interactions for performance.

It's not an exact science. When Settled first implemented its page, the load time was 4.65 seconds. This was reduced by various optimizations to 2.25 seconds. Once service workers became active, it got the page load time down to 500 milliseconds. A big part of this was page weight. The first page was about 850 KB in size. The second was 50 KB. Once the service workers are active on the browser, the client only needs to send about 1 KB to launch the page.

Settled also took a bold move by building its application in vanilla JavaScript, rather than using a framework like Angular or React. Hume said this kept things simple and allowed the company to reduce the size of the page served to the client. "In our case, we wanted to keep things as lean and mean as possible. We use JavaScript sparingly for things like interaction on the page. This means that with progressive web apps don't need a single page app or framework."

Settled is also experimenting with prefetching techniques. This is used when there is a high likelihood the client will walk through pages in a particular order. Developers tend to want to prefetch everything. But Hume said it is important to look at the data of how people traverse a site to make the most of prefetch; otherwise, it is easy to waste bandwidth sending data the client never users.

Plan for third-party failure

One big performance challenge lies in addressing problems caused by third-party cloud applications. Many modern web applications take advantage of third-party scripts that interact with Facebook, Google analytics and ad tracking services. Hume said, "These are things that are not in your control. If they fail, then you have an amazing app that is at the mercy of a third-party script."

Many web applications fail to load until these third-party services deliver a response. Hume said a much better approach is to implement a JavaScript time-out function using service workers. If the third-party service fails to respond by the deadline, then the service worker delivers an alternate response that keeps the webpage rendering. Hume said, "We are still learning, but so far, it has been a great success."

Next Steps

Forbes talks progressive web applications

Improving data quality with digital transformation

How does IT manage mobile web apps?

Dig Deeper on Topics Archive