Stuff Everybody KnowsPerformance Is UX
Speed is the feature your users care about most
One of the most frequently overlooked aspects of UX is performance. In any situation where you are trading a feature for speed, you should always choose speed.
Speed is: when a user asks for something, how long does it take for them to get it?
Speed is the feature your users care about most. It is, according to many studies, basically the only thing they consciously notice.
Speed encourages exploration
Speed doesn’t just feel nice: it changes behavior. People will tolerate a really mediocre interface if it’s super fast, because they can click into something, discover it’s not what they wanted, and go back instantly. If every click on your website costs a second or two, people stop exploring. They stop trying things. They give up on discovering how your interface works.
Speed vs. efficiency vs. latency
There are several ways to measure performance: speed, efficiency, throughput, latency. But really the only one you should spend your time caring about is speed. It’s the only one your users care about, and therefore the only one you should care about. Why are you solving problems other than your users’ problems?
Efficiency
A lot of people confuse efficiency and speed because they think of hardware as a fixed asset. “If I make my code twice as efficient, it’ll run twice as fast.” Maybe — but you could also just buy a second machine and get the same result.
Hardware is much cheaper than your time. When you’re working at a startup with millions of dollars of funding and four developers, you want to spend money to make sure the developers do as little unnecessary work as possible. Put it on as many machines as it takes.
Efficiency starts to matter when you have a hundred machines and your bill is approaching $10,000 a month. At that point, making your app twice as efficient might save enough money to hire another person. But not before then.
This math gets even better with agents doing the work. Get your agent to figure out your efficiency bottlenecks for you and spend no time on it at all.
Latency
Latency feels like speed but isn’t quite the same thing. Speed is how long your application takes to do something. Latency is how long the user waits for a response — which includes the time it takes for the request to travel to your server and back.
If your user is sitting next to your server, latency and speed are the same thing. If they’re in Australia, it takes about 200 milliseconds for the request to get there and 200 milliseconds to come back. Your 0.1-second app now takes 0.5 seconds. It’s five times slower in Australia, and it’s not your fault.
CDNs (Content Delivery Networks) solve this by putting thousands of servers around the world so that your response comes from a physically nearby machine. A CDN can drop your latency for every user on the planet without requiring a single change to your application.
Caching is the other approach: put the same data somewhere faster. If your HTML is stored in S3, it takes 200ms to retrieve. That’s an eternity. It’s the same as it being in Australia. Put your HTML in memory — in a cache, in Redis, anything closer than a disk — and it comes back instantly.
Throughput
Throughput is how many requests your server can handle at once. It’s another efficiency problem. It’s important, but it’s not something you should be optimizing for until you are at truly enormous scale. If your server can only handle 100 requests per second, but you only get 10 requests per second, you don’t have a throughput problem. You have a speed problem.
Two types of speed: server and client
With efficiency and caching out of the way, there are two things left that can affect your speed: how fast your server is, and how fast your client is.
Server side speed: do less stuff
If you can make your web app faster by buying more hardware, buy more hardware. If you can make it faster by doing less stuff, do less stuff.
My canonical example of the value of performance over anything else is Craigslist. This website is garbage. It looks like it was designed in 1995 because it was. And it prints money. Because it is extremely fast, it doesn’t distract you, and it does the absolute bare minimum. They don’t change because they don’t need to. Craigslist made $300 million in 2025.
Craigslist is doing almost everything on the server (see our previous section about user experience for why that’s a great idea for their use case). And their servers are very fast, because they’re doing almost nothing and then they’re caching the hell out of it.
Client side: rendering speed
Even if your server is blindingly fast, it won’t matter if your HTML and JavaScript is 10 megabytes of stuff that takes forever for a browser to download, parse, and render.
Google’s Core Web Vitals are the industry standard for measuring whether your site is fast enough on the client side. There are three metrics:
Largest Contentful Paint (LCP) measures how quickly the main content of your page appears. Good is under 2.5 seconds. This is the one most people think of as “page load time.”
Interaction to Next Paint (INP) measures how quickly the page responds when you click or tap something. Good is under 200 milliseconds. This replaced the older First Input Delay metric in 2024 because it measures responsiveness across your whole visit, not just your first click.
Cumulative Layout Shift (CLS) measures how much stuff jumps around on screen while loading. Good is under 0.1. You know that feeling when you’re about to tap a button and the page shifts and you tap an ad instead? That’s what CLS measures.
You can check your scores right now at PageSpeed Insights by entering your URL. It will show you both lab data (a simulated test) and field data (how real Chrome users experience your site). The field data is what matters.
There are a million guides to improving your client-side performance, but “do less stuff” is also a good guide here.
Speed is money
There are controlled experiments proving that faster pages generate more revenue. These stats change all the time, but here are some recent ones.
Google maintains a collection of Core Web Vitals case studies on web.dev. These aren’t surveys or correlations; they’re A/B tests where the only difference between the two groups is how fast the page loaded. Here’s what they found:
Vodafone ran an A/B test on a landing page. Version A was optimized; version B was not. They were visually and functionally identical. The optimized page had a 31% better Largest Contentful Paint score, and it generated 8% more sales, a 15% better lead-to-visit rate, and an 11% better cart-to-visit rate. Eight percent more sales, just from making the same page load faster.
Rakuten 24, a Japanese e-commerce site, ran a similar A/B test after optimizing their Core Web Vitals. The result: 53% more revenue per visitor and a 33% higher conversion rate. They got there by eliminating render-blocking resources and optimizing JavaScript and images. Not a redesign. Not new features. Just making the existing page faster.
Redbus, an Indian bus ticketing site, focused on responsiveness: how fast the page reacted after you clicked something. They improved their Interaction to Next Paint metric by 72% and saw a 7% increase in sales. They also saw an 80-100% increase in mobile conversion rates across their global properties after fixing layout shifts and reducing blocking time.
The BBC found they lost 10% of their users for every additional second their site took to load. Ten percent per second. If your site takes three extra seconds, you’ve lost a quarter of your audience before they’ve read a word.
The pattern is consistent across dozens of case studies: The Economic Times cut bounce rates by 43%. Renault improved both bounce and conversion rates. Tokopedia improved their main content load time by 55% and saw 23% longer sessions. AliExpress cut bounce rates by 15%. Yahoo! Japan saw a 15% uplift in page views per session. You can browse more at web.dev/case-studies and wpostats.com, which is a community-maintained collection of performance case studies going back to 2006.
If you think “I must have this JavaScript widget and it must load before anyone can do anything,” reconsider. You may be trading a significant chunk of your users for a feature they never asked for.
And if you’re thinking about user experience and performance, you should be thinking mobile first.