Progressive web apps: when a PWA beats a native app

The term comes from Google and has been gathering momentum since 2015, but 2017 is the year it became practical for ordinary businesses. Three pieces of web technology make it work:

• A service worker, a script the browser runs in the background. It intercepts network requests, serves cached pages and images when the network is slow or absent, and receives push messages.
• A web app manifest, a small JSON file that gives the site a name, icon, theme color and start URL so it can be installed on the home screen and launched full-screen.
• HTTPS, which is required for service workers to run at all.

On top of that sits everything you would expect from a good responsive site: fast first paint, an app-shell layout that renders instantly and fills in content, and touch-friendly interface design. Chrome on Android supports all of it and will show an "Add to Home Screen" banner when a site meets its criteria. Firefox and Opera support most of it. Microsoft announced this year that Edge will support service workers and that PWAs will be listed in the Windows Store. Safari remains the gap, which we cover below.

The public case studies are now hard to dismiss. Flipkart, India's largest e-commerce company, reported tripling time on site after launching Flipkart Lite. Twitter shipped Twitter Lite in April and has talked about a 65 percent increase in pages per session and a 20 percent drop in bounce rate. Lancôme reported mobile conversions up 17 percent after its PWA launch. AliExpress and The Washington Post have published similar figures, and the techniques scale down.

The honest starting question is why you want an app at all. Most answers fall into one of three buckets.

Use these rules of thumb:

1. If more than half of your mobile traffic is on Android, a PWA covers the majority of users with the full feature set. Check Google Analytics under Audience > Mobile > Devices before deciding anything.
2. If your business depends on the App Store as a discovery channel, build native. Retail and media brands rarely do; games and utilities often do.
3. If you are a content, commerce, booking or service business, your "app" is almost certainly a PWA. The things users want, speed and a tap-to-open icon, are exactly what it delivers.
4. If the budget for the app is under $100,000 and you do not have an in-house mobile team, a PWA is the only option where maintenance stays manageable. Native apps need updates for every OS release and every store policy change.
5. Hybrid wrappers such as Cordova or Ionic are a middle path if you must be in the stores, but do not confuse them with a PWA. A PWA has no wrapper and no store.

Google's own data this year puts the average mobile page load at over 15 seconds on 3G, and says 53 percent of visits are abandoned if a page takes longer than three seconds. A PWA earns its name only if it clears that bar. Targets worth writing into the brief:

• First meaningful paint under 2 seconds on a simulated 3G connection on a mid-range Android phone, not on your office Wi-Fi.
• Time to interactive under 5 seconds on the same test.
• Total JavaScript under about 200 KB compressed for the initial route. Framework choice matters here: a full React or Angular bundle can blow this budget before you write a line of your own code.
• Lighthouse PWA score above 90. Lighthouse is Google's free audit tool, available as a Chrome extension and now built into Chrome DevTools. Run it before and after every significant change.

Get there with an app-shell architecture, image compression, lazy loading below the fold, HTTP/2 and a CDN. None of this is exotic, but it has to be designed in from the start.

Businesses tend to start with the flashy parts. Start with reliability instead.

Offline first. Decide what should work without a connection. For a retailer, that is browsing recently viewed products and the cart. For a publisher, it is the last few articles read. For a field-service business, it is forms that queue and submit later. Show a clear "you are offline" state rather than a browser error page. A custom offline page alone is a visible improvement over almost every competitor's site.

Install second. Chrome's Add to Home Screen banner appears when the site has a manifest, a registered service worker, HTTPS and a user who has visited at least twice with five minutes between visits. Write the manifest carefully: a short name of 12 characters or fewer, icons at 192 and 512 pixels, a start URL with a tracking parameter so you can see launches from the home screen in analytics.

Push last, and sparingly. Web push through a service worker reaches Android users in Chrome and Firefox even when the browser is closed. It is powerful and easy to abuse. Ask for permission in context, after the user has done something that makes a notification plausible, never on first load. Industry opt-in rates for prompts shown on arrival are in the single digits; prompts shown after an action commonly convert several times better.

Apple does not support service workers or the manifest in Safari today, and iOS is between 40 and 60 percent of mobile traffic for most US businesses. Be clear-eyed about what that means.

iPhone users of your PWA get a fast, well-built responsive site. They do not get offline caching, push notifications or the install banner. They can still add the site to their home screen manually through the share sheet, and the Apple-specific meta tags for icon and title still work, so use them. Do not launch a campaign promising "our new app" to iOS users unless you are comfortable with the gap.

WebKit's feature status page moved service workers to "in development" this summer. Plan for the gap to close, but do not build the business case on it.

• Caching too aggressively. A service worker that caches HTML indefinitely means customers see last month's prices. Version your caches and keep dynamic data network-first.
• JavaScript-only rendering. Google can execute some JavaScript, but slowly and imperfectly. Server-side rendering for landing and product pages is not optional for SEO.
• Ignoring the long tail of browsers. A PWA should degrade gracefully. Users on older browsers get the normal site. If they get a blank screen, the build is wrong.
• Treating it as a project rather than a property. A PWA is your website. It needs the same ongoing performance monitoring and content work.

We begin with discovery: analytics on device and connection mix, a Lighthouse and speed baseline, and interviews about what customers actually need to do on mobile. From that we plan which PWA features matter for your audience, set the performance budget and decide the rendering approach. Build covers the responsive front end, the service worker, manifest, hosting and CDN, and the tracking. Then we improve: monthly performance checks, offline and install metrics, and iteration on the flows that drive revenue. The work joins brand, growth, web and technology, because a PWA is a design job, an engineering job and an acquisition channel at the same time.

A representative engagement is the e-commerce work we did for a retailer whose mobile traffic had overtaken desktop while mobile conversion lagged well behind. Rather than fund two native apps, we rebuilt the mobile experience as a PWA on the existing platform: an app shell for category and product pages, offline cart and recently viewed items, and a home-screen install prompt shown after the second visit. Load time on a 3G test fell from double digits to under three seconds, Android users began returning through the home-screen icon, and mobile conversion rose into the range the desktop site had been achieving, at a fraction of the cost of the native option.