10 ms·

The 64 Milliseconds Manifesto

65 points by anderspitman 7y ago

dx7tnt 7y ago
I'm pretty sure that site took longer than 64ms to render on my phone.
stephen82 7y ago
...and on my browser [Firefox ESR 60.8.0esr (64-bit)] it takes 241ms to load this plain HTML website.
- mempko 7y ago
  clearly, browsers fail. have you tried lynx?
- noir_lord 7y ago
  Markup is invalid as well. I thought it was a presentation or something and I needed to use arrows to navigate it..turns out. Well not really sure what the point of the thing is tbh.
- joe_hoyle 7y ago
  This website isn't an interactive software application though!
- kzrdude 7y ago
  It's loading favicon.ico, which redirects to favicon.ico/ which returns some kind of html page (larger than the / page itself!), so that seems misconfigured.
- stefan_ 7y ago
  You also see the background flash as it "renders". The whole website concept is just rotten and dead if you want to even get close to as smooth as Doom in 1995 on computers with less computing power than a shader processor in my mobile phone. Cue the discussion on "speed of light" in this thread while people applaud getting your website to display in under a second.
- dahart 7y ago
  How long does it take Firefox to show you a loading spinner & new tab?
- smadge 7y ago
  PageSpeed Insights says it is .2 seconds time to interactive on desktop and .8 on mobile.
kzrdude 7y ago
For reference that's about this much: 16 ms → 62 Hz 32 ms → 31 Hz 64 ms → 16 Hz.
deleted 7y ago
[deleted]
yummypaint 7y ago
Meanwhile major news sites take 45 seconds to load content randomly accross the page so the text jumps around and is unreadable.
- adrianmonk 7y ago
  I kind of want web browsers to give a budget of layout changes. Once a page does enough things to exceed the budget, too bad, your layout is stuck there. If the user does something interactive to warrant further layout changes, then you're allowed to start changing things again. The idea is to make it cost something to change the layout. Then people will have to actually try not to do it excessively.
  - yummypaint 7y ago
    On many sites the layout isnt even relevant, and all people actually want is to read the plaintext and locate any relevant images amongst the chaos. Im wondering about a browser extension or something that extracts this information directly and re-renders it in simple (like year 2000 era) html. I would kill for this on my phone.
mattmar96 7y ago
Meh.. sure. Any reason behind these specific figures?
- apetresc 7y ago
  They're powers of 2, so clearly they are significant for deep technical reasons.
- theandrewbailey 7y ago
  16.666...ms (aka 16ms) is 1 complete cycle at 60Hz, the frequency most computer displays operate at. 32ms and 64ms are approximately 2 and 4 cycles respectively.
ksec 7y ago
>In an interactive software application, any user action SHOULD result in a noticeable change within 16ms In many cases the Input Lag ( Especially Touch Screen ) in itself is more than 16ms. That is excluding the processing from CPU to GPU rendering and your Display Lag.
- mrob 7y ago
  Apple IIe managed 30ms total[0]. There's no reason why modern computers, which are thousands of times faster, shouldn't manage 16ms. The slow response of modern systems is the result of a deliberate choice to prioritize ease of development over user experience. We can do better. [0] https://danluu.com/input-lag/ https://danluu.com/input-lag/
  - viklove 7y ago
    You speak as if ease-of-development doesn't enhance UX. Of course it does. If a team can ship features and fix bugs faster, the UX does improve. Most would say that's worth it over shaving 15ms off the input lag.
  - nemothekid 7y ago
    The mechanism that gave the Apple IIe such low latency has little to do with processing power - the keyboard had an exotic setup that you likely won't get over something as generic USB.
    - fsh 7y ago
      High end USB peripherals are polled in 1 ms intervals and even the cheapest ones every 8 ms at most.
    - Dylan16807 7y ago
      Exotic how? Just being 533Hz isn't; you can get very cheap chips that are capable of polling the keys at 1000Hz or higher. If you really want to minimize latency on a modern system, and can choose whatever commodity hardware you want, you can get the input+rendering+scanout delay below 10ms. At that point it's a matter of how often your screen accepts new frames. And with a high-end, frame wait plus pixel response time can also be under 10ms. 20ms for local end-to-end latency is a completely achievable goal. https://www.blurbusters.com/gsync/gsync101-input-lag-tests-and-settings/3/ https://www.blurbusters.com/gsync/gsync101-input-lag-tests-a... Their best combo here achieved an end-to-end latency of 12-15ms, on a 200/240Hz screen with counterstrike running at 2000+ fps. At a more mainstream 144Hz to the screen, running the game at 'only' 288Hz, end-to-end latency was 13-19ms. Even at 60Hz they could easily keep the latency below 30ms.
