Skip to content

Commit 61207be

Browse files
authored
docs: emphasize some points on what makes a good audit
1 parent 6330d77 commit 61207be

File tree

4 files changed

+38
-12
lines changed

4 files changed

+38
-12
lines changed

assets/detail-type-examples.png

319 KB
Loading

docs/new-audits.md

+36-11
Original file line numberDiff line numberDiff line change
@@ -3,19 +3,44 @@ document is to help you understand what constitutes as a "good" audit for Lighth
33
to propose a new audit.
44

55
## New audit principles
6-
Lighthouse audits that surface in the report should be:
7-
- Applicable to a significant portion of web developers (based on scale and severity of impact)
8-
- Contribute significantly towards making the mobile web experience better for end users.
9-
- Not have a significant impact on our runtime performance or bundle size.
10-
- Something that is new, and not something that is already measured by existing audits.
11-
- Important for our strategic goals as a product.
12-
- Measurable (especially for performance audits) or have clear pass/fail states.
13-
- Not use 3rd party APIs for completing the audit check.
146

7+
Lighthouse audits that surface in the report should:
8+
- be applicable to a significant portion of web developers (based on scale and severity of impact)
9+
- contribute significantly towards making the mobile web experience better for end users.
10+
- not have a significant impact on our runtime performance or bundle size.
11+
- be new, not something that is already measured by existing audits.
12+
- be measurable (especially for performance audits) or have clear pass/fail states.
13+
- be actionable - when failing, specific advice should be given. If the failure can be tied to a specific resource (a DOM element, script, line of code), use the appropriate detail type (see below). If multiple failures can occur for a page, return a table.
14+
- not use 3rd party APIs for completing the audit check.
15+
16+
## Actionability
17+
18+
1. Specific advice should be given if the audit fails. If an audit can fail in multiple ways, each way should have specific guidance that the user should take to resolve the problem.
19+
1. If the failure can be applied to a specific resource, use the appropriate detail type (see subsection).
20+
1. If multiple failures can occur on a single page, show each (use a table - don't just return a binary score).
21+
22+
### Detail Types
23+
24+
An audit can return a number of different [detail types](https://github.com/GoogleChrome/lighthouse/blob/master/types/audit-details.d.ts).
25+
26+
| detail type | resource | notes |
27+
|---------------------------|-----------------------|----------------------------------------|
28+
| `'node'` | DOM element | set path to a devtoolsNodePath |
29+
| `'source-location'` | Code Network Resource | use to point to specific line, column |
30+
| `'code'` | N/A; freeform | render as monospace font `like this` |
31+
| `'url'` | Network Resource | we will make it a pretty link |
32+
| `'thumbnail'` | Image Resource | same as above, but we show a thumbnail |
33+
| `'link'` | - | arbitrary link / url combination |
34+
| `'text'\|'ms'\|'numeric'` | - | |
35+
36+
37+
<!--- https://docs.google.com/document/d/1KS6PGPYDfE_TWrRdw55Rd67P-g_MU4KdMetT3cTPHjI/edit#heading=h.32w9jjm4c70w -->
38+
![Detail type examples](../assets/detail-type-examples.png)
1539

1640
## Process for creating a new audit
17-
1. Briefly scan the criteria we’ve laid out above. If you think the principles match with your proposed new audit, then proceed!
18-
2. Next step is to create an issue on GitHub with answers to the following questions:
41+
42+
1. Scan the criteria we’ve laid out above. If you think the principles match with your proposed new audit, then proceed!
43+
1. Next step is to create an issue on GitHub with answers to the following questions:
1944
```
2045
#### Provide a basic description of the audit
2146
#### How would the audit appear in the report?
@@ -34,4 +59,4 @@ Lighthouse audits that surface in the report should be:
3459
```
3560
3. Once the proposal is submitted, then Lighthouse team will take a look and followup. We will discuss possible implementation approaches, and associated runtime overhead.
3661
With this new information we can better understand the impl cost and effort required and prioritize the audit into our sprint/roadmap.
37-
4. Depending on the prioritization, we'll then work with you to figure out the necessary engineering/UX/product details.
62+
1. Depending on the prioritization, we'll then work with you to figure out the necessary engineering/UX/product details.

docs/plugins.md

+1-1
Original file line numberDiff line numberDiff line change
@@ -17,7 +17,7 @@
1717

1818
## Introduction
1919

20-
If you're new to Lighthouse development, start by reading up on the overall [architecture](./architecture.md) and how [configuration](./configuration.md) works before continuing.
20+
If you're new to Lighthouse development, start by reading up on the overall [architecture](./architecture.md), how [configuration](./configuration.md) works, and what makes a [good audit](./new-audits.md) before continuing.
2121

2222
### What is a Lighthouse Plugin?
2323

readme.md

+1
Original file line numberDiff line numberDiff line change
@@ -232,6 +232,7 @@ Useful documentation, examples, and recipes to get you started.
232232
- [Using Lighthouse programmatically](./docs/readme.md#using-programmatically)
233233
- [Testing a site with authentication](./docs/authenticated-pages.md)
234234
- [Developing Plugins](./docs/plugins.md)
235+
- [Making a New Audit](./docs/new-audits.md)
235236
- [Testing on a mobile device](./docs/readme.md#testing-on-a-mobile-device)
236237
- [Lighthouse Architecture](./docs/architecture.md)
237238

0 commit comments

Comments
 (0)