200 Milliseconds

(200ms.thenodebook.com)

76 points | by dimitarpanov 2 days ago

9 comments

  • jonahrd 41 minutes ago
    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?
    • antonymoose 2 minutes ago
      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.
    • 1986 1 minute ago
      IIRC TurboTax has a bunch of loaders / spinners like this, similar idea.
    • blue_sauce_bean 20 minutes ago
      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
      • eterm 14 minutes ago
        No-one mourned when that one went to the Google Graveyard.
    • JoeBOFH 32 minutes ago
      Same, I call it the perception of work.
      • dagi3d 28 minutes ago
        I remember prior de AI era, it was a common pattern to for some delay in the answers to make it feel more "human"
  • felooboolooomba 1 hour ago
    > 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."

    • zahlman 1 hour ago
      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.)

      • p-e-w 1 hour ago
        > 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.

        • Aurornis 50 minutes ago
          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.

        • Crunchified 18 minutes ago
          I'm finding more and more web sites that won't load at all until I request them a second time.
        • bloppe 1 hour ago
          GitHub
        • hobonation 50 minutes ago
          [dead]
  • beders 1 hour ago
    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!

    • LeBit 18 minutes ago
      You are not jealous. You are envious.

      Homer explains it best https://youtu.be/Tmx1jpqv3RA

    • ahofmann 43 minutes ago
      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".
      • mimischi 34 minutes ago
        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.

  • inerte 46 minutes ago
    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.
    • Carrok 43 minutes ago
      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.
  • arjie 33 minutes ago
    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.
  • viggio24 1 hour ago
    Wonderful page, congratulations! navigating to the end takes time but the contents and the presentation are great
  • 3dedb728-3f77 1 hour ago
    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.

    • ahofmann 39 minutes ago
      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.
  • eterm 36 minutes ago
    The CSS animation of the encrypted message overwriting the plain is utterly cool.