There is definitely a difference of performance: about 2-3x slower on my machine.

Attaching traces from:
 - Google Chrome 54.0.2832.2 (Official Build) canary (64-bit)
 - Revision	 373f6bdd42a605a49fa170b2bcdbae3fbd015acc-refs/branch-heads/2832@{#3}
 - Mac OS X

+hotlist-loading (not limited to loading per se but relevant to project Caminito) +kouhei as an fyi

Oops, wrongs traces... Fixing.

To what extent do you think the use of animation keyframes is key to the performance issue you're seeing? From your investigation, have you seen any indications that the issue is in animations code? I haven't spotted anything in the traces.

Good question. From what I can tell, it seems unlikely that the keyframes can be blamed. The cost appears to be in layout (maybe paint as well?). Removing for now.

Thanks for the comment!

Installing keyframes do impact reflow time, though it may be independent of having a Web font loaded.

If you change the click handler to just install an empty CSS rule, e.g. '.empty {}' instead of keyframes, the reflow time is fractions of a millisecond for both the default and Roboto cases.

With keyframes, default reflow takes 10x or more longer and Roboto reflow takes ~40x or more longer.

The multipliers may depend on the machine, but adding keyframes increases reflow time by an order of magnitude over a simple style rule and doing either with Roboto loaded seems to increase by ~4x.

Has anyone confirmed whether this is Roboto specific, or any web font?
Also, is it Google Fonts specific? or any web font served from any old
location?

Repros with Open Sans and Droid Sans served from Google Fonts:
https://fonts.googleapis.com/css?family=Open+Sans
https://fonts.googleapis.com/css?family=Droid+Sans
https://fonts.googleapis.com/css?family=Roboto

Actually, it can be reduced all the way down to this:

@font-face {
  font-family: 'Anything';
  src: local('Anything');
}

Performance of this test differs quite a lot between stable and canary. On my MacBook Air:

52.0.2743.82, no web font => 7ms
52.0.2743.82, with Roboto => 30ms

54.0.2835.0, no web font => 0.2ms
54.0.2835.0, with Roboto => 0.6ms

I'm not sure if we should worry about this 0.6ms.


> Observation: "Capturing timeline shows 'Recalculate style' appears 2 times for Default, but with Roboto, 'Recalculate style' is slower and each one is followed by an equally slow 'Layout'.

I see this in stable but not in canary.

Interesting.

Given that the performance on Canary for both cases now beat the best case on Stable, I'm thinking that the Google team that raised this issue should be happy.

And agreed that given the significantly smaller order of magnitude, we might consider the case closed.

I'll circle back.

We are in a much better place and the original reporter is happy.

It would be nice to determine which change lead to this win and find out if we have the right test in place to catch any regression. I'll try to do a bisect.

Adding needs-bisect (try to do one myself but the tool is not working anymore :( )

rnimmagadda@, could you help us?

We want to find the CL that lead to a massive improvement between Chrome 52 and 53 (or 54).

Test case: https://codepen.io/anon/pen/grJbKQ
steps: 
 0. start a bisect
 1. open the URL above
 2. open devtools => console
 3. click on the button a bunch of times
 4. look at the durations logged in the console
 5. at one point the performance should be much much better (see comment #12 for an example on a particular machine).


Thanks in advance!

====================================

Good Build:

53.0.2785.0    Base Position: 403382


Bad Build:

53.0.2763.0    Base Position: 398752

=====================================

Able to repro this issue on Windows 7, MAC (10.11.6) & Ubuntu Trusty (14.04) for the Google Chrome Stable Version - 52.0.2743.116

This is a regression issue broken in M53, below mentioned is the bisect info:

CHANGELOG URL: https://chromium.googlesource.com/chromium/src/+log/11d33ea93b80c9f1f6f37514b5beb633ec644c09..adfc5e3c37b1a155af7b2a0f29b52dc8b4dfd0b3

Suspecting Commit: 9c88a15f059aec65af294b8789a27cc377363da6

Review URL: https://codereview.chromium.org/2105743002

@rune: Could you please look into the issue, and if it has nothing to do with your changes and if possible please do assign it to the concerned owner.

Thank you.

Note: Issue got fixed in the Latest Canary Version - 54.0.2839.0 [In fact, as mentioned above this issue got fixed after the version - 53.0.2785.0 (which covers the latest Chrome Beta Version as well). Needs to be fixed on Chrome Stable Version only]

The @keyframes performance improvement is my commit, yes.

The fixed issue is 623911, so if it needs to be back-ported, that issue should get the merge request.

What should happen with this issue? Mark as duplicate, or should it be kept open to investigate the slower-layout-in-the-presence-of-webfonts issue?

Don't know why this is marked as a regression, though.

Assigning back to Kenji (although I guess we can just close this).

rnimmagadda@ that was really fast! Thanks a lot.

Rune@: I wanted to find out why things go so much faster. Now that we know: congratulations on such a massive improvement. I'm hoping that we have tests/etc. so that we don't regress from there on, up to you :)

Rune's CL (https://crrev.com/9c88a15f05) has a layout test, so we already have test coverage on this :)

Hurray!

@kenjibaheux: My pleasure.

Thank you.