wait-a-minute 7y ago
This manifesto's website takes longer than 64 milliseconds to respond though.
- deleted 7y ago
  [deleted]
ar_lan 7y ago
I enjoy that it gives no rationales. Without reasons/research/sources, these are just arbitrary numbers.
novok 7y ago
As nice as this goal is, I think the RAIL model's benchmarks are a bit more realistic: https://developers.google.com/web/fundamentals/performance/rail#ux https://developers.google.com/web/fundamentals/performance/r...
earthboundkid 7y ago
Too vague, not actionable, no context. More useful: People can often respond to things within a few frames (1/60 second = 16ms). For some interactions, it's useful to respond within one frame. For others, more latency is acceptable. For yet others, sub-frame latency is required (e.g. VR/AR). Light can move ~3,000 miles in that time, which is a hard limit on latency.
kissgyorgy 7y ago
I really like this, even though if it is impossible with today's microservice architectures... A couple of years ago I was thinking about this either and someone suggested a study defined 0.1, 1 and 10 seconds as limits: https://stackoverflow.com/questions/17138585/what-is-the-maximum-time-a-web-application-or-website-should-respond-to-a-requ https://stackoverflow.com/questions/17138585/what-is-the-max...
- feifan 7y ago
  The interface isn't necessarily related to backend services (i.e. you don't need backend services to drive every change in the interface)
juancn 7y ago
It's impossible. Lightspeed doesn't allow for that on websites if you're far enough from the servers. If you add intermediate network gear, it's hard enough to get across half the globe in under 180ms (I'know, I live in Argentina and that's my ping time to almost anywhere non local). You could fake it somehow in some scenarios or with an awful lot of money.
- mrob 7y ago
  Speculatively make and cache likely requests. Predict server responses client-side, and update with the server response if it differs. Multiplayer games have been hiding latency since QuakeWorld.
  - littlestymaar 7y ago
    Have you ever tried playing a competitive game with above 300ms ping?
    - mrob 7y ago
      Yes, and it doesn't work well. But 300ms ping is unusually high. I'm 141ms from HN's server, and that's in a different continent from me. Google is only 10ms. 141ms is playable with good client-side prediction.
      - littlestymaar 7y ago
        > But 300ms ping is unusually high It's not that high if you live in a rural area (And I'm not even talking about a third world country, I live in France). Most of the time, the main culprit is Bufferbloat[1]. I'm currently playing World of Warcraft with 250ms of ping, and even for solo level up it's annoying. League of Legends with 350ms isn't fun at all… [1] https://en.wikipedia.org/wiki/Bufferbloat https://en.wikipedia.org/wiki/Bufferbloat
        Dylan16807 7y ago
        Buffer bloat is an example of what this manifesto is motivated by. The hardware's capable of being much faster, and has been set up wrong. A game dev can't fix it, but it should not be taken as a ground truth of the world. It needs to be fixed. Combine that with a smaller amount of prediction, and things come out pretty well.
Dylan16807 7y ago
If I'm going to have a full screen of content after 64ms, why do I care about having something incomplete but 'actionable' after 32ms? And the policy of showing some feedback before then is useful in some circumstances but not very important in others. The 64ms goal by itself is clearer and more useful than this combo of three goals.
spullara 7y ago
It takes 250ms to curl this website. Ping time to the site is less than 64ms though and it is cached by Cloudflare and still can't seem to serve it that fast. Maybe HTTPS can't get under 250ms or so? Only way for me to get under 250ms is to use HTTP...
- toast0 7y ago
  Depending on how your environment is configured... Curl will do one round trip to your resolv.conf configured resolver Then you have one round trip for tcp. Then another for TLS hello (presuming TLS 1.3 or false-start) Then one last round trip for HTTP. Assuming cached DNS, you need a ping to the server of about 21ms to get content via https in 64ms. And that's assuming you can get enough content for a screens worth in the initial congestion window (10ish packets, so let's say 15kb). Good luck! Oh, and my DSL connection adds at least 20ms to the path, and that's not unusual.
  - PeterisP 7y ago
    HTTPS requires a bunch of redundant roundtrips. We need adoption of QUIC/HTTP3 to reduce that.
