Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Perceived performance update #2918

Merged
merged 3 commits into from
Mar 9, 2021
Merged

Perceived performance update #2918

Changes from 1 commit
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
0596a7a
Perceived performance - reorg
hamishwillee Mar 8, 2021
2f1d0a1
Feedback fixes and cut back glossary
hamishwillee Mar 8, 2021
5475e18
Further fixes
hamishwillee Mar 9, 2021
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
57 changes: 33 additions & 24 deletions files/en-us/learn/performance/perceived_performance/index.html
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -9,9 +9,9 @@

<div>{{PreviousMenuNext("Learn/Performance/what_is_web_performance", "Learn/Performance/Measuring_performance", "Learn/Performance")}}</div>

<p><span class="seoSummary"><strong><a href="/en-US/docs/Glossary/Perceived_performance">Perceived performance</a></strong> is how fast a website seems to the user.</span> 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.</p>
<p><span class="seoSummary"><strong><a href="/en-US/docs/Glossary/Perceived_performance">Perceived performance</a></strong> is a subjective measure of website performance, responsiveness and reliability.</span> It is harder to quantify and measure than the actual speed of operation, but perhaps even more important.</p>
hamishwillee marked this conversation as resolved.
Show resolved Hide resolved

<p>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.</p>
<p>This article provides a brief introduction to the factors that affect perceived performance, along with a number of tools for assessing and improving the perception.</p>

<table class="learn-box standard-table">
<tbody>
Expand All @@ -26,33 +26,43 @@
</tbody>
</table>

<p>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 unavailability 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="Overview">Overview</h2>
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@chrisdavidmills FYI, I did try to change this id to lower case "o" but that made the rendered heading disappear. I very much want the heading, so changed it back.


<h2 id="Perceived_performance">Perceived performance</h2>
<p>The perception of how quickly (and smoothly) pages load and respond to user interaction is even more important that the actual time required to fetch the resources. While you may not be able to physically make your site run faster, you may well be able to improve how fast it <em>feels</em> for your users.</p>

<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 other sections can't be improved.</p>
<p>A good general rule for improving perceived performance is that it is usually better to provide a quick response and regular status updates than make the user wait until an operation fully completes (before providing any information). For example, when loading a page it is better to display the text when it arrives rather than wait for all the images and other resources. Even though the content has not fully downloaded the user can see something is happening and they can start interacting with the content.</p>

<p>There is no unicorn metric that can measure what the user feels, but metrics are useful in gauging 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>
<div class="notecard note">
<h4>Note</h4>
<p>Subjective time passes more quickly for users who are actively engaged, distracted, or entertained, than those who are waiting passively for something to happen. Where possible, actively engage and inform users who are waiting for a task to complete.</p>
hamishwillee marked this conversation as resolved.
Show resolved Hide resolved
</div>

<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 noticeable. 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 significance, 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, defined 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>Similarly, it is better to display a "loading animation" as soon as a user clicks a link to perform a long running animation. This makes the site feel more responsive, and the user is informed that the site is working/not frozen.</p>
hamishwillee marked this conversation as resolved.
Show resolved Hide resolved

<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>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Couple of bits here:

  1. remove comma after "time to interactive" link.
  2. spacing needs sorting out in <a href="/en-US/docs/Glossary/Long_task">long task </a>of
  3. "available for user interaction with delay" sounds confusing. What does that mean?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I deleted all this crap yesterday, so no fix to do :-)

<h2 id="Perceived_performance">Performance metrics</h2>
hamishwillee marked this conversation as resolved.
Show resolved Hide resolved

<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>
<p>There is no single metric or test that can be run on site to evaluate how a user "feels". However there are a number of metrics that can be "useful indicators":</p>
hamishwillee marked this conversation as resolved.
Show resolved Hide resolved

<h3 id="Improving_perceived_performance">Improving perceived performance</h3>
<dl>
<dt><a href="/en-US/docs/Glossary/First_paint">First paint</a></dt>
<dd>The time to start of first paint operation. Note that this change may not be visible; it can be a simple background color update or something even less noticeable.</dd>
<dt><a href="/en-US/docs/Glossary/First_contentful_paint">First Contentful Paint</a> (FCP)</dt>
<dd>The time until first significant rendering (e.g. of text, foreground or background image, canvas or SVG, etc.).Note that just because there's content, doesn't mean it's useful content or that the user has content to consume.</dd>
hamishwillee marked this conversation as resolved.
Show resolved Hide resolved
<dt><a href="/en-US/docs/Glossary/first_meaningful_paint">First Meaningful Paint</a> (FMP)</dt>
<dd>The time at which useful content is rendered to the screen.</dd>
<dt><a href="https://wicg.github.io/largest-contentful-paint/">Largest Contentful Paint</a> (LCP)</dt>
<dd>The render time of the largest content element visible in the viewport.</dd>
<dt><a href="/en-US/docs/Glossary/Speed_index">Speed index</a></dt>
<dd>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.</dd>
hamishwillee marked this conversation as resolved.
Show resolved Hide resolved
<dt><a href="/en-US/docs/Glossary/Time_to_interactive">Time to interactive</a></dt>
<dd>Time until the UI is available for user interaction (i.e. the last <a href="/en-US/docs/Glossary/Long_task">long task</a> of the load process finishes).</dd>
</dl>

<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 entertained, 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>
<h2 id="Improving_performance">Improving performance</h2>
hamishwillee marked this conversation as resolved.
Show resolved Hide resolved

<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>Here are a few tips and tricks to help improve performance:</p>
<p>Here are a few tips and tricks to help improve perceived performance:</p>

<h3 id="Minimize_initial_load">Minimize initial load</h3>

Expand All @@ -70,15 +80,15 @@ <h3 id="Prevent_jumping_content_and_other_reflows">Prevent jumping content and o

<h3 id="Avoid_font_file_delays">Avoid font file delays</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>Font choice is important. Selecting an appropriate font can greatly improve the user experience. From a perceived performance point of view, "suboptimal fonts importing" can result in flicker as text is styled or when falling back to other fonts.</p>

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

<h3 id="Interactive_elements_are_interactive">Interactive elements are interactive</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 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 behaving poorly 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>
<p>Make things like type-ahead a progressive enhancement: use CSS to display input modal, JS to add autocomplete as it is available</p>

<h3 id="Make_task_initiators_appear_more_interactive">Make task initiators appear more interactive</h3>

Expand All @@ -99,10 +109,9 @@ <h2 id="In_this_module">In this module</h2>
<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/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>
<li><a href="/en-US/docs/Learn/Performance/business_case_for_performance">Business case for performance</a></li>
</ul>