Load https://html.spec.whatwg.org/ Opend findbar (ctrl+f), and wait ... it takes surprisingly lots of time, and the time is mostly spent under MediaFeatureValuesChanged recalculating all the data. | | | | | | | | | | | -PresShell::FlushPendingNotifications(mozilla::ChangesToFlush) 90.3% 0.0% 1.44KB libxul.so | | | | | | | | | | | | -nsPresContext::MediaFeatureValuesChanged(nsPresContext::StyleRebuildType, nsChangeHint) 90.3% 0.0% 280B libxul.so | | | | | | | | | | | | | -mozilla::RestyleManager::RebuildAllStyleData(nsChangeHint) 90.3% 0.0% 220B libxul.so

The problem is this: (mUsesViewportUnits && mPendingViewportChange)) { which causes a full style rebuild... Specifically, the page has: html { background: bottom right linear-gradient(357deg, #A4A4A4 0, #CCCCCC 7.5em, #FFFFFF 60vh); } body { margin-bottom: 60vh; } in the https://whatwg.org/style/specification stylesheet, which means that the styles depend on the viewport height, which is changing in this case.

Anything we can do to make rebuilding style data faster?

We've been doing a lot (e.g., bug 931668, bug 977991), but they don't help this case. The main thing we could do to help this case is to change viewport units to be part of the computed value, but that requires every caller that handles lengths to handle viewport units, which is a huge amount of work. Viewport units are really a poorly designed feature for performance; in hindsight, we shouldn't have implemented them. Given http://caniuse.com/#feat=viewport-units it's probably too late to remove them, though.

Or we could build data structures specifically for invalidating viewport units.