sarah180 7y ago
Is this an example of the kind of reactive, interactive design you're advocating? I don't see how this is helpful: it's dogmatic and doesn't address the actual tradeoffs that might be at play. Why 64 ms? And 32 and 16? What studies are you relying on to suggest that 65 ms is too slow or that 30 ms is too slow for initial feedback? How does it affect user behavior? What is advised when these rules, especially the "full screen of content" cannot be met because of things like external dependencies out of the site's control?
- loup-vaillant 7y ago
  60 frames per second. - 16ms: one frame - 32ms: two frames - 64ms: four frames So it's really 1, 2, 4. Maybe we could have 1, 2, 3, but I'm guessing the "48ms Manifesto" wouldn't sound too great: they probably preferred to have a nice power of two. And if I may, I think the manifesto is basically right. Something I have to wait several frames for before it reacts feels sluggish. When I type a character, I want it now, not 5 frames later. When I move the mouse, I want it in sync, not lagging behind my hand. Touch screens are even more exacting. They only feel perfect when latency falls under one millisecond. But that last one isn't achievable in practice on current stock hardware…
  - userulluipeste 7y ago
    Well then... why 60 frames per second? This isn't obvious to me and I presume to others using today's tech too.
    - dvdkon 7y ago
      Because most displays today run at 60Hz. It's a nice metric, as it provides a useful coarseness for measuring response times.
- dahart 7y ago
  Yeah it's simplistic and doesn't explain the rationale, but having studied human perception a bit, I know without further explanation that this is targeting the time frames of our human ability to see change. The numbers here are similar to the reasons most movies are 24fps. > What is advised when these rules, especially the "full screen of content" cannot be met because of things like external dependencies out of the site's control? This is missing the point, and many people here seem to be attempting to pick the same nit. You never have to wait for external dependencies to show changes on screen. This is how browsers and well designed high traffic websites like YouTube already operate. When you take action, you are shown UI changes on-screen that indicate the action is in progress. The manifesto is saying to acknowledge the user action so the user knows the application received the request. It is not saying everything in the world needs to be done in 64ms. Applications can always acknowledge the request immediately, and yet some still don't.
wbhart 7y ago
They missed the remaining portion of the manifesto: * Websites making controversial claims should state clearly the claim in the first paragraph * Controversial claims should be backed up by at least a summary of a well reasoned argument within the first 5 paragraphs. * Controversial claims should be backed up by citing sources.
- loup-vaillant 7y ago
  Controversial? Really? What's written there is basically what's required for interactive speed. What's described here is basically what's required for interaction to feel instantaneous. Why should we settle for anything but immediacy? Sure, with all those laggy applications we have right now, we tend to become desensitised. That's not an excuse, though. Also note that in some cases, we're not even close to acceptable latency. Finger tracking on touch screens for instance, require a one millisecond response time to feel perfect. Otherwise the objects we drag will lag behind our fingers.
greencore 7y ago
People must learn some patience instead of wasting our time and talent on optimizing stuff for those milliseconds.
- AnIdiotOnTheNet 7y ago
  Ah yes, ye olde "my time as a developer is worth more than that of mere users". That kind of thinking is the reason modern computing sucks so bad.
dangus 7y ago
The most popular website in the world, known for incredible speed, google.com, took me 197 ms to load, with 139ms spent waiting. A search for "hacker news" took 186 ms, with 111 ms spent waiting. 64.ms itself takes 3 ms for DNS lookup, 39 ms for the initial connection, and 29 ms for the SSL - total of 71 ms before any content download happens. I'm on 802.11 AC WiFi seated about 5 feet from my router. Apparently, users are quite willing to wait longer than 64 milliseconds. I'm no web developer, so I don't claim to have expertise, but it really does seem like an unreasonable expectation. As soon as you have any sort of complex functionality the idea falls apart: "Wait for the credit card payment to process" "Download a high resolution image" (that counts as a page of content right?) "Start watching this 4K video" "Download a CSV of your 100,000 row data set"
- juped 7y ago
  Google hasn't had incredible speed for many years, now. That reputation is woefully out of date.
