lighthouse 8.0.0-dev.20210709 → 8.0.0

package/docs/v8-perf-faq.md

@@ -0,0 +1,244 @@
+# v8.0 Performance FAQ
+
+### Give me a summary of the perf score changes in v8.0. What's new/different?
+
+First, it may be useful to refresh on [the math behind Lighthouse's metric
+scores and performance score.](https://web.dev/performance-scoring/)
+
+In [Lighthouse v8.0](https://github.com/GoogleChrome/lighthouse/releases/tag/v8.0.0), we updated the score curves for FCP and TBT measurements,
+making both a bit more strict. CLS has been updated to its new, [windowed
+definition](https://web.dev/evolving-cls/). Additionally, the Performance
+Score's weighted average was
+[rebalanced](https://googlechrome.github.io/lighthouse/scorecalc/#FCP=3000&SI=5800&FMP=4000&TTI=7300&FCI=6500&LCP=4000&TBT=600&CLS=0.25&device=mobile&version=8&version=6&version=5),
+giving more weight to CLS and TBT than before, and slightly decreasing the
+weights of FCP, SI, and TTI.
+
+From an analysis of HTTP Archive's latest [crawl of the
+web](https://httparchive.org/faq#how-does-the-http-archive-decide-which-urls-to-test),
+we project that the performance score for the majority of sites will stay the
+same or improve in Lighthouse 8.0.
+- ~20% of sites may see a drop of up to 5 points, though likely less
+- ~20% of sites will see little detectable change
+- ~30% of sites should see a moderate improvement of a few points
+- ~30% could see a significant improvement of 5 points or more
+
+The biggest drops in scores are due to TBT scoring becoming stricter and the
+metric's slightly higher weight. The biggest improvements in scores are also due
+to TBT changes in the long tail and the windowing of CLS, and both metrics'
+higher weights.
+
+### What are the exact score weighting changes?
+
+#### Changes by metric
+
+| metric                         | v6 weight | v8 weight | Δ |
+|--------------------------------|-----------|-----------|----------|
+| First Contentful Paint (FCP)   | 15        | **10**    | -5       |
+| Speed Index (SI)               | 15        | **10**    | -5       |
+| Largest Contentful Paint (LCP) | 25        | **25**    | 0        |
+| Time To Interactive (TTI)        | 15        | **10**    | -5       |
+| Total Blocking Time (TBT)        | 25        | **30**    | 5        |
+| Cumulative Layout Shift (CLS)    | 5         | **15**    | 10       |
+
+#### Changes by phase
+
+| phase          | metric                         | v6 phase weight | v8 phase weight | Δ   |
+|----------------|--------------------------------|-----------------|-----------------|-----|
+| early          | First Contentful Paint (FCP)   | 15              | 10              | -5  |
+| mid            | Speed Index (SI)               | 40              | 35              | -5  |
+|                | Largest Contentful Paint (LCP) |                 |                 |     |
+| interactivity  | Time To Interactive (TTI)      | 40              | 40              | 0   |
+|                | Total Blocking Time (TBT)      |                 |                 |     |
+| predictability | Cumulative Layout Shift (CLS)  | 5               | 15              | 10  |
+
+### Why did the weight of CLS go up?
+
+When introduced in Lighthouse v6, it was still early days for the metric.
+There've been [many improvements and
+bugfixes](https://chromium.googlesource.com/chromium/src/+/refs/heads/main/docs/speed/metrics_changelog/cls.md)
+to the CLS metric since then. Now, given its maturity and established placement in Core
+Web Vitals, the weight increases from 5% to 15%.
+
+### Why are the Core Web Vitals metrics weighted differently in the performance score?
+
+The Core Web Vitals metrics are [independent signals in the Page Experience
+ranking
+update](https://support.google.com/webmasters/thread/104436075/core-web-vitals-page-experience-faqs-updated-march-2021).
+Lighthouse weighs each lab equivalent metric based on what we believe creates
+the best incentives to improve overall page experience for users.
+
+LCP, CLS, and TBT are [very good
+metrics](https://chromium.googlesource.com/chromium/src/+/lkgr/docs/speed/good_toplevel_metrics.md)
+and that's why they are the three highest-weighted metrics in the performance
+score.
+
+### How should I think about the Lighthouse performance score in relation to Core Web Vitals?
+
+[Core Web Vitals](https://web.dev/vitals/) refer to a specific set of key user
+experience metrics, their passing thresholds, and percentile at which they're measured.
+In general, CWV's primary focus is field data.
+
+The Lighthouse score is a means to understand the degree of opportunity
+available to improve critical elements of user experience. The lower the score,
+the more likely the user will struggle with load performance, responsiveness, or
+content stability.
+
+Lighthouse's lab-based data overlaps with Core Web Vitals in a few key ways.
+Lighthouse features two of the three core vitals (LCP and CLS) with the exact
+same passing thresholds. There's no user input in a Lighthouse run, so it cannot
+compute FID. Instead, we have TBT, which you can consider a proxy metric for
+FID, and though they measure two different things they are both signals about a
+page's interactivity.
+
+_So CWV and Lighthouse have commonalities, but are different. How can you
+rationalize paying attention to both?_
+
+Ultimately, a combination approach is most effective. Use field data for the
+long-term overview of your user's experience, and use lab data to iterate your
+way to the best experience possible for your users. CrUX data summarizes [the
+most recent 28
+days](https://developers.google.com/web/tools/chrome-user-experience-report/api/reference#data-pipeline),
+so it'll take some time to confidently determine that any change has definite
+impact.
+
+Lighthouse's analysis allows you to debug and optimize in an environment that is
+repeatable with an immediate feedback loop. In addition, lab-based tooling can
+provide significantly more detail than field instrumentation, as it's not
+limited to web-exposed APIs and cross-origin restrictions.
+
+The exact numbers of your lab and field metrics aren't expected to match, but
+any substantial improvement to your lab metrics should be observable in the
+field once it's been deployed. The higher the Lighthouse score, the less you're
+leaving up to chance in the field.
+
+### What blindspots from the field does lab tooling illuminate?
+
+Field data analyzes all successful page loads. Lab tooling analyzes the
+experience of a fixed configuration for a hypothetical user. If every potential
+user in the world successfully loaded an equal number of pages on your site, we
+might not need to focus on the experience of a hypothetical one, but in reality
+we know this isn't the case. Users who have better experiences use your site
+more; that's why we care about performance in the first place! Lab tooling shows
+you the quality of the experience for these hypothetical users that field data
+might be [missing
+entirely](https://blog.chriszacharias.com/page-weight-matters).
+
+Lighthouse mobile reports emulate a slow 4G connection on a mid-tier Android
+device. While field data might not indicate these conditions are especially
+common for your site, analyzing how your site performs in these tougher
+conditions helps expand your site's audience. Lighthouse identifies the worst
+experiences, experiences you can't see in the field because they were so bad the
+user never came back (or waited around in the first place).
+
+### How should I work to optimize CLS differently given that it has been updated?
+
+The [windowing
+adjustment](https://www.google.com/url?q=https://web.dev/evolving-cls/&sa=D&source=editors&ust=1622570731600000&usg=AOvVaw2R7Y5uFrQX7Mpdj__5SdYq)
+will likely not have much effect for the lab measurement, but instead will have
+a large effect on the field CLS for long-lived pages.
+
+Lighthouse 8 introduces another adjustment to our CLS definition: including
+layout shift contributions from subframes. This brings our implementation in
+line with how CrUX computes field CLS. This comes with the implication that
+iframes (including ones you may not control) may be adding layout shifts which
+ultimately affect your CLS score. Keep in mind that the subframe contributions
+are [weighted by the in-viewport
+portion](https://github.com/WICG/layout-instability#cumulative-scores) of the
+iframe.
+
+### Why don't the numbers for TBT and FID match, if TBT is a proxy metric for FID?
+
+The commonality between TBT (collected in a lab environment) and FID (collected
+in a field context) is that they measure the impact on input responsiveness from
+long tasks on the main thread. Beyond that, they're quite different. FID
+captures the delay in handling the first input event of the page, whenever that
+input happened.  TBT roughly captures how dangerous the length of all the main
+thread's tasks are.
+
+It's very possible to have a page that does well on FID, but poorly on TBT.  And
+it's slightly harder, but possible, to do well on TBT but poorly on FID\*.   So,
+you shouldn't expect your TBT and FID measurements to correlate strongly. A
+large-scale analysis found their [Spearman's
+ρ](https://en.wikipedia.org/wiki/Spearman%27s_rank_correlation_coefficient) at
+about 0.40, which indicates a connection, but not one as strong as many would
+prefer.
+
+From the Lighthouse project's perspective, the current passing threshold for FID
+is quite lenient but more importantly, the percentile-of-record for FID (75th
+percentile) is not sufficient for detecting issues. The 95th percentile is a
+much stronger indicator of problematic interactions for this metric. We
+encourage user-centric teams to focus on the 95th percentile of all input delays
+(not just the first) in their field data in order to identify and address
+problems that surface just 5% of the time.
+
+\*Aside: the [Chrome 91 FID change for
+double-tap-to-zoom](https://chromium.googlesource.com/chromium/src.git/+/refs/heads/main/docs/speed/metrics_changelog/2021_05_fid.md)
+fixes a lot of high FID / low TBT cases and may be observable in your field
+metrics, with higher percentiles improving slightly. Most remaining high FID /
+low TBT cases are likely due to incorrect meta viewport tags, which [Lighthouse
+will
+flag](https://www.google.com/url?q=https://web.dev/viewport/&sa=D&source=editors&ust=1622651275263000&usg=AOvVaw1OS_kJ9oNMlPSjIJbFy7c8).
+Delivering a mobile-friendly viewport, reducing main-thread blocking JS, and
+keeping your TBT low is the best defense against bad FID in the field.
+
+### Overall, what motivated the changes to the performance score?
+
+As with all Lighthouse score updates, changes are made to reflect
+the latest in how to measure user-experience quality holistically and accurately,
+and to focus attention on key priorities.
+
+Heavy JS and long tasks are a problem for the web that's
+[worsening](https://httparchive.org/reports/state-of-javascript#bytesJs). Field
+FID is currently too lenient and not sufficiently incentivizing action to
+address the problem. Lighthouse has historically weighed its interactivity
+metrics at 40-55% of the performance score and—as interactivity is key to user
+experience—we maintain a 40% weighting (TBT and TTI together) in Lighthouse
+8.0.
+
+[FCP's score curve was
+adjusted](https://github.com/GoogleChrome/lighthouse/pull/12556) to align with
+the current de facto ["good" threshold](https://web.dev/fcp/#what-is-a-good-fcp-score),
+and as a result will score a bit more strictly.
+
+The curve for TBT was made stricter to [more closely
+approach](https://github.com/GoogleChrome/lighthouse/pull/12576) the ideal score
+curve. TBT has had (and still has) a more lenient curve than our methodology
+dictates, but the new curve is more linear which means there's a larger range
+where improvements in the metric are rewarded with improvements in the score. If
+your page currently scores poorly with TBT, the new curve will be more
+responsive to changes as page performance incrementally improves.
+
+FCP's weight drops slightly from 15% to 10% because it's fairly gameable and is also partly
+captured by Speed Index.
+
+### What's the story with TTI?
+
+TTI serves a useful role as it's the largest metric value reported (often >10
+seconds) and helps anchor perceptions.
+
+We see TBT as a stronger metric for evaluating the health of your main thread
+and its impact on interactivity, plus it [has lower
+variability](https://docs.google.com/document/d/1xCERB_X7PiP5RAZDwyIkODnIXoBk-Oo7Mi9266aEdGg/edit).
+ TTI serves as a nice complement that captures the cost of long tasks, often
+from heavy JavaScript. That said, we expect to continue to reduce the weight
+of TTI and will likely remove it in a future major Lighthouse release.
+
+### How does the Lighthouse Perf score get calculated? What is it based on?
+
+The Lighthouse perf score is calculated from a weighted, blended set of
+performance metrics. You can see the current and previous Lighthouse score
+compositions (which metrics we are blending together, and at what weights) in
+the [score
+calculator](https://googlechrome.github.io/lighthouse/scorecalc/#FCP=3000&SI=5800&FMP=4000&TTI=7300&FCI=6500&LCP=4000&TBT=600&CLS=0.25&device=mobile&version=8&version=6&version=5),
+and learn more about the [calculation specifics
+here](https://web.dev/performance-scoring/).
+
+### What is the most exciting update in LH v8?
+
+We're really excited about the [interactive
+treemap](https://github.com/GoogleChrome/lighthouse/blob/v8changelog/changelog.md#treemap-release),
+[filtering audits by
+metric](https://github.com/GoogleChrome/lighthouse/blob/v8changelog/changelog.md#:~:text=new%20metric%20filter),
+and the new [Content Security Policy
+audit](https://web.dev/strict-csp/#adopting-a-strict-csp), which was a
+collaboration with the Google Web Security team.

package/docs/variability.md

@@ -0,0 +1,150 @@
+# Score Variability
+
+## Summary
+
+Lighthouse performance scores will change due to inherent variability in web and network technologies, even if there hasn't been a code change. Run Lighthouse multiple times and beware of variability before drawing conclusions about a performance-impacting change.
+
+## Sources of Variability
+
+Variability in performance measurement is introduced via a number of channels with different levels of impact. Below is a table containing several common sources of metric variability, the typical impact they have on results, and the extent to which they are likely to occur in different environments.
+
+| Source                      | Impact | Typical End User | PageSpeed Insights | Controlled Lab |
+| --------------------------- | ------ | ---------------- | ------------------ | -------------- |
+| Page nondeterminism         | High   | LIKELY           | LIKELY             | LIKELY         |
+| Local network variability   | High   | LIKELY           | UNLIKELY           | UNLIKELY       |
+| Tier-1 network variability  | Medium | POSSIBLE         | POSSIBLE           | POSSIBLE       |
+| Web server variability      | Low    | LIKELY           | LIKELY             | LIKELY         |
+| Client hardware variability | High   | LIKELY           | UNLIKELY           | UNLIKELY       |
+| Client resource contention  | High   | LIKELY           | POSSIBLE           | UNLIKELY       |
+| Browser nondeterminism      | Medium | CERTAIN          | CERTAIN            | CERTAIN        |
+
+Below are more detailed descriptions of the sources of variance and the impact they have on the most likely combinations of Lighthouse runtime + environment. While applied throttling and simulated throttling approaches could be used in any of these three environments, the typical end user uses simulated throttling.
+
+### Page Nondeterminism
+
+Pages can contain logic that is nondeterministic that changes the way a user experiences a page, i.e. an A/B test that changes the layout and assets loaded or a different ad experience based on campaign progress. This is an intentional and irremovable source of variance. If the page changes in a way that hurts performance, Lighthouse should be able to identify this case. The only mitigation here is on the part of the site owner in ensuring that the exact same version of the page is being tested between different runs.
+
+### Local Network Variability
+
+Local networks have inherent variability from packet loss, variable traffic prioritization, and last-mile network congestion. Users with cheap routers and many devices sharing limited bandwidth are usually the most susceptible to this. _Applied_ throttling partially mitigates these effects by applying a minimum request latency and maximum throughput that masks underlying retries. _Simulated_ throttling mitigates these effects by replaying network activity on its own.
+
+### Tier-1 Network Variability
+
+Network interconnects are generally very stable and have minimal impact but cross-geo requests, i.e. measuring performance of a Chinese site from the US, can start to experience a high degree of latency introduced from tier-1 network hops. _Applied_ throttling partially masks these effects with network throttling. _Simulated_ throttling mitigates these effects by replaying network activity on its own.
+
+### Web Server Variability
+
+Web servers have variable load and do not always respond with the same delay. Lower-traffic sites with shared hosting infrastructure are typically more susceptible to this. _Applied_ throttling partially masks these effects by applying a minimum request latency in its network throttling. _Simulated_ throttling is susceptible to this effect but the overall impact is usually low when compared to other network variability.
+
+### Client Hardware Variability
+
+The hardware on which the webpage is loading can greatly impact performance. _Applied_ throttling cannot do much to mitigate this issue. _Simulated_ throttling partially mitigates this issue by capping the theoretical execution time of CPU tasks during simulation.
+
+### Client Resource Contention
+
+Other applications running on the same machine while Lighthouse is running can cause contention for CPU, memory, and network resources. Malware, browser extensions, and anti-virus software have particularly strong impacts on web performance. Multi-tenant server environments (such as Travis, AWS, etc) can also suffer from these issues. Running multiple instances of Lighthouse at once also typically distorts results due to this problem. _Applied_ throttling is susceptible to this issue. _Simulated_ throttling partially mitigates this issue by replaying network activity on its own and capping CPU execution.
+
+### Browser Nondeterminism
+
+Browsers have inherent variability in their execution of tasks that impacts the way webpages are loaded. This is unavoidable for applied throttling as at the end of the day they are simply reporting whatever was observed by the browser. _Simulated_ throttling is able to partially mitigate this effect by simulating execution on its own, only re-using task execution times from the browser in its estimate.
+
+### Effect of Throttling Strategies
+
+Below is a table containing several common sources of metric variability, the typical impact they have on results, and the extent to which different Lighthouse throttling strategies are able to mitigate their effect. Learn more about different throttling strategies in our [throttling documentation](./throttling.md).
+
+| Source                      | Impact | Simulated Throttling | Applied Throttling  | No Throttling |
+| --------------------------- | ------ | -------------------- | ------------------- | ------------- |
+| Page nondeterminism         | High   | NO MITIGATION        | NO MITIGATION       | NO MITIGATION |
+| Local network variability   | High   | MITIGATED            | PARTIALLY MITIGATED | NO MITIGATION |
+| Tier-1 network variability  | Medium | MITIGATED            | PARTIALLY MITIGATED | NO MITIGATION |
+| Web server variability      | Low    | NO MITIGATION        | PARTIALLY MITIGATED | NO MITIGATION |
+| Client hardware variability | High   | PARTIALLY MITIGATED  | NO MITIGATION       | NO MITIGATION |
+| Client resource contention  | High   | PARTIALLY MITIGATED  | NO MITIGATION       | NO MITIGATION |
+| Browser nondeterminism      | Medium | PARTIALLY MITIGATED  | NO MITIGATION       | NO MITIGATION |
+
+## Strategies for Dealing With Variance
+
+### Run on Adequate Hardware
+
+Loading modern webpages on a modern browser is not an easy task. Using appropriately powerful hardware can make a world of difference when it comes to variability.
+
+- Minimum 2 dedicated cores (4 recommended)
+- Minimum 2GB RAM (4-8GB recommended)
+- Avoid non-standard Chromium flags (`--single-process` is not supported, `--no-sandbox` and `--headless` should be OK, though educate yourself about [sandbox tradeoffs](https://github.com/GoogleChrome/lighthouse-ci/tree/fbb540507c031100ee13bf7eb1a4b61c79c5e1e6/docs/recipes/docker-client#--no-sandbox-issues-explained))
+- Avoid function-as-a-service infrastructure (Lambda, GCF, etc)
+- Avoid "burstable" or "shared-core" instance types (AWS `t` instances, GCP shared-core N1 and E2 instances, etc)
+
+AWS's `m5.large`, GCP's `n2-standard-2`, and Azure's `D2` all should be sufficient to run a single Lighthouse run at a time (~$0.10/hour for these instance types, ~30s/test, ~$0.0008/Lighthouse report). While some environments that don't meet the requirements above will still be able to run Lighthouse and the non-performance results will still be usable, we'd advise against it and won't be able to support those environments should any bugs arise. Remember, running on inconsistent hardware will lead to inconsistent results!
+
+**DO NOT** collect multiple Lighthouse reports at the same time on the same machine. Concurrent runs can skew performance results due to resource contention. When it comes to Lighthouse runs, scaling horizontally is better than scaling vertically (i.e. run with 4 `n2-standard-2` instead of 1 `n2-standard-8`).
+
+### Isolate External Factors
+
+- Isolate your page from third-party influence as much as possible. It’s never fun to be blamed for someone else's variable failures.
+- Isolate your own code’s nondeterminism during testing. If you’ve got an animation that randomly shows up, your performance numbers might be random too!
+- Isolate your test server from as much network volatility as possible. Use localhost or a machine on the same exact network whenever stability is a concern.
+- Isolate your client environment from external influences like anti-virus software and browser extensions. Use a dedicated device for testing when possible.
+
+If your machine has really limited resources or creating a clean environment has been difficult, use a hosted lab environment like PageSpeed Insights or WebPageTest to run your tests for you. In continuous integration situations, use dedicated servers when possible. Free CI environments and “burstable” instances are typically quite volatile.
+
+### Run Lighthouse Multiple Times
+
+When creating your thresholds for failure, either mental or programmatic, use aggregate values like the median, 90th percentile, or even min/max instead of single test results.
+
+The median Lighthouse score of 5 runs is twice as stable as 1 run. There are multiple ways to get a Lighthouse report, but the simplest way to run Lighthouse multiple times and also get a median run is to use [lighthouse-ci](https://github.com/GoogleChrome/lighthouse-ci/).
+
+```bash
+npx -p @lhci/cli lhci collect --url https://example.com -n 5
+npx -p @lhci/cli lhci upload --target filesystem --outputDir ./path/to/dump/reports
+```
+
+> Note: you must have [Node](https://nodejs.org/en/download/package-manager/) installed.
+
+You can then process the reports that are output to the filesystem. Read the [Lighthouse CI documentation](https://github.com/GoogleChrome/lighthouse-ci/blob/master/docs/configuration.md#outputdir) for more.
+
+```js
+const fs = require('fs');
+const lhciManifest = require('./path/to/dump/reports/manifest.json');
+const medianEntry = lhciManifest.find(entry => entry.isRepresentativeRun)
+const medianResult = JSON.parse(fs.readFileSync(medianEntry.jsonPath, 'utf-8'));
+console.log('Median performance score was', medianResult.categories.performance.score * 100);
+```
+
+You can also direct `lighthouse-ci` to use PageSpeedInsights:
+
+```bash
+npx -p @lhci/cli lhci collect --url https://example.com -n 5 --mode psi --psiApiKey xXxXxXx
+npx -p @lhci/cli lhci upload --target filesystem --outputDir ./path/to/dump/reports
+```
+
+If you're running Lighthouse directly via node, you can use the `computeMedianRun` function to determine the median using a blend of the performance metrics.
+
+```js
+const spawnSync = require('child_process').spawnSync;
+const lighthouseCli = require.resolve('lighthouse/lighthouse-cli');
+const {computeMedianRun} = require('lighthouse/lighthouse-core/lib/median-run.js');
+
+const results = [];
+for (let i = 0; i < 5; i++) {
+  console.log(`Running Lighthouse attempt #${i + 1}...`);
+  const {status = -1, stdout} = spawnSync('node', [
+    lighthouseCli,
+    'https://example.com',
+    '--output=json'
+  ]);
+  if (status !== 0) {
+    console.log('Lighthouse failed, skipping run...');
+    continue;
+  }
+  results.push(JSON.parse(stdout));
+}
+
+const median = computeMedianRun(results);
+console.log('Median performance score was', median.categories.performance.score * 100);
+```
+
+## Related Documentation
+
+- [Lighthouse Variability and Accuracy Analysis](https://docs.google.com/document/d/1BqtL-nG53rxWOI5RO0pItSRPowZVnYJ_gBEQCJ5EeUE/edit?usp=sharing)
+- [Throttling documentation](./throttling.md)
+- [Why is my Lighthouse score different from PageSpeed Insights?](https://www.debugbear.com/blog/why-is-my-lighthouse-score-different-from-pagespeed-insights)

package/jest.config.js

@@ -11,7 +11,6 @@ module.exports = {
   collectCoverageFrom: [
     '**/lighthouse-core/**/*.js',
     '**/lighthouse-cli/**/*.js',
-    '**/report/**/*.js',
     '**/lighthouse-viewer/**/*.js',
   ],
   coveragePathIgnorePatterns: [
@@ -23,7 +22,6 @@ module.exports = {
   testMatch: [
     '**/lighthouse-core/**/*-test.js',
     '**/lighthouse-cli/**/*-test.js',
-    '**/report/**/*-test.js',
     '**/lighthouse-core/test/fraggle-rock/**/*-test-pptr.js',
     '**/lighthouse-treemap/**/*-test.js',
     '**/lighthouse-treemap/**/*-test-pptr.js',
@@ -34,5 +32,4 @@ module.exports = {
     '**/docs/**/*.test.js',
   ],
   transform: {},
-  prettierPath: null,
 };

package/lighthouse-cli/bin.js

@@ -5,8 +5,11 @@
  */
 'use strict';
 
-/**
- * @fileoverview The relationship between these CLI modules:
+const fs = require('fs');
+const path = require('path');
+
+/*
+ * The relationship between these CLI modules:
  *
  *   index.js     : only calls bin.js's begin()
  *   cli-flags.js : leverages yargs to read argv, outputs LH.CliFlags
@@ -18,25 +21,24 @@
  *               cli-flags        lh-core/index
  */
 
-const fs = require('fs');
-const path = require('path');
 const commands = require('./commands/commands.js');
 const printer = require('./printer.js');
 const {getFlags} = require('./cli-flags.js');
 const {runLighthouse} = require('./run.js');
 const {generateConfig} = require('../lighthouse-core/index.js');
+
 const log = require('lighthouse-logger');
 const pkg = require('../package.json');
 const Sentry = require('../lighthouse-core/lib/sentry.js');
+
 const updateNotifier = require('update-notifier');
 const {askPermission} = require('./sentry-prompt.js');
-const {LH_ROOT} = require('../root.js');
 
 /**
  * @return {boolean}
  */
 function isDev() {
-  return fs.existsSync(path.join(LH_ROOT, '/.git'));
+  return fs.existsSync(path.join(__dirname, '../.git'));
 }
 
 /**

package/lighthouse-core/audits/accessibility/aria-command-name.js

@@ -18,7 +18,7 @@ const UIStrings = {
   title: '`button`, `link`, and `menuitem` elements have accessible names',
   /** Title of an accessibility audit that evaluates if important HTML elements do not have accessible names. This title is descriptive of the failing state and is shown to users when there is a failure that needs to be addressed. */
   failureTitle: '`button`, `link`, and `menuitem` elements do not have accessible names.',
-  /** Description of a Lighthouse audit that tells the user *why* they should have accessible names for HTML elements. This is displayed after a user expands the section to see more. No character length limits. 'Learn More' becomes link text to additional documentation. */
+  /** Description of a Lighthouse audit that tells the user *why* they should have accessible names for command elements. This is displayed after a user expands the section to see more. No character length limits. 'Learn More' becomes link text to additional documentation. */
   description: 'When an element doesn\'t have an accessible name, screen readers announce it with a generic name, making it unusable for users who rely on screen readers. [Learn more](https://web.dev/aria-name/).',
 };
 

package/lighthouse-core/audits/accessibility/aria-meter-name.js

@@ -18,7 +18,7 @@ const UIStrings = {
   title: 'ARIA `meter` elements have accessible names',
   /** Title of an accessibility audit that evaluates if meter HTML elements do not have accessible names. This title is descriptive of the failing state and is shown to users when there is a failure that needs to be addressed. */
   failureTitle: 'ARIA `meter` elements do not have accessible names.',
-  /** Description of a Lighthouse audit that tells the user *why* they should have accessible names for HTML elements. This is displayed after a user expands the section to see more. No character length limits. 'Learn More' becomes link text to additional documentation. */
+  /** Description of a Lighthouse audit that tells the user *why* they should have accessible names for meter elements. This is displayed after a user expands the section to see more. No character length limits. 'Learn More' becomes link text to additional documentation. */
   description: 'When an element doesn\'t have an accessible name, screen readers announce it with a generic name, making it unusable for users who rely on screen readers. [Learn more](https://web.dev/aria-name/).',
 };
 

package/lighthouse-core/audits/accessibility/aria-progressbar-name.js

@@ -19,7 +19,7 @@ const UIStrings = {
   /** Title of an accessibility audit that evaluates if progressbar HTML elements do not have accessible names. This title is descriptive of the failing state and is shown to users when there is a failure that needs to be addressed. */
   failureTitle: 'ARIA `progressbar` elements do not have accessible names.',
   /** Description of a Lighthouse audit that tells the user *why* they should try to pass. This is displayed after a user expands the section to see more. No character length limits. 'Learn More' becomes link text to additional documentation. */
-  description: 'When a `progressbar` element doesn\'t have an accessible name, screen readers announce it with a generic name, making it unusable for users who rely on screen readers. [Learn more](https://web.dev/aria-name/).',
+  description: 'When an element doesn\'t have an accessible name, screen readers announce it with a generic name, making it unusable for users who rely on screen readers. [Learn more](https://web.dev/aria-name/).',
 };
 
 const str_ = i18n.createMessageInstanceIdFn(__filename, UIStrings);

package/lighthouse-core/audits/accessibility/aria-tooltip-name.js

@@ -18,7 +18,7 @@ const UIStrings = {
   title: 'ARIA `tooltip` elements have accessible names',
   /** Title of an accessibility audit that evaluates if tooltip HTML elements do not have accessible names. This title is descriptive of the failing state and is shown to users when there is a failure that needs to be addressed. */
   failureTitle: 'ARIA `tooltip` elements do not have accessible names.',
-  /** Description of a Lighthouse audit that tells the user *why* they should have accessible names for HTML elements. This is displayed after a user expands the section to see more. No character length limits. 'Learn More' becomes link text to additional documentation. */
+  /** Description of a Lighthouse audit that tells the user *why* they should have accessible names for tooltips. This is displayed after a user expands the section to see more. No character length limits. 'Learn More' becomes link text to additional documentation. */
   description: 'When an element doesn\'t have an accessible name, screen readers announce it with a generic name, making it unusable for users who rely on screen readers. [Learn more](https://web.dev/aria-name/).',
 };
 

package/lighthouse-core/audits/accessibility/aria-treeitem-name.js

@@ -18,7 +18,7 @@ const UIStrings = {
   title: 'ARIA `treeitem` elements have accessible names',
   /** Title of an accessibility audit that evaluates if treeitem HTML elements do not have accessible names. This title is descriptive of the failing state and is shown to users when there is a failure that needs to be addressed. */
   failureTitle: 'ARIA `treeitem` elements do not have accessible names.',
-  /** Description of a Lighthouse audit that tells the user *why* they should have accessible names for HTML elements. This is displayed after a user expands the section to see more. No character length limits. 'Learn More' becomes link text to additional documentation. */
+  /** Description of a Lighthouse audit that tells the user *why* they should try to pass. This is displayed after a user expands the section to see more. No character length limits. 'Learn More' becomes link text to additional documentation. */
   description: 'When an element doesn\'t have an accessible name, screen readers announce it with a generic name, making it unusable for users who rely on screen readers. [Learn more](https://web.dev/aria-name/).',
 };
 

package/lighthouse-core/audits/apple-touch-icon.js

@@ -38,7 +38,6 @@ class AppleTouchIcon extends Audit {
       title: str_(UIStrings.title),
       failureTitle: str_(UIStrings.failureTitle),
       description: str_(UIStrings.description),
-      supportedModes: ['navigation'],
       requiredArtifacts: ['LinkElements'],
     };
   }

package/lighthouse-core/audits/audit.js

@@ -7,7 +7,7 @@
 
 const {isUnderTest} = require('../lib/lh-env.js');
 const statistics = require('../lib/statistics.js');
-const Util = require('../../report/renderer/util.js');
+const Util = require('../report/html/renderer/util.js');
 
 const DEFAULT_PASS = 'defaultPass';
 
@@ -133,7 +133,7 @@ class Audit {
 
   /**
    * @param {LH.Audit.Details.List['items']} items
-   * @return {LH.Audit.Details.List}
+   * @returns {LH.Audit.Details.List}
    */
   static makeListDetails(items) {
     return {
@@ -180,7 +180,7 @@ class Audit {
   /**
    * @param {string} content
    * @param {number} maxLineLength
-   * @return {LH.Audit.Details.SnippetValue['lines']}
+   * @returns {LH.Audit.Details.SnippetValue['lines']}
    */
   static _makeSnippetLinesArray(content, maxLineLength) {
     return content.split('\n').map((line, lineIndex) => {

package/lighthouse-core/audits/autocomplete.js

@@ -63,11 +63,11 @@ const validAutocompleteTokens = ['name', 'honorific-prefix', 'given-name',
   'tel-local', 'tel-local-prefix', 'tel-local-suffix', 'tel-extension', 'email', 'impp', 'off',
   'additional-name-initial', 'home', 'work', 'mobile', 'fax', 'pager', 'shipping', 'billing'];
 
-/** @type {string[]} This array contains all autofull suggestions that have no prediction tied to it. Autofill predictions found at https://source.chromium.org/chromium/chromium/src/+/main:components/autofill/core/browser/field_types.h;l=26 */
+/** @type {string[]} This array contains all autofull suggestions that have no prediction tied to it. Autofill predictions found at https://source.chromium.org/chromium/chromium/src/+/master:components/autofill/core/browser/field_types.h;l=26 */
 const noPrediction = ['NO_SERVER_DATA', 'UNKNOWN_TYPE', 'EMPTY_TYPE', 'HTML_TYPE_UNSPECIFIED',
   'HTML_TYPE_UNRECOGNIZED'];
 
-/** This mapping contains all autofill predictions to corresponding autocomplete attributes. Autofill predictions are found at https://source.chromium.org/chromium/chromium/src/+/main:components/autofill/core/browser/field_types.h;l=34*/
+/** This mapping contains all autofill predictions to corresponding autocomplete attributes. Autofill predictions are found at https://source.chromium.org/chromium/chromium/src/+/master:components/autofill/core/browser/field_types.h;l=34*/
 const predictionTypesToTokens = {
   'NO_SERVER_DATA': str_(UIStrings.manualReview),
   'UNKNOWN_TYPE': str_(UIStrings.manualReview),

package/lighthouse-core/audits/byte-efficiency/byte-efficiency-audit.js

@@ -105,8 +105,7 @@ class UnusedBytes extends Audit {
    * @param {LH.Audit.Context} context
    * @return {Promise<LH.Audit.Product>}
    */
-  static async audit(artifacts, context) {
-    const gatherContext = artifacts.GatherContext;
+  static audit(artifacts, context) {
     const trace = artifacts.traces[Audit.DEFAULT_PASS];
     const devtoolsLog = artifacts.devtoolsLogs[Audit.DEFAULT_PASS];
     const settings = context && context.settings || {};
@@ -115,14 +114,15 @@ class UnusedBytes extends Audit {
       settings,
     };
 
-    const networkRecords = await NetworkRecords.request(devtoolsLog, context);
-    const [result, graph, simulator] = await Promise.all([
-      this.audit_(artifacts, networkRecords, context),
-      PageDependencyGraph.request({trace, devtoolsLog}, context),
-      LoadSimulator.request(simulatorOptions, context),
-    ]);
-
-    return this.createAuditProduct(result, graph, simulator, gatherContext);
+    return NetworkRecords.request(devtoolsLog, context)
+      .then(networkRecords =>
+        Promise.all([
+          this.audit_(artifacts, networkRecords, context),
+          PageDependencyGraph.request({trace, devtoolsLog}, context),
+          LoadSimulator.request(simulatorOptions, context),
+        ])
+      )
+      .then(([result, graph, simulator]) => this.createAuditProduct(result, graph, simulator));
   }
 
   /**
@@ -186,34 +186,19 @@ class UnusedBytes extends Audit {
     return Math.round(Math.max(savings, 0) / 10) * 10;
   }
 
-  /**
-   * TODO(FR-COMPAT): Rework opportunities to remove emphasis on `wastedMs`
-   * @param {number} wastedBytes
-   * @param {Simulator} simulator
-   */
-  static computeWastedMsWithThroughput(wastedBytes, simulator) {
-    const bitsPerSecond = simulator.getOptions().throughput;
-    const wastedBits = wastedBytes * 8;
-    const wastedMs = wastedBits / bitsPerSecond * 1000;
-    return wastedMs;
-  }
-
   /**
    * @param {ByteEfficiencyProduct} result
    * @param {Node} graph
    * @param {Simulator} simulator
-   * @param {LH.Artifacts['GatherContext']} gatherContext
    * @return {LH.Audit.Product}
    */
-  static createAuditProduct(result, graph, simulator, gatherContext) {
+  static createAuditProduct(result, graph, simulator) {
     const results = result.items.sort((itemA, itemB) => itemB.wastedBytes - itemA.wastedBytes);
 
     const wastedBytes = results.reduce((sum, item) => sum + item.wastedBytes, 0);
-    const wastedMs = gatherContext.gatherMode === 'navigation' ?
-      this.computeWasteWithTTIGraph(results, graph, simulator, {
-        providedWastedBytesByUrl: result.wastedBytesByUrl,
-      }) :
-      this.computeWastedMsWithThroughput(wastedBytes, simulator);
+    const wastedMs = this.computeWasteWithTTIGraph(results, graph, simulator, {
+      providedWastedBytesByUrl: result.wastedBytesByUrl,
+    });
 
     let displayValue = result.displayValue || '';
     if (typeof result.displayValue === 'undefined' && wastedBytes) {