Digital

October 2026

The Price of 100 Milliseconds: on the economics of web performance

On the economics of web performance

In 2006, Amazon engineer Greg Linden shared the result of an internal experiment in a presentation: every 100 milliseconds of delay deliberately added to pages cut sales by roughly one percent. The same year, Marissa Mayer, then in charge of Google's search products, described another experiment: users had asked for thirty results per page instead of ten; Google obliged, and traffic fell by twenty percent. The cause was not the number of results; the thirty-result page loaded half a second later. The two companies had measured the same thing: people spend delay the way they spend money, and they do not ask for it back. Twenty years on, these measurements are the basic numbers that decide what comes first in the design of a website.

1. Three limits, one threshold

The response-time limits of cognitive psychology apply to the web as well: Robert Miller in 1968 and Jakob Nielsen in 1993 wrote that a hundred milliseconds feels "instantaneous," one second keeps the user "in the flow," and ten seconds is "the limit of attention." Doherty and Thadani of IBM measured in 1982 that productivity leaps once response time drops below 400 milliseconds. These numbers define a website not as a broadcast but as a conversation: if the other side answers late, the conversation breaks off. That is why performance is not a technical matter to be handed off to the IT department; it is the experience itself.

2. The abandonment curve

In 2017, Google and the analytics company SOASTA examined 900,000 mobile ad landing pages. The findings traced a curve: when a page took longer than three seconds to load, 53 percent of mobile visits were abandoned; as load time went from one second to three, the probability of abandonment rose by 32 percent, and to five, by 90 percent. The same year, Pinterest wrote on its engineering blog that it had cut perceived wait time by 40 percent and that search traffic and sign-ups had risen by 15 percent. In 2018 the BBC measured that every additional second cost it 10 percent of its readers; Walmart had announced in 2012 that every one-second improvement raised conversion by 2 percent.

What these figures have in common is that none of them is about "beautiful design." The same design, arriving two seconds late, loses half its visitors. A website's first design decision is not which typeface to use but how many kilobytes to make do with.

3. Google's ruler: Core Web Vitals

Google made speed a desktop ranking factor in 2010 and a mobile one in 2018; in 2021 it reduced the measure to three numbers. Largest Contentful Paint (LCP) must be under 2.5 seconds: the main image or headline must be visible within that time. Interaction to Next Paint (INP, which replaced the old FID metric in March 2024) must be under 200 milliseconds: a tapped button must respond within that time. Cumulative Layout Shift (CLS) must be under 0.1: elements must not move around while the page loads. All three must be met at the 75th percentile of real users; what counts is not the lab test but the phones in the field.

These thresholds coincide with the limits from psychology: 200 milliseconds is the practical counterpart of the Doherty threshold, and 2.5 seconds of Nielsen's "flow" limit. Google invented nothing new; it tied sixty years of response-time literature to search ranking.

4. Where a page's weight comes from

According to the measurements HTTP Archive takes on millions of pages every month, the median mobile page exceeds 2 megabytes; half of it is images, and half a megabyte of it is JavaScript. Addy Osmani's 2018 analysis "The Cost of JavaScript" showed that the two are not equal: a byte of JavaScript is far more expensive than a byte of image, because an image is only downloaded; JavaScript is downloaded, parsed, compiled, and executed, all on the phone's processor. On a mid-range Android phone, a half-megabyte framework library eats seconds of processor time before any content appears.

This knowledge is a design decision. A corporate site's job is to show content; when the content is generated on the server as HTML and sent, the browser has nothing to do but parse and paint it. JavaScript is added only where interaction is genuinely needed, in small pieces. pentograf.com is built on this principle: pages are generated on the server, there is no framework library, and images are served at the requested size and in modern formats. The choice is not ideological but arithmetic: Linden's hundred milliseconds are not to be spent on a half-megabyte library.

5. Fitts, Hick, and the jam jars

In 1954, Paul Fitts measured the logarithmic relationship between the time it takes to reach a target and the target's distance and size; in 1952, William Hick showed that decision time grows logarithmically as the number of options increases. The two laws give the interface its two basic rules: what is to be tapped must be large and close, and what is to be chosen must be few. Apple's interface guidelines require at least 44 points for a touch target, Google's 48 pixels; the reason is Fitts. The same reason explains why the macOS menu bar sits flush against the top edge of the screen: the edge is a target of "infinite size," since the pointer cannot overshoot it.

