Software craft and quality

#performance

Performance, latency, speed, and attendant considerations / 10 posts

Newsletter
  • Get a newsletter digest every Friday:
Other ways to follow
Contact

Send me feedback, tips, bug reports, and anything else:

About me and the blog

My name is Marcin Wichary. I’ve worked as a UX designer, typographer, front-end person, and manager at Google, Medium, and Figma. I’ve also written a book about keyboards and typing, gave talks, and published essays about design, typography, and technology.

Unsung is my blog about software craft and quality.

More info about Unsung

Send me feedback, tips, bug reports, and anything else:

More info about Unsung

Unsung Heroes: Super Sprint

I know, I know. I’m supposed to say iPod’s click wheel, or the Western Electric 500 rotary dial, or maybe the first Nest.

But, have you ever played Super Sprint?

It was Super Sprint that had the first amazing rotary controller I’ve ever used, and the whole cabinet design told you the game was very well aware of that.

Super Sprint was a 1986 arcade game from Atari that was, in a nutshell: four cars (at least one computer-controlled), eight tracks, fast races.

You might think that those wheels functioned similarly to a regular car steering wheel, but not really – they were much easier to spin, and needed to travel further to rotate the car. You wouldn’t steer delicately, but rather the opposite: you needed to throw the wheel violently in one direction, and then, at the perfect moment, stop it on a dime:

So the huge wheels were not realistic. Neither were the cars. They accelerated rapidly – the gas pedal was your only other control – and had a ridiculous amount of understeer.

Don’t let the size and intensity of the interface fool you, though: this was a very precise operation. The game was tight – Rollercoaster Tycoon tight or Excel 97 tight, a whole decade before them. In the world awash with slow computers, Super Sprint lived up to its name, laughing latency and delays in their faces. It’s hard for me, even today, to imagine something faster or tighter – and for even my contemporary work, it’s good to remember things can feel this way. And, on top of all that? Better-than-usual sound design, higher-than-usual resolution, shortcuts to reward really good players, and a bunch of great details and easter eggs.

Super Sprint wasn’t Atari’s first attempt here – it was preceded by Sprint 2, Sprint 4, Sprint 8, and Sprint One – and you could tell. It was designed and coded by Kelly Turner and Robert Weatherby, polished as hell, and might have been the first interface between the person, the hardware, and the software that really inspired me. It was almost as much fun to watch three good players compete, as it was to play yourself. But when I played it, it’s possible these were my first – please excuse me here – motor memories.

Atari used the same wheel for other games, famous and obscure, but this was where it met its match in software. I can show that to you, but experiencing it is impossible from afar. Even perfect emulation can’t do it justice – there has simply never been a home controller that approached it. (I mean, the whole cabinet weighed 400 pounds!)

But if you are ever in an old-school-themed arcade, look out for Super Sprint (locations), or its two-player cousin Championship Sprint (locations) – and give it a turn or two.

Sep 7, 2026

“No such thing as too fast”

On Mastodon, Alex Russell, a product architect who’s worked on Chrome and Edge, and has focused on tech standards for a while:

Once Upon A Time At Google, a team presented results that had confounded them: making the system load several times faster increased engagement somewhat, but in line with Tammy’s findings, engagement went way up for every 100ms improvement below the 1s threshold.

Going fast enough to become “dial tone” changed user behaviour and expectations in a hugely positive way for the product.

This sort of “no such thing as too fast until you prove it” lesson is everywhere.

Phrasing it as “no such thing as too fast” is really interesting, and not something I encountered before.

(The way I understand the “dial tone” remark is commenting on reliability of landline phones in the second half of last century. The landlines were extremely reliable and even came with their own power source; you could pick up the handset and the dial tone – the system’s confirmation it’s ready for you to dial – was inevitably and immediately always there, already waiting for you. There was never any delay when the phone had to get ready for you to call.)

Russell links to a report by Tammy Everts:

If you make websites for a living, stop what you’re doing and read this research by Tammy Everts; it shows what many of us have been saying for a long time: even if there is such a thing as “fast enough” (there isn’t), it’s generally much faster than you are targeting.

The report itself is perhaps too deep and jargony for this blog, but the TL; DR seems to be: Google suggests the time for the site to finish loading its largest piece is 2.5 seconds, and Everts argues and shows evidence that it’s a lot less.

I have before focused on “finger speed” – making sure the interactions operate at the “speed of flow,” which requires sweating speeds counted in milliseconds. Everts’s and Russell’s comments confirm that millisecond-speeds matter for other reasons, too.

