38 comments

[ 2.2 ms ] story [ 4.4 ms ] thread
> The person who clicked noticed no delay.

Just to be the "actually..." guy: People notice 200ms delay. It's just that in cases it doesn't cause any bad feelings."

Users know to expect different things at different speeds, and have come to expect the actual "buy" button to be slow. 200ms is pretty fast for that, tbf
200ms is insane, 50ms is the goal.

But really, great page.

Someone new could learn from it the basics of what to check when debugging web.

This is magnificent!

Gave me roller-coaster ride across 40 years of gathering knowledge about computers and networks.

I'm very jealous of whoever created that. Well done!

Wonderful page, congratulations! navigating to the end takes time but the contents and the presentation are great
Back in the day "what happens when the user types a url in the address bar and press enter" used to be an interview question, and I remember nobody has ever mentioned the hardware and keyboard keys and interrupts. This post does! Pretty awesome detailed view of a request lifecycle.
Am I crazy if for something like an online purchase, I kind of expect it to take a second or two to process the payment, so I would assume something went wrong if it was 200ms?
The CSS animation of the encrypted message overwriting the plain is utterly cool.
Wow, input lag is a lot lower than I thought. I thought it was a polling-based flow at some 120 Hz roughly. Good to update these numbers.
(comment deleted)
This is very nice and for me especially because I've tried to think about it before your post. I think you can write a very long book if you go really into detail such as the underlying physics for wifi starting from maxwell's equations, how specific CPU architectures execute one instruction at a hardware level and maybe more in depth discussion about the math and cryptography within TLS.
> Violet marks the data as it moves, always top to bottom. Nothing else on the page uses that color.

Proceeds to use that color for tooltips, text color, headers, and more

This was a really cool visualization but that ^ bothered me way more than it should have.

If it was 200ms, then it had already charged the card...
> Violet marks the data as it moves, always top to bottom. Nothing else on the page uses that color.

I'm seeing 3 violet elements on my screen. "ms" in the top left, the dot next to that text, and a dot on a horizontal timeline at the lower edge of the screen. Scrolling down I see yet more violet UI elements, I assume the one on the vertical timeline represents the data, while all the others represent... other things.

It seems violet is just the accent colour used for everything, which makes it an especially perplexing comment. I can only assume the "author" never even read the LLM's output before posting it.

(comment deleted)
I'd be impressed with a touchpad and OS that can go from an actuation to a userspace process receiving a click event in 1.2ms. I'd expect something more like 10x that. My understanding is that most hardware samples between 90-130Hz, and even premium hardware only samples at 250Hz which would average 2ms before the kernel is aware.
So why does it take 5-10 seconds from card presented to accepted at Starbucks and CVS?
is it bad that while this does look like a really cool method to explain a complex topic, my instinct on reading mic-droppy, RLHF AI prose is to be dismissive? there's just something about the persistent mic drops and this-not-that writing that feels so cheap

I think it's because the explainer is passive, there's no interiority, it tells and doesn't show. plus, stylistically, if this were rewritten in second person (like most explainers are) it would make it a heck of a lot more readable:

'You order a coffee on your coffee shop's tablet. 211.4 ms later you see 'Order Confirmed'.

There's a world of complexity behind that status confirmation. Let's see how it all works.' etc

  > A problem repeatedly occurred on "https://200ms.thenodebook.com/#act-O-prologue”
I find this usually is caused by being too clever with layouts.
> "The internet"

Classic software engineer perspective.

I have good friends who build their entire career between "ISP" and "Load Balancer"

Great read. I was already familiar with the overall concept, but the step-by-step, chronological explanation made it much easier to understand.

Highly recommended for infrastructure engineers, solution architects, and developers.

Fine, but what is the journey of the p99.9 900ms request?
>touchpad controller

>capacitance dip → interrupt raised

>hid driver report: x 512 · y 288 · button 1 down

>...

>One millisecond in, the click has passed through four pieces of software and nothing has left the laptop.

I'm going to press X to doubt.

There's no way you're getting from "finger touching glass" -> "chrome seeing a click" in one millisecond. Heck, I know for a fact that even the cap touch controller isn't going to be that quick.

I would believe it's closer to 40-50ms, E2E. Even if the captouch was instantaneous, 1ms latency latency is in the realm of RTOS, not a general-purpose OS feeding a bloated app like chrome.