Impact of performance on traffic

How fast should a web page load? According to Skilled. Co, 47% of clients expect web pages to load in two seconds or less. Tests by mPulse Mobile, an AI healthcare software company, also from Skilled. Co, found:

  • When the page load time is less than 2.4 seconds, the conversion rate is 1.9%
  • At 3.3 seconds, the conversion rate was 1.5%
  • At 4.2 seconds, the conversion rate was less than 1.1%
  • Over 5.7 seconds, the conversion rate is 0.6%

Other companies have had similar results:

  • Walmart found that for every one-second reduction in page load time, the number of conversions increased by 2%
  • COOK improved the conversion count by 7% by reducing page load time by 0.85 seconds
  • Mobify found that every 100-millisecond reduction in homepage load time resulted in a 1.11% increase in conversion rates

Performance model

RAIL

RAIL is a user-centric performance model that provides a structure that takes performance into account. This model breaks down the user experience into key actions (for example, click, scroll, load) and helps you define performance goals for each action.

RAIL represents four different aspects of the Web application life cycle: response, animation, idle, and load. Users have different performance expectations for each of these contexts, so performance goals are defined in terms of context and UX studies of how users perceive delays.

RAIL’s four parts of the performance model

Response Response: Processes the event within 50 milliseconds

The goal is to respond to input in 100 milliseconds, so why do we plan to achieve 50 milliseconds? This is because there is usually work to be done in addition to input processing, and that work takes up part of the time available to accept input responses. If the application performs work in the recommended 50-millisecond block during idle time, this means that if input occurs during one of these work blocks, it can queue up to 50 milliseconds. With this in mind, it’s safe to assume that only the remaining 50 milliseconds are available for actual input processing. This effect is shown in the figure below, which shows how input received during idle tasks is queued, thereby reducing available processing time

How do idle tasks affect input responses

Animation: Generates a frame in 10 milliseconds

  • Generate each frame in the animation in 10 milliseconds or less. Technically, the maximum budget per frame is 16 ms (1000 ms / 60 frames per second ≈16 ms), but browsers need about 6 ms to render each frame, so 10 ms per frame is the guideline.
  • Aim for visual smoothness. The user will notice when the frame rate changes.

Idel idle: Maximizes idle time

Maximize the idle time to increase the chances that the page will respond to user input within 50 milliseconds.

Load: Page content should be interactive within 5 seconds

When the page loads slowly, the user’s attention will wander and the user will think the task is corrupted. Sites that load faster have longer average sessions, lower bounce rates, and higher AD visibility.

web vitals

Core Web metrics are a subset of Web metrics that apply to all Web pages, should be measured by each site owner, and will be displayed in all Google tools. Each core Web metric represents a different aspect of the user experience that can be realistically measured and reflects the real experience of user-centered key outcomes.

The composition of core Web metrics will evolve over time. The current composition of metrics for 2020 focuses on three aspects of the user experience — loading performance, interactivity, and visual stability — and includes the following metrics (and their corresponding thresholds) :

Largest Contentful Paint (LCP)

Maximum content is drawn to measure loading performance. To provide a good user experience, the LCP should occur within 2.5 seconds after the page first starts loading.

First Input Delay (FID)

First input delay, measuring interactivity. To provide a good user experience, a page’s FID should be 100 milliseconds or less.

Cumulative Layout Shift (CLS)

Cumulative layout offset to measure visual stability. To provide a good user experience, a page’s CLS should be kept at 0.1. Or less.

A good measurement threshold for each of these metrics is the 75th percentile of page loading, and applies to both mobile and desktop devices, in order to ensure that you can reach the recommended target values during the majority of users’ visits.

CLS = Impact score * Distance score

Influence score

The set of visible areas of all unstable elements from the previous and current frames (the portion of the total visible area) is the influence score of the current frame.

In the image above, one element occupies half of the viewable area in one frame. Then, in the next frame, the element moves down 25% of the height of the viewable area. The red dotted rectangular box represents the set of visible areas of the elements in both frames, which in this example accounts for 75% of the total visible area, soInfluence scorefor0.75 。

Distance score

The distance score refers to the maximum distance (horizontal or vertical) that any unstable element can move in a frame divided by the maximum dimensional dimension (width or height, whichever is greater) of the visible area.

In the example above, the largest visual area size dimension is height, and the unstable element’s displacement distance is 25% of the visual area height, soDistance score0.25.

So, in this example, the influence score is 0.75 and the distance score is 0.25, so the layout offset score is 0.75 * 0.25 = 0.1875.

Indicators collected

Web-vitals is recommended

  • Measure the LCP in JavaScript
  • Measure FID in JavaScript
  • Measure CLS in JavaScript

Problem analysis

Commonly used tools

lighthouse

Lighthouse is available in Chrome DevTools, web.dev/measure, Chrome extensions, the Node.js module, and WebPageTest. You give it a URL, it simulates a mid-range device with a slow 3G connection, runs a series of audits on the page, and then gives you a load performance report with suggestions on how to improve.

Chrome Developer Tools

Chrome DevTools provides in-depth analysis of everything that happens when a page loads or runs. See Start Profiling runtime Performance to familiarize yourself with the performance panel UI.

WebPageTest

WebPageTest is a Web performance tool that uses a real browser to access Web pages and collect timing metrics. Enter a URL at webpagetest.org/easy to get a detailed report of the page’s load performance on a real Moto G4 device with a slow 3G connection. You can also configure it to include Lighthouse auditing.

Performance – Bookmarklet (Personal recommendation)

The plugin can see the waterfall flow sequence, the resource call sequence of each domain name, resource classification and other helpful information

Navigational timing waterfall

  • If you useUser Timing API (performance.markandperformance.measure) sets the tag, which also displays the tag and metrics
  • Hover over the bar to view a tooltip containing the precise millisecond/duration

Navigation timing API details

Refer to the article

  • Github.com/GoogleChrom…
  • web.dev/rail/
  • Github.com/micmro/perf…