Jul 17, 2026

Not slow and not steady

Adam Engst at TidBits did the lord’s work of transforming the “sweating details” slide from WWDC26’s opening keynote…

…into a nice, human-readable list of 264 items.

It’s an impressive list that garnered universally positive reactions, but I have one observation:

  • “Fast” and variants thereof appear on this list 59 times.
  • “Reliable” and similar words appear 22 times.

It’s true that everything could be faster and a whole many things should. Speed is paramount to great user experience. Speed is also more than just speed; there are nonlinear aspects when latency or delays cross invisible thresholds that can drastically change app usage for the better.

But in my experience, much more often the things that frustrate me about using Apple’s products are not issues of speed, but issues of reliability:

  • I don’t need faster network connectivity in Finder, but I struggle with computers not appearing, a pizza cursor that occasionally just dies spinning, or randomly being thrown to the root of the networking volume.
  • I don’t need AirDrop to be faster. I just want it to connect reliably every single time, give me consistent and understandable UI feedback, and stop forgetting I’m not just “everyone” when sending stuff to myself.
  • I don’t need Messages to be faster. I need them to just, you know, not haphazardly stop syncing across computers on occasion.
  • We just talked about undo being profoundly broken, and I have many more examples like that. (Often from apps like Finder and Settings that are not on the list at all.)

It’s not just me. 15 out of 17 bugs listed on the Bugs Apple Loves site are about reliability. None seem to be directly about speed, although more on that in a second. Or, here’s a recent list from Ilya Birman – different issues, but a similar shape.

I’m going to say it: Speed is an easier problem. Not easier in an engineering sense; I’ve seen an engineer try to carve ten milliseconds out a busy computer’s schedule, and in that moment, one must truly imagine Sisyphus happy. But it’s easier as a problem: it often comes with a lot of pre-built telemetry, plus a clear goal of “here’s Xms and X now needs to be smaller.”

Reliability is much harder, more difficult to debug, reproduce, agree on metrics for, even find ownership of – just generally fuzzy around the edges, and less obviously thrilling as a challenge. It needs more champions and structures.

I know a simple marketing slide is not meant to be an accurate representation of Apple’s efforts. I wasn’t at WWDC so perhaps the vibe in the room was different than what this slide represents. Yet, the slide exists and I’m allowed to judge it.

(And yeah, I know in some cases speed and reliability are correlated. After all, if you have a timeout, making something finish faster and do so before the timeout will turn it from unreliable to reliable. But hey, I wasn’t the one choosing the words on the slide.)

I just… I would be a lot more excited if the 3:1 ratio of fast-to-reliable on that slide went the other way.

  • [ ] Typewriters
  • [ ] fujitsu standalone
  • [ ] canons cat add
  • [ ] Find the old file catalog
  • [ ] move to spreadsheet
Jun 13, 2026

“We accepted this gradual bloat, but that’s not progress.”

I like the Fits on a Floppy manifesto by Matt Sephton:

Software should be as small as it can be. Not as a gimmick, but as a discipline. The floppy disk is the measuring stick: 1.44 MB. If the software that ran entire businesses could fit in that space, then a modern, focused, single-purpose tool certainly can.

In my own work, I have mostly focused on the web side of this equation, as this is where the situation feels the most dire: tens of megabytes dedicated to heavy frameworks, unnecessary tracking scripts, and video ads have a real negative effect on experiencing websites. Progressive loading challenges also make it harder to offer a great experience.

But space considerations are starting to feel more pertinent to local software too, in an era where SSD and hard drive prices are going up, and where local LLM models start taking up more room.

Also, this passage feels very Unsung, and is exactly why the tag #history exists on this blog:

I don’t miss floppy disks. I miss the mindset they demanded—that every byte matters, that constraints breed creativity, and that software should be light on its footprint.

If you reduce tech history to just nostalgia, it won’t be that useful. But if you look at it as inspiration, you might find some truly wonderful and meaningful stuff in there.

On that note: Bonus for a nice classic domain, and a nod toward Mac’s most famous screensaver.

May 17, 2026

“Nothing short of a magic trick”

A fascinating 25-minute video from Mark Brown at Game Maker’s Toolkit about how the team building Grand Theft Auto 3 conquered the technical limitations of PlayStation 2:

How do you squeeze a city that occupies over 50 megabytes into the 32MB memory of the console? You simply do what The Truman Show did, and construct the city around the player as they’re moving around:

