Tried testing the issue on reported chrome version #70.0.3538.77 using Windows 10(HP Elitebook) by following below steps.

Steps:
=====
1.Launched chromium.
2.Navigated to -"https://uimovement.com/" (URL containing UI  animations).
3.Observed that the UI animations played smoothly.
4.Tried giving input in address bar and search box, observed that typing into the URL box did not have any input delay.
Note: Tried with chrome also but found the same behavior as chromium.

Attached screen-cast of the issue and screenshot of the system information as reference.
@reporter: Could you review attached screen-cast and let us know if anything is being missed here. Request you check the issue by creating a new person without any app and extensions in it, reset all flags to default and let us know if issue still exists.
Thanks.!

Deleted: 904486.mp4 19.9 MB

904486.mp4 19.9 MB Download

Deleted: system_info.png 207 KB

	system_info.png 207 KB View Download

Thanks for the quick reply. There are a couple problems with your testing methods that may have caused us to see different results.

1. The "UI animations" tested on that website are actually gifs. These do not accurately represent browser UI animations which are drawn by Chromium itself.

2. Having a 7th Gen Intel Core i5, the PC you tested is relatively powerful. The machines I'm using (that all demonstrate this problem) likely have Intel Celeron N3060 with Intel HD Graphics 400. 

Not to mention, this regression mostly appears immediately after starting Chromium/Chrome. Afterwards, performance will improve. However, clearing necessary data is irrelevant because it appears my organization configured Chrome to reset completely upon each relaunch. Firefox and Microsoft Edge both constantly work completely fine.

My hypothesis is that some obscure resource-heavy operation is running every time the browser is re-launched. (The browser data gets cleared at this point) Whether this is being done by the browser itself or my organization still needs to be verified. 

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

This sounds like a performance issue.  Can you capture a trace?
https://www.chromium.org/developers/how-tos/trace-event-profiling-tool/recording-tracing-runs

(Will the lagging happen for long enough that you can open a tab and start the trace?)

Hello, I apologize for the delay.

I am unable to perform a trace because these are organization computers, which I am merely a user of. Doing some research online, led me to believe that these computers are using the Ephemeral Mode policy for Chrome. Seems to me that some heavy operation is running on the startup of the browser, and when it stops running after 30-60 seconds, performance will improve.

NOTE: Some more relevant affected component labels should be "Enterprise" and "UI" instead of Blink>Animation

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

The title should also be changed to "Temporary Browser UI Slowness With Ephemeral Mode Upon Startup"

