Updated Performance content #249
Conversation
src/content/en/2019/performance.md
Outdated
| --- | ||
|
|
||
| ## Intro | ||
|
|
||
| Performance is a visceral part of the user experience. For [many websites](https://wpostats.com/), an improvement to the user experience by speeding up the page load time aligns with an improvement to conversion rates. Conversely, when performance is poor, users don't convert as often and have even been observed [rage clicking](https://blog.fullstory.com/rage-clicks-turn-analytics-into-actionable-insights/) on the page in frustration. | ||
|
|
||
| There are many ways to quantify web performance. The most important thing is to measure what actually matters to users. Events like `onload` or `DOM content loaded` may not necessarily reflect what users experience visually. For example, an email client might have a very fast onload event but the only thing loaded is the interstitial progress bar, meanwhile the inbox contents are loading asynchronously. The loading metric that matters for this web app is the "time to inbox", and focusing on the `onload` event may be misleading. For that reason this chapter will look at more modern and universally applicable paint, load, and interactivity metrics to try to capture how users are actually experiencing the page. | ||
| There are many ways to quantify web performance. The most important thing is to measure what actually matters to users. However, events like `onload` or `DOMContentLoaded` may not necessarily reflect what users experience visually. For example, an email client might have a very fast `onload` time but the only thing loaded is the interstitial progress bar, meanwhile the inbox contents are loading asynchronously. The loading metric that matters for this web app is the "time to inbox", and focusing on the `onload` event may be misleading. For that reason this chapter will look at more modern and universally applicable paint, load, and interactivity metrics to try to capture how users are actually experiencing the page. |
There was a problem hiding this comment.
the only thing loaded is the interstitial progress bar, meanwhile the inbox contents are loading asynchronously
Can you make it a bit more clear that the inbox is currently empty and has not finished loading yet?
There was a problem hiding this comment.
Rewrote this part. PTAL.
| <figcaption>Figure 6. Distribution of websites labelled as having fast, average, or slow FCP, broken down by device type.</figcaption> | ||
| <figure id="fig5"> | ||
| <iframe width="600" height="371" seamless frameborder="0" scrolling="no" src="https://docs.google.com/spreadsheets/d/e/2PACX-1vSQlf3_ySLPB5322aTumUZhbVGdaUdkmi1Hs4bYuO3Z1kqM4xspx7REbwXukwPd_tsOSg6oImzpYLM9/pubchart?oid=486448175&format=interactive"></iframe> | ||
| <figcaption>Figure 5. Distribution of websites labelled as having fast, moderate, or slow FCP, broken down by device type.</figcaption> |
There was a problem hiding this comment.
How should we tackle adding descriptive alt text to all the charts? In a separate PR after charts have been added and copy-editing is complete?
There was a problem hiding this comment.
The figures should all contain a figcaption where we describe the contents of the figure. Then in the paragraphs before/after the figure we should be describing what the key takeaways are from the chart. So even if we don't convey all of the detail of the visualization ("desktop Foo is X%, mobile Foo is Y%, desktop Bar is Z%, etc") we're still getting the point across in text so that it's understandable to all readers.
How does that sound?
There was a problem hiding this comment.
I don't think every chapter has been written in a way that spells out what each of the values in the charts are. We might have to do a lot of editing...
Think the best solution may be to have a short figcaption like you are describing, but also have additional screen reader only (see CSS Clip) content in the figcaptions as well.
If we do this, I could put together some templates to follow so we get descriptions like below... but it still might be tough to get all this text written by the deadline...
<insert graphic of metric 09_26>
*Figure 2. Percentage of sites that disable zooming and scaling vs device type*
Alt text: Figure 2. Vertical grouped bar chart titled "Are zooming and scaling enabled?" measuring percentage data, ranging from 0 to 80 in increments of 20, vs. the device type, grouped into desktop and mobile. Desktop enabled: 75.46%; Desktop disabled 24.54%; Mobile enabled: 67.79%; Mobile disabled: 32.21%.
There was a problem hiding this comment.
Yeah, having longer descriptions in off-screen figcaptions seems like a reasonable approach. I agree it would be tough to get that for all chapters by launch.
Closes #171
Progress on #237