Last modified: 2013-11-07 17:49:01 UTC
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
Created attachment 13511 [details] contents of the invisible iframe
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.
probably not, closing.