Page MenuHomePhabricator

significant intermittent performance problem in Chrome
Closed, InvalidPublic

Description

Seen in Chrome and not Firefox:

Sometimes initiating a VE session can take on the order of 3X the normal time (or possibly more). This is a UX issue and also causes significant intermittent browser test failures in Chrome version 30. Here are 10 runs of a script[*] that times how long it takes to bring up and dismiss the "Welcome..." iframe:

2.194106
2.187554
2.222601
2.226447
2.369503
2.182237
7.639938 *
2.335375
2.397571
2.271333

This is on a fast connection. The performance issue is exacerbated on a slow connection.

Speculation as to the root cause:

  • The "Welcome..." iframe is actually the second iframe in the page. The first, much larger iframe in the page is invisible and is a complete copy of the base VisualEditor UI. It could be that loading both iframes could cause intermittent performance problems.
  • (Note that the invisible first iframe on the page not only contains an entire VE UI, but may also contain gadget code like HotCat or ProveIt sourced from other places like bits, see screen shot and Bug 55759.)
  • The meat of the little Ruby timer script is:

#CLICK EDIT
b.a(:title => /Edit this page with VisualEditor/).when_present.click
#SAVE START TIME
welcome_start_time = Time.now
#CLICK CLOSE ON THE WELCOME IFRAME WHEN IT BECOMES CLICKABLE
b.frame(:index => 1).a(:title => 'Close').when_present.click
#SAVE END TIME
welcome_end_time = Time.now
welcome_load_time = welcome_end_time - welcome_start_time
puts welcome_load_time.to_s


Version: unspecified
Severity: normal

Details

Reference
bz55801

Event Timeline

bzimport raised the priority of this task from to Needs Triage.Nov 22 2014, 2:40 AM
bzimport set Reference to bz55801.

Created attachment 13511
contents of the invisible iframe

Attached:

invisible_iframe_contents.png (822×1 px, 172 KB)

I also don't see a reason to load gadgets in the VE frames. Since it's same-origin, gadgets can reach into the iframe if needed. E.g.

$( $( '.ve-ui-frame' )[0].contentDocument ).find( '.ve-ui-labeledElement-label' )

Gadgets are not and never were loaded in our iframes.

The only thing related to gadgets being applied in iframes is their stylesheets. And this is not an explicit action, but a result of the stylesheet link established between the parent and child frame to ensure content looks the same.

Afaik this should not have any significant impact in performance as 1) these styles are loaded in the same request as other styles, 2) the exact same request has been fired and cached already in the parent frame, and as such is pretty much guaranteed to be 304 cached if not already.

Also, in non-debug mode, most stylesheets actually become <style> tags which are cloned to the iframe without any intermittent load.php request (be it a 304 or not).

I don't know what significant intermittent performance problem you are observing in Chrome, but I am fairly confident that this is not related to ProveIt, or any other gadget.