Improve toolbar's front-end performance

Tagging

it'd mostly be DOM time

Note that Drupal.behaviors.toolbar.attach() has a @todo at the top for generating each subtree DOM on demand.

Did perf mesurements for front-end before it was committed. There is like a 10-20% (toolbar is closed/toolbar has menu tray open) hit on page load because of all the new JS compared to the old toolbar. Wasn't that bad and code can be streamlined to reduce the gap so didn't raise it on the other issue.

editing tags

Raised related #1927174: Complete the work to make the Toolbar administration menu sub tree rendering more efficient to critical.

Trying to help out getting some performance data. Hope this helps, attaching a more detailed rapport from Yslow.

Test env:
Clean install with all the default settings from the normal install profile
PHP 5.4.x
MariaDB

Firefox 20.0

Browser: Firefox 20.0
Report generator: Firebug and Yslow.

Toolbar module enabled

1.82s load time
268ms waiting
10ms loading
1.25 DOMContentLoaded

Toolbar module disabled

1.3s load time
225ms waiting
10ms loading
979ms DOMContentLoaded

Chrome benchmark

Chrome Version 26.0.1410.65

Toolbar module enabled

86 requests
856 KB transferred
1.46 s
onload: 1.46 s
DOMContentLoaded: 1.43 s

Toolbar module disabled

55 requests
741 KB transferred
546 ms
onload: 548 ms
DOMContentLoaded: 537 ms

Edit: Added info about what browser this was tested on (FF) and did a quick test with Chrome devel.

the subtree script thing is a big hit, it should have the async or defer attribute added to it. I'd try removing it altogether and see the timings. Personally i don't care for the expending menu so I won't have the subtree script loaded.

See #1927174: Complete the work to make the Toolbar administration menu sub tree rendering more efficient and #1805054: Cache localized, access filtered, URL resolved, and rendered menu trees.

Tagging, though I suspect this is a duplicate of both the issues mentioned in #9? Or are there other things to do here?

there are always other things to do. It's just that #9 should be fixed first because that's the real perf issue today. Once that's solved the next bottleneck will be here.

Currently not working on the issue.

Better title.

Marked #2145365: Make toolbar rendering fast as a duplicate of this. From its IS:

Now that overlayslayer is in core, the toolbar loads much more frequently than before and it's initialization is slow. It makes page loading particularly ugly.

Toolbar should be loaded like the no-js version on page load (and opening the menu tray by default in the no-js version) and get initialized when the user scroll.

That way the page won't jump around when the page loads. Hopefully we can make a few things a bit simpler as well.

That's a slightly different scope than this issue, but it's definitely in the "front-end performance" realm.

Adding one relevant tag that the other issue had but this one didn't yet.

For now let's focus on #2542050: Toolbar implementation creates super annoying re-rendering.. Folks are welcome to reopen this issue with a more narrow scope if desired.