From 2b8caf21a3e9d03633b52e43e35e97291ae6553d Mon Sep 17 00:00:00 2001
From: Adam Raine <6752989+adamraine@users.noreply.github.com>
Date: Tue, 18 Apr 2023 16:49:26 -0700
Subject: [PATCH] docs: update throttling methods (#14993)

---
 build/readme.md              |  2 +-
 clients/extension/popup.html |  2 +-
 docs/authenticated-pages.md  |  2 +-
 docs/throttling.md           |  8 ++++----
 docs/variability.md          | 32 ++++++++++++++++----------------
 report/README.md             |  2 +-
 6 files changed, 24 insertions(+), 24 deletions(-)

diff --git a/build/readme.md b/build/readme.md
index 65855de20ebd..271117ab7bbe 100644
--- a/build/readme.md
+++ b/build/readme.md
@@ -2,7 +2,7 @@
 
 Lighthouse is built into browser-friendly bundles for two clients:
 
-* Chrome DevTools Audits Panel
+* Chrome DevTools Lighthouse Panel
 * Lightrider, the backend of PageSpeed Insights
 
 Additionally, there are build processes for:
diff --git a/clients/extension/popup.html b/clients/extension/popup.html
index bed5cb8059e9..02336b99af5f 100644
--- a/clients/extension/popup.html
+++ b/clients/extension/popup.html
@@ -32,7 +32,7 @@
       <div class="hidden browser-brand browser-brand--chrome">
         <h2 class="section--header">Chrome DevTools</h2>
         <span class="section--description">
-          You can also run Lighthouse via the DevTools Audits panel.
+          You can also run Lighthouse via the DevTools Lighthouse panel.
           <br><br>
           Shortcut to open DevTools: <span class="devtools-shortcut"><!-- filled dynamically --></span>
         </span>
diff --git a/docs/authenticated-pages.md b/docs/authenticated-pages.md
index 3fe606830d4f..35dcc2c35682 100644
--- a/docs/authenticated-pages.md
+++ b/docs/authenticated-pages.md
@@ -12,7 +12,7 @@ View our full documentation for using [Lighthouse along with Puppeteer](https://
 
 ## Option 2: Leverage logged-in state with Chrome DevTools
 
-The Audits panel in Chrome DevTools will never clear your cookies, so you can log in to the target site and then run Lighthouse. If `localStorage` or `indexedDB` is important for your authentication purposes, be sure to uncheck `Clear storage`.
+The Lighthouse panel in Chrome DevTools will never clear your cookies, so you can log in to the target site and then run Lighthouse. If `localStorage` or `indexedDB` is important for your authentication purposes, be sure to uncheck `Clear storage`.
 
 ## Option 3: Pass custom request headers with Lighthouse CLI
 
diff --git a/docs/throttling.md b/docs/throttling.md
index 0cfce6ef4914..4f9f8f56efb7 100644
--- a/docs/throttling.md
+++ b/docs/throttling.md
@@ -19,7 +19,7 @@ This preset is identical to the [WebPageTest's "Mobile 3G - Fast"](https://githu
 Within web performance testing, there are four typical styles of network throttling:
 
 1. **_Simulated throttling_**, which Lighthouse uses by **default**, uses a simulation of a page load, based on the data observed in the initial unthrottled load. This approach makes it both very fast and deterministic. However, due to the imperfect nature of predicting alternate execution paths, there is inherent inaccuracy that is summarized in this doc: [Lighthouse Metric Variability and Accuracy](https://docs.google.com/document/d/1BqtL-nG53rxWOI5RO0pItSRPowZVnYJ_gBEQCJ5EeUE/edit). The TLDR: while it's roughly as accurate or better than DevTools throttling for most sites, it suffers from edge cases and a deep investigation to performance should use _Packet-level_ throttling tools.
-1. **_Request-level throttling_** , also referred to as **_Applied throttling_** in the Audits panel or _`devtools` throttling_ in Lighthouse configuration, is how throttling is implemented with Chrome DevTools. In real mobile connectivity, latency affects things at the packet level rather than the request level. As a result, this throttling isn't highly accurate. It also has a few more downsides that are summarized in [Network Throttling & Chrome - status](https://docs.google.com/document/d/1TwWLaLAfnBfbk5_ZzpGXegPapCIfyzT4MWuZgspKUAQ/edit). The TLDR: while it's a [decent approximation](https://docs.google.com/document/d/10lfVdS1iDWCRKQXPfbxEn4Or99D64mvNlugP1AQuFlE/edit), it's not a sufficient model of a slow connection. The [multipliers used in Lighthouse](https://github.com/GoogleChrome/lighthouse/blob/main/core/config/constants.js#:~:text=*%201024%2C-,requestLatencyMs,-%3A%20150%20*) attempt to correct for the differences.
+1. **_Request-level throttling_** , also referred to as **_DevTools throttling_** in the Lighthouse panel or _`devtools` throttling_ in Lighthouse configuration, is how throttling is implemented with Chrome DevTools. In real mobile connectivity, latency affects things at the packet level rather than the request level. As a result, this throttling isn't highly accurate. It also has a few more downsides that are summarized in [Network Throttling & Chrome - status](https://docs.google.com/document/d/1TwWLaLAfnBfbk5_ZzpGXegPapCIfyzT4MWuZgspKUAQ/edit). The TLDR: while it's a [decent approximation](https://docs.google.com/document/d/10lfVdS1iDWCRKQXPfbxEn4Or99D64mvNlugP1AQuFlE/edit), it's not a sufficient model of a slow connection. The [multipliers used in Lighthouse](https://github.com/GoogleChrome/lighthouse/blob/main/core/config/constants.js#:~:text=*%201024%2C-,requestLatencyMs,-%3A%20150%20*) attempt to correct for the differences.
 1. **_Proxy-level_** throttling tools do not affect UDP data, so they're decent, but not ideal.
 1. **_Packet-level_** throttling tools are able to make the most accurate network simulation. While this approach can model real network conditions most effectively, it also can introduce [more variance](https://docs.google.com/document/d/1BqtL-nG53rxWOI5RO0pItSRPowZVnYJ_gBEQCJ5EeUE/edit) than request-level or simulated throttling. [WebPageTest uses](https://github.com/WPO-Foundation/wptagent/blob/master/docs/remote_trafficshaping.md) packet-level throttling.
 
@@ -31,7 +31,7 @@ The Lighthouse panel has a simplified throttling setup:
 
 1. _Simulated throttling_ remains the default setting. This matches the setup of PageSpeed Insights and the Lighthouse CLI default, maintaining cross-tool consistency.
    - If you click the `View Original Trace` button, the trace values will not match up with Lighthouse's metric results, as the original trace is prior to the simulation.
-1. _Applied throttling_ is available within the Lighthouse panel settings (⚙): uncheck the _Simulated throttling_ checkbox.
+1. _DevTools throttling_ is available within the Lighthouse panel settings (⚙): select _DevTools throttling_ from the throttling method dropdown.
    - In this mode, the performance data seen after clicking the [`View Trace` button](https://developers.google.com/web/updates/2018/04/devtools#traces) will match Lighthouses's numbers.
 
 Of course, CLI users can still control the exact [configuration](../readme.md#cli-options) of throttling.
@@ -147,5 +147,5 @@ lighthouse --throttling.cpuSlowdownMultiplier=6 https://example.com
 
 Within web performance testing, there are two typical styles of CPU throttling:
 
-1. **_Simulated throttling_**, which Lighthouse uses by **default**, uses a simulation of a page load, based on the data observed in the initial unthrottled load. This approach makes it very fast. However, due to the imperfect nature of predicting alternate execution paths, there is inherent inaccuracy that is summarized in this doc: [Lighthouse Metric Variability and Accuracy](https://docs.google.com/document/d/1BqtL-nG53rxWOI5RO0pItSRPowZVnYJ_gBEQCJ5EeUE/edit). The TLDR: while it's fairly accurate for most circumstances, it suffers from edge cases and a deep investigation to performance should use _applied_ CPU throttling tools.
-1. **_Applied throttling_** , also called _`devtools` throttling_ in Lighthouse configuration. This method actually interrupts execution of CPU work at periodic intervals to emulate a slower processor. It is [fairly accurate](https://docs.google.com/document/d/1jGHeGjjjzfTAE2WHXipKF3aqwF2bFA6r0B877nFtBpc/edit) and much easier than obtaining target hardware. The same underlying principle can be used by [linux cgroups](https://www.kernel.org/doc/html/latest/scheduler/sched-bwc.html) to throttle any process, not just the browser. Other tools like [WebPageTest use applied CPU throttling](https://github.com/WPO-Foundation/wptagent/commit/f7fe0d6b5b01bd1b042a1fe3144c68a6bff846a6) offered by DevTools.
+1. **_Simulated throttling_**, which Lighthouse uses by **default**, uses a simulation of a page load, based on the data observed in the initial unthrottled load. This approach makes it very fast. However, due to the imperfect nature of predicting alternate execution paths, there is inherent inaccuracy that is summarized in this doc: [Lighthouse Metric Variability and Accuracy](https://docs.google.com/document/d/1BqtL-nG53rxWOI5RO0pItSRPowZVnYJ_gBEQCJ5EeUE/edit). The TLDR: while it's fairly accurate for most circumstances, it suffers from edge cases and a deep investigation to performance should use _DevTools_ CPU throttling tools.
+1. **_DevTools throttling_** , also called _`devtools` throttling_ in Lighthouse configuration. This method actually interrupts execution of CPU work at periodic intervals to emulate a slower processor. It is [fairly accurate](https://docs.google.com/document/d/1jGHeGjjjzfTAE2WHXipKF3aqwF2bFA6r0B877nFtBpc/edit) and much easier than obtaining target hardware. The same underlying principle can be used by [linux cgroups](https://www.kernel.org/doc/html/latest/scheduler/sched-bwc.html) to throttle any process, not just the browser. Other tools like [WebPageTest use CPU throttling](https://github.com/WPO-Foundation/wptagent/commit/f7fe0d6b5b01bd1b042a1fe3144c68a6bff846a6) offered by DevTools.
diff --git a/docs/variability.md b/docs/variability.md
index a0f51bd8078c..53c7be336f7a 100644
--- a/docs/variability.md
+++ b/docs/variability.md
@@ -18,7 +18,7 @@ Variability in performance measurement is introduced via a number of channels wi
 | 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.
+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 DevTools throttling and simulated throttling approaches could be used in any of these three environments, the typical end user uses simulated throttling.
 
 ### Page Nondeterminism
 
@@ -26,41 +26,41 @@ Pages can contain logic that is nondeterministic that changes the way a user exp
 
 ### 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.
+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. _DevTools_ 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.
+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. _DevTools_ 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.
+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. _DevTools_ 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.
+The hardware on which the webpage is loading can greatly impact performance. _DevTools_ 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.
+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. _DevTools_ 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.
+Browsers have inherent variability in their execution of tasks that impacts the way webpages are loaded. This is unavoidable for devtools 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 |
+| Source                      | Impact | Simulated Throttling | DevTools 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
 
diff --git a/report/README.md b/report/README.md
index 51e513f571c5..6a40d205a5ec 100644
--- a/report/README.md
+++ b/report/README.md
@@ -27,5 +27,5 @@ Examples:
 The renderer was designed to be portable across various environments.
 
 1. _LH CLI_: It [creates the HTML as the runner finishes up](https://github.com/GoogleChrome/lighthouse/blob/da3c865d698abc9365fa7bb087a08ce8c89b0a05/core/runner.js#L130-L131) and [saves it to disk](https://github.com/GoogleChrome/lighthouse/blob/da3c865d698abc9365fa7bb087a08ce8c89b0a05/cli/printer.js#L52-L70).
-1. _Chrome DevTools Lighthouse Panel_: The `renderer` files are rolled into the Chromium repo, and they execute within the DevTools context. The audits panel [receives the LHR object from a WebWorker](https://github.com/ChromeDevTools/devtools-frontend/blob/e540d8037c1f724d61ae70553cc630a0453efebe/front_end/panels/lighthouse/LighthouseProtocolService.ts#L122-L142), through a `postMessage` and then runs [the renderer within DevTools UI](https://github.com/ChromeDevTools/devtools-frontend/blob/e540d8037c1f724d61ae70553cc630a0453efebe/front_end/panels/lighthouse/LighthousePanel.ts#L293-L317), making a few [simplifications](https://github.com/ChromeDevTools/devtools-frontend/blob/main/front_end/panels/lighthouse/LighthouseReportRenderer.ts).
+1. _Chrome DevTools Lighthouse Panel_: The `renderer` files are rolled into the Chromium repo, and they execute within the DevTools context. The Lighthouse panel [receives the LHR object from a WebWorker](https://github.com/ChromeDevTools/devtools-frontend/blob/e540d8037c1f724d61ae70553cc630a0453efebe/front_end/panels/lighthouse/LighthouseProtocolService.ts#L122-L142), through a `postMessage` and then runs [the renderer within DevTools UI](https://github.com/ChromeDevTools/devtools-frontend/blob/e540d8037c1f724d61ae70553cc630a0453efebe/front_end/panels/lighthouse/LighthousePanel.ts#L293-L317), making a few [simplifications](https://github.com/ChromeDevTools/devtools-frontend/blob/main/front_end/panels/lighthouse/LighthouseReportRenderer.ts).
 1. _Hosted [Lighthouse Viewer](https://googlechrome.github.io/lighthouse/viewer/)_: It's a webapp that has the renderer (along with some [additional features](https://github.com/GoogleChrome/lighthouse/blob/main/report/renderer/report-ui-features.js)) all compiled into a [`main-XXX.js`](https://github.com/GoogleChrome/lighthouse/tree/main/viewer/app/src) file. Same [basic approach](https://github.com/GoogleChrome/lighthouse/blob/da3c865d698abc9365fa7bb087a08ce8c89b0a05/viewer/app/src/lighthouse-report-viewer.js#L235-L239) there.