Sheena Iyengar and Mark Lepper carried Hick's law into the world of shopping. In 2000 they set up a jam tasting booth in a supermarket: on some days six varieties, on others twenty-four. The twenty-four-variety booth drew more interest, but only 3 percent of those who stopped to taste bought jam; at the six-variety booth the figure was 30 percent. The abundance of choice was paralyzing the decision. Nine menu headings on a website, fifteen items on a services page, and five separate call-to-action buttons on the home page are twenty-four jars of jam.

6. Where the eye looks

In 2006, Jakob Nielsen recorded the eye movements of 232 users and found the letter F: the reader first scans the top line from left to right, then makes a shorter horizontal sweep a little lower, then moves down the left edge. The lower right quarter of the page is almost never looked at. When Harald Weinreich and colleagues analyzed 25,000 page visits in 2008, they found that users read at most 20 percent of the words on an average page. Web text is not read but scanned; the headline, the first words, and the left edge carry the whole page.

Typography is built around this scanning: headings deliver their meaning in the first two words, paragraphs are kept short, and line length stays between 45 and 75 characters. CSS's clamp() function scales type size continuously with the width of the screen, so the line holds the same character count on a 360-pixel phone and on a 1,440-pixel display. This is not aesthetics; it is the work of preserving Nielsen's F.

7. The invisible load: fonts and third parties

The most expensive components of a page are often the ones that cannot be seen. A web font loaded in three weights exceeds a hundred kilobytes, and until it loads the text is either invisible or appears in the wrong font and then jumps; font-display: swap chooses the latter, and a variable font brings the number of files down to one. Marketing tags, chat widgets, and analytics scripts, meanwhile, are guests invited onto the page: each connects to its own server, runs its own code, and degrades the INP metric with no one accountable for it. Every third party added to a page should be added at a measured cost.

8. The performance budget in the studio

We start every web project with a budget: on a 4G connection, LCP under 1.5 seconds, total payload for the first view under 500 kilobytes, zero render-blocking JavaScript, at most one variable font, images in AVIF or WebP and at the requested size. The budget is written before the design; a design element that does not fit the budget is changed, however "beautiful" it may be. After launch, the measure is Google's field data (CrUX): the three Core Web Vitals values are monitored monthly, and any page that crosses a threshold is fixed.

Linden's hundred milliseconds is not a small number; it is the unit of every decision about a website.

References

Linden, G. (2006). Make Data Useful. Stanford University presentation (Amazon 100 ms experiment).

Mayer, M. (2006). Web 2.0 Summit talk (Google 30-result experiment).

Miller, R. B. (1968). Response time in man-computer conversational transactions. AFIPS; Nielsen, J. (1993). Usability Engineering; Doherty, W. J. & Thadani, A. J. (1982). The economic value of rapid response time. IBM.

An, D. (2017). Find out how you stack up to new industry benchmarks for mobile page speed. Google/SOASTA, Think with Google.

Pinterest Engineering (2017). Driving user growth with performance improvements. BBC News Labs (2018); Walmart Labs (2012), Velocity conference.

Google (2020–2024). Web Vitals: LCP, INP, CLS thresholds; INP replacing FID (March 12, 2024).

HTTP Archive, Web Almanac (page weight and JavaScript measurements); Osmani, A. (2018). The cost of JavaScript.

Fitts, P. M. (1954). The information capacity of the human motor system in controlling the amplitude of movement. Journal of Experimental Psychology, 47(6), 381–391.

Hick, W. E. (1952). On the rate of gain of information. Quarterly Journal of Experimental Psychology, 4(1), 11–26.

Iyengar, S. S. & Lepper, M. R. (2000). When choice is demotivating: Can one desire too much of a good thing? Journal of Personality and Social Psychology, 79(6), 995–1006.

Nielsen, J. (2006). F-shaped pattern for reading web content. Nielsen Norman Group.

Weinreich, H., Obendorf, H., Herder, E. & Mayer, M. (2008). Not quite the average: An empirical study of web use. ACM Transactions on the Web, 2(1).

Apple Human Interface Guidelines (44 pt touch target); Material Design (48 dp).

More articles

All articles →