back
107 comments
The URL was originally https://64.ms/ but it no longer works, so we've changed to one that does (by the submitter's request).
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"

I think your examples hinted at an important part of network-driven applications: loading. Loading statuses, done correctly, and with the right attention to detail, can result in users waiting more patiently than many would ever believe. Sometimes that’s as small as conveying “something is happening” and other times it requires conveying details that communicate why the user must wait so that they can simply think, “that seems reasonable. I understand why that could take some time”.
Instant.page and Quicklink attempt to speed up the perceived loading of pages by pre-loading pages before a user clicks.

The "Test your click speed" button is fun to play with. Times 50-100 ms for mobile and 150-300 ms for desktop are reasonable long for performing some pre-loading.

[1] https://instant.page/ [2] https://github.com/GoogleChromeLabs/quicklink

There are about 20 different things that happen on screen while google.com is loading in my Chrome browser, starting within 16ms.
Note that it says "interactive software application" not "website", though it's possible on a website using a single page application and preloaded resources. Any time you're fetching a resource from some external source, it's unreasonable to expect it to load in under 64ms.

I assume the intention isn't speed alone, but part of the user experience. When you interact with an application, you should be able to tell immediately that it's recognized your input and something is happening.

Google hasn't had incredible speed for many years, now. That reputation is woefully out of date.
Will you wait > 100ms for a checkbox to change state? The point is that actions that should be instantaneous need to appear as such within the limits of human perception. Complex operations can take longer.
There are other things than the web. Though maybe not for long, if everyone starts thinking like you just did…
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?
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.

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…

I don't agree with the page too, it seems better to make terms on order of magnitude may be (10s of ms, 100s of ms), but in their favor the exact times might not be hard limits but maxima in terms of latency, with the hope that you can be better. A point against me is specific numbers (ones that are essentially memorized by every programmer as powers of two) are easy to remember and good for messaging purposes.
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.

This manifesto is made just for you! Waiting for the response before updating the screen is the wrong answer. It’s not impossible, you’re assuming incorrectly that the manifesto is saying the final result needs to be on screen. It didn’t say that, it said the app needs to respond to action visually, not that the response or interaction sequence must be completed within that time frame.

The right answer for web and networked applications is to update the screen with UI that acknowledges the user action and shows the user that the result is pending. Ideally, progress is visible, but that’s tangential to the point of the manifesto.

A client can, in fact, almost always respond to actions within these time constraints. The point is to do something, rather than wait for the network response.

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.
Getting a CDN to put your content much closer to users does not require an awful lot of money. The vast majority of your users shouldn't be across half the globe; if you're a tiny local shop, then you're targeting local users; and if you're targeting multiple continents then it's not that hard to host stuff on multiple continents cheaply even if you're just a couple people, there are services available for that.
> Lightspeed doesn't allow for that on websites if you're far enough from the servers.

This assumes that we need remote servers to do our computing for us. :~) P2P software doesn't require remote servers, plus it means your apps still work offline.

In most situations you can have more than one server. If you focus on the 64ms goal, and you budget 20 for ethernet/fiber, that gets you 2000km each way to reach the closest one.
In some cases (most requests succeed, and you know the likely outcome) an optimistic update would suffice.
> 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.

>Lightspeed doesn't allow for that on websites if you're far enough from the servers.

This is a hint that you're writing for the wrong platform. Write real apps.

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.

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.

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.

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.

...and on my browser [Firefox ESR 60.8.0esr (64-bit)] it takes 241ms to load this plain HTML website.
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...
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.

Meanwhile major news sites take 45 seconds to load content randomly accross the page so the text jumps around and is unreadable.
I enjoy that it gives no rationales. Without reasons/research/sources, these are just arbitrary numbers.
This manifesto's website takes longer than 64 milliseconds to respond though.
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...

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

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

For reference that's about this much:

16 ms → 62 Hz

32 ms → 31 Hz

64 ms → 16 Hz.

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

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.

Half the comments here seem to assume this manifesto is about web sites. Can I remind everyone that many applications run locally?
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.
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.
Too vague. Isn't moving caret in a text field "any user action"? Then why should it invoke a full screen of content?
Meh.. sure. Any reason behind these specific figures?
64ms? Without any context or reasoning? Wrong all ui should load in 100ns and anyone who disagrees is an idiot.
People must learn some patience instead of wasting our time and talent on optimizing stuff for those milliseconds.