- dahart 7y ago
  There are about 20 different things that happen on screen while google.com is loading in my Chrome browser, starting within 16ms.
  - dangus 7y ago
    But when can I interact with it? To be honest, I have no way of knowing or testing, because ~180 ms is already faster than I can see or react to. 64.ms itself takes 3 ms for DNS lookup, 39 ms for the initial connection, and 29 ms for the SSL - total of 71 ms before any content download happens. Then my browser waits for 250ms (slower than Google).
    - dahart 7y ago
      You can interact with it immediately. You can hit the X to cancel the page load, you can close the tab, you can quit the browser or use another tab. Browser devs already adhere notoriously and fiercely to the ideas in the manifesto. Whether the app/site you requested can be interacted with depends on whether the app/site devs care about interaction latency. Talking about network response times is irrelevant to the point here. Clients can, and do, make changes on-screen before the network response.
deleted 7y ago
[deleted]
korethr 7y ago
By the numbers it sounds like this is built around an assumption of 60fps. The rounding is wrong, but let's roll with it. That's a noticeable change by the next frame, actionable information two frames thereafter, and a full screen worth of content four frames thereafter. My intuition says that's steep. Noticeable change 1 frame later might be doable with a web app, if the app is structured well and focuses on fast response times. However, I don't think actionable information two frames later, or a full screen of content four frames later is feasible for a network-based application, especially given the fact that just crossing local layer 3 network segments can add 10s of ms to your latency, depending on the router's load. Really, these numbers strike me as only achievable by an application where all data and processing is done locally on the computer that controls the display. Even then, these target numbers still feel steep.
- ekimekim 7y ago
  In a networked app where your latency is too high for these figures, or if you need to do some large number crunching etc, you should instead focus on giving the user feedback that progress is occurring. A progress bar, a spinning ball, etc are far better than nothing. Just as long as you acknowledge that the user has requested an action, and give the user confidence the action is proceeding.
  - korethr 7y ago
    That, I don't disagree with at all. There's been more than one time I've clicked on something, and then waited for the computer to do something that lets me know it's received my command and acted on it. It can be damn frustrating.
AndriyKunitsyn 7y ago
Too vague. Isn't moving caret in a text field "any user action"? Then why should it invoke a full screen of content?
loup-vaillant 7y ago
Half the comments here seem to assume this manifesto is about web sites. Can I remind everyone that many applications run locally?
- CSSer 7y ago
  They do? The web is the future!
aidenn0 7y ago
I just want at least a filler response within ~150ms when I tap a button on my phone. Occasionally I will miss a touch target. If I haven't seen a response, I will assume I missed the touch target.
devadvance 7y ago
It seems as though relying on something a bit more verbose, such as the guidance from Nielsen Norman Group [1], might be more effective in helping people building software. In particular: > 0.1 second is about the limit for having the user feel that the system is reacting instantaneously, meaning that no special feedback is necessary except to display the result. [1] https://www.nngroup.com/articles/response-times-3-important-limits/ https://www.nngroup.com/articles/response-times-3-important-...
ghostbust555 7y ago
64ms? Without any context or reasoning? Wrong all ui should load in 100ns and anyone who disagrees is an idiot.
arch-ninja 7y ago
I love this. Software developers too often focus on the final end state and this distracts from the state changes in the middle of any process. By focusing on UI responsiveness you vastly improve discoverability and interoperability because it naturally decouples the problem into a model/view/controller design. Best of all you can't mis-design: the responsiveness is your constraint, and if the design doesn't give you responsiveness you KNOW it is a poor design. This is the ultimate quality litmus test.
ninthcat 7y ago
https://webpagetest.org/result/190924_7C_b9373b51a084f69f1bc50f5f7f9c2679/1/details/#waterfall_view_step1 https://webpagetest.org/result/190924_7C_b9373b51a084f69f1bc...
jenkstom 7y ago
The fastest I can view and respond to information is maybe 2 times per second if I'm not really viewing anything. So I'd say 512ms makes more sense or maybe 256ms if you want it to "feel" snappier (assuming we are sticking to powers of 2 for some reason). Any higher is looking more for animation speed than usability speed.
dang 3y ago
The URL was originally https://64.ms/ https://64.ms/ but it no longer works, so we've changed to one that does (by the submitter's request).

