I was tasked with investigating why on large pages, mobile takes longer to load a page then VE. To do this I loaded a template heavy page in both mobile and desktop and ran JavaScript profiling on both.
In desktop7.9% of time was spent in jQuery.extend.css - this was the most heavy function. In mobile it was also the most heavy - however in mobile a whopping 23.76% of time was spent in jQuery.extend.css
In mobile 14360 calls were made to by both desktop and mobile to get the value of float.
Looking closer at what was calling these I found it was related to phantom element.
So it looks like fixing the following bug: https://bugzilla.wikimedia.org/show_bug.cgi?id=64709 will help improve performance in mobile drastically.
I imagine the slowdown is related to the fact that on desktop existing content is replaced with VisualEditor interface but on mobile there are more DOM elements as VisualEditor is opened in an overlay on top of the content.
Specifically the calls inside this callback that hog the most are: 1) $this.css( 'float' ); 2) node.$.context.importNode( $shieldTemplate[0], true )
Awesome work Jon! Did you happen to see anywhere else that seemed like viable places for us to make additional gains?
On Thu, May 1, 2014 at 12:15 PM, Jon Robson jrobson@wikimedia.org wrote:
I was tasked with investigating why on large pages, mobile takes longer to load a page then VE. To do this I loaded a template heavy page in both mobile and desktop and ran JavaScript profiling on both.
In desktop7.9% of time was spent in jQuery.extend.css - this was the most heavy function. In mobile it was also the most heavy - however in mobile a whopping 23.76% of time was spent in jQuery.extend.css
In mobile 14360 calls were made to by both desktop and mobile to get the value of float.
Looking closer at what was calling these I found it was related to phantom element.
So it looks like fixing the following bug: https://bugzilla.wikimedia.org/show_bug.cgi?id=64709 will help improve performance in mobile drastically.
I imagine the slowdown is related to the fact that on desktop existing content is replaced with VisualEditor interface but on mobile there are more DOM elements as VisualEditor is opened in an overlay on top of the content.
Specifically the calls inside this callback that hog the most are:
- $this.css( 'float' );
- node.$.context.importNode( $shieldTemplate[0], true )
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
On 05/01/2014 12:15 PM, Jon Robson wrote:
I imagine the slowdown is related to the fact that on desktop existing content is replaced with VisualEditor interface but on mobile there are more DOM elements as VisualEditor is opened in an overlay on top of the content.
That's a good point. We should try, as an experiment, removing the original article from DOM and see if this helps. CC-ing Roan.
I investigated a little more and found out what specifically in mobile causes the issue.. https://bugzilla.wikimedia.org/show_bug.cgi?id=64719
Re-adding ve-tech
On Thu, May 1, 2014 at 1:52 PM, Juliusz Gonera jgonera@wikimedia.org wrote:
On 05/01/2014 12:15 PM, Jon Robson wrote:
I imagine the slowdown is related to the fact that on desktop existing content is replaced with VisualEditor interface but on mobile there are more DOM elements as VisualEditor is opened in an overlay on top of the content.
That's a good point. We should try, as an experiment, removing the original article from DOM and see if this helps. CC-ing Roan.
-- Juliusz
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
The issues on load I believe we are having have to do with "shields".
Shields are transparent 1x1 gif images we inject into the DOM to simulate selecting over objects which are made up of complex HTML structures. They originally also protected the HTML structure from being clicked on directly (hence the name "shield"). More recently other techniques such as "phantoms", "highlights" and "relocatable markers" have taken over the click blocking functionality. This technique was invented by Inez/Christian of Wikia, and is regarded as creative and effective but inefficient.
Without doing much profiling, here is my best guess about what is going on.
First we traverse DOM structures, looking for elements which might be able to display outside their parent's bounding box, such as position: absolute, or floats. This can be quite expensive because we have to do a lot of CSS computed style checks and measurements, and the code isn't fully optimized to use direct DOM methods so there's a little jQuery overhead. Second we then insert the transparent images into the DOM structures, and there could be hundreds of these pretty easily.
Trying to solve this problem we can optimize the first step a bit. However, the traversal and measurement stuff will hit a limit pretty quickly. The technique we use to fake the selection may have alternative solutions, but I'm not sure about their performance impacts, especially on mobile devices.
Overall, the shield/phantom/highlight/marker systems need to converge into a simpler and more performant solution, and I have a few general ideas and the intention to do this, but haven't yet sized it up or scheduled it. I'm hoping we can surface this as a more pressing issue now that mobile VE is hitting this wall, and get going on it soon.
- Trevor
On Thu, May 1, 2014 at 12:15 PM, Jon Robson jrobson@wikimedia.org wrote:
I was tasked with investigating why on large pages, mobile takes longer to load a page then VE. To do this I loaded a template heavy page in both mobile and desktop and ran JavaScript profiling on both.
In desktop7.9% of time was spent in jQuery.extend.css - this was the most heavy function. In mobile it was also the most heavy - however in mobile a whopping 23.76% of time was spent in jQuery.extend.css
In mobile 14360 calls were made to by both desktop and mobile to get the value of float.
Looking closer at what was calling these I found it was related to phantom element.
So it looks like fixing the following bug: https://bugzilla.wikimedia.org/show_bug.cgi?id=64709 will help improve performance in mobile drastically.
I imagine the slowdown is related to the fact that on desktop existing content is replaced with VisualEditor interface but on mobile there are more DOM elements as VisualEditor is opened in an overlay on top of the content.
Specifically the calls inside this callback that hog the most are:
- $this.css( 'float' );
- node.$.context.importNode( $shieldTemplate[0], true )
Trevor and VE folks more broadly, is this something you have now scheduled to work on? We're currently planning to have VE for tablets in stable and launch the automatic mobile redirect for tablets on June 17, and I'm curious about the likelihood of tackling the performance issues from the VE side of things before then.
On Thu, May 1, 2014 at 3:53 PM, Trevor Parscal tparscal@wikimedia.orgwrote:
The issues on load I believe we are having have to do with "shields".
Shields are transparent 1x1 gif images we inject into the DOM to simulate selecting over objects which are made up of complex HTML structures. They originally also protected the HTML structure from being clicked on directly (hence the name "shield"). More recently other techniques such as "phantoms", "highlights" and "relocatable markers" have taken over the click blocking functionality. This technique was invented by Inez/Christian of Wikia, and is regarded as creative and effective but inefficient.
Without doing much profiling, here is my best guess about what is going on.
First we traverse DOM structures, looking for elements which might be able to display outside their parent's bounding box, such as position: absolute, or floats. This can be quite expensive because we have to do a lot of CSS computed style checks and measurements, and the code isn't fully optimized to use direct DOM methods so there's a little jQuery overhead. Second we then insert the transparent images into the DOM structures, and there could be hundreds of these pretty easily.
Trying to solve this problem we can optimize the first step a bit. However, the traversal and measurement stuff will hit a limit pretty quickly. The technique we use to fake the selection may have alternative solutions, but I'm not sure about their performance impacts, especially on mobile devices.
Overall, the shield/phantom/highlight/marker systems need to converge into a simpler and more performant solution, and I have a few general ideas and the intention to do this, but haven't yet sized it up or scheduled it. I'm hoping we can surface this as a more pressing issue now that mobile VE is hitting this wall, and get going on it soon.
- Trevor
On Thu, May 1, 2014 at 12:15 PM, Jon Robson jrobson@wikimedia.org wrote:
I was tasked with investigating why on large pages, mobile takes longer to load a page then VE. To do this I loaded a template heavy page in both mobile and desktop and ran JavaScript profiling on both.
In desktop7.9% of time was spent in jQuery.extend.css - this was the most heavy function. In mobile it was also the most heavy - however in mobile a whopping 23.76% of time was spent in jQuery.extend.css
In mobile 14360 calls were made to by both desktop and mobile to get the value of float.
Looking closer at what was calling these I found it was related to phantom element.
So it looks like fixing the following bug: https://bugzilla.wikimedia.org/show_bug.cgi?id=64709 will help improve performance in mobile drastically.
I imagine the slowdown is related to the fact that on desktop existing content is replaced with VisualEditor interface but on mobile there are more DOM elements as VisualEditor is opened in an overlay on top of the content.
Specifically the calls inside this callback that hog the most are:
- $this.css( 'float' );
- node.$.context.importNode( $shieldTemplate[0], true )
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
We now have our QA person (Rummana) testing on an iPad, which is helping to surface issues in general, but her focus has mostly been on bugs. We do have some scheduled bandwidth to deal with these problems, and now that we have a sort of deadline, I think it's a good idea to get some focus on this. I have a personal iPad, but prying it out of my wife's hands is tough. Do we have any more devices we can use at work for testing?
- Trevor
On Thu, May 15, 2014 at 10:22 AM, Arthur Richards arichards@wikimedia.orgwrote:
Trevor and VE folks more broadly, is this something you have now scheduled to work on? We're currently planning to have VE for tablets in stable and launch the automatic mobile redirect for tablets on June 17, and I'm curious about the likelihood of tackling the performance issues from the VE side of things before then.
On Thu, May 1, 2014 at 3:53 PM, Trevor Parscal tparscal@wikimedia.orgwrote:
The issues on load I believe we are having have to do with "shields".
Shields are transparent 1x1 gif images we inject into the DOM to simulate selecting over objects which are made up of complex HTML structures. They originally also protected the HTML structure from being clicked on directly (hence the name "shield"). More recently other techniques such as "phantoms", "highlights" and "relocatable markers" have taken over the click blocking functionality. This technique was invented by Inez/Christian of Wikia, and is regarded as creative and effective but inefficient.
Without doing much profiling, here is my best guess about what is going on.
First we traverse DOM structures, looking for elements which might be able to display outside their parent's bounding box, such as position: absolute, or floats. This can be quite expensive because we have to do a lot of CSS computed style checks and measurements, and the code isn't fully optimized to use direct DOM methods so there's a little jQuery overhead. Second we then insert the transparent images into the DOM structures, and there could be hundreds of these pretty easily.
Trying to solve this problem we can optimize the first step a bit. However, the traversal and measurement stuff will hit a limit pretty quickly. The technique we use to fake the selection may have alternative solutions, but I'm not sure about their performance impacts, especially on mobile devices.
Overall, the shield/phantom/highlight/marker systems need to converge into a simpler and more performant solution, and I have a few general ideas and the intention to do this, but haven't yet sized it up or scheduled it. I'm hoping we can surface this as a more pressing issue now that mobile VE is hitting this wall, and get going on it soon.
- Trevor
On Thu, May 1, 2014 at 12:15 PM, Jon Robson jrobson@wikimedia.orgwrote:
I was tasked with investigating why on large pages, mobile takes longer to load a page then VE. To do this I loaded a template heavy page in both mobile and desktop and ran JavaScript profiling on both.
In desktop7.9% of time was spent in jQuery.extend.css - this was the most heavy function. In mobile it was also the most heavy - however in mobile a whopping 23.76% of time was spent in jQuery.extend.css
In mobile 14360 calls were made to by both desktop and mobile to get the value of float.
Looking closer at what was calling these I found it was related to phantom element.
So it looks like fixing the following bug: https://bugzilla.wikimedia.org/show_bug.cgi?id=64709 will help improve performance in mobile drastically.
I imagine the slowdown is related to the fact that on desktop existing content is replaced with VisualEditor interface but on mobile there are more DOM elements as VisualEditor is opened in an overlay on top of the content.
Specifically the calls inside this callback that hog the most are:
- $this.css( 'float' );
- node.$.context.importNode( $shieldTemplate[0], true )
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
-- Arthur Richards Software Engineer, Mobile [[User:Awjrichards]] IRC: awjr +1-415-839-6885 x6687
On Thu, May 15, 2014 at 10:26 AM, Trevor Parscal tparscal@wikimedia.orgwrote:
We now have our QA person (Rummana) testing on an iPad, which is helping to surface issues in general, but her focus has mostly been on bugs. We do have some scheduled bandwidth to deal with these problems, and now that we have a sort of deadline, I think it's a good idea to get some focus on this.
Awesome!
I have a personal iPad, but prying it out of my wife's hands is tough. Do we have any more devices we can use at work for testing?
I am fairly certain the answer to this is 'yes'. Check with Tomasz about access to devices - there's a page on officewiki documenting the specific devices we have for testing and who is currently hanging on to them, but I suspect it's out of date ( https://office.wikimedia.org/wiki/Engineering/Mobile/Testing_Devices).
On May 15, 2014 10:22 AM, "Arthur Richards" arichards@wikimedia.org wrote:
Trevor and VE folks more broadly, is this something you have now
scheduled to work on? We're currently planning to have VE for tablets in stable and launch the automatic mobile redirect for tablets on June 17, and I'm curious about the likelihood of tackling the performance issues from the VE side of things before then.
Ed has been fixing some things to do with shields and phantoms. I'll send you some Gerrit links in a minute.
Roan
On May 15, 2014 10:27 AM, "Roan Kattouw" rkattouw@wikimedia.org wrote:
Ed has been fixing some things to do with shields and phantoms. I'll send
you some Gerrit links in a minute.
https://gerrit.wikimedia.org/r/#/c/133236/
https://gerrit.wikimedia.org/r/#/c/130823/
The former should address the importNode problem Jon mentioned and the latter should improve CSS performance, as it addresses something similar to a problem in MF that Jon reported.
As James said, new performance feedback after these changes (though in fairness one of them was merged only this week) would be helpful. We think we've quashed most of the things Jon flagged initially, but we may not have done so adequately or new problems may now be surfacing.
Roan
I'm still waiting for Kaldari or someone in mobile to merge https://gerrit.wikimedia.org/r/131892 before I can confirm the current state.
It definitely seems to be marginally improved on desktop and mobile (with desktop benefiting most) after a few runs.
For the record the nasty page I'm testing on is http://en.m.wikipedia.beta.wmflabs.org/wiki/Jon%27s_nasty_VE_test_page?mobil...
On Thu, May 15, 2014 at 7:44 PM, Roan Kattouw rkattouw@wikimedia.org wrote:
On May 15, 2014 10:27 AM, "Roan Kattouw" rkattouw@wikimedia.org wrote:
Ed has been fixing some things to do with shields and phantoms. I'll send you some Gerrit links in a minute.
https://gerrit.wikimedia.org/r/#/c/133236/
https://gerrit.wikimedia.org/r/#/c/130823/
The former should address the importNode problem Jon mentioned and the latter should improve CSS performance, as it addresses something similar to a problem in MF that Jon reported.
As James said, new performance feedback after these changes (though in fairness one of them was merged only this week) would be helpful. We think we've quashed most of the things Jon flagged initially, but we may not have done so adequately or new problems may now be surfacing.
Roan
On Thu, May 15, 2014 at 3:58 PM, Jon Robson jrobson@wikimedia.org wrote:
I'm still waiting for Kaldari or someone in mobile to merge https://gerrit.wikimedia.org/r/131892 before I can confirm the current state.
It definitely seems to be marginally improved on desktop and mobile (with desktop benefiting most) after a few runs.
Cool. Earlier, you did some profiling and identified specific culprits. Are those now gone/different?
BTW, I hear we're upgrading jQuery to 1.11, according to Timo this made our unit tests run faster and should make everything run faster in general.
Roan
I believe iPad testing is available on crossbrowsertesting.com On 16 May 2014 00:06, "Roan Kattouw" rkattouw@wikimedia.org wrote:
On Thu, May 15, 2014 at 3:58 PM, Jon Robson jrobson@wikimedia.org wrote:
I'm still waiting for Kaldari or someone in mobile to merge https://gerrit.wikimedia.org/r/131892 before I can confirm the current state.
It definitely seems to be marginally improved on desktop and mobile (with desktop benefiting most) after a few runs.
Cool. Earlier, you did some profiling and identified specific culprits. Are those now gone/different?
BTW, I hear we're upgrading jQuery to 1.11, according to Timo this made our unit tests run faster and should make everything run faster in general.
Roan
The % of time spent in these functions has been reduced somewhat according to my latest profiling, but the MobileFrontend nth-child selector /still/ exists so it's still ridiculously high on mobile.
I'm not quite sure at which point we say that we have succeeded in improving VE mobile performance but when someone finally bothers reviewing https://gerrit.wikimedia.org/r/131892 we should have a better idea if mobile is on par with desktop.
On Fri, May 16, 2014 at 1:06 AM, Roan Kattouw rkattouw@wikimedia.org wrote:
On Thu, May 15, 2014 at 3:58 PM, Jon Robson jrobson@wikimedia.org wrote:
I'm still waiting for Kaldari or someone in mobile to merge https://gerrit.wikimedia.org/r/131892 before I can confirm the current state.
It definitely seems to be marginally improved on desktop and mobile (with desktop benefiting most) after a few runs.
Cool. Earlier, you did some profiling and identified specific culprits. Are those now gone/different?
BTW, I hear we're upgrading jQuery to 1.11, according to Timo this made our unit tests run faster and should make everything run faster in general.
Roan
On Fri, May 16, 2014 at 7:19 AM, Jon Robson jrobson@wikimedia.org wrote:
I'm not quite sure at which point we say that we have succeeded in improving VE mobile performance but when someone finally bothers reviewing https://gerrit.wikimedia.org/r/131892 we should have a better idea if mobile is on par with desktop.
Thanks for the review here Juliusz.
--tomasz
So with our latest changes we've also deferred the rendering of shields until the are first focused (tapped, in mobile). This should completely eliminate any page load bottleneck these were causing. On 16 May 2014 15:19, "Jon Robson" jrobson@wikimedia.org wrote:
The % of time spent in these functions has been reduced somewhat according to my latest profiling, but the MobileFrontend nth-child selector /still/ exists so it's still ridiculously high on mobile.
I'm not quite sure at which point we say that we have succeeded in improving VE mobile performance but when someone finally bothers reviewing https://gerrit.wikimedia.org/r/131892 we should have a better idea if mobile is on par with desktop.
On Fri, May 16, 2014 at 1:06 AM, Roan Kattouw rkattouw@wikimedia.org wrote:
On Thu, May 15, 2014 at 3:58 PM, Jon Robson jrobson@wikimedia.org
wrote:
I'm still waiting for Kaldari or someone in mobile to merge https://gerrit.wikimedia.org/r/131892 before I can confirm the current state.
It definitely seems to be marginally improved on desktop and mobile (with desktop benefiting most) after a few runs.
Cool. Earlier, you did some profiling and identified specific culprits. Are those now gone/different?
BTW, I hear we're upgrading jQuery to 1.11, according to Timo this made our unit tests run faster and should make everything run faster in general.
Roan
Awesome, thanks!
On 05/24/2014 02:31 AM, Ed Sanders wrote:
So with our latest changes we've also deferred the rendering of shields until the are first focused (tapped, in mobile). This should completely eliminate any page load bottleneck these were causing.
On 16 May 2014 15:19, "Jon Robson" <jrobson@wikimedia.org mailto:jrobson@wikimedia.org> wrote:
The % of time spent in these functions has been reduced somewhat according to my latest profiling, but the MobileFrontend nth-child selector /still/ exists so it's still ridiculously high on mobile. I'm not quite sure at which point we say that we have succeeded in improving VE mobile performance but when someone finally bothers reviewing https://gerrit.wikimedia.org/r/131892 we should have a better idea if mobile is on par with desktop. On Fri, May 16, 2014 at 1:06 AM, Roan Kattouw <rkattouw@wikimedia.org <mailto:rkattouw@wikimedia.org>> wrote: > On Thu, May 15, 2014 at 3:58 PM, Jon Robson <jrobson@wikimedia.org <mailto:jrobson@wikimedia.org>> wrote: >> I'm still waiting for Kaldari or someone in mobile to merge >> https://gerrit.wikimedia.org/r/131892 before I can confirm the current >> state. >> >> It definitely seems to be marginally improved on desktop and mobile >> (with desktop benefiting most) after a few runs. >> > Cool. Earlier, you did some profiling and identified specific > culprits. Are those now gone/different? > > BTW, I hear we're upgrading jQuery to 1.11, according to Timo this > made our unit tests run faster and should make everything run faster > in general. > > Roan
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Thanks a bunch Ed and friends for focusing on the rendering of shields. Will be good to see the impact this has on both desktop and mobile :-)
On Sat, May 24, 2014 at 12:27 PM, Juliusz Gonera jgonera@wikimedia.org wrote:
Awesome, thanks!
On 05/24/2014 02:31 AM, Ed Sanders wrote:
So with our latest changes we've also deferred the rendering of shields until the are first focused (tapped, in mobile). This should completely eliminate any page load bottleneck these were causing.
On 16 May 2014 15:19, "Jon Robson" jrobson@wikimedia.org wrote:
The % of time spent in these functions has been reduced somewhat according to my latest profiling, but the MobileFrontend nth-child selector /still/ exists so it's still ridiculously high on mobile.
I'm not quite sure at which point we say that we have succeeded in improving VE mobile performance but when someone finally bothers reviewing https://gerrit.wikimedia.org/r/131892 we should have a better idea if mobile is on par with desktop.
On Fri, May 16, 2014 at 1:06 AM, Roan Kattouw rkattouw@wikimedia.org wrote:
On Thu, May 15, 2014 at 3:58 PM, Jon Robson jrobson@wikimedia.org wrote:
I'm still waiting for Kaldari or someone in mobile to merge https://gerrit.wikimedia.org/r/131892 before I can confirm the current state.
It definitely seems to be marginally improved on desktop and mobile (with desktop benefiting most) after a few runs.
Cool. Earlier, you did some profiling and identified specific culprits. Are those now gone/different?
BTW, I hear we're upgrading jQuery to 1.11, according to Timo this made our unit tests run faster and should make everything run faster in general.
Roan
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
I think the root issue in that we are committing CSS on all children. We've yet to come up with a more efficient way of computing the outline of an element but we're open to ideas. Potentially we could drop the shields and only compute outlines on focus. I believe we only need the shields for IE which doesn't respect contenteditable=false. On 15 May 2014 23:58, "Jon Robson" jrobson@wikimedia.org wrote:
I'm still waiting for Kaldari or someone in mobile to merge https://gerrit.wikimedia.org/r/131892 before I can confirm the current state.
It definitely seems to be marginally improved on desktop and mobile (with desktop benefiting most) after a few runs.
For the record the nasty page I'm testing on is
http://en.m.wikipedia.beta.wmflabs.org/wiki/Jon%27s_nasty_VE_test_page?mobil...
On Thu, May 15, 2014 at 7:44 PM, Roan Kattouw rkattouw@wikimedia.org wrote:
On May 15, 2014 10:27 AM, "Roan Kattouw" rkattouw@wikimedia.org wrote:
Ed has been fixing some things to do with shields and phantoms. I'll
send
you some Gerrit links in a minute.
https://gerrit.wikimedia.org/r/#/c/133236/
https://gerrit.wikimedia.org/r/#/c/130823/
The former should address the importNode problem Jon mentioned and the latter should improve CSS performance, as it addresses something similar
to
a problem in MF that Jon reported.
As James said, new performance feedback after these changes (though in fairness one of them was merged only this week) would be helpful. We
think
we've quashed most of the things Jon flagged initially, but we may not
have
done so adequately or new problems may now be surfacing.
Roan
On 15 May 2014 19:22, Arthur Richards arichards@wikimedia.org wrote:
On Thu, May 1, 2014 at 3:53 PM, Trevor Parscal tparscal@wikimedia.org wrote:
The issues on load I believe we are having have to do with "shields".
Trevor and VE folks more broadly, is this something you have now scheduled to work on? We're currently planning to have VE for tablets in stable and launch the automatic mobile redirect for tablets on June 17, and I'm curious about the likelihood of tackling the performance issues from the VE side of things before then.
Which "this"?
If you mean performance generally, we've made I think 6 identifiable performance improvements since the start of May. Some feedback on performance characteristic changes would be appreciated (see my comment on bug 64709 yesterday).
If you mean specifically the phantoms, Ed's done some work as part of these changes, but it's not been "completed" to the length that Trevor suggested earlier.
J.