What It Takes for a Web App to Feel Premium

Performance work rarely arrives as a single insight. It tends to show up as a collection of irritations. Small delays you notice at first and then cannot unsee. A pause that feels longer than it should. A screen that forgets where you were. An interaction that technically works, but never quite feels settled.

That has been the shape of our work for a while now. Not a grand plan, more a sequence of corrections. Each one made for a specific reason, each one exposing the next thing that felt off.

Arrival

The earliest problem was obvious enough. The app took too long to arrive. Blank screens. Late content. Interfaces assembling themselves in front of the player.

Server-side rendering was the right fix. It moved work earlier, closer to the source, and allowed the browser to present something meaningful immediately. The app arrived already formed, rather than apologising while it booted.

Hydration came with it. There is no avoiding that cost. You pay it once per session and move on. That trade is now well understood, and for most serious apps it is a reasonable one. SSR fixed arrival. It did nothing for what came next.

Responsiveness

Once the app was interactive, a different kind of delay stood out. Interactions were mostly fast, until they weren’t. A tap would occasionally hesitate. A scroll would stutter for reasons that were hard to pin down.

The cause was rarely core product code. It was everything orbiting it. Analytics. Tracking. Affiliate logic. Marketing tags. All legitimate, all useful, none of them directly involved in helping a player take their next action.

Introducing Partytown was less about metrics and more about priorities. Third-party scripts still ran. Data was still collected. But that work stopped competing with interaction. The computation that mattered most stayed where it belonged. The main thread became calmer. The app stopped feeling distracted.

Native Browser First

That calm exposed something else. There was simply too much JavaScript involved in basic interaction.

Over time we had accumulated code whose job was to recreate behaviour the browser already understands. Scrolling with momentum. Snapping. Touch and pointer gestures. Animated transitions between states. All of it implemented in JavaScript, all of it running on the main thread.

Every scroll became a calculation. Every swipe became a listener. Every animation became a scheduling problem. We were simulating a browser inside a browser, and then wondering why input sometimes felt late.

The same was true of animation. Anything that required JavaScript to advance frames, coordinate timing, or update layout under load competed directly with interaction. Even when it looked smooth in isolation, it took priority at exactly the wrong moment.

Removing this code reduced JavaScript execution, not just bundle size. More work moved into native browser paths. Scrolling became composited. Gestures became direct. Animation stopped blocking interaction. This wasn’t minimalism. It was recognising when to stop arguing with the browser.

Run on the Fastest Browser

Once that principle was clear, it applied beyond the code we wrote and into how we shipped it, particularly on Android.

Wrapping the web in a WebView worked, but it came with a ceiling. Even well tuned, it is typically slower than a fully optimised Chrome instance. Not marginally. Often by twenty or thirty percent. That gap shows up in rendering, input handling, and overall smoothness.

Moving to a Trusted Web Activity followed the same logic as everything else. Use the best browser available. Stop embedding a constrained one. Nothing about the app changed conceptually. The same code ran. The same features existed. But rendering was faster, input smoother, and the browser handled more of the heavy lifting.

Anticipation

With interaction steadier and JavaScript reduced, navigation became the next source of friction. Clicking into an event or a game triggered network calls that could never feel instant, no matter how well tuned they were.

The problem wasn’t speed. It was timing.

Speculative links came from that realisation. If a link is visible, the player is already considering it. That is enough information to begin loading data, warming resolvers, and doing work before the click happens.

Loading didn’t disappear. It moved out of the critical path and into idle time. Navigation stopped feeling like a pause.

Continuity

Even with data ready, navigation could still feel abrupt. Screens appeared and disappeared without continuity.

View transitions helped here, not because animation makes things faster, but because continuity makes things legible. Elements that move rather than vanish preserve context.

Around the same time, gesture-based navigation arrived. Swipe to go back. Drag to dismiss. Movement stopped being a command and started behaving like motion. The interface responded immediately, even if the destination was still catching up.

Memory

By this point the app arrived quickly. Interactions were steady. The main thread was quieter. Data was often ready. Transitions felt coherent.

And yet, one irritation remained. Going back still felt like starting over.

Angular’s default routing model destroys components on navigation. It is a reasonable default, but it is not unique. React behaves much the same unless you are deliberate about preserving state through layouts, caches, or offscreen trees. The default mental model in most web frameworks is still page-like.

Native apps tend to take the opposite approach. Screens stay alive unless there is a good reason to discard them. Navigation reveals existing state rather than reconstructing it. The premium feel often comes from these lifecycle defaults rather than raw performance.

Route reuse on the web is an attempt to choose the same defaults. Not everywhere, and not blindly, but where it matches how players actually move through the app. Coming back should feel like returning, not rebuilding.

In our company we’ve made progress on parts of this, and we’re open about what still needs to land. That’s expected. This isn’t a finished state so much as a direction we’re deliberately moving in. One that applies to any team trying to make a single web codebase carry a genuinely premium experience across many surfaces, where duplication is permanent and improvements only really pay off if they land everywhere at once.

Epilogue: Where the Feel Comes From

Most of what makes a web app feel premium lives below the headline features. The big steps matter, but the lasting impression comes from texture. A steady frame rate rather than a high one. No layout shifts once the page hydrates. Interactions that acknowledge intent immediately. Scroll positions and tabs that remember where they were left. Data warmed before it is needed. Navigation that behaves the way the player expects, not the way the router prefers.

Native apps benefit from these defaults by design. On the web, we choose them deliberately. That choice is sometimes uncomfortable, but it is what allows a single codebase to carry a serious experience across many surfaces.

The premium feel is not a breakthrough. It is the accumulation of small decisions that protect flow. Most of them are already within reach.