65 points by anderspitman 7y ago

dx7tnt 7y ago

I'm pretty sure that site took longer than 64ms to render on my phone.

stephen82 7y ago

...and on my browser [Firefox ESR 60.8.0esr (64-bit)] it takes 241ms to load this plain HTML website.

mempko 7y ago
clearly, browsers fail. have you tried lynx?
noir_lord 7y ago
Markup is invalid as well. I thought it was a presentation or something and I needed to use arrows to navigate it..turns out. Well not really sure what the point of the thing is tbh.
joe_hoyle 7y ago
This website isn't an interactive software application though!
kzrdude 7y ago
It's loading favicon.ico, which redirects to favicon.ico/ which returns some kind of html page (larger than the / page itself!), so that seems misconfigured.
stefan_ 7y ago
You also see the background flash as it "renders". The whole website concept is just rotten and dead if you want to even get close to as smooth as Doom in 1995 on computers with less computing power than a shader processor in my mobile phone. Cue the discussion on "speed of light" in this thread while people applaud getting your website to display in under a second.
dahart 7y ago
How long does it take Firefox to show you a loading spinner & new tab?
smadge 7y ago
PageSpeed Insights says it is .2 seconds time to interactive on desktop and .8 on mobile.

kzrdude 7y ago

For reference that's about this much: 16 ms → 62 Hz 32 ms → 31 Hz 64 ms → 16 Hz.

deleted 7y ago

[deleted]

yummypaint 7y ago

Meanwhile major news sites take 45 seconds to load content randomly accross the page so the text jumps around and is unreadable.

adrianmonk 7y ago
I kind of want web browsers to give a budget of layout changes. Once a page does enough things to exceed the budget, too bad, your layout is stuck there. If the user does something interactive to warrant further layout changes, then you're allowed to start changing things again. The idea is to make it cost something to change the layout. Then people will have to actually try not to do it excessively.
- yummypaint 7y ago
  On many sites the layout isnt even relevant, and all people actually want is to read the plaintext and locate any relevant images amongst the chaos. Im wondering about a browser extension or something that extracts this information directly and re-renders it in simple (like year 2000 era) html. I would kill for this on my phone.

mattmar96 7y ago

Meh.. sure. Any reason behind these specific figures?

apetresc 7y ago
They're powers of 2, so clearly they are significant for deep technical reasons.
theandrewbailey 7y ago
16.666...ms (aka 16ms) is 1 complete cycle at 60Hz, the frequency most computer displays operate at. 32ms and 64ms are approximately 2 and 4 cycles respectively.

ksec 7y ago

>In an interactive software application, any user action SHOULD result in a noticeable change within 16ms In many cases the Input Lag ( Especially Touch Screen ) in itself is more than 16ms. That is excluding the processing from CPU to GPU rendering and your Display Lag.

mrob 7y ago
Apple IIe managed 30ms total[0]. There's no reason why modern computers, which are thousands of times faster, shouldn't manage 16ms. The slow response of modern systems is the result of a deliberate choice to prioritize ease of development over user experience. We can do better. [0] https://danluu.com/input-lag/ https://danluu.com/input-lag/
- viklove 7y ago
  You speak as if ease-of-development doesn't enhance UX. Of course it does. If a team can ship features and fix bugs faster, the UX does improve. Most would say that's worth it over shaving 15ms off the input lag.
- nemothekid 7y ago
  The mechanism that gave the Apple IIe such low latency has little to do with processing power - the keyboard had an exotic setup that you likely won't get over something as generic USB.
  - fsh 7y ago
    High end USB peripherals are polled in 1 ms intervals and even the cheapest ones every 8 ms at most.
  - Dylan16807 7y ago
    Exotic how? Just being 533Hz isn't; you can get very cheap chips that are capable of polling the keys at 1000Hz or higher. If you really want to minimize latency on a modern system, and can choose whatever commodity hardware you want, you can get the input+rendering+scanout delay below 10ms. At that point it's a matter of how often your screen accepts new frames. And with a high-end, frame wait plus pixel response time can also be under 10ms. 20ms for local end-to-end latency is a completely achievable goal. https://www.blurbusters.com/gsync/gsync101-input-lag-tests-and-settings/3/ https://www.blurbusters.com/gsync/gsync101-input-lag-tests-a... Their best combo here achieved an end-to-end latency of 12-15ms, on a 200/240Hz screen with counterstrike running at 2000+ fps. At a more mainstream 144Hz to the screen, running the game at 'only' 288Hz, end-to-end latency was 13-19ms. Even at 60Hz they could easily keep the latency below 30ms.

