Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

docs: devtools throttling deprecation notice #9933

Merged
merged 6 commits into from
Nov 7, 2019
Merged

Conversation

connorjclark
Copy link
Collaborator

This doc will added via a link next to the throttling option in DevTools.

CL: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/1885347

@brendankenny
Copy link
Member

brendankenny commented Nov 6, 2019

Would this be better on devsite or in a "What's New In DevTools" post? Seems weird to document here for whatever reason (but also fine :)

@paulirish
Copy link
Member

nah it's great here. just perfect. really the finest location. best place on earth.

@paulirish
Copy link
Member

but i'm actually gonna merge this lil thing into the throttling.md doc and it'll be even better then.

@paulirish
Copy link
Member

Copy link
Collaborator

@patrickhulce patrickhulce left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

solid plan 👍

1. **_Request-level_** throttling, also referred to as _DevTools throttling_ or in the Audits Panel as _Applied throttling_, 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/3be483287a530fb560c843b7299ef9cfe91ce1cc/lighthouse-core/lib/emulation.js#L33-L39) attempt to correct for the differences.
1. **_Proxy-level_** throttling tools do not affect UDP data, so they're decent, but not ideal.
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/3be483287a530fb560c843b7299ef9cfe91ce1cc/lighthouse-core/lib/emulation.js#L33-L39) attempt to correct for the differences.
1. **_Proxy-level_** tools do not affect UDP data, so they're decent, but not ideal.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

feels weird to remove it just from here, Proxy-level tools but Packet-level throttling tools

what motivated the removal?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

mistake


Starting with Chrome 80, the Audits panel is simplifying the throttling configuration. To wit:

1. _Simulated throttling_ becomes the default setting. This matches the setup of PageSpeed Insights and the Lighthouse CLI default, so you should see more consistent results.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

wasn't it already the default for new users? are we just removing the stickiness?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

okay yah. reworded.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think calling out that it will become the only option is what's important.

Copy link

@ChromeCAB ChromeCAB left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like it. :)

Copy link
Contributor

@egsweeny egsweeny left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks great. :)


In Chrome 79 and earlier, you could choose between [the throttling types](#types-of-throttling) of Simulated, Applied, and none.

Starting with Chrome 80, the Audits panel is simplifying the throttling configuration. To wit:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Starting with Chrome 80, the Audits panel is simplifying the throttling configuration. To wit:
Starting with Chrome 80, the Audits panel is simplifying the throttling configuration.


1. _Simulated throttling_ becomes the default setting. This matches the setup of PageSpeed Insights and the Lighthouse CLI default, so you should see more consistent results.
1. _No throttling_ is removed as it leads to innacurate scoring and misleading metric results.
1. Within the Audits panel settings, you can uncheck the _Simulated throttling_ checkbox to use _Applied throttling_.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fwiw a radio button seems significantly less confusing for this. If "Simulated Throttling" is unchecked I would assume it's not throttled, personally

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it's super weird. i agree. so let's get a reasonable lantern trace generated and then we can drop this silliness.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it's super weird. i agree. so let's get a reasonable lantern trace generated and then we can drop this silliness.
-- former UX engineer Paul Irish

:P

Lighthouse, by default, uses simulated throttling as it provides both quick evaluation and minimized variance. However, some may want to experiment with more accurate throttling...
Lighthouse, by default, uses simulated throttling as it provides both quick evaluation and minimized variance. However, some may want to experiment with more accurate throttling... [Learn more about these throttling types and how they behave in in different scenarios](https://www.debugbear.com/blog/network-throttling-methods).

## Audits Panel Throttling Settings
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

maybe call out DevTools Audits Panel clearly here


For the moment, we are keeping _Applied throttling_ option available for users of the [`View Trace` button](https://developers.google.com/web/updates/2018/04/devtools#traces). Under applied throttling, the trace matches the metrics values, whereas under Simulated things do not currently match up.

We plan to improve the experience of viewing a trace under simulated throttling. At that point, the _Applied throttling_ option will be removed from the Audits panel. Of course, CLI users can still control the exact [configuration](../#cli-options) of throttling.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess somehow DevTools isn't for power users anymore :P

@paulirish paulirish merged commit 3acba79 into master Nov 7, 2019
@paulirish paulirish deleted the dt-deprecation branch November 7, 2019 01:02
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants