1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
|
---
title: 感知性能
slug: learn/Performance/感知性能
tags:
- Web 性能
- 感知性能
translation_of: Learn/Performance/perceived_performance
---
<div>{{LearnSidebar}}</div>
<div>{{PreviousMenuNext("Learn/Performance/what_is_web_performance", "Learn/Performance/Measuring_performance", "Learn/Performance")}}</div>
<p><span class="seoSummary"><strong><a href="/zh-CN/docs/Glossary/Perceived_performance">感知性能</a></strong> 是用户对网站速度的感受。</span> 用户如何看待性能与任何客观统计数据一样重要，甚至更重要，但它是主观的，并且不易测量。感知性能是用户视角，而不是指标。</p>
<p>本文简要介绍了感知性能，着眼于用户的感知，以及可以使用哪些客观工具来衡量这类主观因素。</p>
<table class="learn-box standard-table">
<tbody>
<tr>
<th scope="row">预备知识：</th>
<td>基础计算机知识，<a href="https://developer.mozilla.org/en-US/Learn/Getting_started_with_the_web/Installing_basic_software">基本软件安装</a>， <a href="/en-US/docs/Learn/Getting_started_with_the_web">客户端 web 技术</a>的基础知识</td>
</tr>
<tr>
<th scope="row">目标</th>
<td>基本了解用户对Web性能的看法。</td>
</tr>
</tbody>
</table>
<p>性能是关于用户视角的。 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 or inavailability of the <a href="/en-US/docs/Glossary/Main_thread">main thread</a>), 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.</p>
<h2 id="感知性能">感知性能</h2>
<p>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 <em>feel</em> faster even if the metrics discussed in the othser sections can't be improved.</p>
<p>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.</p>
<p><strong><a href="/en-US/docs/Glossary/First_paint">First paint </a></strong>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. <strong><a href="/en-US/docs/Glossary/First_contentful_paint">First Contentful Paint</a> (FCP) </strong>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 <strong><a href="/en-US/docs/Glossary/first_meaningful_paint">First Meaningful Paint</a></strong>, 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. <strong>Largest contentful paint (LCP)</strong> metric, definited in the <a href="https://wicg.github.io/largest-contentful-paint/">Largest Contentful Paint API</a>, reports the render time of the largest content element visible in the viewport.</p>
<p><strong><a href="/en-US/docs/Glossary/Speed_index">Speed index</a></strong> 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.</p>
<p>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, <strong><a href="/en-US/docs/Glossary/Time_to_interactive">time to interactive</a></strong>, is a good metric; it is the moment when the last <a href="/en-US/docs/Glossary/Long_task">long task </a>of the load process finishes and the UI is available for user interaction with delay.</p>
<p>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.</p>
<h3 id="提升感知性能">提升感知性能</h3>
<p>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.</p>
<p>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.</p>
<p>There are tips and tricks to follow. Some of these quick tips have full articles if you want to dive deeper.</p>
<p>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 <em>feel</em> faster.</p>
<p>这里有一些技巧有助于提升性能：</p>
<h3 id="最小化初始加载">最小化初始加载</h3>
<p>要提升可感知性能，请最小化页面初始加载。 换句话说，首先下载将实际显示的所有内容，但仅下载实际使用的内容，然后下载其余内容。 因为最终要下载所有资源，所以实际上资源总量并没有改善——实际上还需要增加一些代码。但因为暂不需要的资源被延后加载了，所以用户并不会感知资源量的增加，而会感受到页面加载更快了。 </p>
<p>为了最大程度地<a href="https://onilab.com/blog/perceived-performance-vs-actual-load-time-5-secrets-of-lightning-fast-magento-store/">减少初始加载资源</a>，请从内容中分离交互式功能，以便优先加载初始化时所需的可见内容——文本、样式和图像。 延迟加载其余资源。</p>
<p>不要加载初始页面未使用或看不到的图像或脚本，而在页面可用后延时加载，或在需要使用时按需加载。 在初始页面加载之后加载其他资源可提高感知性能。 在初始请求中加载基本数据，并仅根据需要逐步加载功能部件和数据，有助于改善低带宽和低规格硬件的体验。</p>
<p>此外，您应该优化需加载的资源。 图片和视频应以最佳格式、压缩后的大小和正确尺寸进行投放。</p>
<h3 id="防止内容跳转和其他重排">防止内容跳转和其他重排</h3>
<p>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.</p>
<h3 id="避免字体文件延迟">避免字体文件延迟</h3>
<p>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.</p>
<p>Make fallback fonts the same size and weight so that when fonts load the page change is less noticeable.</p>
<h3 id="交互类元素是可交互的">交互类元素是可交互的</h3>
<p>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.</p>
<p>Make things like type-ahead a progressive enhancement: use css to display input modal, JS to add typeahead/autocomplete as it is available</p>
<h3 id="使任务启动器显得更具交互性">使任务启动器显得更具交互性</h3>
<p>在按下按键而不是等待按键弹起时发出请求，可以使感知的内容加载减少200毫秒。在 KEYUP 后添加一个有趣但不显眼的200毫秒动画，甚至可以再降低200毫秒的加载感知。 您并没有节省400毫秒的时间，但是用户直到真正等待内容时，才感觉到他们在等待内容。</p>
<h2 id="总结">总结</h2>
<p>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.</p>
<p>{{PreviousMenuNext("Learn/Performance/what_is_web_performance", "Learn/Performance/Measuring_performance", "Learn/Performance")}}</p>
<h2 id="In_this_module">In this module</h2>
<ul>
<li><a href="/en-US/docs/Learn/Performance/why_web_performance">The "why" of web performance</a></li>
<li><a href="/en-US/docs/Learn/Performance/What_is_web_performance">What is web performance?</a></li>
<li><a href="/en-US/docs/Learn/Performance/Perceived_performance">How do users perceive performance?</a></li>
<li><a href="/en-US/docs/Learn/Performance/Measuring_performance">Measuring performance</a></li>
<li><a href="/en-US/docs/Learn/Performance/Multimedia">Multimedia: images</a></li>
<li><a href="/en-US/docs/Learn/Performance/video">Multimedia: video</a></li>
<li><a href="/en-US/docs/Learn/Performance/JavaScript">JavaScript performance best practices</a>.</li>
<li><a href="/en-US/docs/Learn/Performance/HTML">HTML performance features</a></li>
<li><a href="/en-US/docs/Learn/Performance/CSS">CSS performance features</a></li>
<li><a href="/en-US/docs/Learn/Performance/Fonts">Fonts and performance</a></li>
<li><a href="/en-US/docs/Learn/Performance/Mobile">Mobile performance</a></li>
<li><a href="/en-US/docs/Learn/Performance/business_case_for_performance">Focusing on performance</a></li>
</ul>
|