wait-a-minute 7y ago

This manifesto's website takes longer than 64 milliseconds to respond though.

deleted 7y ago
[deleted]

ar_lan 7y ago

I enjoy that it gives no rationales. Without reasons/research/sources, these are just arbitrary numbers.

novok 7y ago

As nice as this goal is, I think the RAIL model's benchmarks are a bit more realistic: https://developers.google.com/web/fundamentals/performance/rail#ux https://developers.google.com/web/fundamentals/performance/r...

earthboundkid 7y ago

Too vague, not actionable, no context. More useful: People can often respond to things within a few frames (1/60 second = 16ms). For some interactions, it's useful to respond within one frame. For others, more latency is acceptable. For yet others, sub-frame latency is required (e.g. VR/AR). Light can move ~3,000 miles in that time, which is a hard limit on latency.

kissgyorgy 7y ago

I really like this, even though if it is impossible with today's microservice architectures... A couple of years ago I was thinking about this either and someone suggested a study defined 0.1, 1 and 10 seconds as limits: https://stackoverflow.com/questions/17138585/what-is-the-maximum-time-a-web-application-or-website-should-respond-to-a-requ https://stackoverflow.com/questions/17138585/what-is-the-max...

feifan 7y ago
The interface isn't necessarily related to backend services (i.e. you don't need backend services to drive every change in the interface)

juancn 7y ago

It's impossible. Lightspeed doesn't allow for that on websites if you're far enough from the servers. If you add intermediate network gear, it's hard enough to get across half the globe in under 180ms (I'know, I live in Argentina and that's my ping time to almost anywhere non local). You could fake it somehow in some scenarios or with an awful lot of money.

mrob 7y ago
Speculatively make and cache likely requests. Predict server responses client-side, and update with the server response if it differs. Multiplayer games have been hiding latency since QuakeWorld.
- littlestymaar 7y ago
  Have you ever tried playing a competitive game with above 300ms ping?
  - mrob 7y ago
    Yes, and it doesn't work well. But 300ms ping is unusually high. I'm 141ms from HN's server, and that's in a different continent from me. Google is only 10ms. 141ms is playable with good client-side prediction.
    - littlestymaar 7y ago
      > But 300ms ping is unusually high It's not that high if you live in a rural area (And I'm not even talking about a third world country, I live in France). Most of the time, the main culprit is Bufferbloat[1]. I'm currently playing World of Warcraft with 250ms of ping, and even for solo level up it's annoying. League of Legends with 350ms isn't fun at all… [1] https://en.wikipedia.org/wiki/Bufferbloat https://en.wikipedia.org/wiki/Bufferbloat
      - Dylan16807 7y ago
        Buffer bloat is an example of what this manifesto is motivated by. The hardware's capable of being much faster, and has been set up wrong. A game dev can't fix it, but it should not be taken as a ground truth of the world. It needs to be fixed. Combine that with a smaller amount of prediction, and things come out pretty well.

Dylan16807 7y ago

If I'm going to have a full screen of content after 64ms, why do I care about having something incomplete but 'actionable' after 32ms? And the policy of showing some feedback before then is useful in some circumstances but not very important in others. The 64ms goal by itself is clearer and more useful than this combo of three goals.

spullara 7y ago

It takes 250ms to curl this website. Ping time to the site is less than 64ms though and it is cached by Cloudflare and still can't seem to serve it that fast. Maybe HTTPS can't get under 250ms or so? Only way for me to get under 250ms is to use HTTP...

toast0 7y ago
Depending on how your environment is configured... Curl will do one round trip to your resolv.conf configured resolver Then you have one round trip for tcp. Then another for TLS hello (presuming TLS 1.3 or false-start) Then one last round trip for HTTP. Assuming cached DNS, you need a ping to the server of about 21ms to get content via https in 64ms. And that's assuming you can get enough content for a screens worth in the initial congestion window (10ish packets, so let's say 15kb). Good luck! Oh, and my DSL connection adds at least 20ms to the path, and that's not unusual.
- PeterisP 7y ago
  HTTPS requires a bunch of redundant roundtrips. We need adoption of QUIC/HTTP3 to reduce that.

