Why is performance important?

From the perspective of user experience, 75% of people consider the page loading time as a core factor, far higher than other issues that affect user experience, such as simplicity and ease of use, screen adaptation, attractive design and so on.

Performance also has a direct impact on retention, page conversion, and user experience for the business.

There are many examples in the industry where performance directly affects business:

  • Pinterest reduced page load times by 40% and increased searches and sign-ups by 15%
  • BBC lost 10% of its users for every second it took to load a page
  • DoubleClick found that 53% of users abandon a mobile site if it takes longer than three seconds to load

So with the popularity of 4G, 5G promotion, is the website performance will not become a very serious problem? After all, Internet speeds will improve dramatically, and theoretically web pages will load faster and faster, so shouldn’t we worry too much?

From the data analysis of the global website, the current performance data in all aspects are not optimistic

Since 2011, the total resource size of websites has increased by 314% on PC and 1106% on mobile, while the corresponding time for page onLoad has increased by 3.3% on PC and 392% on mobile. You can see that while the web environment has improved over the past eight years, the overall loading time has actually increased significantly due to the increasing functionality of mobile sites. And the median load time is 18.7s, which is virtually unusable for end users.

The fallacy of measuring performance

If you can’t measure it, you can’t improve it.

Peter Drucker is the father of modern management

There are several misconceptions about measuring performance:

  • Only individual data are collected

For performance measurement, it’s common to hear someone say THAT I tested XX websites and the page load time was X.X seconds. This is very misleading, and load times vary from user to user, depending on device capabilities and network conditions. Displaying load times as a single number ignores users who experience longer load times.

In fact, your application’s load time is a collection of all load times from each user, and the only way to fully represent that load time is to use a distribution as in the following histogram:

  • Focus on single data

Many teams make this mistake, and most performance tools tend to focus on page load times.

But the reality is that performance problems can happen all the time, not just during loading. Apps that don’t respond quickly to clicks or taps and don’t smoothly scroll or animate can be just as bad as apps that load slowly.

Similarly, traditional performance metrics (such as onLoad or DOMContentLoaded time) are highly unreliable because they may or may not correspond to when the user thinks the application is loading.

Performance metrics based on user experience

Performance metrics based on user experience processes are often critical, and are generally categorized into the following categories of experiences:

  • Whether loading: FP/FCP. The user can be prompted to indicate that the page is loading, and the page should change from a blank screen stage to some page frames. To improve the loading time of the first screen, a skeleton screen can be used to render the page before obtaining server data.
  • Useful content: FMP. A page usually has some core element, also called Hero element, such as playing a website, and the player is often the core element, and the rendering of this core element tells the user whether the page is valuable to him or not. To improve FMP, core elements can be rendered first on the core rendering path, and other information can be rendered later.
  • Whether to use: TTI. This usually refers to the time when the page can accept user operation response and the page load is complete.
  • Whether to use smooth: Long Tasks. Whether the page responds in a timely manner when users click, swipe, etc. In general, we need to ensure that the FPS is above 60, so that the user will not feel obvious slowness, so the execution time of a single JS Long Task should be within 1s/60 = 16ms.

Percentile line

Concept: TP=Top Percentile, is a statistical term, and the average, median are the same.

Application: Indicators TP50, TP90, and TP99 are commonly used in system performance monitoring scenarios. Indicators are higher than 50%, 90%, and 99%.

When calculating performance data, percentile lines are usually used instead of averages. Because the actual user’s device and network environment vary greatly, the actual page loading performance index will vary greatly. In order to avoid the overall data distortion caused by individual extreme data, it is reasonable to use percentile line data.

Second open rate

In the era of mobile Internet, especially for pages in App, second opening is the best experience for users. If a page can be loaded within one second, users can almost get a similar native experience without too much anxiety.

Generally speaking, different page opening standards can be set according to the service situation, such as FCP, FMP, or TTI. Then, the ratio of data less than 1s in real user data is the open rate in seconds. In the industry outstanding companies, such as the hand out of the page second open rate basically reached more than 80%.

RAIL model

The RAIL model is also a performance measure based on user experience

Response: process the event within 50ms

Objective: To complete the transformation initiated by user input in 100ms. Users spend most of their time waiting for the site to respond to their input, rather than waiting for the site to load.

Animation: Generates the next frame of the Animation in 10ms

Goal: Generate each frame in an animation in 10ms 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.

Idle: Maximizes the Idle time

Goal: Maximize idle time to improve user input response time

Load: Complete site loading in 5 seconds

Goal: Complete page loading and interactive in 5 seconds or less on moderately configured mobile devices with slow 3G connections when the page is first loaded.

The data collection

Data collection falls into two categories: laboratory data and real user data. Laboratory data is often obtained by local testing tools in a controlled internal test environment, simulating user operations. Real user data is used to judge real user experience by collecting and summarizing real data. Data indicators are few and difficult to debug.

Laboratory data

For lab data collection, Lighthouse and Chrome Devtools are typically used.

  • Lighthouse: Provides advice on best practices for performance, accessibility, PWA, SEO, and more

  • Chrom Devtools: A series of developer tools that make it easy to analyze network traffic, page loads, JS execution times, and more for performance.

Real user data

In 2012, W3C formulated the standard of Navigation Timing, which is now supported by mainstream browsers. Window. performance can be used to obtain the time points in each stage of page loading, so as to collect performance data of real users.

Some core times can be calculated by the following time points:

  • DNS query: domainLookupEnd – domainLookupStart
  • TCP connection: connectEnd – connectStart
  • FP first render: domloading – navigationStart
  • TTI (page interactive time) : domInteractive – navigationStart
  • DOMReady: domContentLoadedEventEnd – navigationStart
  • Onload: loadEventEnd – navigationStart

conclusion

Performance is a very critical and important function. The requirements related to performance indicators should be considered at the beginning of system design, and performance tuning attempts should be made in the local environment. At the same time, data of real users should be collected and continuously tuned after the system goes online.

Performance metrics must be related to the experience of real users, rather than relying on a single data set. Performance optimization can be done in a variety of ways, starting with conceptual recognition of its importance, and then developing performance budgets, development specifications, simulation tuning, online data collection, metrics operations, and so on throughout the development process.

Ux optimization is a path that can continue to evolve, and choosing the right performance metrics is a good place to start.

If you are interested, you can follow the wechat public account Daidadyannong to share information about investment, financial management and IT: