Performance
Progressive web app
Also called PWA.
Progressive web app is a website that meets installability requirements, usually HTTPS, a web app manifest, and a service worker, so it can be added to a home screen and keep working from a cache. It is still a website.
How it is measured
Check installability in Chrome DevTools, Application panel, Manifest: it lists problems such as a missing icon size. Lighthouse retired its PWA category in version 12, so DevTools is now the place to look. Track installs and the install prompt's acceptance rate on the product side.
For performance, compare first load with repeat load. The Network panel shows '(ServiceWorker)' as the source for cached responses. Repeat-visit LCP should beat first-visit LCP, and DevTools offline mode should render a fallback page.
Worked example
A bus timetable site for a regional operator has a manifest, a service worker caching the shell and the last-viewed timetable, and a 48 KB app shell. First load on 3G takes 4.2 s. A second load from the worker cache shows the timetable in 0.6 s, and in a tunnel with no signal it still shows the last schedule.
Of 40,000 monthly visitors, 1,300 install it, an install rate of 3.25%.
How it differs
A PWA is a packaging of a site: manifest, installability, and offline behavior. A service worker is one ingredient, the script that intercepts requests. A site can have a service worker and never be installable, and a PWA's speed still depends on the same Core Web Vitals as any other page.
Common errors
Calling any responsive site a PWA. Caching everything, so users see stale prices for weeks. Shipping a service worker with no update path. Assuming iOS installs behave like Android. Expecting an install banner to fix a slow first load.
In practice
Ask whether your visitors return often and have unreliable connections. If yes, add a manifest and a small service worker that caches the shell and an offline page, and test the update path. If not, skip it; a fast, well-cached normal site gets most of the benefit.