sarah180 7y ago

Is this an example of the kind of reactive, interactive design you're advocating? I don't see how this is helpful: it's dogmatic and doesn't address the actual tradeoffs that might be at play. Why 64 ms? And 32 and 16? What studies are you relying on to suggest that 65 ms is too slow or that 30 ms is too slow for initial feedback? How does it affect user behavior? What is advised when these rules, especially the "full screen of content" cannot be met because of things like external dependencies out of the site's control?

loup-vaillant 7y ago
60 frames per second. - 16ms: one frame - 32ms: two frames - 64ms: four frames So it's really 1, 2, 4. Maybe we could have 1, 2, 3, but I'm guessing the "48ms Manifesto" wouldn't sound too great: they probably preferred to have a nice power of two. And if I may, I think the manifesto is basically right. Something I have to wait several frames for before it reacts feels sluggish. When I type a character, I want it now, not 5 frames later. When I move the mouse, I want it in sync, not lagging behind my hand. Touch screens are even more exacting. They only feel perfect when latency falls under one millisecond. But that last one isn't achievable in practice on current stock hardware…
- userulluipeste 7y ago
  Well then... why 60 frames per second? This isn't obvious to me and I presume to others using today's tech too.
  - dvdkon 7y ago
    Because most displays today run at 60Hz. It's a nice metric, as it provides a useful coarseness for measuring response times.
dahart 7y ago
Yeah it's simplistic and doesn't explain the rationale, but having studied human perception a bit, I know without further explanation that this is targeting the time frames of our human ability to see change. The numbers here are similar to the reasons most movies are 24fps. > What is advised when these rules, especially the "full screen of content" cannot be met because of things like external dependencies out of the site's control? This is missing the point, and many people here seem to be attempting to pick the same nit. You never have to wait for external dependencies to show changes on screen. This is how browsers and well designed high traffic websites like YouTube already operate. When you take action, you are shown UI changes on-screen that indicate the action is in progress. The manifesto is saying to acknowledge the user action so the user knows the application received the request. It is not saying everything in the world needs to be done in 64ms. Applications can always acknowledge the request immediately, and yet some still don't.

wbhart 7y ago

They missed the remaining portion of the manifesto: * Websites making controversial claims should state clearly the claim in the first paragraph * Controversial claims should be backed up by at least a summary of a well reasoned argument within the first 5 paragraphs. * Controversial claims should be backed up by citing sources.

loup-vaillant 7y ago
Controversial? Really? What's written there is basically what's required for interactive speed. What's described here is basically what's required for interaction to feel instantaneous. Why should we settle for anything but immediacy? Sure, with all those laggy applications we have right now, we tend to become desensitised. That's not an excuse, though. Also note that in some cases, we're not even close to acceptable latency. Finger tracking on touch screens for instance, require a one millisecond response time to feel perfect. Otherwise the objects we drag will lag behind our fingers.

greencore 7y ago

People must learn some patience instead of wasting our time and talent on optimizing stuff for those milliseconds.

AnIdiotOnTheNet 7y ago
Ah yes, ye olde "my time as a developer is worth more than that of mere users". That kind of thinking is the reason modern computing sucks so bad.

dangus 7y ago

The most popular website in the world, known for incredible speed, google.com, took me 197 ms to load, with 139ms spent waiting. A search for "hacker news" took 186 ms, with 111 ms spent waiting. 64.ms itself takes 3 ms for DNS lookup, 39 ms for the initial connection, and 29 ms for the SSL - total of 71 ms before any content download happens. I'm on 802.11 AC WiFi seated about 5 feet from my router. Apparently, users are quite willing to wait longer than 64 milliseconds. I'm no web developer, so I don't claim to have expertise, but it really does seem like an unreasonable expectation. As soon as you have any sort of complex functionality the idea falls apart: "Wait for the credit card payment to process" "Download a high resolution image" (that counts as a page of content right?) "Start watching this 4K video" "Download a CSV of your 100,000 row data set"

