Web Page Usability Matters
Tags: webperf, lighthouse, webdev, timetointeractive
Published: 2019-01-10 17:44:23

---
title: "Web Page Usability Matters"
published: true
description: Users appreciate pages being usable and interactive soon after they're visually ready. UI interactions (scrolls, taps, clicks) can be delayed by script and other browser work so minimizing their impact can really help your users.
tags: 
  - web performance
  - lighthouse
  - webdev
  - time to interactive
canonical_url: https://addyosmani.com/blog/usability/
---

**Users appreciate pages being usable and interactive soon after they're visually ready. UI interactions (scrolls, taps, clicks) can be delayed by script and other browser work so minimizing their impact can really help your users.**

You may have heard there isn't a single metric that fully captures the "loading experience" of a web page. Loading a page is a progressive journey with four key moments to it: is it happening? Is it useful? is it usable? and is it delightful?. 

![When did the user feel they could interact? When could they interact? Speed metrics illustrate First Paint, First Contentful Paint, Time to Interactive for a page](https://thepracticaldev.s3.amazonaws.com/i/9enrd4e7p4slrlgns6t1.png)


In terms of measurable metrics, these moments breakdown as follows:

* **Is it happening?**: Has the navigation started successfully? has the server started responding? Metric: [First Paint](https://www.w3.org/TR/paint-timing/)
* **Is it useful?**: when you’ve painted text, an image or content that allows the user to derive value from the experience and engage with it. Metrics: [First Contentful Paint](https://developers.google.com/web/tools/lighthouse/audits/first-contentful-paint), [First Meaningful Paint](https://developers.google.com/web/tools/lighthouse/audits/first-meaningful-paint), [Speed Index](https://sites.google.com/a/webpagetest.org/docs/using-webpagetest/metrics/speed-index) (lab)
* **Is it usable?**: when a user can start meaningfully interacting with the experience and have something happen (e.g tapping on a button). This can be critical as users can get disappointed if they try using UI that looks ready but isn't. Metrics: [Time to Interactive](https://developers.google.com/web/tools/lighthouse/audits/time-to-interactive) (lab), [First CPU Idle](https://developers.google.com/web/tools/lighthouse/audits/first-cpu-idle), [First Input Delay](https://developers.google.com/web/updates/2018/05/first-input-delay) (field)
* **Is it delightful?**: delightfulness is about ensuring performance of the user experience remains consistent after page load. Can you smoothly scroll without janking? are animations smooth and running at 60fps? do other [Long Tasks](https://calendar.perfplanet.com/2017/tracking-cpu-with-long-tasks-api/) block any of these from happening?. 

<img alt="Time to Interactive as highlighted by Chrome DevTools and Lighthouse. The user sees content early on but the page is not interactive until much later." src="https://thepracticaldev.s3.amazonaws.com/i/2g63ozqm2x3wyce97c8a.jpg">

Page usability matters. Single-page Apps are unlikely to be usable (able to quickly respond to user input) if they haven't completed loading the JavaScript needed to attach event handlers for the experience or are hogging the browser's main thread (similar to above). This is a reason why monitoring usability metrics can be important.

## Do users care about page usability? 

In 2018, Akamai conducted a [UX study](https://speakerdeck.com/bluesmoon/ux-and-performance-metrics-that-matter-a062d37f-e6c7-4b8a-8399-472ec76bb75e) into the impact of interactivity on [Rage Clicks](https://blog.fullstory.com/rage-clicks-turn-analytics-into-actionable-insights/) using [mPulse](https://www.akamai.com/us/en/products/web-performance/mpulse-real-user-monitoring.jsp). Rage Clicks happen when users rapid-click (or tap) on a site out of frustration. Akamai discovered that **Rage Click likelihood depends on the latency of page usability**:

* Rage Clicks are consistent if a user's first interaction is before the page becomes interactive (before interactive or `onload`). This may be because event handlers are hogging CPU.
* In 30%+ of cases, pages were interactive after `onload` fired and in 15%, users tried interacting sometime between `onload` and interactive.

<img alt="Rage Clicks by first interaction and visually ready. There is a clear correlation." src="https://thepracticaldev.s3.amazonaws.com/i/6ok1usi72wmur9ssgqjy.jpg">


**What is the optimum time to reduce Rage Clicking?** 

<img alt="What is the optimum time to reduce Rage Clicking? Pages can be visually complete. Users expect they can interact soon after (1.3x). There is the potential for a rage-click soon after." src="https://thepracticaldev.s3.amazonaws.com/i/vxcakzxga0zm55znq8rt.jpg">


Akamai observed:
 
* The majority of users who Rage Click attempt to interact with a page between 1.25 and 1.5x the visually ready time.
* They suggested making sure your page is interactive and loaded before 1.3x the visually ready time. 

For more on this study, see [UX and performance metrics that matter](https://speakerdeck.com/bluesmoon/ux-and-performance-metrics-that-matter-a062d37f-e6c7-4b8a-8399-472ec76bb75e) by Philip Tellis.

**Time to Interactive can have a high correlation with overall conversion rate**

In a [2017 study](https://www.slideshare.net/nicjansma/reliably-measuring-responsiveness), Akamai and Chrome found that across three real-world sites (in retail, travel and gaming) Time to Interactive had a high correlation with overall conversion rate. Conversions can be tapping a button to complete a purchase flow or any number of other types of responses to an interaction.

<img src="https://thepracticaldev.s3.amazonaws.com/i/gy6g572iop59oigb86m8.png" alt="Time to Interactive impact on conversion rates">


They discovered: 

* Long Tasks directly delayed Time to Interactive. 
* As first-page Long Task time increased, overall conversion rates decreased.
* Mobile devices could see a 12x Long Task time vs Desktop. 
* Older devices could be spending half of their load-time on Long Tasks.

Note: This is an obviously small sample size and every site can be different.


## The phases of loading in more detail


### Is it happening? Is it useful?

When the user gets timely feedback that "It is happening" they feel much better, and they perceive the site as faster. At the same time, you don't want a user to render a page which is "useful" but which they cannot interact with because it isn't yet ready. This would leave them feeling it's not [usable](https://www.slideshare.net/fwdays/improve-your-web-application-using-progressive-web-metrics).

<img src="https://thepracticaldev.s3.amazonaws.com/i/9vhm0ypfgg1g5qobo7x5.jpg" alt="Perceptual load timings. The timestamp of a shipped frame that contains any of these - first paint of text, first paint of SVG" class="lazyload">


#### First Paint

First Paint marks when the browser can render anything visually different from what was displayed before navigation. It confirms that rendering has started. This can be an important metric, as the duration of ‘blank screen’ is probably the most significant indicator of page abandonment.

#### First Contentful Paint

First Contentful Paint is when the browser renders the first content from the DOM - this could be article text, an image or SVG. The hope is this paint communicates a navigation successfully began.


### Is it usable?

As I've covered in [The Cost Of JavaScript](https://medium.com/@addyosmani/the-cost-of-javascript-in-2018-7d8950fbb5d4), the web has a problem. Many sites are optimizing for content visibility but ignoring interactivity as their JavaScript for accomplishing this takes time to be processed. This means large numbers of very popular sites have [multi-second](https://httparchive.org/reports/loading-speed#ttci) delays between having painted something useful and being "usable" or interactive. During this time, the web feels slow and unresponsive. 

#### Time to Interactive and First Input Delay

![First Contentful Paint - FCP - when the main thread is idle, styles are loaded and browser can paint content. First Interactive - when the browser can respond to the first user input](https://thepracticaldev.s3.amazonaws.com/i/1h5f9t29ggc0mh5v2vqy.png)

[Time to Interactive](https://github.com/WICG/time-to-interactive) (TTI) is a metric that measures how long it takes for a web page to become interactive. This is defined as a point when:

* The page has displayed useful content
* Event handlers are registered for most visible page elements
* When a user interacts with the page, the page consistently responds within 50ms - the user does not experience jank.

When a page has a great TTI, a user can tap around the interface with high confidence it will respond to input. This strictly meets the Idle guideline of the [RAIL performance model](https://developers.google.com/web/fundamentals/performance/rail): the page yields control back to the main thread at least once every 50ms. The network is idle. Specifically, there are only two open network requests remaining.

First Input Delay (FID) is TTI's complimentary metric in the field - it measures the time from a user first interacting with a page (e.g. tapping a button) to when the browser can actually respond to the interaction.

## Optimizing user-centric metrics

A focus on optimizing user-centric metrics will ultimately improve the user experience. If you would like to reduce... 

Time to Interactive or First Input Delay:

* Do less work
* Split up large JavaScript bundles using [code-splitting](https://web.dev/fast/reduce-javascript-payloads-with-code-splitting)
* Split up long tasks. Consider moving intensive off-main thread to workers.
* Postpone non-critical work until after page load

First Paint and First Contentful Paint:

* Remove render blocking scripts from head
* Identify the [critical CSS](https://www.smashingmagazine.com/2015/08/understanding-critical-css/) needed and inline in `<head>`
* App Shell pattern - improve user perception rendering UI skeleton 


## Monitoring metrics

Performance tools like [PageSpeed Insights](https://developers.google.com/speed/pagespeed/insights/), [WPT](https://webpagetest.org/easy) and [Lighthouse](https://developers.google.com/web/tools/lighthouse/) capture user-centric loading metrics:

<img src="https://thepracticaldev.s3.amazonaws.com/i/mt5uxwewjkgy3bntc8av.png" alt="First Contentful Paint, Speed Index, Time to Interactive, First Meaningful Paint, First CPU Idle in Lighthouse">

For CLI users, they are also available via [pwmetrics](https://github.com/paulirish/pwmetrics) by Paul Irish and Artem Denysov. 

For monitoring metrics in the field (via RUM), I recommend the [Paint Timing API](https://developer.mozilla.org/en-US/docs/Web/API/PerformancePaintTiming) which provides First Paint and First Contentful Paint. A polyfill for [First Input Delay](https://github.com/GoogleChromeLabs/first-input-delay) is also available. Paired with an analytics service these enable logging progressive web metrics for your real users.

The [Chrome User Experience Report](https://developers.google.com/web/tools/chrome-user-experience-report/) ([also in PageSpeed Insights](https://developers.google.com/speed/pagespeed/insights/?url=https%3A%2F%2Fchrome.com)) provides access to some of these metrics (like First Contentful Paint and First Input Delay) for your real users using Chrome:

<img alt="Chrome User Experience Report distributions for metrics" src="https://thepracticaldev.s3.amazonaws.com/i/2zyvauug3fdk6kqudgi6.png">


I also like [SpeedCurve](https://speedcurve) or [Calibre](https://calibreapp.com) for tracking metrics like FCP and TTI over time. It allows me to set performance budgets for them too which can help detect regressions:

<img src="https://thepracticaldev.s3.amazonaws.com/i/4mw8beesk2j3lc3qna4e.png" alt="Speedcurve metrics tracking">


## Debugging metrics

Chrome DevTools now highlights performance metrics in the Performance panel. These can be found under Timings:

<img alt="DevTools Metrics in performance panel" src="https://thepracticaldev.s3.amazonaws.com/i/hb2e04oc9ej4h8b4gqhn.png">

In addition to other surfaces these metrics are exposed, this can provide value while attempting to improve times in your iteration workflow.


## References and learn more

* [The Latest in Metrics & Measurement - Paul Irish](https://www.youtube.com/watch?v=XvZ7-Uh0R4Q) 
* [UX and performance metrics that matter - Philip Tellis](https://speakerdeck.com/bluesmoon/ux-and-performance-metrics-that-matter-a062d37f-e6c7-4b8a-8399-472ec76bb75e)
* [User-centric Performance Metrics - Philip Walton](https://developers.google.com/web/fundamentals/performance/user-centric-performance-metrics)
* [Reliably Measuring Responsiveness In The Wild - Shubhie Panicker and Nick Jansma](https://www.slideshare.net/nicjansma/reliably-measuring-responsiveness)
* [Speed Tooling - State Of the Union: Elizabeth Sweeny and Paul Irish](https://www.youtube.com/watch?v=ymxs8OSXiUA)
* [Focusing on the human-centric metrics - Radimir Bitsov](https://calibreapp.com/blog/time-to-interactive/)
* [Improve your web application using Progressive Web Metrics - Artem Denysov](https://www.slideshare.net/fwdays/improve-your-web-application-using-progressive-web-metrics)
* [Why Web Developers Need to Care about Interactivity - Philip Walton](https://philipwalton.com/articles/why-web-developers-need-to-care-about-interactivity/)
* [First Input Delay - Philip Walton](https://developers.google.com/web/updates/2018/05/first-input-delay)
* [First Input Delay - State Of The Web - Rick Viscomi](https://www.youtube.com/watch?v=ULU-4-ApcjM)
* [The Guide to Understanding Frustration Online](https://www.fullstory.com/resources/guide-to-understanding-frustrating-user-experiences-online/)
* [First Input Delay: Correlation with TTI - Tim Dresser](https://docs.google.com/document/d/1g0J5JIcICFyXYM6ifBF6vNd_qUPIfpf6YAfFHE1TYRE/edit#heading=h.c79uz11ezek4)
* [An Event Timing API - Tim Dresser and Nicolás Peña Moreno](https://wicg.github.io/event-timing/)