
The 64 Milliseconds Manifesto - anderspitman
https://64.ms/
======
dangus
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"

~~~
dahart
There are about 20 different things that happen on screen while google.com is
loading in my Chrome browser, starting within 16ms.

~~~
dangus
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
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.

~~~
dangus
For me, neither Google nor 64.ms complete the SSL handshake by 64 ms, so I'm
not sure which content I'm supposed to be interacting with, assuming my body
is physically capable of doing so by that time.

And really, even offline interactive apps have no chance of reacting this
fast.

Try opening TextEdit or Mail - they don't even draw the window frame in 64 ms.

Performance _is_ important but normal users only care about it when it's
getting in the way of functionality. If we chose our preferences by
performance alone, Windows Phone and webOS phones would still be here and
Android would be gone, Microsoft Office would be the least popular office
suite, and Steam would be the least popular PC game store.

~~~
dahart
> And really, even offline interactive apps have no chance of reacting this
> fast.

What do you mean? Lots of games run at 60Hz, and lots of games are considered
unplayable if they render frames slower than 64ms. You might consider your
terminal broken if it took more than 64ms to respond by displaying your input.
[https://danluu.com/term-latency/](https://danluu.com/term-latency/)

> Try opening TextEdit or Mail - they don't even draw the window frame in 64
> ms.

The OS shows you the app is loading. This seems like you're intentionally
trying to prove some point and not listen, rather than being open to
understanding. Arguing that an app doesn't respond quickly when the app isn't
running seems obtuse.

> If we chose our preferences by performance alone,

Nobody said that, so this is another straw man. The post is suggesting that UI
& frontend devs use generally accepted interaction principles, and nothing
more.

------
sarah180
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?

~~~
dahart
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.

~~~
jlg23
> It is not saying everything in the world needs to be done in 64ms.

Well, most actually could be. And a snappy "acknowledgement" only impresses me
the first time. The second time I stare at the loading indicators in
disbelief, while waiting for the not-so-snappy action to execute.

~~~
dahart
What are you suggesting as alternatives that will impress you? Would you
prefer to have no indication on screen that something is loading, and no
indication that acknowledges you even clicked on something? Do you see a
better way to show that megabytes of data are on the way but not here yet?

Loading indicators are simply one single example of how to respond to user
actions on-screen. The idea is more broad than this, the idea is for clients
to respond immediately to any inputs. This is true for opening menus, clicking
buttons, typing, pushing on the D-pad, waving the Wiimote, pressing on your
MIDI controller, waving your arms for the camera... it applies to any and all
input devices for all applications.

This idea is not in the least bit controversial, I'm surprised by the amount
of push-back here in this thread. Devs of games and interactive apps have
always done this. If the machine doesn't acknowledge user input immediately,
the user doesn't know if the input was captured, and very quickly decides the
machine is slow or buggy.

~~~
jlg23
> What are you suggesting as alternatives that will impress you?

In contrast to "not-so-snappy actions"? Snappy actions.

As I tried to say before: Instantaneous feedback is great (even necessary) for
first time users. But once I get used to an app, waiting for the termination
of a loading indicator is just as annoying as waiting for
{page|script}-{load|parse|eval}.

Edit: > This idea is not in the least bit controversial.

I agree that content generation in one-digit milliseconds is not
controversial.

~~~
dahart
The post's entire point is to say make all actions snappy. That doesn't mean
you can finish loading a video instantaneously, it means you can acknowledge
the user's request to start loading a video instantaneously.

Waiting for termination of a loading indicator on a web page is irrelevant to
this post, it's a tangential topic completely.

"content" in the post is not referring to web page content, it's referring to
UI content. We're not talking about content generation in the web page sense.

------
juancn
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.

~~~
acdha
> It's impossible. Lightspeed doesn't allow for that on websites if you're far
> enough from the servers.

Your second sentence explains why the first is wrong. Yes, you can’t have the
entire world using a single server but it’s never been easier to get servers
around the world and the new edge compute services are further improving that.

~~~
littlestymaar
> around the world

Only if your «world» means «developed countries only»…

~~~
big_chungus
Cloudflare's got POPs almost everywhere (though densities vary with population
of heavy internet users), and has a very good free plan which I use. Have a
look:
[https://www.cloudflare.com/network/](https://www.cloudflare.com/network/)

Akamai's coverage is better still; they've got just about the entire world
covered: [https://www.akamai.com/us/en/resources/visualizing-
akamai/me...](https://www.akamai.com/us/en/resources/visualizing-akamai/media-
delivery-map.jsp)

Cloudfront, Google, Fastly, etc. all have pretty good coverage, though you're
right they're spottier when it comes to S. America, Africa, and a few other
places. Their POPs are, from what I understand, have higher capacity but are
less dense. Good for cost savings, though probably worse for latency.

There's also the consideration that most web sites have most of their users in
the developed world (though that equation is shifting quickly for a some).

Out of curiosity, what is the significance of "<<" and ">>"? I'm assuming
they're not bitwise shift left and right. I've seen them more often as of
late, and they seem to come mostly from non-Americans. I ask because they're
quite difficult to run an internet search on without knowing what they are
called.

~~~
littlestymaar
> Have a look:
> [https://www.cloudflare.com/network/](https://www.cloudflare.com/network/)

This is a really good example. Did you look at Africa? For the record, 1.2
billion people live there nowadays ;)

> Out of curiosity, what is the significance of "<<" and ">>"

Oh, you mean '«' and '»'? They are French quotation marks[1], I try to use the
English ones '“' and '”' when I'm writing English, but sometimes I forget.
Same for the space before the question and exclamation mark (there is a space
in French, but not in English).

[1]:
[https://fr.wikipedia.org/wiki/Guillemet](https://fr.wikipedia.org/wiki/Guillemet)

~~~
Dylan16807
> Did you look at Africa?

Yeah, I looked at it. There are datacenters within 2000km of everywhere, and
that's including the Sahara. About 1500km outside of the Sahara.

1500km as the crow flies, so let's say 2400km of fiber. At the speed of light
in fiber, that's 11.5 milliseconds. Double it, add time for ten routers,
that's 27 milliseconds to go from any ISP line to a Cloudflare data center.

Sounds good to me. If there are infrastructure problems that's a separate
issue from whether Cloudflare has enough POPs.

------
earthboundkid
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.

------
wbhart
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
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.

------
Dylan16807
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.

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

~~~
stefan_
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_.

------
spullara
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
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
HTTPS requires a bunch of redundant roundtrips. We need adoption of QUIC/HTTP3
to reduce that.

------
korethr
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
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
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.

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

~~~
adrianmonk
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
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.

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

------
wait-a-minute
This manifesto's website takes longer than 64 milliseconds to respond though.

------
novok
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/r...](https://developers.google.com/web/fundamentals/performance/rail#ux)

------
ksec
>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
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/)

~~~
nemothekid
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.

~~~
Dylan16807
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-a...](https://www.blurbusters.com/gsync/gsync101-input-lag-tests-and-
settings/3/)

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.