juped 7y ago
Google hasn't had incredible speed for many years, now. That reputation is woefully out of date.
dahart 7y ago
There are about 20 different things that happen on screen while google.com is loading in my Chrome browser, starting within 16ms.
- dangus 7y ago
  But when can I interact with it? To be honest, I have no way of knowing or testing, because ~180 ms is already faster than I can see or react to. 64.ms itself takes 3 ms for DNS lookup, 39 ms for the initial connection, and 29 ms for the SSL - total of 71 ms before any content download happens. Then my browser waits for 250ms (slower than Google).
  - dahart 7y ago
    You can interact with it immediately. You can hit the X to cancel the page load, you can close the tab, you can quit the browser or use another tab. Browser devs already adhere notoriously and fiercely to the ideas in the manifesto. Whether the app/site you requested can be interacted with depends on whether the app/site devs care about interaction latency. Talking about network response times is irrelevant to the point here. Clients can, and do, make changes on-screen before the network response.

deleted 7y ago

[deleted]

korethr 7y ago

By the numbers it sounds like this is built around an assumption of 60fps. The rounding is wrong, but let's roll with it. That's a noticeable change by the next frame, actionable information two frames thereafter, and a full screen worth of content four frames thereafter. My intuition says that's steep. Noticeable change 1 frame later might be doable with a web app, if the app is structured well and focuses on fast response times. However, I don't think actionable information two frames later, or a full screen of content four frames later is feasible for a network-based application, especially given the fact that just crossing local layer 3 network segments can add 10s of ms to your latency, depending on the router's load. Really, these numbers strike me as only achievable by an application where all data and processing is done locally on the computer that controls the display. Even then, these target numbers still feel steep.

ekimekim 7y ago
In a networked app where your latency is too high for these figures, or if you need to do some large number crunching etc, you should instead focus on giving the user feedback that progress is occurring. A progress bar, a spinning ball, etc are far better than nothing. Just as long as you acknowledge that the user has requested an action, and give the user confidence the action is proceeding.
- korethr 7y ago
  That, I don't disagree with at all. There's been more than one time I've clicked on something, and then waited for the computer to do something that lets me know it's received my command and acted on it. It can be damn frustrating.

AndriyKunitsyn 7y ago

Too vague. Isn't moving caret in a text field "any user action"? Then why should it invoke a full screen of content?

loup-vaillant 7y ago

Half the comments here seem to assume this manifesto is about web sites. Can I remind everyone that many applications run locally?

CSSer 7y ago
They do? The web is the future!

aidenn0 7y ago

I just want at least a filler response within ~150ms when I tap a button on my phone. Occasionally I will miss a touch target. If I haven't seen a response, I will assume I missed the touch target.

devadvance 7y ago

It seems as though relying on something a bit more verbose, such as the guidance from Nielsen Norman Group [1], might be more effective in helping people building software. In particular: > 0.1 second is about the limit for having the user feel that the system is reacting instantaneously, meaning that no special feedback is necessary except to display the result. [1] https://www.nngroup.com/articles/response-times-3-important-limits/ https://www.nngroup.com/articles/response-times-3-important-...

ghostbust555 7y ago

64ms? Without any context or reasoning? Wrong all ui should load in 100ns and anyone who disagrees is an idiot.

arch-ninja 7y ago

I love this. Software developers too often focus on the final end state and this distracts from the state changes in the middle of any process. By focusing on UI responsiveness you vastly improve discoverability and interoperability because it naturally decouples the problem into a model/view/controller design. Best of all you can't mis-design: the responsiveness is your constraint, and if the design doesn't give you responsiveness you KNOW it is a poor design. This is the ultimate quality litmus test.

ninthcat 7y ago

https://webpagetest.org/result/190924_7C_b9373b51a084f69f1bc50f5f7f9c2679/1/details/#waterfall_view_step1 https://webpagetest.org/result/190924_7C_b9373b51a084f69f1bc...

jenkstom 7y ago

The fastest I can view and respond to information is maybe 2 times per second if I'm not really viewing anything. So I'd say 512ms makes more sense or maybe 256ms if you want it to "feel" snappier (assuming we are sticking to powers of 2 for some reason). Any higher is looking more for animation speed than usability speed.

dang 3y ago

The URL was originally https://64.ms/ https://64.ms/ but it no longer works, so we've changed to one that does (by the submitter's request).