> 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.
Yeah this smells like the type of comment an LLM leaves when it gets a really specific instruction. “use one consistent color for the data timeline. Right now we’re using multiple which is confusing.” Then the LLM writes some comment that’s a mini retrospective on what happened to justify itself.
Claude seems to do this all the time. That, the empty words and the increased self initiative of claude were all reasons I decided to just use codex (now merged into GPT).
Codex does this too, I've noticed. LLMs seem to love documenting irrelevant implementation details in what should be user-facing text. I guess because the context is overwhelmingly the technical side of things, so without a later directive to steer it, that's what's most likely to come out.
What' especially annoying is when you as a code reviewer have to go through tons of such comments that keep distracting you because the author could not bother reading those comments and assessing that they contain references to prompts / instructions that are completely irrelevant to he target audience
The user-facing string stuff is definitely the thing that drives me the most nuts. I guess it's nice that it defaults to gag-inducingly transparent, but I don't think the backend structure should be written out in the title element of the app.
Absolutely, makes my blood boil. Claude proposes an obviously wrong/overengineered solution to a problem. I come up with a better approach and we agree to do that instead. Every step of the way, Claude leaves code comments with long-winded explanations of how we're doing X instead of doing $insane_thing.
Literally # This method rejects splines that can't be reticulated. This helps us avoid murdering puppies and punching a baby in the face.
Claude using documentation and comments as its personal diary is one of the most infuriating behaviors it exhibits.
Half the time it’ll record some temporary implementation quirk, which later sessions interpret as infallible product design requirements. Absolutely unsustainable.
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
Thank you for putting into words how a lot of AI prose makes me feel. 'Persistent mic drops' is the most accurate way I have seen it described and I would even argue the 'this-not-that writing' is part of it. Setting up a chain of ever increasing seemingly powerful phrases to then conclude in a final statement which may or may not actually explain the core concept.
It also made me think of the Feynman Learning Technique[1] or learning by teaching in general: being able to accurately explain in simple terms requires to fully grasp the concept and noticing gaps in the explanation is an insight to the explainer to evaluate and understand those parts again at a deeper level. An AI arguably does not have this understanding and will happily drive home any point we have asked it to make.
In a way I think it's tied to the other discussion from today[2] where it was posited that domain knowledge makes you better at prompting LLMs and, consequently, would enable you to also better structure and evaluate explainers. But then again, explaining well is a different skill altogether.
Dismissive is appropriate-- "By the time the confirmation renders, the request and its replies will have crossed North America six times"
35ms times 6 is 210ms-- so just about physically possible with current infrastructure. But: this leaves no time for any of the hosts to do anything, or the wifi in the cafe, or whatever.
And immediately get shown an ad "how to build a backend framework from the wire up".
The first thing you think to yourself is how does building a backend relate to a coffeeshop click? Why would you even have to click in a coffee shop in the first place? If you really insist on product placement, why not explain how your order page works instead?
"the rules of this page" is a terrible wall of text that expects you to read carefully and memorize instead of using the scroll mechanism itself to show the clock in the center of the screen and then move it with a fluid animation to the top, so you notice it is there. Same problem problem with the time stop. You have to introduce the time stop mechanic as you go.
"the cast" is terrible yet again, you've primed me to expect the clock to start and I scroll through the request and nothing happens??? Why emphasize the infrastructure at the end with text? Why are there six requests? You only need one HTTP request/reply and TCP does not have the concept of requests. The packet round trips created by TCP/TLS handshakes do not count as multiple requests. This explainer feels wrong from a technical perspective already .
Then there is the fact that the text columns are incredibly thin with heavy vertical separation, there's an incredible waste of horizontal and vertical space to the point where you hardly get to read anything at all. You can divide the screen into 9 rectangles and only one of those is used. 90% of the screen is empty.
It also keeps jumping from single column, to double column to single double column (yes) and left bound text.
Not only does it not hook me, I'm having a hard time believing that the creator of this actually looked at the output or iterated on it at all.
In the audio/synth world, the lower bound is 8ms, as in, anything above this can become bothersome to the musician. I've heard it stated that this is also the threshold for fighter pilot control systems providing feedback.
> At 2000ms, without output, you wonder if it crashed. (That was the old one.)
That must have been a really, really long time ago indeed, because there are very few websites now that take less than 2000ms to load. The linked site didn’t even come close on my phone (probably 3-4 seconds), and I most certainly didn’t wonder whether it had crashed.
Yes, exactly what I meant. (FWIW, the original context was J2ME mobile games. It was important to use as few classes as possible to keep JAR size down; but in my testing, everything put into the entry-point class had to be loaded before the program would get past an initial black screen.)
Indeed. But there are also delays that cause good feelings.
I still remember the POS in my previous employers cafeteria. It had something like 100-200ms delay in processing a contactless payment card. It felt like an order of magnitude faster than any grocery store (exact same POS device). It was always very satisfying to pay for lunch. By the time you brought the card to the reader it felt like it was already printing the receipt.
I always wonder how it was so fast and if it was just some random dev optimising some obscure edge case.
In South Africa I notice this difference all the time where the big supermarket chains seem to be near instantaneous while small stores are 10+ seconds.
I'm certain it's because the big store's card machines have a wired network connection to a router with a fibre connection, while most smaller shops just use card machines with integrated GPRS wireless modems as they even show feedback about connecting as you tap your card.
A stall vendor who I use somewhat regularly warned me one time that her card machine was down (I guess some kind of maintenance as it was earlyish on a Sunday morning) so would only be able to accept cash. I helped her put the card machine on a nearby shop's free WiFi and not only did it work around the problem, but it made card transactions going forward significantly faster.
I was expecting the site it’s talking about to have faked an instant response. Ironically, sometimes it goes the other way and UIs have to fake a small delay otherwise the user won’t believe it’s actually done anything (although arguably the real issue there is lack of positive feedback, not response time.)
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
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?
I’ve definitely had in the UX side a situation where the PM/Owner types asked me to introduce a delay in the “disabled button with loading spinner” such that the user sees it for a visible amount of time because our API was too fast for their taste.
Yes similar here, async operation that could be quick enough not to warrant a busy state, but not all the time. So rather than show a flash of busy state, that makes the ui look janky when the operation is quick, show the busy state for a minimum amount of time
For one of the supermarket chains I frequent, from me handing over the single item I'm purchasing I can be walking away within 20s. They scan the item, then a loyalty barcode on my phone and finally I tap my iPhone which has my bank card loaded onto it.
Basically, they don't have any significant bottlenecks, POS hardware + software is responsive with an efficient UI for the operator, and the card machine is a wired connection to a router with a fibre uplink.
With the speed of modern internet connections, I'd honestly think something were wrong if it took a couple of seconds. I'd expect almost instantaneous results. What amazes me every time is the amount of things happening in that short amount of time though. The amount of endpoints/channels the signal has to go through to go from "I want to buy this" to "You bought it!".
I agree that purchases on e-commerce sites are virtually never this fast; but I have used some extremely fast physical payment terminals (e.g., Square): sometimes it seems like the transaction is sub 300ms, which I find very impressive given the complexity of payment processing.
That was terrible, I used to always turn it off. It's like speaking one word and the person interrupting you based on the prefix you had uttered so far... every single darn word. Imagine writing "how do I kill" and having it assume you meant a living being rather than a program.
I think it was a poor choice of example, because people will expect payment to be involved. They’re actually just inserting a row into a database for the order; presumably payment is to be handled out-of-band.
>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.
You're right the kernel might be able to handle that pretty quickly, but I know from experience even good, ~200Hz sampling captouch system is 1/200 = 5ms worst case, 2.5ms avg. That's already 2.5-5x the budget and we haven't gotten off the display.
Lisa's dictionary is different from widely-used real dictionaries. Here's what Merriam-Webster says[1]:
Some assert that only envious is correctly used to describe someone who feels or shows a very strong desire for something that belongs to someone else, but in truth both envious and jealous commonly carry this meaning. Jealous alone is used to describe someone who tends to suspect unfaithfulness.
They may be equivalent in common parlance, but that’s a bit like saying it is ok to use ‘your’ instead of “you’re” just because it is so common.
We say “jealously guarded’ not ‘enviously guarded’ for a reason. Jealousy is about being protective of your own possessions and relationships; you feel jealousy if your spouse responds well to a coworker’s flirtations. Envy is when you find think of the coworker’s luck in having a good looking spouse
If you check "jealousy" (instead of "jealous") on MW, you get this editorial note:
Depending on who you ask, jealousy and envy are either exact synonyms, totally different words, or near-synonyms with some degree of semantic overlap and some differences. It is difficult to make the case, based on the evidence of usage that we have, for either of the first two possibilities. Both jealousy and envy are often used to indicate that a person is covetous of something that someone else has, but jealousy carries the particular sense of “zealous vigilance” and tends to be applied more exclusively to feelings of protectiveness regarding one’s own advantages or attachments. In the domain of romance, it is more commonly found than envy. If you were to say “your salt-shaker collection fills me with jealousy,” most people would take it to mean much the same thing as “your salt-shaker collection fills me with envy.” But if someone made a flirtatious comment to your partner, you would likely say that it caused you jealousy, not envy.
While I also enjoyed it very much, some thing are strangely ordered and not how I would expect someone with such knowledge of all the moving parts in a request, would build such a site. So for me it feels like an LLM has build it and the human with the prompt saw it and said "eh, good enough".
Agreed. This reeks LLM writing with no human oversight, or at least a human with no writing experience. The text underneath “The Click” is an immediate giveaway:
> Five milliseconds of hardware and browser bookkeeping before a single byte leaves the laptop.
I don’t even know how to describe it, but the “[…] before X” sentence style stands out to me.
I once asked a question like this for an interview. "Tell me what happens when you press the Buy button on a web site". It really helped me gauge a sense for the person's interests and expertise. Like some folks just talked about javascript and some node code. Others talked about tcp a bit, some got into cloud stuff. It was really telling. Not bad or good, just a great way to learn where someone's head is at and was a fun back-and-forth conversation.
This web site is basically a cheat code for that question lol. So well done, kudos to the author. Bookmarked and shared
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.
I'm surprised at all the "200ms is slow" comments. I make many purchases online, don't we all? I can't remember the last time one took sub 1000ms; they usually take several. What are some of the websites you purchase from that truly complete a purchase in sub-200ms?
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.
> Its addresses are MAC addresses, serial numbers burned into each card at the factory.
oof
Nice idea, but execution could be better - way too many factual errors. Actually, considering it appears to be just 100% ai slop it's a little bit shocking how many just plain wrong statements it put out. Almost every section is at least a little bit off...
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.
I’ve always wanted a version of this sort of a timeline that really lets you zoom out and in to the fractal complexity of it all. Right at the end we’re talking about updating the DOM and rendering… there’s a whole Unicode and font stack and rasterization process happening in there.
I still like this question because of exactly what you mentioned. What the interviewee does and does not mention can give you a fair bit of insight into their priors.
I once got that question, started with the keyboard switches and the interrupts, and the interviewer sighed and asked me to get to the stuff in the browser.
Usually the dominant time is from POS to acceptor. These are frequently still on high latency links.
Also a lot of times in person payment flows allow a lot more in their latency budget because it won’t impact the sale, you won’t walk out because of a second here or there, unlike online.
So systems aren’t as optimized, they route to older systems, marketing or further risk checks are added, and a broader range of accepted services that have higher latency (ent/snap processors and the like).
I hate this. The style of LLM-written prose is unbearable, and I found several mistakes. This is "dazzle them with bullshit details" with no understanding behind it.
I assume the book this post is marketing is also AI slop too and I lost respect for its author.
You actually should not, usual (non-gaming) mice still do the same (most touchpads in cheap laptops even slower, they share already slow i2c bus with several other endpoints), and the article ignores drivers and the UI stack altogether.
I don’t know how much a human was involved in making this, but clearly not enough. Some parts of the timing it’s talking about make no sense, the ordering of some parts is incoherent, and it promptly goes into unreasonable and irrelevant detail while completely missing other actually relevant aspects of that detail. For example, “HSTS preload”: it’s utterly irrelevant, because you already know it’s HTTPS; and even if it were HTTP, you should talk about HSTS, the preload list is effectively just a prefilled cache; it then adds more to that cache as you visit sites that have HSTS headers.
I’m very confident that if I looked further I’d find it riddled with errors. I just skimmed it and looked at a couple of the bits I’m most familiar with and immediately found notable errors.
I looked at the beginning and it is already wrong. It talks about multiple requests and when you go all the way to the end, it suddenly talks about a single request.
The US is so big, that 50 ms is physically not possible for everyone.
This is something that not everybody is aware of. When I as a German build something for germans, everyone who needs to wait longer than 100 ms for a request, is rightfully mad. But when I want to serve the same stuff to americans at the same speed, I have to build something completely different and much more complex.
Yeah, but you would need to run an API server in each of those to reach that latency, and even then you're well into eventually-consistent distributed system headache if you accept the POST without synchronising with all the others first.
You terminate SSL (err, TLS) at the pop so the clients TCP connection gets setup faster, and then you use a hot TCP connection from the pop to a centralized API server. That gets you not having to deal with the headache of running a distributed system but a better experience for the client.
If you want 50ms then you're gonna have to do the distributed systems headache that rcxdude was trying to avoid. For everything smaller than Google, that's too expensive, but it can be done.
“On the wire, each label is stored with its length in front, 3 api 11 thenodebook 3 com 0, and the final 0 marks the end of the name, where the last dot would go.”
Am I the only one that doesn’t think of this as ‘api.thenodebook.com.’? What does the LLM mean by the zero after .com marking where the last dot would go?
The last '.' is essentially the equivalent of the first '/' in a file path: it refers to the root of the DNS and marks it as an absolute name (otherwise, in principle, it could be treated as relative even though it usually is not outside of the DNS machinery).
> 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.
Yeah this smells like the type of comment an LLM leaves when it gets a really specific instruction. “use one consistent color for the data timeline. Right now we’re using multiple which is confusing.” Then the LLM writes some comment that’s a mini retrospective on what happened to justify itself.
Claude seems to do this all the time. That, the empty words and the increased self initiative of claude were all reasons I decided to just use codex (now merged into GPT).
Codex does this too, I've noticed. LLMs seem to love documenting irrelevant implementation details in what should be user-facing text. I guess because the context is overwhelmingly the technical side of things, so without a later directive to steer it, that's what's most likely to come out.
What' especially annoying is when you as a code reviewer have to go through tons of such comments that keep distracting you because the author could not bother reading those comments and assessing that they contain references to prompts / instructions that are completely irrelevant to he target audience
The user-facing string stuff is definitely the thing that drives me the most nuts. I guess it's nice that it defaults to gag-inducingly transparent, but I don't think the backend structure should be written out in the title element of the app.
Absolutely, makes my blood boil. Claude proposes an obviously wrong/overengineered solution to a problem. I come up with a better approach and we agree to do that instead. Every step of the way, Claude leaves code comments with long-winded explanations of how we're doing X instead of doing $insane_thing.
Literally # This method rejects splines that can't be reticulated. This helps us avoid murdering puppies and punching a baby in the face.
Claude using documentation and comments as its personal diary is one of the most infuriating behaviors it exhibits.
Half the time it’ll record some temporary implementation quirk, which later sessions interpret as infallible product design requirements. Absolutely unsustainable.
Also “the clock at the top is exact” but the clock (on my phone, at least) is at the bottom. Still cool though!
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
Thank you for putting into words how a lot of AI prose makes me feel. 'Persistent mic drops' is the most accurate way I have seen it described and I would even argue the 'this-not-that writing' is part of it. Setting up a chain of ever increasing seemingly powerful phrases to then conclude in a final statement which may or may not actually explain the core concept.
It also made me think of the Feynman Learning Technique[1] or learning by teaching in general: being able to accurately explain in simple terms requires to fully grasp the concept and noticing gaps in the explanation is an insight to the explainer to evaluate and understand those parts again at a deeper level. An AI arguably does not have this understanding and will happily drive home any point we have asked it to make.
In a way I think it's tied to the other discussion from today[2] where it was posited that domain knowledge makes you better at prompting LLMs and, consequently, would enable you to also better structure and evaluate explainers. But then again, explaining well is a different skill altogether.
[1]: https://en.wikipedia.org/wiki/Learning_by_teaching#Plastic_p... [2]: https://news.ycombinator.com/item?id=49161518
Dismissive is appropriate-- "By the time the confirmation renders, the request and its replies will have crossed North America six times"
35ms times 6 is 210ms-- so just about physically possible with current infrastructure. But: this leaves no time for any of the hosts to do anything, or the wifi in the cafe, or whatever.
"mic-droppy" is the perfect description. Now I can imagine Claude sheepishly picking up the mic yet again after I correct it.
No, this site is awful.
You read this sentence:
>This website shows what happened in between.
And immediately get shown an ad "how to build a backend framework from the wire up".
The first thing you think to yourself is how does building a backend relate to a coffeeshop click? Why would you even have to click in a coffee shop in the first place? If you really insist on product placement, why not explain how your order page works instead?
"the rules of this page" is a terrible wall of text that expects you to read carefully and memorize instead of using the scroll mechanism itself to show the clock in the center of the screen and then move it with a fluid animation to the top, so you notice it is there. Same problem problem with the time stop. You have to introduce the time stop mechanic as you go.
"the cast" is terrible yet again, you've primed me to expect the clock to start and I scroll through the request and nothing happens??? Why emphasize the infrastructure at the end with text? Why are there six requests? You only need one HTTP request/reply and TCP does not have the concept of requests. The packet round trips created by TCP/TLS handshakes do not count as multiple requests. This explainer feels wrong from a technical perspective already .
Then there is the fact that the text columns are incredibly thin with heavy vertical separation, there's an incredible waste of horizontal and vertical space to the point where you hardly get to read anything at all. You can divide the screen into 9 rectangles and only one of those is used. 90% of the screen is empty.
It also keeps jumping from single column, to double column to single double column (yes) and left bound text.
Not only does it not hook me, I'm having a hard time believing that the creator of this actually looked at the output or iterated on it at all.
[dead]
> 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."
I learned three thresholds over the years. Well, one of them decades ago and the others recently. Basically:
At 50ms, you notice.
At 400ms, you care.
At 2000ms, without output, you wonder if it crashed. (That was the old one.)
In the audio/synth world, the lower bound is 8ms, as in, anything above this can become bothersome to the musician. I've heard it stated that this is also the threshold for fighter pilot control systems providing feedback.
> At 2000ms, without output, you wonder if it crashed. (That was the old one.)
That must have been a really, really long time ago indeed, because there are very few websites now that take less than 2000ms to load. The linked site didn’t even come close on my phone (probably 3-4 seconds), and I most certainly didn’t wonder whether it had crashed.
The timing refers to feeling like the device acknowledged your request with some response.
Not seeing the final completion of the request.
Your phone probably showed something after you clicked the link but before the page rendered: Link highlight change, a progress bar, etc.
If your phone had crashed and the browser was non-responsive, you would have recognized it quickly. More quickly than the page load time.
Yes, exactly what I meant. (FWIW, the original context was J2ME mobile games. It was important to use as few classes as possible to keep JAR size down; but in my testing, everything put into the entry-point class had to be loaded before the program would get past an initial black screen.)
I dunno man, i am In China.. everything outside of it takes at least 2000-5000 ms to even start responding on a good day
That is your government trying to block you
I'm finding more and more web sites that won't load at all until I request them a second time.
maybe the site's debouncing logic on the buttons isn't working well
GitHub
[dead]
Indeed. But there are also delays that cause good feelings.
I still remember the POS in my previous employers cafeteria. It had something like 100-200ms delay in processing a contactless payment card. It felt like an order of magnitude faster than any grocery store (exact same POS device). It was always very satisfying to pay for lunch. By the time you brought the card to the reader it felt like it was already printing the receipt.
I always wonder how it was so fast and if it was just some random dev optimising some obscure edge case.
In South Africa I notice this difference all the time where the big supermarket chains seem to be near instantaneous while small stores are 10+ seconds.
I'm certain it's because the big store's card machines have a wired network connection to a router with a fibre connection, while most smaller shops just use card machines with integrated GPRS wireless modems as they even show feedback about connecting as you tap your card.
A stall vendor who I use somewhat regularly warned me one time that her card machine was down (I guess some kind of maintenance as it was earlyish on a Sunday morning) so would only be able to accept cash. I helped her put the card machine on a nearby shop's free WiFi and not only did it work around the problem, but it made card transactions going forward significantly faster.
May be your cafeteria was doing offline processing, while other were doing it online?
But even offline there are huge differences, say Visa / Mastercard EMV and Suicia's Felica in Japan, where the whole transaction finish in 150ms.
There were previously some work where they try to get it down to 50ms, I don't know if they are still working on it or has abandoned it.
I was expecting the site it’s talking about to have faked an instant response. Ironically, sometimes it goes the other way and UIs have to fake a small delay otherwise the user won’t believe it’s actually done anything (although arguably the real issue there is lack of positive feedback, not response time.)
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
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?
I’ve definitely had in the UX side a situation where the PM/Owner types asked me to introduce a delay in the “disabled button with loading spinner” such that the user sees it for a visible amount of time because our API was too fast for their taste.
Yes similar here, async operation that could be quick enough not to warrant a busy state, but not all the time. So rather than show a flash of busy state, that makes the ui look janky when the operation is quick, show the busy state for a minimum amount of time
For one of the supermarket chains I frequent, from me handing over the single item I'm purchasing I can be walking away within 20s. They scan the item, then a loyalty barcode on my phone and finally I tap my iPhone which has my bank card loaded onto it.
Basically, they don't have any significant bottlenecks, POS hardware + software is responsive with an efficient UI for the operator, and the card machine is a wired connection to a router with a fibre uplink.
IIRC TurboTax has a bunch of loaders / spinners like this, similar idea.
reticulating spines...
kicking llama's ass...
I don’t think a visa transaction can go faster than about a half second so definitely something off there.
Same, I call it the perception of work.
I remember prior de AI era, it was a common pattern to for some delay in the answers to make it feel more "human"
It only inserts a sku and a quantity into a Postgres database - yeah, there’s a few things missing from this purchase scenario.
Might have been better to have made it clicking a ‘like’ button.
With the speed of modern internet connections, I'd honestly think something were wrong if it took a couple of seconds. I'd expect almost instantaneous results. What amazes me every time is the amount of things happening in that short amount of time though. The amount of endpoints/channels the signal has to go through to go from "I want to buy this" to "You bought it!".
I agree that purchases on e-commerce sites are virtually never this fast; but I have used some extremely fast physical payment terminals (e.g., Square): sometimes it seems like the transaction is sub 300ms, which I find very impressive given the complexity of payment processing.
Your comment reminded me of when Google introduced "Instant Search" in 2010. Here's an old HN thread from the launch: https://news.ycombinator.com/item?id=1672391
That was terrible, I used to always turn it off. It's like speaking one word and the person interrupting you based on the prefix you had uttered so far... every single darn word. Imagine writing "how do I kill" and having it assume you meant a living being rather than a program.
No-one mourned when that one went to the Google Graveyard.
I think it was a poor choice of example, because people will expect payment to be involved. They’re actually just inserting a row into a database for the order; presumably payment is to be handled out-of-band.
[dead]
>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.
1ms latency is too much for RTOS, from ISR to the app code should be less than 1ms
but bloated OS ? i have no idea
You're right the kernel might be able to handle that pretty quickly, but I know from experience even good, ~200Hz sampling captouch system is 1/200 = 5ms worst case, 2.5ms avg. That's already 2.5-5x the budget and we haven't gotten off the display.
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!
You are not jealous. You are envious.
Homer explains it best https://youtu.be/Tmx1jpqv3RA
Lisa's dictionary is different from widely-used real dictionaries. Here's what Merriam-Webster says[1]:
[1] https://www.merriam-webster.com/dictionary/enviousI can always rely on hacker news to improve my English
thanks for posting this, I just shared this with everyone in the room here and nobody knew the difference.
Not really, jealous is defined as envious (being envious is one of the definitions of being jealous).
For common usage they are equivalent, e.g. I'm jealous of X is the same as I'm envious of X.
They may be equivalent in common parlance, but that’s a bit like saying it is ok to use ‘your’ instead of “you’re” just because it is so common.
We say “jealously guarded’ not ‘enviously guarded’ for a reason. Jealousy is about being protective of your own possessions and relationships; you feel jealousy if your spouse responds well to a coworker’s flirtations. Envy is when you find think of the coworker’s luck in having a good looking spouse
https://www.merriam-webster.com/dictionary/jealous
1: hostile toward a rival or one believed to enjoy an advantage : envious
>His success made his old friends jealous.
>They were jealous of his success.
I rest my case.
If you check "jealousy" (instead of "jealous") on MW, you get this editorial note:
Depending on who you ask, jealousy and envy are either exact synonyms, totally different words, or near-synonyms with some degree of semantic overlap and some differences. It is difficult to make the case, based on the evidence of usage that we have, for either of the first two possibilities. Both jealousy and envy are often used to indicate that a person is covetous of something that someone else has, but jealousy carries the particular sense of “zealous vigilance” and tends to be applied more exclusively to feelings of protectiveness regarding one’s own advantages or attachments. In the domain of romance, it is more commonly found than envy. If you were to say “your salt-shaker collection fills me with jealousy,” most people would take it to mean much the same thing as “your salt-shaker collection fills me with envy.” But if someone made a flirtatious comment to your partner, you would likely say that it caused you jealousy, not envy.
https://www.merriam-webster.com/dictionary/jealousy
While I also enjoyed it very much, some thing are strangely ordered and not how I would expect someone with such knowledge of all the moving parts in a request, would build such a site. So for me it feels like an LLM has build it and the human with the prompt saw it and said "eh, good enough".
Agreed. This reeks LLM writing with no human oversight, or at least a human with no writing experience. The text underneath “The Click” is an immediate giveaway:
> Five milliseconds of hardware and browser bookkeeping before a single byte leaves the laptop.
I don’t even know how to describe it, but the “[…] before X” sentence style stands out to me.
I once asked a question like this for an interview. "Tell me what happens when you press the Buy button on a web site". It really helped me gauge a sense for the person's interests and expertise. Like some folks just talked about javascript and some node code. Others talked about tcp a bit, some got into cloud stuff. It was really telling. Not bad or good, just a great way to learn where someone's head is at and was a fun back-and-forth conversation.
This web site is basically a cheat code for that question lol. So well done, kudos to the author. Bookmarked and shared
> 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.
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.
chrome can detect my 1000hz polling mouse, but i bet there must be a buffer somewhere.
recent chrome versions actually throttle these reports down to 60hz max, checked this on several systems and mice
I see, but the path from hardware to userspace app should remain unchange, right ?
> "The internet"
Classic software engineer perspective.
I have good friends who build their entire career between "ISP" and "Load Balancer"
I'm surprised at all the "200ms is slow" comments. I make many purchases online, don't we all? I can't remember the last time one took sub 1000ms; they usually take several. What are some of the websites you purchase from that truly complete a purchase in sub-200ms?
Fine, but what is the journey of the p99.9 900ms request?
Also see this classic:
https://github.com/alex/what-happens-when
"What happens when you type google.com into your browser's address box and press enter?"
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.
Great website! Seems like the web version of this book (which is highly recommended btw): https://www.goodreads.com/book/show/17985198-high-performanc...
> Its addresses are MAC addresses, serial numbers burned into each card at the factory.
oof
Nice idea, but execution could be better - way too many factual errors. Actually, considering it appears to be just 100% ai slop it's a little bit shocking how many just plain wrong statements it put out. Almost every section is at least a little bit off...
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.
I’ve always wanted a version of this sort of a timeline that really lets you zoom out and in to the fractal complexity of it all. Right at the end we’re talking about updating the DOM and rendering… there’s a whole Unicode and font stack and rasterization process happening in there.
I still like this question because of exactly what you mentioned. What the interviewee does and does not mention can give you a fair bit of insight into their priors.
I once got that question, started with the keyboard switches and the interrupts, and the interviewer sighed and asked me to get to the stuff in the browser.
So why does it take 5-10 seconds from card presented to accepted at Starbucks and CVS?
Usually the dominant time is from POS to acceptor. These are frequently still on high latency links.
Also a lot of times in person payment flows allow a lot more in their latency budget because it won’t impact the sale, you won’t walk out because of a second here or there, unlike online.
So systems aren’t as optimized, they route to older systems, marketing or further risk checks are added, and a broader range of accepted services that have higher latency (ent/snap processors and the like).
This scenario does not include payment. Would be much more interesting if it did.
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.
Why would no local cache on a laptop hold the IP address for the api endpoint if it's already open in the browser and being posted to?
I hate this. The style of LLM-written prose is unbearable, and I found several mistakes. This is "dazzle them with bullshit details" with no understanding behind it.
I assume the book this post is marketing is also AI slop too and I lost respect for its author.
If it was 200ms, then it had already charged the card...
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.
You actually should not, usual (non-gaming) mice still do the same (most touchpads in cheap laptops even slower, they share already slow i2c bus with several other endpoints), and the article ignores drivers and the UI stack altogether.
The website is barely readable on my shitty screen.
I don’t know how much a human was involved in making this, but clearly not enough. Some parts of the timing it’s talking about make no sense, the ordering of some parts is incoherent, and it promptly goes into unreasonable and irrelevant detail while completely missing other actually relevant aspects of that detail. For example, “HSTS preload”: it’s utterly irrelevant, because you already know it’s HTTPS; and even if it were HTTP, you should talk about HSTS, the preload list is effectively just a prefilled cache; it then adds more to that cache as you visit sites that have HSTS headers.
I’m very confident that if I looked further I’d find it riddled with errors. I just skimmed it and looked at a couple of the bits I’m most familiar with and immediately found notable errors.
I looked at the beginning and it is already wrong. It talks about multiple requests and when you go all the way to the end, it suddenly talks about a single request.
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.
The US is so big, that 50 ms is physically not possible for everyone. This is something that not everybody is aware of. When I as a German build something for germans, everyone who needs to wait longer than 100 ms for a request, is rightfully mad. But when I want to serve the same stuff to americans at the same speed, I have to build something completely different and much more complex.
Not for everyone, but most people are located in population centers with nearby PoPs.
Yeah, but you would need to run an API server in each of those to reach that latency, and even then you're well into eventually-consistent distributed system headache if you accept the POST without synchronising with all the others first.
You terminate SSL (err, TLS) at the pop so the clients TCP connection gets setup faster, and then you use a hot TCP connection from the pop to a centralized API server. That gets you not having to deal with the headache of running a distributed system but a better experience for the client.
And you still have to send your light pulses through a fiber over thousands of kilometers, so 50ms is still physically impossible.
If you want 50ms then you're gonna have to do the distributed systems headache that rcxdude was trying to avoid. For everything smaller than Google, that's too expensive, but it can be done.
> When I as a German build something for germans, everyone who needs to wait longer than 100 ms for a request, is rightfully mad.
Somewhat ironic, given how many contracts here seem to come with 3 months notice periods.
“On the wire, each label is stored with its length in front, 3 api 11 thenodebook 3 com 0, and the final 0 marks the end of the name, where the last dot would go.”
Am I the only one that doesn’t think of this as ‘api.thenodebook.com.’? What does the LLM mean by the zero after .com marking where the last dot would go?
The last '.' is essentially the equivalent of the first '/' in a file path: it refers to the root of the DNS and marks it as an absolute name (otherwise, in principle, it could be treated as relative even though it usually is not outside of the DNS machinery).
The CSS animation of the encrypted message overwriting the plain is utterly cool.
[flagged]
[flagged]
[dead]
[dead]
200 ms is very slow.