Thanks for the update.  Hopefully someone relevant will triage this further with these new component labels.  (I'm not sure otherwise how to hand this off.)

OP: could you follow the instructions at http://dev.chromium.org/developers/how-tos/trace-event-profiling-tool/recording-tracing-runs#TOC-Capturing-chrome-desktop-startup to capture a startup trace? please use a trace-startup-duration value that is long enough for the browser to get up and running to the point where you would expect it to be snappy but find it sluggish. thanks.

pastarmovj: can you think of anything specific to ephemeral profiles that could cause this temporary slowdown? could we be deleting old data during startup on anything other than a low-priority background thread or something?

As per C#11, adding Needs-Feedback label.

This is possible. I don't know the current dynamics of profile cleanup. It used to happen on the now long gone FILE thread back in the good old days but even if it is not necessarily saturating the CPU it might be causing some excessive disk usage that competes with other file IO maybe.

pastarmovj: thanks for chiming in.

OP: the next step for us to diagnose this is to get the startup trace and/or an ETW trace. Please see https://support.google.com/chrome/a/answer/9025467 for instructions on recording an ETW trace. Thanks.

I will attempt to gather a trace today.

The NextAction date has arrived: 2018-12-16

Here's a trace I recorded demonstrating Chrome with high CPU usage when loading one simple tab. (Google News)

Deleted: trace_perftrace_output.json.gz 8.9 MB

trace_perftrace_output.json.gz 8.9 MB Download

bruce: looks like you're primary this week. could you assign this to someone skilled at the art of analyzing perf traces? i took a peek and couldn't see any obvious file IO that would be getting in the way of chrome doing its normal thing. thanks.

I also noticed that Chrome uses nearly 25-30 subprocesses in Task Manager with one tab open. Very CPU intensive.

I also can't see anything in the trace that could explain the slowdowns, nor can I see the 25-30 subprocesses.

Those subprocesses are probably from extensions - are there a lot of extensions running? They tend to run at startup which can be expensive if there are enough of them. Chrome's Task Manager should display them. Sometimes Chrome extensions are installed by corporate policy and can affect startup.

If extensions aren't an obvious problem then I would need an ETW trace. The instructions are at https://support.google.com/chrome/a/answer/9025467. Since this is a startup trace I would want ETW tracing To File to be started, then Chrome launched, and then the trace buffers saved after 30 seconds or so, or when Chrome starts being responsive. If you can share the trace with brucedawson@chromium.org then I will analyze it.

Sorry about the confusion. The trace I recorded yesterday was not an ETW startup trace. I went home tried to replicate the environment where the slowdown was most noticeable by enabling the ForceEphermeralProfiles policy and force installing an extension. The results I noticed were an insane increase in subprocess count from the usual 4-6 (of an unconfigured chrome) to 35-40 immediately during startup. This will last about 15 seconds on my speedy Skylake i5 machine, but the computers affected (Intel Celeron N3060) will take quite a while to return to the normal count. Usually around 1-2 minutes. It has been shared with you via Google Drive.

(the new trace was shared with you via Google Drive)

Here is a screenshot of Task Manager immediately after opening Chrome.

Deleted: screenshot.jpg 281 KB

	screenshot.jpg 281 KB View Download

A screen shot of Chrome's task manager is more useful because it identifies process types and it associates processes with specific tabs. But - the ETW trace has most of that information. It lets me see, for instance, that there are nine extension processes and a *lot* of utility processes, with 70 processes in total:

C:\Program Files (x86)\Google\Chrome\Application\chrome.exe (4204) - 70 processes
    browser     : 4204 
    crashpad    : 12700 
    extension   : 2840 4456 5960 7808 10424 10912 11404 12688 13140 
    gpu-process : 1612 13200 
    renderer    : 1740 6932 9288 13024 
    utility     : 112 208 1236 1360 1724 2092 2540 2592 4208 5388 5520 6012 6244 6360 6652 6712 6768 6824 6928 6952 7076 7400 7716 8068 8204 8256 8304 8400 8588 9072 9156 9416 9896 10012 10124 10404 10816 10820 10856 11104 11124 11396 11644 12024 12576 12692 12708 12876 12912 13120 13200 13284 
    watcher     : 1572 

About half of the CPU usage is from the browser process with most of the rest just coming from starting up so many processes. I'll see what I can find.

Most of the processes live for less than six seconds, with many living for less than 0.5 seconds. That's why it looked like there were "only" 35-40 processes - that was the maximum that were alive at any given time. The utility processes (when sorted by creation time) seem to alternate between the extremely short-lived processes (200-500 ms) and longer-lived processes (5-6 s), with renderer and extension processes mixed in occasionally. You can see the lifetimes of a few dozen of the processes in the attached screenshot - the numbers on the bottom are times in seconds.

Unless this utility-process proliferation makes sense to somebody I think we need a chrome://tracing startup trace to better understand *why* this is happening.

https://www.chromium.org/developers/how-tos/trace-event-profiling-tool/recording-tracing-runs#TOC-Capturing-chrome-desktop-startup

It looks like the bulk of the action happens in the first ten seconds, but capturing the first twenty seconds would probably be best. So, something like this (you can add the arguments to the properties of the Chrome icon).

  chrome.exe --trace-startup --trace-startup-file=%temp%\bug_904486.json --trace-startup-duration=20

Then you can share %temp%\bug_904486.json

Deleted: Process lifetimes.PNG 7.9 KB

	Process lifetimes.PNG 7.9 KB View Download

Here is a theory - if extensions are being installed, most probably due to policy because otherwise ephemeral profiles will start with only the default set of extensions which is small, then Chrome will download the extension and spawn a process for each to unzip it. 

I think the issue is well enough understood now - assigning to someone who works on enterprise for triage. There may be opportunities to optimize the ephemeral startup procedure in the presence of many extensions. For instance, each process startup/shutdown can easily cost 100-200 ms (across chrome.exe, System, and MsMpEng.exe, see crbug.com/894253, comment #12) so reusing utility processes to install extensions could save 5-10 s of CPU time.

Alternately, this could be addressed by reducing the number of extensions that are installed.

I only force-installed one additional extension in my testing.

Some other notes I failed to add, and reassigning to somebody else:

Good theory. I like it. And now that the ETW symbols have finally loaded I can see that chrome_child.dll!zip::ZipReader::OpenCurrentEntryInZip shows up on the CPU usage call stacks of at least 22 processes.

My guess is that there is a two-stage process dance to download, unzip, and install the extensions. That explains the short/long pattern seen in the process lifetimes above. If there are 22 extensions being downloaded then that explains 44 of the 52 utility processes, maybe more.

I guess this is working-as-intended. Either we should document that ephemeral mode works poorly with extensions, or find some way to improve this situation.


> I only force-installed one additional extension in my testing.

How many total? Just one? That's quite weird if that's the case. Maybe the 22 extension processes that are doing unzipping are unzipping... something else? I don't know what.

I can confirm this bug occurs even when no extensions are installed.

Op: I have a couple of follow-up questions:

- Did you use an existing or a new profile when testing with the ForceEphermeralProfiles policy?
- Was sync enabled for the profile used during your tests?
- Could you provide the number of extensions shown in the chrome://extensions page?

Okay, the ForceEphemeralProfiles policy applies to the entire browser. Thus, it clears the browser's data regardless of sign-in information. For instance, the browser has no account signed in by default. However, a user may choose to sign in, and their account will be cleared, afterwards. To answer your question, it starts out with a blank profile every time because of this policy. 

The testing I've done revealed that the slowdown occurs regardless of sync enabled or not. Even a browser that hasn't any user signed in still experiences the slowdown on start.

According to the extensions page, the only extension present on the affected devices is Google Docs Offline as well as the Docs, Sheets, Slides apps. (which come bundled with Chrome)

Hope this helps.

I also performed a much more "scientific" test on one of the actual affected devices. The slow down lasts approximately 40 seconds to 1 minute, and does correspond with the increased activity in the Chrome Task Manager. 

P.S. On heavy websites like The Verge, it is hard to scroll using the scrollbar and even worse with the touch pad. I am aware that this is a separate bug. However, the slowness during this time makes it worse.

Deleted: chrometaskmanager.png 25.8 KB

	chrometaskmanager.png 25.8 KB View Download

I have another related hypothesis.
I previously was not aware that branded Chromium builds (for instance Google Chrome) may come with numerous other “component extensions” that provide core functionality to users. Some of these may be the CryptoTokenExtension, Google Hangouts, HotwordHelper, etc. My main concern would be whether or not these are cleared upon every startup with the ForceEphemeralProfiles policy enabled. This would potentially explain some of the startup operations. If so, this is relatively inefficient as the policy was intended to only clear the USER’s data, rather than core Chrome functionality.

P.S. A list of these extensions may be found in chrome://system  There seem to be many of them. Perhaps I’m just stating the obvious.