This has, as you can expect, a lot of technical and even game-design consequences, and the video goes into a lot of detail on these – including Brown rebuilding the Grand Theft Auto 3 source to visualize things better.

This technique is also used in interface design, for example if you have a really long list of things that would take too much memory or GPU power to render. What the video calls “streaming” is, in the context of UI, often called “virtualization”: instead of having a full long list (or an entire world), you abstract it away – or, virtualize – into something nimbler.

Some of the challenges and techniques used by Grand Theft Auto 3 apply pretty directly here, as well:

  • you can use UI skeletons as “low poly” models,
  • in some contexts, you can guess the user is more likely to move in one direction (for example, going through fonts in a font picker), and more eagerly preload where they’re going to look next, rather than symmetrically in both directions.

On the other hand, “speedy players” and “pop in” can’t ever be solved because any UI list is random access, and slowing users down is not typically appropriate; better to make loading as pleasant as possible than introduce any roadblocks, even if figurative ones.

May 11, 2026

Only time will tell

Why is there a short wait if you press a button on your headphone remote or your AirPods to pause the music? Because the interface has to let a bit of time pass to figure out if you’re going to press the button again, making it a double press (advance to next track) instead of a single press.

This kind of disambiguation delay is everywhere for simple gestures.

Why is there a short wait if you press a button twice in that situation? The double press processing also has to be delayed, because there is a chance it might become a triple press (go to previous track).

Why is there a short wait if you press a button to go to the next track on your car’s steering wheel? It’s a delay of a different kind, but the same principle: the function cannot kick in on press down, because press down and hold mean “fast forward.” So, software has to wait for button up event to go to the next track (which feels a bit slower than button down), or for enough time to pass so we’re certain it’s a button-down hold rather than a slow press. Here, both interactions experience a penalty for coexisting.

The most infamous of those disambiguation delays exists in mobile browsers. Since every double tap can zoom into the page ever since that famous 2007 iPhone presentation, every single tap on a link or elsewhere has to be delayed by about 300ms. This has been a source of contention since it does make the web feel a bit slower, and today browsers suspend double tapping on sites designed for mobile, trading zooming affordances for higher interaction speed – after all, you can still zoom in by pinching. But if you always wondered why older websites tend to be a bit sluggish to interact with, now you know.

Different tradeoffs are possible. In the Finder, clicking on icons isn’t slowed down even though double clicking exists, because selecting an icon is compatible with opening it! So in effect it’s not a choice between a faster A and a slower B – it’s A or A+B.

Even in the iPhone presentation above, you can see the interface highlights the link on double tap, to at least make it feel snappier, at the expense of the highlight being “wrong” and potentially distracting – or even confusing – when you end up double tapping. (You can imagine smartphones pausing on the first remote/​headset button press, too. It feels like it would be compatible with advancing to the next track, but I think it might also feel too “choppy,” too chaotic, in practice.)

Lastly, why is there a short wait if you press a button on your hotel TV to increase the volume? Oh, I think that one is just sluggish for no good reason.

Apr 11, 2026

“If you use your computer to do important work, you deserve fast software.”

Two great posts about interaction latency on the hardware and software side. First is from Ink & Switch:

There is a deep stack of technology that makes a modern computer interface respond to a user’s requests. Even something as simple as pressing a key on a keyboard and having the corresponding character appear in a text input box traverses a lengthy, complex gauntlet of steps, from the scan rate of the keyboard, through the OS and framework processing layers, through the graphics card rendering and display refresh rate.

There is reason for this complexity, and yet we feel sad that computer users trying to be productive with these devices are so often left waiting, watching spinners, or even just with the slight but still perceptible sense that their devices simply can’t keep up with them.

We believe fast software empowers users and makes them more productive. We know today’s software often lets users down by being slow, and we want to do better. We hope this material is helpful for you as you work on your own software.

I loved the slow-motion videos comparing what is normally impossible to notice:

Dan Luu has a complementary post digging a bit more into computer hardware latency from the 1970s to now:

I’ve had this nagging feeling that the computers I use today feel slower than the computers I used as a kid. As a rule, I don’t trust this kind of feeling because human perception has been shown to be unreliable in empirical studies, so I carried around a high-speed camera and measured the response latency of devices I’ve run into in the past few months.

I feel both of these essays are fantastic, and important to develop some sense of what are specific numeric thresholds separating fast and slow, also in the context of being able to have an informed conversation with a front-end engineer. (Luu subsequently links to even more articles in the “Other posts on latency measurement” section, if you are curious.)

