PWA: what it is and how to take care of performance on a daily basis

A Progressive Web App promises the best of both worlds: the reachability of the web with the feel of an installed app. It opens quickly, works offline, can send notifications, installs on the home screen without going to a store. In theory, it's elegant.

A lot of people turn on a PWA, see that it "works" and assume they've gotten free performance. A few months later, the app is slow, the cache is more of a hindrance than a help, and the app experience has become a heavy web page with an icon on the screen.

PWA is not a performance switch. It is an architecture that, if well cared for, delivers speed, and that, neglected, delivers frustration. I want to explain what a PWA is and, mainly, how to maintain a healthy performance in your routine, because it is on a daily basis that you win or lose.

What is a PWA, no mystery

A PWA is, in essence, a website that uses a set of modern web technologies to behave like an application. The three pillars are the service worker, which runs in the background and controls caching and offline operation; the manifest, which allows you to install the app on the home screen with its own icon and name; and the use of HTTPS, a security requirement for all of this to work.

The service worker is the heart of the story. It sits between the app and the network, intercepting requests and deciding what to serve from the cache and what to fetch online. This is what makes the PWA open instantly and work without a connection.

This power is also the source of problems. A poorly configured service worker serves old content, doesn't update when it should, or fills the device with useless cache. The same part that gives you speed can give you slowness.

The thesis: PWA performance is maintenance, not installation

The idea I most want to combat is that performance comes from the decision to "use PWA". I argue that it comes from continuous development habits, and that a PWA requires more discipline, not less, than a typical website.

The reason is simple: PWA adds a layer, the service worker and its caching strategies, that needs to be thought out, tested and maintained. Each new version of the app is an opportunity to break the cache, serve outdated content or inflate what is stored on the device.

Therefore, performance of PWA is routine care. It's something that goes into the flow of each delivery, not a setup you do once and forget about. Those who treat it as forgettable accumulate problems that only appear when the user is already irritated.

Caching strategy: the central care

The most important decision in a PWA routine is how each type of resource is cached. There is no single strategy that is good for everything.

Files that change rarely, application code, icons, fonts, can be aggressively cached, served first from the cache to open quickly. Data that changes all the time, the content that the user consumes, requires strategies that prioritize the network or that validate whether the cache is still fresh.

The most common mistake is applying an aggressive strategy to everything. The app opens quickly, but shows old information, and the user sees outdated prices, status or content. In applications with sensitive data, this goes from a nuisance to a serious problem.

On a daily basis, each new feature added to the app should raise the question: how should this be cached? Treating this question as part of development, not a detail, is what holds performance and correctness together.

Painless versioning and updating

A classic PWA problem is the user getting stuck on an old version because the service worker keeps serving the old cache. You publish a correction and the user doesn't see it, because their app insists on showing what they had saved.

Resolving this requires a cache versioning and service worker update strategy. When a new version is published, the app needs to notice, download the new content and activate it in a controlled way, ideally notifying the user or updating it the next time it is opened.

This flow needs to be tested with each delivery. I've seen teams publish urgent fixes that simply didn't reach users because of poorly managed cache. The fix existed on the server and was useless on the device. Performance here includes the ability to patch quickly, and this depends on whether the update cycle works.

Measuring is part of the routine

You can't take care of what you don't measure. The performance of a PWA needs to be monitored with real data, not just with the impression that "it's fast on my machine".

Web performance audit tools help measure loading time, resource size and quality of offline operation. Perceived load metrics, how quickly the user sees something useful on the screen, say more about the experience than isolated technical numbers.

The ideal is to incorporate this measurement into the delivery flow, so that performance regressions are caught before they reach the user. An app that was fast and slowed down rarely got worse all at once; It got worse little by little, in deliveries that no one measured. Continuous measurement is what turns performance from luck into control.

The limits and pitfalls of PWA

As much as I defend PWA, it is important to recognize its limits so as not to sell illusion. In some systems, access to device resources is even more restricted than in a native app. Notifications and installation behavior vary between platforms. And there are hardware features that a PWA simply doesn't reach in the same depth.

Furthermore, the flexibility of the web itself can lead to bloated apps. Without discipline, it's easy to accumulate libraries, scripts, and styles that weigh down the load. PWA does not fix bad code; it just adds a layer on top. Bad performance at the base continues to be bad with the PWA turned on.

The biggest trap is complacency. Because the PWA "looks" like an app and opens quickly after the first load, it's easy to stop measuring and caring. Degradation arrives silently, and when someone notices, recovering performance costs more than it would have cost to maintain it.

PWA is an excellent technology for anyone who wants application-quality web reach, as long as they understand that this quality is the result of continuous care. The speed of the first day only remains if there is discipline every day.

If your team maintains a PWA and wants to structure a performance care routine, there are other texts here on the blog about web, performance and development. And if you want to talk about your product, I'm at your disposal.