What does Fast 3G actually mean?

Question

In the Chrome browser's developer tools, there are various ways to throttle your network connection to emulate different connection types.

Those menus for selecting a connection type used to show the speeds and latency that would be used to simulate each connection type.

Now, as of at least Chrome 64, the useful information about speed and latency has been removed.

I tried duplicating the numbers from the first image for Regular 3G and Good 3G in my own custom profiles to see if they matched the Slow 3G and Fast 3G presets from the first image but I got significantly different results for the DOMContentLoaded and Load event times between the presets and my custom profiles.

Answer 1

DevTools tech writer and developer advocate here. The history behind the change is that DevTools now tries to emulate the real conditions of what a fast 3G network really feels like. Previously, DevTools showed you upload / download / RTT values, as you have shown in your screenshot of the old UI. But those values were misleading. They may be technically correct, but when DevTools was benchmarked against other throttling tools, DevTools didn't throttle enough. E.g. if you loaded a page with tool A that throttles for 3G, and then loaded that same page with DevTools (also throttling for 3G), the page loaded faster with DevTools.

So DevTools doesn't show the exact values anymore, but if you measure the load performance of DevTools against other throttling tools, you can see that they all perform similarly now.

The reason that DevTools doesn't show values anymore is that they don't map to reality well. For example, maybe you look up that a certain connection speed is defined as X download rate, Y upload rate, and Z RTT rate. So you put those values into DevTools. Those values aren't going to approximate the real-world conditions well. DevTools is going to load faster than the real-world experience. It's better to benchmark how a certain page really loads on that connection, and then tweak the input values until DevTools loads your benchmark page at around the same amount of time as your real-world benchmark.

Of course, another approach would be to get a Chrome engineer to tweak Chrome's throttling engine so that the values you input actually do map to reality well. But for whatever reason, that's not happening.

Since it's possible to add custom throttles, I'm aware that we need to update the DevTools UI to explain this limitation. In other words, when you create custom throttles, you should benchmark a page and then tweak DevTools inputs until it matches the benchmark, rather than relying on the values.

Hope that makes sense.