Key takeaways

• Sluggish apps are a common issue we often tolerate although it has strong impact in the user.
• There are two types of performance you can improve: user-perceived performance and system performance.
• Companies that make "performance" solely Engineering's responsibility will likely see a decline in user-perceived performance.
• Companies where Product Managers own user-perceived performance have a better shot at satisfying their customers.

The Sad State of App Performance

Day after day, we're stuck with slow apps that kill our productivity and patience. What's worse? Those of us in the software industry often commit the same sin, delivering sluggish apps to our users. The root cause often comes down to one classic mistake—poorly defined responsibilities.

Users obviously hate this, as The Nielsen Group has been saying for years. Slow apps disrupt our flow, drain our energy, and drag down productivity. If you're reading this, you probably agree.

Over time, more sophisticated apps manage to slow themselves down. More features, complex views, bloated JSON responses, and larger databases—all chip away at performance. If you don't actively fight this, you're left with a poor user experience characterized by a gradual decline in speed.

But these are just excuses. As hardware gets faster and cheaper year over year, software is constantly playing catch-up, becoming slower than it used to be. Julio Merino illustrated this well in this post.

Why do companies neglect app speed? It's easy to point fingers at enterprise software, where decision-makers often prioritize features over UX. But the issue is widespread, even outside the enterprise space.

We could also call out the fact that we're often sold apps and devices that run smoothly in a clean state. Yet, once they're loaded with data, other apps, or plugins, they slow down. By then, it's too late; the deal is sealed. But no company wants to be known for slow products. I'm sure Notion's sales team isn't thrilled with Google suggesting "slow," "so slow," and "too slow" when people search "Notion is..."

Two Kinds of Performance

So, back to our question: why do companies overlook this critical aspect of user experience? Often, no one's accountable.

Some might think, "Hold on. Someone is accountable—that's Engineering, isn't it? I recall a meeting where we said, 'Performance is an Engineering responsibility, and initiatives to improve it should come from their backlog.'"

That's actually how this problem gets sidelined. Let me clarify. When we say, "Performance is an Engineering responsibility," we're blending two types of performance:

- System Performance: This pleases servers and engineers. It's about optimizing database queries, JavaScript bundle sizes, and HTTP responses, etc.
- User-Perceived Performance: This pleases your users. Examples include reducing Largest Contentful Paint, Real User Monitoring, etc.

Engineers naturally lean toward system performance. And while improvements in one can impact the other, the effect is often not significant enough.

For example, shaving 50 ms from that database query might significantly impact our infrastructure. However, on a page that takes 3 seconds to load due to large images, it'll have a negligible effect. Another one: If a single JSON contains too many items and times out, we could paginate it into multiple requests. Servers will be happy... but  to the eyes of the user, waiting for two HTTP requests will take the same or even more.

In fact, strategies that will increase performance from a UX point of view, can actually increase engineering complexity. Examples include serving static files through a Content Delivery Network, or splitting JavaScript code into smaller bundles... Although engineers care and can feel proud when see the impact of these things, they won't be their choice of investment for their limited effort budget.

Occasionally, you find heroes on your team—the ones who set up Google Lighthouse or enable Real User Monitoring. But they often struggle to get the rest of the team on board, including Product. Improvement initiatives aren't prioritised, and charts end up collecting digital dust.

Splitting responsibilities right

The heart of the issue is that user-perceived performance is motivated by user experience, not developer experience. And, unlike its counterpart, it's better owned by the product organisation rather than engineering.

Still skeptical? Let's consider what's really needed to build a product that performs well in the eyes of the user:

• Understand user expectations and how performance impacts their satisfaction.
• Choose the right metrics and goals that represent these expectations.
• Prioritize between performance improvements and feature work to maximize user satisfaction.
• Track the evolution of these metrics over time.
• Make trade-offs between new features and their impact on performance.
• Factor in perceived performance when making UX decisions...

Given these complexities, it's clear that Engineering Managers alone aren't best equipped to shoulder the responsibility for user-perceived performance. At the end of the day, the solution will be a joint effort between Product and Engineering. But companies that grasp the difference between user-perceived performance and system performance—and allocate responsibilities accordingly—stand a better chance at building an app that meets customer expectations.

So take a moment to reflect: Is user-perceived performance well understood within your company? Are your customers satisfied? If not, a shift in responsibilities might be in order.