Performance is rarely the single determinant of product success, but it can be the margin of victory. Improving latency and reducing variance allows teams to test other product hypotheses with less noise. A senior product leader recently framed a big performance win as "creating space that allows us to be fallible in other areas."
Not only is web performance a user experience issue, it may well be the user experience issue. Page speed has a proven demonstrable direct effect on user experience (and revenue and customer satisfaction and whatever other metrics you’re using).
Users really care about speed in interaction design...A snappy user experience beats a glamorous one, for the simple reason that people engage more with a site when they can move freely and focus on the content instead of on their endless wait.
0.1 seconds gives the feeling of instantaneous response. This level of responsiveness is essential to support the feeling of direct manipulation.
1 second keeps the user's flow of thought seamless.
10 seconds keeps the user's attention. A 10-second delay will often make users leave a site immediately.
I love fast software. That is, software speedy both in function and interface. Software with minimal to no lag between wanting to activate or manipulate something and the thing happening. Lightness.
Software that’s speedy usually means it’s focused. Like a good tool, it often means that it’s simple, but that’s not necessarily true. Speed in software is probably the most valuable, least valued asset. To me, speedy software is the difference between an application smoothly integrating into your life, and one called upon with great reluctance. Fastness in software is like great margins in a book — makes you smile without necessarily knowing why.
Performance needs effort throughout a project’s lifecycle
Architecture strongly impacts performance
Performance isn’t just about hot spots
Performant foundations simplify architecture
…we underrate performance when designing and building software. We have become accustomed to casually giving up factors of two or ten or more with our choices of tools and libraries, without asking if the benefits are worth it.
Site performance is potentially the most important metric. The better the performance, the better chance that users stay on a page, read content, make purchases, or just about whatever they need to do. A 2017 study by Akamai says as much when it found that even a 100ms delay in page load can decrease conversions by 7% and lose 1% of their sales for every 100ms it takes for their site to load which, at the time of the study, was equivalent to $1.6 billion if the site slowed down by just one second.
Many of us are fortunate to live in high bandwidth regions, but there are still large portions of the world that do not. By keeping your client side code small and lightweight, you can literally open your product up to new markets.
Why aim small in this era of fast computers with plenty of RAM? A number of reasons, but the ones that are most important to me are:
Fewer moving parts. It’s easier to create more robust systems and to fix things when they do go wrong.
Small software is faster. Fewer bits to download and clog your computer’s memory.
Reduced power consumption. This is important on a “save the planet” scale, but also on the very local scale of increasing the battery life of your phone and laptop.
The light, frugal aesthetic. That’s personal, I know, but as you’ll see, I’m not alone.
Millions of programs have that unfulfilled potential of becoming your second nature, something you don’t even think about when interacting with. They’re waiting to be enabled to “click”. Speed is a feature.
A few people have asked me what I did to make this [website] so fast.
The answer is: nothing.
I just didn't add anything to make it slow.
I kept it simple.
The pages are pre-rendered.
The CSS is inlined.
I didn't add unnecessary javascript.
The work was done before you got there.
Your websites start fast until you add too much to make them slow. Do you need any framework at all? Could you do what you want natively in the browser? Would doing it without a framework at all make your site lighter, or actually heavier in the long run as you create or optimize what others have already done?
Finda uses vectorized CPU instructions and bitmap indexes to search in-memory results, and never waits on the disk or network.
Furthermore, Finda is developed and used by the author exclusively on a circa 2013 MacBook Air. If you have a newer or more powerful computer, it’ll be even faster.
Software's girth has surpassed its functionality, largely because hardware advances make this possible. The way to streamline software lies in disciplined methodologies and a return to the essentials.
Something strange is happening in the world of software: It’s slowly getting worse. Not all software, but a lot of it. It’s becoming more sluggish, less responsive, and subtly less reliable than it was a few years ago.
In some ways this is hyperbole. Objectively, we’ve never been able to do so much, so easily with our smartphones and laptops and tablets. We’ve never pushed more data between more places more readily. But while the insidious “worseness” I mention falls only in part on the engineering side of things, it falls harder on the more subjective, craft side of things, making it all the more worrisome.
Why should we care about this? Because the majority of our waking hours take place within the confines of applications. A truth recently amplified by the covid pandemic.
And I believe software used by millions (if not billions) has a moral duty to elevate the emotional and intellectual qualities of its users. That elevation begins with craft.
"If it could save a person's life, would you find a way to shave ten seconds off the boot time?" [Jobs] asked. Kenyon allowed that he probably could. Jobs went to a whiteboard and showed that if there were five million people using the Max, and it took ten seconds extra to turn it on every day, that added up to three hundred million or so hours per year that people would save, which was the equivalent of at least one hundred lifetimes saved per year. "Larry was suitably impressed, and a few weeks later he came back and it booted up twenty-eight seconds faster," Atkinson recalled. "Steve had a way of motivating by looking at the bigger picture."