Try the following command line: chrome --remote-debugging-port=9222
Then open http://localhost:9222 and inspect your page via devtools webUI.
Make sure to fully quit Chrome before launching it with the new command line so that no "hidden" processes remain.

> Try the following command line: chrome --remote-debugging-port=9222

I'm stuck trying to do that on stupid Windows 10 (I'm used to Linux).
Can you help me?

See screenshot. When I use the quotes around the file path alone (I need the quotes because there are spaces), it complains of some syntax error with the "--".
If I try to enclose everything into the quotes, then it just does nothing (certainly doesn't launch Chrome).

Deleted: Untitled.png 43.4 KB

	Untitled.png 43.4 KB View Download

You can either cd into chrome app directory or use the quotes around the path:
"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --remote-debugging-port=9222

Ok I could run it.

This workaround seems to work, except that then I wanted to SAVE THE PROFILE and I couldn't: it says 
"Saving is not enabled in hosted mode [WHY THE F**K??] Please inspect using chrome://inspect"

I tried going to chrome://inspect and I could indeed inspect the page running in the other window; however this causes all sorts of nonsense behavior, such as emulating a touchscreen on the desktop page that was already open in a desktop window where there's no reason whatsoever to emulate a touchscreen device.

All this is unbelievably stupid.

> or use the quotes around the path:
> "C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --remote-debugging-port=9222

As demonstrated in my screenshot, that does NOT work. Not sure if it's Windows 10 stupidity or a bug in Chrome.

I was finally able to run it with
start "C:\Path to\chrome.exe" --remote-debugging-port=9222

>As demonstrated in my screenshot, that does NOT work

Your screenshot contains invalid single quotes around the entire command line whereas my example explicitly used doublequotes around the app path only.

Oh, sorry about that.

Anyway, see comment 4.

Now by having the Developer Tools in a separate window, I was able to keep observing the slowness in the browser window with the Devtools open. However, the moment I start recording for profiling, the slowness usually disappears. Apparently not 100% of the times, but it's hard to tell because sometimes I start observing some slowness again while profiling, and I'm not sure whether I'm observing the original slowness  or the one introduced by profiling itself.

The behavior indeed looks strange. If we compare the following modes:
(a) DevTools is not open
(b) DevTools is open, but not profiling
(c) DevTools is open, profiling
the (a) should be the fastest, (c) is expected to be a bit slower, and (b) is expected to be the slowest.
If you can share the URL where you observe the behavior it would be much easier to investigate the issue. Is it possible? Thanks.

> (c) is expected to be a bit slower, and (b) is expected to be the slowest.

I guess you meant the other way round.

> If you can share the URL where you observe the 
> behavior it would be much easier to investigate the issue. Is it possible?

Unfortunately, not. Up to now I've observed it only on websites with restricted access.

By the way, I'm almost sure the slowness I'm trying to debug is due to a Chrome bug and not an issue in the scripts running in those web pages, as it has appeared suddenly a few weeks ago on several sites of ours where we haven't touched absolutely anything, and it only happens in Chrome. Also, it appears and disappears very randomly, though I have never observed an instance when attempting to profile wouldn't make it disappear.

> > (c) is expected to be a bit slower, and (b) is expected to be the slowest.
> I guess you meant the other way round.

No, I meant it the way I said.
When you open DT it enables lots of instrumentation hooks on the page, so it becomes slower. When you start recording performance it disables most of the hooks to reduce the instrumentation overhead and make the profile as close to the original page behavior as possible.

> Unfortunately, not. Up to now I've observed it only on websites with restricted access.

Can you please then record a couple traces and attach them to the bug report. Here are the steps:

1. Open the affected page. It's better if you close all other tabs.
2. Make sure DevTools are not open.
3. Open another tab and navigate to chrome://tracing
4. Press Record (in the top left corner) and then Record again in the dialog box.
5. Switch to the page and observe the "slow behavior".
6. Switch back to the chrome://tracing tab, stop recording and save the trace to a file.

Do these steps with DevTools open for the page in step 2, make sure you observe the "fast behavior" in step 5.

Attach both traces to the bug report. Thanks.

> No, I meant it the way I said.
> When you open DT it enables lots of instrumentation hooks on the page, 
> so it becomes slower. When you start recording performance it disables 
> most of the hooks to reduce the instrumentation overhead and make 
> the profile as close to the original page behavior as possible.

Well, in my experience, leaving aside the particular case in this issue which is tricky, whenever I have something that consistently does a certain amount of work in javascript, (c) is WAY slower than both (a) and (b) (between which I can't notice any difference), which is what I would expect given that actually recording performance data seems to me an hugely costly task even if you try hard to keep it to a minimum.