Skip to content
This repository was archived by the owner on Aug 10, 2022. It is now read-only.

Commit 8d29647

Browse files
petelepetele
authored
Merge pull request #3693 from kaycebasques/lighthouse-audits
add moar lighthouse references
2 parents 1bde0db + 23aeff7 commit 8d29647

9 files changed

+376
-6
lines changed

‎src/content/en/tools/lighthouse/_toc.yaml

Lines changed: 22 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -7,13 +7,29 @@ toc:
77
section:
88
- title: Cache Contains start_url From Manifest
99
path: /web/tools/lighthouse/audits/cache-contains-start_url
10-
- title: URL Responds with a 200 When Offline
11-
path: /web/tools/lighthouse/audits/http-200-when-offline
10+
- title: Content Size Correctly for Viewport
11+
path: /web/tools/lighthouse/audits/content-sized-correctly-for-viewport
12+
- title: Critical Request Chains
13+
path: /web/tools/lighthouse/audits/critical-request-chains
14+
- title: Estimated Input Latency
15+
path: /web/tools/lighthouse/audits/estimated-input-latency
16+
- title: First Meaningful Paint
17+
path: /web/tools/lighthouse/audits/first-meaningful-paint
18+
- title: Has a Registered Service Worker
19+
path: /web/tools/lighthouse/audits/registered-service-worker
20+
- title: HTML Has Viewport Meta Tag
21+
path: /web/tools/lighthouse/audits/has-viewport-meta-tag
22+
- title: Page Contains Some Content When Its Scripts Are Not Available
23+
path: /web/tools/lighthouse/audits/no-js
1224
- title: Site Redirects HTTP Traffic to HTTPS
1325
path: /web/tools/lighthouse/audits/http-redirects-to-https
1426
- title: Site is on HTTPS
1527
path: /web/tools/lighthouse/audits/https
16-
- title: Page Contains Some Content When Its Scripts Are Not Available
17-
path: /web/tools/lighthouse/audits/no-js
18-
- title: Has a Registered Service Worker
19-
path: /web/tools/lighthouse/audits/registered-service-worker
28+
- title: Speed Index
29+
path: /web/tools/lighthouse/audits/speed-index
30+
- title: Time to Interactive
31+
path: /web/tools/lighthouse/audits/time-to-interactive
32+
- title: URL Responds with a 200 When Offline
33+
path: /web/tools/lighthouse/audits/http-200-when-offline
34+
- title: User Timing Marks and Measures
35+
path: /web/tools/lighthouse/audits/user-timing

‎src/content/en/tools/lighthouse/audits/content-sized-correctly-for-viewport.md

