Part I – Introduction to Progressive Web Apps using React.js

Progressive Web Apps leverage new technologies to provide consumers with the best of mobile sites and native apps. They're dependable, quick, and entertaining. They come from a safe source and load irrespective of network conditions.

 

There's a lot going on in the realm of Progressive Web Apps (PWAs), and you might be wondering how they work with existing designs that use frameworks like React and JS module bundlers like Webpack. Is it necessary to completely rebuild a PWA? What web performance metrics should you monitor? In this series of essays, I'll describe my experience converting Reactjs web development projects into Progressive Web Apps (PWAs). We'll also discuss why delivering only what customers need for a route and removing all additional scripts are smart ideas for high performance.

 

Lighthouse

Let us start with a PWA checklist. We'll be utilising Lighthouse for this, which is a tool for inspecting your app for PWA features and ensuring that your app meets a reasonable benchmark for web performance under mimicked mobile settings. Lighthouse is available as a Chrome extension (which I prefer) and a CLI, both of which display a report that looks something like this:

Audits at the highest levels Lighthouse effectively executes a combination of contemporary online best practises that have been tuned for a mobile world:

• The network connection is safe.
• The user may be asked to Add to Homescreen.
• The installed web app will start with a personalised splash screen.
• The app can load when there is no internet connection or when the connection is unstable.
• The page load time is quick, and the design is mobile-friendly.
• The site is gradually being improved.
• The address bar matches the brand colours.

Lighthouse has a getting started tutorial, and it also supports remote debugging. Very nice.

Whatever libraries you have in your stack, I want to underline that everything on the above list is doable today with a little effort. However, there are certain restrictions.

 

We all know how sluggish the mobile web is.

The web has progressed from a platform focused on documents to a first-rate application platform. Simultaneously, the majority of our computing has shifted away from powerful desktop workstations with fast, consistent network connections and toward comparatively weak mobile devices with connections that are frequently sluggish, flaky, or both. This is especially true in areas of the world where the next billion people are gaining access to the internet. To enable quicker mobile web:

We must all transition to testing on real mobile devices with genuine network connections (e.g Regular 3G in DevTools). Chrome:/inspect and WebPageTest (video) can help you. Touch events, viewport emulation, and a throttled network connection are all included in Lighthouse's simulation of a Nexus 5X. (150ms latency, 1.6Mbps throughput).

If the JS libraries you're utilising weren't designed with mobile in mind, you could be fighting a losing battle when it comes to being interactive. We'd like to be interactive in under 5 seconds on a typical device, therefore we'll need more of that amount for app code.

However, many libraries are attempting to improve in this area and may need to if they are to remain viable for performance on physical devices. Just have a peek at Preact's A+ performance with real-world devices.

 

Examples of open-source React Progressive Web Apps

If you're looking for non-trivial examples of PWAs developed using React and optimised with Lighthouse, check out: ReactHN, a HackerNews client with server-side rendering and offline support, or iFixit, a React-based hardware repair guide that leverages Redux for state management.

Let's go over what we need to do to complete each item on the Lighthouse report, with React.js-specific recommendations sprinkled throughout the series.

 

The network connection is safe.

HTTPS tooling and advice

HTTPS protects against criminal actors meddling with communications between your app and the browser your users are using, and you may have heard that Google is working to shame unencrypted sites. Powerful new web platform APIs, such as Service Worker, require secure origins via HTTPS, but the good news is that with services like LetsEncrypt providing free SSL certificates and low-cost options like Cloudflare enabling end-to-end traffic encryption for all, getting this setup has never been easier.

I normally deploy my personal projects to Google App Engine, which enables providing SSL traffic through an appspot.com domain if you provide the'secure' option to your app.yaml file. I use Node on App Engine for my React projects that require Node.js support for Universal Rendering. HTTPS is now supported by Github Pages.

You may check issues with security certificates and mixed content errors using the Chrome DevTools Security panel.

Here are some more security suggestions for your website:

Upgrade insecure requests ("HTTP" connections) to "HTTPS" when needed, redirecting users. Consider Content Security Policy and upgrade-insecure-requests.

Change any references to "http://" to "https://." If you use third-party scripts or material, talk to them about making their resources HTTPS as well.

When serving websites, use HTTP Strict Transport Security (HSTS) headers. It's a directive that compels browsers to only communicate with your site via HTTPS.

For additional information, I recommend viewing Deploying HTTPS: The Green Lock and Beyond and Mythbusting HTTPS: Busting Security Urban Legends.

 

The user may be asked to Add to Homescreen.

The next step is to personalise your app's "add to homescreen" experience (favicons, application name displayed, orientation and more). This is accomplished by including a Web Application Manifest. Customizing cross-browser (and OS) favicons is generally the most time-consuming part of this process, although sites like realfavicongenerator.net take a lot of the sting out of it.

There has been significant debate about the "minimum" number of favicons required for a site to simply operate in most locales. Lighthouse has suggested shipping a 192px icon for your homescreen and a 512px icon for your splashscreen. Personally, I like the output of realfavicongenerator because, despite involving more metatags, I prefer the certainty that all of my bases are covered.

Some websites may wish to ship a platform-specific favicon. For more information on this issue, I recommend reading Designing a Progressive Web App symbol.

You also have access to app installer banners with a Web App manifest setup, offering you a means to directly urge visitors to install your PWA if they find themselves engaging with it frequently. It's also feasible to delay the prompt until a user interacts with your programme in a helpful way. Flipkart discovered that the ideal place to display the alert was on their order confirmation page.

The Chrome DevTools Application Panel allows you to check your Web App Manifest by going to Application > Manifest:

 

The layout is mobile-friendly.

Apps designed for many devices should include a meta-viewport in the document's head>. This may sound apparent, but I've seen many Reactnative apps where this has been overlooked. Fortunately, create-react-app includes a proper meta-viewport by default, and Lighthouse will warn you if it is missing:

 

<meta name="viewport" content="width=device-width, initial-scale=1">

 

Although we place a strong emphasis on improving the mobile web experience in Progressive Web Apps development, this does not mean that desktop should be overlooked. As illustrated by Housing.com, a well-crafted PWA may function across a variety of viewport widths, browsers, and devices.

 

We'll look at page-load speed using React and Webpack in Part 2 of this series. We'll look at code splitting, route-based chunking, and the PRPL pattern to get to interactivity faster.