Otherwise, from my observation, the two most quoted laws of user-facing latency are still Jakob Nielsen’s response time limits, and the Doherty Threshold. But the Jakob Nielsen 100/1000/10000ms rule is from 1993 and as far as I understand is concerned primarily with UX flows: reactions to clicking a button, responses to typing a command, and so on. And the Doherty Threshold is even older. Both are simply not enough, especially not for things related to typing, multitouch, or mousing, where for a great experience you have to go way below 100ms, occasionally even down to single-digit milliseconds.

(My internal yardstick is “10 for touch, 30 for mousing, 50 for typing.” Milliseconds, of course.)

At the end of his essay, Luu writes:

It’s not clear what force could cause a significant improvement in the default experience most users see.

Perhaps one challenge is that these posts are dense and informative, but only appeal to people who care? Maybe latency eradication needs a PR strategy, with a few memorable rules and – perhaps arbitrary, but well-informed – numbers that come with some great names attached? I know in the context of web loading some of the metric names like FCP (First Contentful Paint) broke through at least to some extent, but those still feel more on the nerdy side. Even Nielsen’s otherwise fun 2019 video about response time limits didn’t stick the landing – why focus on slowing down an arbitrary label appearing above the glass when the ping sound was right there for the taking?!

I can’t help but dream of interaction speed’s “enshittification” moment.

Apr 4, 2026

“Distinct absence of anything that takes away screen real-estate”

Neil Panchal writing in 2020 about a cool little page called diskprices.com:

The performance of this website is stellar. It loads almost instantly. And the list (although it’s not sortable) gets the job done, it is sorted by price already which is the most important attribute.

Diskprices.com deserves the UI/UX award of the decade. We’ve lost our ability to design user interfaces laser-focused on the user. Instead, we have purple gradients, scroll jacking, responsive bullshit, emojis, animations, and many other things designers do today. The utilitarian approach of Diskprices.com is refreshing, although the contemporary designers cast it off as ‘brutalist design’, thereby marking it as a statement of fashion.

But both the creators of the page and Panchal might be getting this wrong:

Do you need a graphic designer?
No. This site is designed to maximize information density, accessibility, and performance. More whitespace, colors, and icons won’t help.

I think this is incorrect. The creator of the page is a graphic designer, that just happens to be the perfect graphic designer for the job.

Jan 23, 2026

“Everything possible to make this website as fast as they can”

This 13-minute video from Wes Bos analyzes this today-almost-mythical McMaster-Carr website and figures out why it’s so fast.

It’s perhaps more technical than what I usually link to, but shows what can happen if someone really cares about performance. What’s interesting to me is that the author posits that it’s actually not an old website that is fast because it’s old… it’s actually kind of a melange of various techniques throughout the decades, from vintage solutions like spriting images, to more modern like JavaScript’s page history API, or pre-caching DNS.

Just visiting the website and clicking around can be inspiring because it reminds one that we gained a lot of computing power and network speed over the last decades, but most websites squander it. Not this one.

And it’s sad this kind of approach of a website appearing and not changing (no reflow, no pop-ups, no endless spinners, no infinite scrolls) feels so rare.

However, two caveats:

At around 7:35, Wes says “nothing else moves”… Oh yeah, it does. It’s perhaps my curse that I notice these things.

Also, the homepage now has an animated, delayed green banner you can see at the photo above. I hope they’re not losing their way.

Jan 12, 2026

“Every aspect of the machine operates as quickly as the user can move.”

Evergreen and inspiring from Craig Mod, a 2019 plea for fast software:

Google Maps is dying a tragic, public death by a thousand cuts of slowness. Google has added animations all over Google Maps. They are nice individually, but in aggregate they are very slow. Google Maps used to be a fast, focused tool. It’s now quite bovine. If you push the wrong button, it moos. Clunky, you could say. Overly complex. Unnecessarily layered. Perhaps it’s trying to do too much? To back out of certain modes — directions, for example — a user may have to tap four or five different areas and endure as many slow animations.

Funnily enough, I feel that way about Apple Maps. I abandoned it since small things felt heavy, mired in superfluous swipey animations that felt like driving a 1960s car. Luckily, this was at the time Google Maps redesign its tiles to match Apple’s, so I got what I wanted to begin with, although in a slightly shady way.

I miss Sublime Text and might take it again for a spin (VS Code and Atom felt slow, Nova is delightful but also struggles in performance, even on simple things).

I miss Notes feeling lightning fast.

Dec 9, 2025