You Bought a 240Hz Monitor and It Still Feels Slow. Here's Why

144Hz monitors are everywhere now. 240Hz is no longer exotic. CPUs are dozens of times faster than they were a decade ago. And yet, when you type into a text editor or drag your cursor across the screen, something still feels a half-beat behind. Developer Nikita Prokopov — better known online as Tonsky — went looking for the source of that lag. His answer: the problem was never how many frames you draw. It’s when you draw them.

Faster Frames, Slower Feel

Start with the counterintuitive part. A high frame rate does not mean a responsive interface. Frames per second is a measure of throughput — how much work gets pushed out per second. What you actually feel is latency — how long you wait for your action to show up. They are not the same thing, and conflating them is where most of the confusion starts.

Think of a bus stop where a bus leaves every second. The service is frequent. But if you reach the stop right as one pulls away, you still wait for the next one. Frequent buses don’t guarantee a short wait — they guarantee an inconsistent one.

Your screen works the same way. The monitor emits frames on a fixed cadence. If your keystroke lands just after a frame goes out, it sits and waits for the next one. Drawing more frames per second doesn’t erase that wait. It just makes the buses come more often.

Tonsky’s Question: When Does Input Get Read?

This is the seam Tonsky pried open. Between the instant you press a key and the instant the character appears on screen, there’s a surprisingly long journey.

Roughly: the keyboard fires a signal, the OS wraps it into an event, the app reads that event, the app redraws, and the monitor finally displays the result. Every stage runs on its own clock. The trouble is that those clocks don’t line up.

The most common place to bleed time is between input and rendering. An app typically polls for input once, right before it draws a frame. If your keystroke arrives just after that poll, it misses this frame entirely and waits for the next one. On a 60Hz display, a frame is about 16.7 milliseconds. With bad luck, that’s 16.7ms thrown away for nothing — not because the machine was busy, but because of when it happened to look.

What “Every Frame Perfect” Actually Means

This is where the phrase every frame perfect comes in. It does not mean “never drop a frame.” It means something closer to: read input as late as possible, right before you draw.

That sounds backwards. How can reading later make things faster? The answer is freshness. If you sample input immediately before rendering, that frame reflects the most recent input available. If you read it at the top of the frame instead, anything that arrives while you’re drawing slips to the next frame. Late reading wins because it shrinks the gap between “what the user just did” and “what gets painted.”

Game developers have known this for ages — late input sampling to cut latency is standard practice in that world. Tonsky’s sharper point is that ordinary apps almost never think about it. Text editors, browsers, chat clients. The everyday software where nobody is tuning frame timing. So the specs improve, the silicon screams, and the felt responsiveness somehow lags behind machines from twenty years ago.

The Uncomfortable Truth: Old Computers Were Faster

Measure input latency directly and the results sting. Plenty of decades-old machines register keystrokes faster than today’s flagship hardware — monochrome screens, sluggish CPUs and all.

The culprit is complexity. On an old machine, pressing a key sent the character almost straight to the display. A short, dumb path. Today that path runs through a compositor, GPU acceleration, double buffering, the OS event queue, and layer upon layer of abstraction. The picture got gorgeous. The number of gates your keystroke must clear got much, much longer.

The reason Tonsky’s argument lands is that he frames this as a design choice, not a law of physics. Nothing about the hardware forces this lag. We built it in, one convenience layer at a time, while nobody was watching the clock. Which also means: line the timing up deliberately, and today’s hardware can feel dramatically faster. The ceiling isn’t the problem. The wiring is.

So What Can You Actually Do

You can’t patch your editor’s render loop over coffee. But this lens changes how you read software.

First, stop trusting the FPS number. If your 240Hz panel still feels mushy, the bottleneck probably isn’t the display — it’s when your input gets processed on the way there. Second, treat responsiveness as a selection criterion when you pick tools. The tactile snap of a keystroke does more for daily productivity than a feature list ever will. That’s the real reason so many developers stubbornly stick with lightweight editors.

If you build software, the message is blunter: read input late, apply it just before the frame. That one small act of alignment — not throwing away a frame — comes back to the user as a vague, persistent sense that the thing is fast.

In the end, Tonsky’s whole argument collapses to a single line: speed is a timing problem, not a throughput one. Look at the tools you use every day. Some feel glued to your fingertips; others lag by a beat. That difference might trace all the way back to a single frame, quietly thrown away. Worth feeling for, next time you sit down to type.