I have come to use a workflow where I measure load-time performance impacts using the Network panel's waterfall diagram. I use the existing checkbox to turn off cacheing, then reload a couple times to get a sense of the normal time and load order.

Today I started working on some performance improvements related to using preconnect and DNS pre-fetching and noticed that it was difficult to get an accurate idea of what effect they were having. Refreshing multiple times, even in incognito with cacheing off, still uses the DNS cache and seems to also reuse SSL sessions previously established. 

It would be fantastic if Chrome DevTools let us prevent the use of DNS cache and existing SSL sessions to really measure the first-time visitor experience to our pages.

For now at least, using http://www.webpagetest.org/ will let you get the results you want to analyze since it always uses a fresh connection (aside from subsequent runs within the same execution).

This is a fairly advanced technique, so I see two solutions here

1. Pick some good default behavior and bake it into a "measure the page load" refresh cycle.
2. Use about:net-internals to manage this sort of details.

One other thought if we're discussing advanced techniques: many load-time optimization techniques rely on knowing likely user paths through a site and optimizing later pages through clever things done on previous pages. Currently DevTools allow you a boolean yes/no on using cached assets. It would be useful, though perhaps outside of DevTools' scope, to provide something like snapshotting of a cache status. I want to save the cache status after loading page 1, and then be able to reload page 2 multiple times with just the status of the cache after page 1.

This is something I spoke a little bit to paulirish@ about a few months ago. We did not come to a definite conclusion, but we both agreed that we should have a better way to emulate dns caching.

Part of the problem is even if we disable chrome dns cache, that does not mean somewhere up the chain did not cache it. One solution would be to bypass the default DNS server(s) and use one we know will not cache, but that poses even more problems.

Perhaps an "emulate dns latency" would be useful and put it somewhere under throttling? Right now throttling does not do anything with DNS afaik.