Lines changed: 35 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,35 @@
1+
project_path: /web/_project.yaml
2+
book_path: /web/tools/_book.yaml
3+
description: Reference documentation for the "Content Sized Correctly for Viewport" Lighthouse audit.
4+
5+
{# wf_updated_on: 2016-10-04 #}
6+
{# wf_published_on: 2016-10-04 #}
7+
8+
# Content Sized Correctly for Viewport {: .page-title }
9+
10+
## Why the audit is important {: #why }
11+
12+
This audit checks that the width of the content on your page is equal
13+
to the width of the viewport. When content width is smaller or larger than
14+
viewport width, that's often a cue that the page is not optimized for
15+
mobile screens.
16+
17+
## How to pass the audit {: #how }
18+
19+
This audit is a roundabout way of determining if your page is optimized for
20+
mobile devices. If your site is not optimized and you want it to be, then see
21+
[Responsive Web Design Basics](/web/fundamentals/design-and-ui/responsive/)
22+
to get started.
23+
24+
You can ignore this audit if:
25+
26+
* Your site does not need to be optimized for mobile screens.
27+
* The content width of your page is intentionally smaller or larger than the
28+
viewport width.
29+
30+
## What the audit tests for {: #what }
31+
32+
*Use this information to determine if the audit is relevant to your needs
33+
or is returning incorrect results.*
34+
35+
The audit passes if `window.innerWidth === window.outerWidth`.

‎src/content/en/tools/lighthouse/audits/critical-request-chains.md

Lines changed: 74 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,74 @@
1+
project_path: /web/_project.yaml
2+
book_path: /web/tools/_book.yaml
3+
description: Reference documentation for the "Critical Request Chains" Lighthouse audit.
4+
5+
{# wf_updated_on: 2016-10-06 #}
6+
{# wf_published_on: 2016-10-06 #}
7+
8+
# Critical Request Chains {: .page-title }
9+
10+
## Why the audit is important {: #why }
11+
12+
The Critical Request Chain is a concept from the Critical Rendering Path (CRP)
13+
optimization strategy. CRP enables the browser to load a page as quickly as
14+
possible by prioritizing which resources get loaded and the order in which
15+
they load.
16+
17+
Check out the [Critical Rendering
18+
Path](/web/fundamentals/performance/critical-rendering-path/) docs to learn
19+
more.
20+
21+
## How to pass the audit {: #how }
22+
23+
This audit is currently not structured as something to "pass" or "fail". The
24+
information that this audit provides gives you an opportunity to improve
25+
the page load performance of your app.
26+
27+
In the Chrome Extension version of Lighthouse, your report generates a diagram
28+
like the following:
29+
30+
```
31+
Initial navigation
32+
|---lighthouse/ (developers.google.com)
33+
|---/css (fonts.googleapis.com) - 1058.34ms, 72.80KB
34+
|---css/devsite-googler-buttons.css (developers.google.com) - 1147.25ms, 70.77KB
35+
|---jsi18n/ (developers.google.com) - 1155.12ms, 71.20KB
36+
|---css/devsite-google-blue.css (developers.google.com) - 2034.57ms, 85.83KB
37+
|---2.2.0/jquery.min.js (ajax.googleapis.com) - 2699.55ms, 99.92KB
38+
|---contributors/kaycebasques.jpg (developers.google.com) - 2841.54ms, 84.74KB
39+
|---MC30SXJEli4/photo.jpg (lh3.googleusercontent.com) - 3200.39ms, 73.59KB
40+
```
41+
42+
This diagram represents the page's critical request chains. The path from
43+
`lighthouse/` to `/css` is one chain. The path from `lighthouse/` to
44+
`css/devsite-googler-buttons.css` is another chain. And so on. The top-most
45+
score of the audit represents this number of chains. For example, the diagram
46+
above would have a "score" of seven.
47+
48+
The diagram also breaks down how much time was spent downloading each
49+
resource, and the number of bytes that was required to download each resource.
50+
51+
You can use this diagram to improve your CRP by:
52+
53+
* Minimizing the number of critical resources: eliminating them, deferring
54+
their download, marking them as async, and so on.
55+
* Optimizing the number of critical bytes to reduce the download time (number
56+
of roundtrips).
57+
* Optimizing the order in which the remaining critical resources are loaded:
58+
downloading all critical assets as early as possible to shorten the critical
59+
path length.
60+
61+
Optimizing any of these factors results in a faster page load.
62+
63+
## What the audit tests for {: #what }
64+
65+
*Use this information to determine if the audit is relevant to your needs
66+
or is returning incorrect results.*
67+
68+
Lighthouse uses network priority as a proxy for identifying render-blocking
69+
critical resources. See [Chrome Resource Priorities and
70+
Scheduling](https://docs.google.com/document/d/1bCDuq9H1ih9iNjgzyAL0gpwNFiEP4TZS-YLRp_RuMlc)
71+
for more information on how Chrome defines these priorities.
72+
73+
Data on critical request chains, resource sizes, and time spent downloading
74+
resources is extracted from the Chrome Debugger Protocol.

‎src/content/en/tools/lighthouse/audits/estimated-input-latency.md

Lines changed: 59 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,59 @@
1+
project_path: /web/_project.yaml
2+
book_path: /web/tools/_book.yaml
3+
description: Reference documentation for the "Estimated Input Latency" Lighthouse audit.
4+
5+
{# wf_updated_on: 2016-10-05 #}
6+
{# wf_published_on: 2016-10-05 #}
7+
8+
# Estimated Input Latency {: .page-title }
9+
10+
## Why the audit is important {: #why }
11+
12+
Input responsiveness is a key factor in how users perceive the performance
13+
of your app. Apps have 100ms to respond to user input. Any longer than that,
14+
and the user perceives the app as laggy. See [Measure Performance with the RAIL
15+
Model](/web/fundamentals/performance/rail) for more information.
16+
17+
See the [What the audit tests for](#what) section of this doc for an
18+
explanation of why this audit tests for a target score of 50ms (rather than
19+
100ms, which is what the RAIL model recommends).
20+
21+
## How to pass the audit {: #how }
22+
23+
To make your app respond to user input faster, you need to optimize how
24+
your code runs in the browser. Check out the series of techniques outlined
25+
in the [Rendering Performance](/web/fundamentals/performance/rendering/)
26+
docs. These tips range from offloading computation to web workers in order
27+
to free up the main thread, to refactoring your CSS selectors to perform
28+
less calculations, to using CSS properties that minimize the amount of
29+
browser-intensive operations.
30+
31+
One important caveat of this audit is that it's not a complete measurement of
32+
input latency. As explained in the [What this doc tests for](#what) section
33+
of this doc, this audit does not measure how long your app truly takes
34+
to respond to a user input. In other words, it does not measure that your app's
35+
response to the user's input is visually complete.
36+
37+
To measure this manually, make a recording with the
38+
Chrome DevTools Timeline. See [How to use the Timeline
39+
Tool](/web/tools/chrome-devtools/evaluate-performance/timeline-tool) for more
40+
help. The basic idea is to start a recording, perform the user input that
41+
you want to measure, stop the recording, and then analyze the flame chart
42+
to ensure that all stages of [the pixel
43+
pipeline](/web/fundamentals/performance/rendering/#the_pixel_pipeline) are
44+
complete within 50ms.
45+
46+
## What the audit tests for {: #what }
47+
48+
*Use this information to determine if the audit is relevant to your needs
49+
or is returning incorrect results.*
50+
51+
The RAIL performance model recommends that apps respond to user input within
52+
100ms, whereas Lighthouse's target score is 50ms. Why?
53+
54+
The reason is that Lighthouse uses a proxy metric to measure how well your
55+
app responds to user input: availability of the main thread. Lighthouse
56+
assumes that your app needs 50ms to completely respond to the user's input
57+
(from performing any JavaScript executions to physically painting the new
58+
pixels to the screen). If your main thread is unavailable for 50ms or more,
59+
that does not leave enough time for your app to complete the response.

‎src/content/en/tools/lighthouse/audits/first-meaningful-paint.md

Lines changed: 34 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,34 @@
1+
project_path: /web/_project.yaml
2+
book_path: /web/tools/_book.yaml
3+
description: Reference documentation for the "First Meaningful Paint" Lighthouse audit.
4+
5+
{# wf_updated_on: 2016-10-05 #}
6+
{# wf_published_on: 2016-10-05 #}
7+
8+
# First Meaningful Paint {: .page-title }
9+
10+
## Why the audit is important {: #why }
11+
12+
Page load is a key aspect of how a user perceives the performance of your
13+
page. See [Measure Performance with the RAIL Method](/web/fundamentals/performance/rail) for more information.
14+
15+
This audit identifies the time at which the user feels that the primary
16+
content of the page is visible.
17+
18+
## How to pass the audit {: #how }
19+
20+
The lower your First Meaningful Paint score, the faster that the page
21+
appears to display its primary content.
22+
23+
[Optimizing the Critical Rendering Path](/web/fundamentals/performance/critical-rendering-path/)
24+
is particularly helpful towards achieving a faster First Meaningful Paint.
25+
26+
## What the audit tests for {: #what }
27+
28+
*Use this information to determine if the audit is relevant to your needs
29+
or is returning incorrect results.*
30+
31+
First Meaningful Paint is essentially the paint after which the biggest
32+
above-the-fold layout change has happened, and web fonts have loaded. See the
33+
spec to learn more:
34+
[First Meaningful Paint: A Layout-Based Aproach](https://docs.google.com/document/d/1BR94tJdZLsin5poeet0XoTW60M0SjvOJQttKT-JK8HI/view).

‎src/content/en/tools/lighthouse/audits/has-viewport-meta-tag.md

Lines changed: 43 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,43 @@
1+
project_path: /web/_project.yaml
2+
book_path: /web/tools/_book.yaml
3+
description: Reference documentation for the "HTML Has a Viewport Meta Tag" Lighthouse audit.
4+
5+
{# wf_updated_on: 2016-10-04 #}
6+
{# wf_published_on: 2016-10-04 #}
7+
8+
# HTML Has a Viewport Meta Tag {: .page-title }
9+
10+
## Why the audit is important {: #why }
11+
12+
Without a viewport meta tag, mobile devices render pages at typical desktop
13+
screen widths, and then scale the pages to fit the mobile screens. Setting
14+
the viewport enables you to control the width and scaling of the viewport.
15+
Check out the following links to learn more:
16+
17+
* [Configure the Viewport](/speed/docs/insights/ConfigureViewport).
18+
* [Set the Viewport](/web/fundamentals/design-and-ui/responsive/#set-the-viewport).
19+
20+
## How to pass the audit {: #how }
21+
22+
Add a viewport `<meta>` tag in the `<head>` of your HTML.
23+
24+
<head>
25+
...
26+
<meta name="viewport" content="width=device-width, initial-scale=1">
27+
...
28+
</head>
29+
30+
The `width=device-width` key-value pair sets the width of the viewport to
31+
the width of the device. The `initial-scale=1` key-value pair sets the initial
32+
zoom level when visiting the page.
33+
34+
## What the audit tests for {: #what }
35+
36+
*Use this information to determine if the audit is relevant to your needs
37+
or is returning incorrect results.*
38+
39+
Lighthouse checks that there's a `<meta name="viewport">` tag in the `<head>`
40+
of the document. It also checks that the node contains a `content` attribute
41+
and that the value of this attribute contains the text `width=`. However,
42+
it does not check that `width` equals `device-width`. Lighthouse also does not
43+
check for a `initial-scale` key-value pair.

‎src/content/en/tools/lighthouse/audits/speed-index.md

Lines changed: 38 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,38 @@
1+
project_path: /web/_project.yaml
2+
book_path: /web/tools/_book.yaml
3+
description: Reference documentation for the "Speed Index" Lighthouse audit.
4+
5+
{# wf_updated_on: 2016-10-04 #}
6+
{# wf_published_on: 2016-10-04 #}
7+
8+
# Speed Index {: .page-title }
9+
10+
## Why the audit is important {: #why }
11+
12+
Speed Index is a page load performance metric that shows you how quickly
13+
the contents of a page are visibly populated. The lower the score, the better.
14+
15+
## How to pass the audit {: #how }
16+
17+
To lower your Speed Index score, you need to optimize your page to visually
18+
load faster. Two good starting places are:
19+
20+
* [Optimizing Content Efficiency](/web/fundamentals/performance/optimizing-content-efficiency/).
21+
* [Optimizing the Critical Rendering Path](/web/fundamentals/performance/critical-rendering-path/).
22+
23+
## What the audit tests for {: #what }
24+
25+
*Use this information to determine if the audit is relevant to your needs
26+
or is returning incorrect results.*
27+
28+
Lighthouse uses a node module called
29+
[Speedline](https://github.com/pmdartus/speedline)
30+
to generate the Speed Index score.
31+
32+
For more information on the algorithms and methodologies behind Speed Index,
33+
see [Speed Index](https://sites.google.com/a/webpagetest.org/docs/using-webpagetest/metrics/speed-index).
34+
35+
The target score is computed by a cumulative distribution function of a
36+
log-normal distribution. Check out the comments in the
37+
[source](https://github.com/GoogleChrome/lighthouse/blob/master/lighthouse-core/audits/speed-index-metric.js)
38+
of the audit if you need to know more.

‎src/content/en/tools/lighthouse/audits/time-to-interactive.md

Lines changed: 33 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,33 @@
1+
project_path: /web/_project.yaml
2+
book_path: /web/tools/_book.yaml
3+
description: Reference documentation for the "Time to Interactive" Lighthouse audit.
4+
5+
{# wf_updated_on: 2016-10-05 #}
6+
{# wf_published_on: 2016-10-05 #}
7+
8+
# Time to Interactive {: .page-title }
9+
10+
## Why the audit is important {: #why }
11+
12+
Page load is a key aspect of how a user perceives the performance of your
13+
page. See [Measure Performance with the RAIL Method](/web/fundamentals/performance/rail) for more information.
14+
15+
This audit identifies the time at which a page appears to be ready enough that
16+
a user can interact with it.
17+
18+
## How to pass the audit {: #how }
19+
20+
Check out the resources in the [How to pass the audit](speed-index#how) section
21+
of the Speed Index audit for more help on improving page load performance.
22+
The lower your Time to Interactive score, the better.
23+
24+
## What the audit tests for {: #what }
25+
26+
*Use this information to determine if the audit is relevant to your needs
27+
or is returning incorrect results.*
28+
29+
Time to Interactive is defined as the point at which layout has stabilized,
30+
key webfonts are visible, and the main thread is available enough to handle
31+
user input.
32+
33+
Note that this metric is in early phases and is subject to change.

‎src/content/en/tools/lighthouse/audits/user-timing.md

Lines changed: 38 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,38 @@
1+
project_path: /web/_project.yaml
2+
book_path: /web/tools/_book.yaml
3+
description: Reference documentation for the "User Timing Marks and Measures" Lighthouse audit.
4+
5+
{# wf_updated_on: 2016-10-06 #}
6+
{# wf_published_on: 2016-10-06 #}
7+
8+
# User Timing Marks and Measures {: .page-title }
9+
10+
## Why the audit is important {: #why }
11+
12+
The User Timing API enables you to measure your app's JavaScript performance.
13+
The basic idea is that you decide which parts of your scripts you want to
14+
optimize, and then you instrument those parts of your scripts with the User
15+
Timing API. From there, you can access the results from JavaScript using the
16+
API, or view them on your [Chrome DevTools Timeline
17+
Recordings](/web/tools/chrome-devtools/evaluate-performance/timeline-tool).
18+
19+
## How to pass the audit {: #how }
20+
21+
This audit is not structured as a "pass" or "fail" test. It's just an
22+
opportunity to discover a useful API that can aid you in measuring your app's
23+
performance. The score that Lighthouse reports for this audit corresponds to the
24+
number of User Timing Marks and Measures that it finds in your app.
25+
26+
When your app does include User Timing Marks and Measures, you'll see these
27+
Marks and Measures in your Lighthouse report.
28+
29+
Check out [User Timing API](https://www.html5rocks.com/en/tutorials/webperformance/usertiming/)
30+
for an introduction on using the User Timing API to measure your app's
31+
JavaScript performance.
32+
33+
## What the audit tests for {: #what }
34+
35+
*Use this information to determine if the audit is relevant to your needs
36+
or is returning incorrect results.*
37+
38+
Lighthouse extracts User Timing data from Chrome's Trace Event Profiling Tool.

0 commit comments

Comments
 (0)