Blogs

What is a progressive web app, and what it means for retail

A progressive web app is a website that behaves like an app. It can sit on the home screen, loads almost instantly on a repeat visit and keeps working when the signal drops. For a retailer it is a set of capabilities to switch on deliberately, one by one.

Shopper browsing a progressive web app store on a train with low signal

Key takeaways

1

A PWA is a website with a service worker, a manifest and HTTPS added to it.

2

Its value for commerce is speed on repeat visits and a store that survives weak signal.

3

Caching rules decide whether shoppers see current prices and stock.

Heading 1

Heading 2

Heading 3

Heading 4

Heading 5
Heading 6

Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur.

Block quote

Ordered list

  1. Item 1
  2. Item 2
  3. Item 3

Unordered list

  • Item A
  • Item B
  • Item C

Text link

Bold text

Emphasis

Superscript

Subscript

The decision on the table is which of those capabilities your storefront needs and who owns them. "We want a PWA" is a common brief. It hides choices about what to cache, when to ask a shopper to install, and how fresh prices and stock must be. Those choices decide whether the result feels quick and trustworthy or quick and wrong.

Three building blocks turn a website into a PWA

A progressive web app (PWA) rests on three technical parts. A service worker is a small script that sits between the browser and the network and decides what to load from a local cache. A web app manifest is a file that tells the phone the name, icon and colours to use when the site is installed. HTTPS is required for both.

None of this needs an app store. The shopper opens a link, the browser picks up the manifest and can offer to add the store to the home screen. From there it opens full screen, without the browser bar. Whether that experience is enough, or whether a native app still earns its place, is the subject of choosing between PWA and native.

What a progressive web app changes for shoppers

The first gain is speed on the second visit. The service worker keeps the storefront's layout, scripts and images on the device, so category and product pages appear before the network has answered. On mobile, where a large share of retail traffic arrives, that difference is felt on every tap. Mobile speed is also one of the main arguments for headless commerce with the Composable Storefront.

The second gain is resilience. A shopper on a train or in a store basement can keep browsing pages already cached, and the basket survives a dropped connection. Push notifications and home screen installation come on top, but they depend on the shopper opting in. On iPhone, web push works only after the site has been added to the home screen.

How Salesforce storefronts deliver PWA capabilities

On Salesforce B2C Commerce, the Salesforce PWA Kit (Composable Storefront) is the toolkit for building a headless storefront as a PWA. It is a React-based front end that talks to the commerce engine through APIs and runs on Managed Runtime, the Salesforce hosting layer. What that toolkit contains, and how it fits alongside Managed Runtime, is covered in the Composable Storefront and Managed Runtime.

We built Fast FORWARD, our own pre-built headless storefront, on the Composable Storefront. It ships with the PWA groundwork in place, which lets a brand go live in weeks instead of months and spend its budget on the parts shoppers notice.

A cached page that shows yesterday's price does more damage than a slow one.

Head of Commerce

|

FORWARD

Caching decides whether a PWA helps or hurts

The service worker is only as good as its caching rules. Layout, fonts and product images change rarely and can be cached for a long time. Prices, stock levels, promotions and the basket change constantly and must come from the server on every view. A cached page that shows yesterday's price does more damage than a slow one.

That split is a business decision as much as a technical one. Merchandising, pricing and IT need to agree which content may be stale for how long. The storefront team then turns that agreement into rules, and someone keeps them current as promotions and ranges change.

Most PWAs are also single page applications

Most commerce PWAs are built as single page applications, which load one page and then update it in the browser. That makes transitions fast. It also means search engines need the full page from the server on the first request, or they index a near-empty shell. Server-side rendering solves this, and the detail is in SEO for single page applications.

A PWA does not have to be a single page application. A traditional multi-page site can add a service worker and a manifest as well. For a retailer with an ageing storefront, that can be a sensible first step before a full headless rebuild.

When a progressive web app is the right next step

A PWA pays off when mobile traffic is high, repeat visits matter and the current site feels slow on a phone. It pays off less when most revenue comes from desktop buyers in B2B, where installation and offline browsing rarely come up. In that case, a faster server response and a cleaner checkout deliver more for the same effort.

The honest measure is what shoppers do after the change: time to first product view on mobile, the share of sessions that reach the basket, and conversion on repeat visits. Set those before the build starts. Then the PWA has a target to hit instead of a feature list to tick.

Explore Fast FORWARD

Our insights

Button Text
No items found.
No items found.
No items found.