当前位置：文江博客知识库 en-US 文档 Learn Performance perceived_performance

Perceived performance - Learn web development 编辑

Perceived performance is how fast a website seems to the user. How a user perceives your performance is as important, or perhaps more important, than any objective statistic, but it's subjective, and not as readily measurable. Perceived performance is user perspective, not a metric.

This article provides a brief introduction to perceived performance, looking at user perceptions, and what objective tools can be used to measure that which is subjective.

Prerequisites:	Basic computer literacy, basic software installed, and basic knowledge of client-side web technologies.
Objective:	To gain basic familiarity of user perception of web performance.

Performance is about user perception. How fast a website feels like it's loading and rendering has a greater impact on user experience than how fast the website actually loads and renders. Even if an operation is going to take a long time (because of latency or inavailability of the main thread), it is possible to keep the user engaged while they wait by showing a loading spinner, or a series of useful hints and tips (or jokes, or whatever else you think might be appropriate). Such an approach is much better than just showing nothing, which will make it feel like it is taking a lot longer and possibly lead to your users thinking it is broken and giving up.

Perceived performance

The perception of how fast your site loads and how responsive feels to user interaction is vitally important; even more important that actual download time but difficult to quantify. There are areas of your site that you may not be able to make faster, but you can make it feel faster even if the metrics discussed in the othser sections can't be improved.

There is no unicorn metric that can measure what the user feels, but metrics are useful in guaging improvements (and regressions). Relevant measurements include first meaningful paint (FMP), largest contentful paint (LCP), time to interactive (TTI), render start, DOM interactive, and speed index.

First paint is reported by the browser and provides the time, in ms, of when the page starts changing; but this change can be a simple background color update or something even less noticable. It doesn’t indicate completeness and may report a time when nothing visible is painted. First Contentful Paint (FCP) reports the time when the browser first rendered anything of signifigance, be that text, foreground or background image, or a canvas or SVG; capturing the very beginning of the loading experience. But, just because there's content, doesn't mean it's useful content or that the user has content to consume. The First Meaningful Paint, or FMP, is the when content appears on the screen that is actually meaningful; which is a better metric for user-perceived loading experience, but still not ideal. Largest contentful paint (LCP) metric, definited in the Largest Contentful Paint API, reports the render time of the largest content element visible in the viewport.

Speed index is also used to approximate perceived performance: it measures the average time for pixels on the visible screen to be painted. It doesn't account for jitter, nor does it weight which content important to a user more highly, so it's not a perfect metric.

These metrics have to do with initial load and render. It is also important to ensure the site feels fast once the user begins interacting with it. For this, time to interactive, is a good metric; it is the moment when the last long task of the load process finishes and the UI is available for user interaction with delay.

UI lack or responsiveness and jank both harm perceived performance. Even though a task may take a long time, though, there are ways to make it seem faster. There are several tips to improving perceived performance.

Improving perceived performance

Understanding networking, how the browser works, user perception of time, etc., can help you better understand how to improve the user interaction. However, you don't have to know the ins and outs of how everything, including how the human mind works, to improve the perception of speed.

How fast or slow something feels like it's taking depends a lot on whether the user is actively or passively waiting for this thing to happen. Waits can have an active and passive phase. When the user is active - moving the mouse, thinking, being entertainted, they are in an active phase. The passive phase occurs when the user is passively waiting, like staring at a monochrome screen. If both the passive and active waits time were objectively equal, users would estimate that the passive waiting period was longer than the active. If a load, render, or response time can not be objectively minimized any further, turning the wait into an active wait instead of a passive wait can make it feel faster.

There are tips and tricks to follow. Some of these quick tips have full articles if you want to dive deeper.

Displaying content, or at least some part of the page with an indication that content is loading, as quickly as possible, is essential to improving perceived performance. For example, because page render is blocked by loading and parsing CSS and JavaScript, minimizing the amount of CSS and JS that needs to be loaded on initially will have a major impact on improving perceived performance. Even though the bytes might be the same, not blocking the page from rendering makes the load feel faster.

Here are a few tips and tricks to help improve performance:

Minimize initial load

To improve perceived performance, minimize the original page load. In other words, first download everything you're going to actually show, but only the stuff you are actually using, then download the rest. If you're downloading all the assets in the end, the weight of all your assets hasn't improved -- in fact, you may need to add some code -- but because the download of non-immediately necessary assets are delayed in a manner that is not perceptible the user, the user will feel like the download was faster.

To minimize the assets required for initial load, separate interactive functionality from content so that required content -- the text, styles, and images visible at initial load -- can be loaded first. Delay, or lazy load, the rest of the assets.

Don't load images or scripts that aren’t used or visible on the initial page load. Either delay their load, loading them when the page becomes usable, or, loading them when they become necessary. Loading additional assets and resources after initial page load improves perceived performance. Loading essential data in initial requests and progressively loading features and data only as needed helps mitigate low bandwidth and lower spec hardware.

Additionally, you should optimize the assets you do load. Images and video should be served in the most optimal format, compressed, and in the correct size.

Prevent jumping content and other reflows

Images or other assets causing content to be pushed down or jump to a different location, like the loading of third party advertisements, can make the page feel like it is still loading and is bad for perceived performance. Content reflowing is especially bad for user experience when not initiated by user interaction. If some assets are going to be slower to load than others, with elements loading after other content has already been painted to the screen, plan ahead and leave space in the layout for them so that content doesn't jump or resize, especially after the site has become interactive.

Avoid font file delays

Font use can both help and harm user experience. Selecting the right fonts is an art form, and can greatly improve the user experience. Fonts can also harm user experience, especially if the fonts used need to be imported, and if the importing is not optimal, or if Comic Sans is used (kidding). Flicker of unstyled text and missing text both harm performance.

Make fallback fonts the same size and weight so that when fonts load the page change is less noticeable.

Interactive elements are interactive

Make sure visible interactive elements are always interactive and responsive. If input elements are visible, the user should be able to interact with them without a lag. Users feel that something is laggy when they take more than 50ms to react. They feel that a page is janky when content repaints slower than 16.67ms (or 60 frames per second) or repaints at uneven intervals.

Make things like type-ahead a progressive enhancement: use css to display input modal, JS to add typeahead/autocomplete as it is available

Make task initiators appear more interactive

Making a content request on keydown rather than waiting for keyup can shave 200ms off the perceived load of the content. Adding an interesting but unobtrusive 200ms animation to that keyup even can reduce another 200ms of the perceived load. You're not saving 400ms of time, but the user doesn't feel like they're waiting for content until, well, until they're waiting for content.

Conclusion

By turning as much of the download, render and wait time into active phases and reducing any passive waiting, even if the objective measurements stay the same, the user will feel like the content downloaded, rendered, and responded more quickly. Now that we know what we should be speeding up, let's take a look at some metrics and learn how we can measure these events.