~~~
nemothekid
Exotic in the sense that pretty much all gear that is polling 1000Hz nowadays
is gaming gear. I never implied it was unattainable - I have a 240Hz monitor,
G903, and still use the ps/2 port and the games. However I wouldn't doubt the
fact that my 240Hz monitor is exotic.

As for touch screen technology, the Apple Pro Pen I believe is only 20ms and
is state of the art. While I do believe that developer ux has contributed to
lazy resource management, it's also clear that sub-60hz latency has regularly
required exotic hardware.

~~~
Dylan16807
It's still "generic USB". When we're talking about the _difficulty_ of it,
it's entirely fair to pull in a $30 keyboard.

Touch is hard to keep ultra fast. But with physical buttons it's mostly
apathy.

------
kissgyorgy
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-
max...](https://stackoverflow.com/questions/17138585/what-is-the-maximum-time-
a-web-application-or-website-should-respond-to-a-requ)

~~~
feifan
The interface isn't necessarily related to backend services (i.e. you don't
_need_ backend services to drive every change in the interface)

------
kzrdude
For reference that's about this much:

16 ms → 62 Hz

32 ms → 31 Hz

64 ms → 16 Hz.

------
ninthcat
[https://webpagetest.org/result/190924_7C_b9373b51a084f69f1bc...](https://webpagetest.org/result/190924_7C_b9373b51a084f69f1bc50f5f7f9c2679/1/details/#waterfall_view_step1)

------
devadvance
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-...](https://www.nngroup.com/articles/response-
times-3-important-limits/)

------
arch-ninja
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.

------
jenkstom
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.

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

~~~
CSSer
They do? The web is the future!

------
aidenn0
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.

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

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

~~~
apetresc
They're powers of 2, so clearly they are significant for deep technical
reasons.

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

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

~~~
AnIdiotOnTheNet
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.

