Core Web Vitals: what each metric measures and how to fix it
LCP, INP and CLS measure different failures with different causes. Knowing which metric is failing tells you almost exactly where to look.
ZooBieDoo Infotech Engineering TeamRead
Key takeaways
- PWAs remove store friction and give one codebase to maintain.
- Deep device capability and store presence are the trade-offs.
- Service worker caching strategy is where the difficult bugs live.
- Decide on how users discover you and what capability you truly need.
What a PWA gives you
A progressive web application is a website that can be installed to the home screen, work offline through a service worker, and receive push notifications on most platforms. There is no store review, no download step and one codebase to maintain.
For products where discovery happens through search or a link rather than through an app store, that removes real friction. A user can be using the product within seconds of arriving.
What it costs you
Platform capability is the trade. Deep hardware integration, background processing, certain sensors and some payment and identity integrations remain easier or only possible natively. Notification support and installation prompts differ by platform and change over time.
There is also a perception issue in some markets: for certain audiences, absence from an app store reads as absence of a product. That is not a technical argument but it is a real commercial one.
The service worker is the hard part
Everything interesting about a PWA runs through the service worker, and it is the part most likely to cause difficult bugs. Caching strategy has to be deliberate: which requests are served from cache, which from network, and how updates reach users who have an old version cached.
- Version your caches and clean up old ones on activation.
- Never cache API responses that carry per-user data without scoping them.
- Provide a clear update path so users are not stuck on a stale build.
- Test the offline experience explicitly rather than assuming it works.
Deciding
The honest test is whether your users would ever look for you in an app store, and whether the product needs capabilities the web cannot reach. If discovery is web-led and the capability requirements are ordinary, a PWA is usually the better commercial choice.
If the product is used daily, needs deep device integration, or competes in a category where store presence is expected, native or cross-platform is the safer answer.
Installation and the update problem
Two operational details decide whether a progressive web app feels like a product or a bookmark. The first is the install prompt: platforms differ in when and whether they offer one, so the app should explain its own installability rather than relying on the browser.
The second is updates. A service worker will serve cached assets indefinitely unless you handle versioning deliberately. Users stuck on a months-old build, unable to explain why a fix has not reached them, is the most common support burden.
Implement an explicit update flow: detect a new version, tell the user, and reload on their action. It takes little effort and removes an entire class of confusing support conversations.
Frequently asked questions
Yes, with limitations that have narrowed over time. Installation and offline support work; some notification and background capabilities behave differently from Android. Test on the platforms your audience actually uses.
It can be wrapped and submitted, and several tools make this straightforward. Whether it is worth doing depends on whether store discovery matters for your product.
Usually, because there is one codebase and no store release cycle. The saving is smaller than it first appears once you account for the testing matrix across browsers and platforms.
