Making a landing page installable (PWA): which pages actually benefit from it

A typical ad landing page gets one visit, converts or doesn't, and fades from the visitor's memory within the hour. Installing it as an app makes no sense there: nobody has a reason to reopen the icon of a page they already filled in or left. But a subset of landing pages works differently — the visitor comes back on purpose, more than once, before deciding or before some event happens. It's on that specific subset that making a page installable as a PWA (Progressive Web App) has a measurable effect, and it's a binary choice made page by page, not across the whole site.

Which landing pages installation actually makes sense on

The criterion isn't technical sophistication, it's the expected return frequency. Three journey profiles clear that bar:

• A SaaS waitlist — the user signs up, then comes back to check their position or wait for launch; a home-screen icon beats an email buried three weeks later in a crowded inbox.
• A webinar signup — between confirmation and the event, the countdown page can be reopened voluntarily several times; paired with a notification, it cuts the no-show rate.
• A long-cycle decision — a property valuation or a mortgage broker quote the visitor compares before deciding, sometimes over several days.

By contrast, an ebook sales page, an ephemeral ad landing page, or any page built for a single session has nothing to gain from offering installation: the friction of the prompt (however small) weighs on 100% of visitors for a benefit that almost none of them will ever use.

What installation actually changes, and what it doesn't

Installing a landing page as a PWA doesn't turn it into a full offline application: in the vast majority of cases, it simply adds a home-screen icon that opens the page full-screen, with no address bar, via display: "standalone". It's a more visible, more engaging shortcut than a bookmark or a pinned tab, nothing more — and that's exactly why selectivity matters. Böhmer and Krüger, in a study published in 2013 in the proceedings of the CHI conference (available on Google Scholar), analyzed over 1,400 smartphone home-screen screenshots and showed that users organize their icons mainly by how often they actually use each app. An installed icon that never gets used ends up buried in a folder or uninstalled — so the install prompt isn't free advertising space, it's a spot the page has to earn with a concrete reason to come back.

The technical criteria for installability

For Chrome to offer installation (the beforeinstallprompt event), the page must be served over HTTPS, expose a valid manifest with at minimum name, short_name, start_url, a display set to standalone or fullscreen, and 192×192 and 512×512 icons, and register a service worker that listens for at least the fetch event. Chrome also applies an engagement heuristic: the visitor must have interacted with the page once (a click or tap) and spent a minimum amount of time on it, on the order of thirty seconds, before the prompt becomes available — which rules out pages viewed for only a few seconds.

On iOS, Safari never triggers an automatic prompt: the user has to open the share menu and choose "Add to Home Screen" themselves. On pages where installation brings real value (a waitlist, a webinar countdown), it's worth adding a discreet visual instruction for iOS visitors rather than relying on a prompt that will never exist for them.

Implementing it in Next.js (App Router)

Next.js exposes a native file convention for the manifest, so there's no static JSON file to maintain by hand:

// app/manifest.ts
import type { MetadataRoute } from "next";

export default function manifest(): MetadataRoute.Manifest {
  return {
    name: "Facturo — Waitlist",
    short_name: "Facturo",
    start_url: "/",
    display: "standalone",
    background_color: "#0b0b0f",
    theme_color: "#0b0b0f",
    icons: [
      { src: "/icon-192.png", sizes: "192x192", type: "image/png" },
      { src: "/icon-512.png", sizes: "512x512", type: "image/png", purpose: "maskable" },
    ],
  };
}

The minimal service worker doesn't need to manage a cache: a plain fetch listener is enough to satisfy the installability criterion. // public/sw.js
self.addEventListener("fetch", () => {}); It gets registered from a client component, after the first render: useEffect(() => {
  if ("serviceWorker" in navigator) navigator.serviceWorker.register("/sw.js");
}, []);

Never cache an offer that changes

This is the costliest trap, and it directly concerns any site running dated promotions. A service worker that answers from cache without revalidating can keep serving an expired discounted price, a stale promo code, or a frozen countdown — exactly what this site deliberately avoids by computing the current offer client-side on mount instead of baking it into the build (see our approach to static rendering versus a price that changes). The minimal service worker described above doesn't cause this problem since it intercepts nothing; if you later add a caching strategy for static assets (fonts, images), keep the page's HTML on network-first or out of the cache entirely, never cache-first.

Timing the install prompt

Chrome's native prompt can be intercepted with e.preventDefault() on the beforeinstallprompt event, stored, then triggered later through a button that matches the page's own design — for example on the confirmation screen right after waitlist signup, rather than on arrival. Timing matters: offering installation after real engagement (the visitor has just signed up) rather than on load meaningfully improves acceptance, for the same reason a poorly timed notification permission request tends to get refused outright. On a webinar page, pairing installation with a reminder notification has a documented retention effect: Bell, Garnett and coauthors, in a randomized controlled trial published in 2023 in JMIR mHealth and uHealth (available on Google Scholar), found that a notification made users 3.5 times more likely to reopen the app within the following hour compared to receiving no notification — an effect measured outside a marketing context, but whose mechanism (a visible reminder triggers a return visit) transfers directly to a webinar reminder.

Mistakes to avoid

• Showing the prompt right on arrival — beyond Chrome's engagement heuristic technically blocking this, repeated dismissals push the browser to space out future prompts on that domain; one well-placed prompt beats a systematic one that gets ignored.
• A service worker that caches the page itself — beyond price or offer content, this can also freeze a bug fix or a content update shipped afterward, making changes invisible to visitors who already installed the page.
• Forgetting the maskable icon — without an icon declared purpose: "maskable", Android can crop a logo never designed to be masked into a circle or rounded square, with a rough result on the home screen.
• Making a single-session page installable on principle — on an ad landing page or a one-off sales page, the setup effort and the prompt's friction return nothing: reserve the PWA treatment for pages where a real return visit is likely.

LanderKit's SaaS Waitlist template and Webinar & Masterclass template ship as Next.js App Router source code: adding an app/manifest.ts and a minimal service worker happens directly in the project, with no third-party plugin to depend on and no need to rebuild the whole site around it. See the full template catalog. For the confirmation screen right after signup — the most relevant place to trigger the install prompt — see also our guide to the thank-you page.