You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Peter Gardfjäll <pe...@gmail.com> on 2009/04/16 15:47:26 UTC
wicket-ajax and IE performance problems for pages with many links
Hi all,
I am working on a wicket application intended to be executed both on
FF3 and IE7.
While working on this application I have discovered that the rendering
of some pages are a lot slower in IE.
The pages that were significantly slower on IE have a couple of things
in common: they are ajax-enabled and have lots of links.
These pages all appear to freeze for a while after all data has been
transferred, but before the page becomes responsive.
The reason (or at least one of the reasons) is that wicket-ajax.js,
which gets pulled in whenever an Ajax component/behavior is added to a
page, registers a function
(addDomReadyEvent(Wicket.Focus.attachFocusEvent)) that traverses all
{input,select,a,textarea,button} tags in the DOM tree when the page
has been loaded.
I timed this function for one of my pages (containing a single big
table with around 300 rows, with each row having about six links).
When the function is registered, the fireDomReadyHandlers in
wicket-event.js takes 2400 ms to execute, compared to 700 ms when not
registered. In firefox, the corresponding numbers are about 470 ms and
400 ms.
Hence, there seems to be quite a performance penalty involved in
loading ajax pages with lots of links in IE7.
I'm a bit worried about this overhead, particularly since I have a
rather fast machine (a lot better than most of the end users anyway).
I would not be surprised if clients see double page load times.
Have anyone on this list experienced similar problems?
Is this a known issue? (I have not been able to find anything similar
on the mailing list)
Any suggestions or pointers are welcome.
best regards, Peter
/PS By the way, I am using wicket 1.3.5.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: wicket-ajax and IE performance problems for pages with many links
Posted by Jason Lea <ja...@kumachan.net.nz>.
Wicket.Focus.attachFocusEvent is very slow in IE compared to FireFox.
At first I thought attaching an event was slow, but it seems to be just
iterating over the list of elements returned by
document.getElementsByTagName takes forever.
FF would take 17 ms, IE 900ms for a test page with 1200 links.
Another issue with attaching events to all of these elements is that it
occurs once in DOM load, but also after every ajax response. So my test
page with one ajax link, with an empty onClick(AjaxRequestTarget), there
is a 900ms delay after the response comes back even with no changes.
I changed the Wicket.Focus.attachFocusEvent function to do nothing, and
added these events (can be done before dom load)
Wicket.Event.add(window,'focus',Wicket.Focus.setFocus);
Wicket.Event.add(window,'blur',Wicket.Focus.blur);
So we capture all the focus and blur events inside the window, and call
the existing functions. The window gets the focus event for the element
first before it gets to the element and bubbles back up again. A quick
look at FF and IE show the same Focus/Blue events in the log, and the
delay is gone. The other benefit is you don't have to reattach events
after the ajax response changes the dom :)
Matej Knopp wrote:
> Well, it kinda does. You can submit the links and buttons with
> keyboard - and when you do it does make sense to preserve focus when
> you replace the submitting button or link.
>
> -Matej
>
> On Fri, Apr 17, 2009 at 9:48 AM, Johan Compagner <jc...@gmail.com> wrote:
>
>> Buttons and links dont make much sense yes.
>> Dont remember why we should do this.
>> Will check the code
>>
>> On 16/04/2009, Igor Vaynberg <ig...@gmail.com> wrote:
>>
>>> this code is there so we can track focus and properly restore it after
>>> ajax modifies the dom. i am not sure why we need to track and restore
>>> focus on anchors, it is only important when you are typing so that the
>>> cursor doesnt move elsewhere - so only for textfields and textareas.
>>>
>>> johan, matej says you wanted to track focus for anchors, whats the deal?
>>>
>>> -igor
>>>
>>> 2009/4/16 Peter Gardfjäll <pe...@gmail.com>:
>>>
>>>> Hi James,
>>>>
>>>> I'm pretty sure that links are part of the problem.
>>>> To verify this, try replacing all <a> tags with e.g. <span> and see if
>>>> you can spot any difference in response time.
>>>> Alternatively, try replacing/commenting out ajax components/behaviors
>>>> on your page to prevent wicket-ajax.js from being pulled into the
>>>> page.
>>>>
>>>> cheers, Peter
>>>>
>>>> On Thu, Apr 16, 2009 at 3:52 PM, James Carman
>>>> <jc...@carmanconsulting.com> wrote:
>>>>
>>>>> Peter,
>>>>> I have experienced similar problems just recently. I didn't narrow it
>>>>> down
>>>>> to the fact that the links were the problem, as you have, though! I have
>>>>> been racking my brains trying to figure this thing out. My page is
>>>>> similar,
>>>>> a table with lots of cells in them that are links. I've turned off CSS
>>>>> and
>>>>> other stuff trying to find the bottleneck. I didn't think for a moment
>>>>> that
>>>>> it might be the links.
>>>>>
>>>>> James
>>>>>
>>>>> 2009/4/16 Peter Gardfjäll <pe...@gmail.com>
>>>>>
>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> I am working on a wicket application intended to be executed both on
>>>>>> FF3 and IE7.
>>>>>> While working on this application I have discovered that the rendering
>>>>>> of some pages are a lot slower in IE.
>>>>>> The pages that were significantly slower on IE have a couple of things
>>>>>> in common: they are ajax-enabled and have lots of links.
>>>>>> These pages all appear to freeze for a while after all data has been
>>>>>> transferred, but before the page becomes responsive.
>>>>>>
>>>>>> The reason (or at least one of the reasons) is that wicket-ajax.js,
>>>>>> which gets pulled in whenever an Ajax component/behavior is added to a
>>>>>> page, registers a function
>>>>>> (addDomReadyEvent(Wicket.Focus.attachFocusEvent)) that traverses all
>>>>>> {input,select,a,textarea,button} tags in the DOM tree when the page
>>>>>> has been loaded.
>>>>>>
>>>>>> I timed this function for one of my pages (containing a single big
>>>>>> table with around 300 rows, with each row having about six links).
>>>>>> When the function is registered, the fireDomReadyHandlers in
>>>>>> wicket-event.js takes 2400 ms to execute, compared to 700 ms when not
>>>>>> registered. In firefox, the corresponding numbers are about 470 ms and
>>>>>> 400 ms.
>>>>>>
>>>>>> Hence, there seems to be quite a performance penalty involved in
>>>>>> loading ajax pages with lots of links in IE7.
>>>>>> I'm a bit worried about this overhead, particularly since I have a
>>>>>> rather fast machine (a lot better than most of the end users anyway).
>>>>>> I would not be surprised if clients see double page load times.
>>>>>>
>>>>>> Have anyone on this list experienced similar problems?
>>>>>> Is this a known issue? (I have not been able to find anything similar
>>>>>> on the mailing list)
>>>>>> Any suggestions or pointers are welcome.
>>>>>>
>>>>>> best regards, Peter
>>>>>>
>>>>>> /PS By the way, I am using wicket 1.3.5.
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
>
--
Jason Lea
Re: wicket-ajax and IE performance problems for pages with many links
Posted by Matej Knopp <ma...@gmail.com>.
Well, it kinda does. You can submit the links and buttons with
keyboard - and when you do it does make sense to preserve focus when
you replace the submitting button or link.
-Matej
On Fri, Apr 17, 2009 at 9:48 AM, Johan Compagner <jc...@gmail.com> wrote:
> Buttons and links dont make much sense yes.
> Dont remember why we should do this.
> Will check the code
>
> On 16/04/2009, Igor Vaynberg <ig...@gmail.com> wrote:
>> this code is there so we can track focus and properly restore it after
>> ajax modifies the dom. i am not sure why we need to track and restore
>> focus on anchors, it is only important when you are typing so that the
>> cursor doesnt move elsewhere - so only for textfields and textareas.
>>
>> johan, matej says you wanted to track focus for anchors, whats the deal?
>>
>> -igor
>>
>> 2009/4/16 Peter Gardfjäll <pe...@gmail.com>:
>>> Hi James,
>>>
>>> I'm pretty sure that links are part of the problem.
>>> To verify this, try replacing all <a> tags with e.g. <span> and see if
>>> you can spot any difference in response time.
>>> Alternatively, try replacing/commenting out ajax components/behaviors
>>> on your page to prevent wicket-ajax.js from being pulled into the
>>> page.
>>>
>>> cheers, Peter
>>>
>>> On Thu, Apr 16, 2009 at 3:52 PM, James Carman
>>> <jc...@carmanconsulting.com> wrote:
>>>> Peter,
>>>> I have experienced similar problems just recently. I didn't narrow it
>>>> down
>>>> to the fact that the links were the problem, as you have, though! I have
>>>> been racking my brains trying to figure this thing out. My page is
>>>> similar,
>>>> a table with lots of cells in them that are links. I've turned off CSS
>>>> and
>>>> other stuff trying to find the bottleneck. I didn't think for a moment
>>>> that
>>>> it might be the links.
>>>>
>>>> James
>>>>
>>>> 2009/4/16 Peter Gardfjäll <pe...@gmail.com>
>>>>
>>>>> Hi all,
>>>>>
>>>>> I am working on a wicket application intended to be executed both on
>>>>> FF3 and IE7.
>>>>> While working on this application I have discovered that the rendering
>>>>> of some pages are a lot slower in IE.
>>>>> The pages that were significantly slower on IE have a couple of things
>>>>> in common: they are ajax-enabled and have lots of links.
>>>>> These pages all appear to freeze for a while after all data has been
>>>>> transferred, but before the page becomes responsive.
>>>>>
>>>>> The reason (or at least one of the reasons) is that wicket-ajax.js,
>>>>> which gets pulled in whenever an Ajax component/behavior is added to a
>>>>> page, registers a function
>>>>> (addDomReadyEvent(Wicket.Focus.attachFocusEvent)) that traverses all
>>>>> {input,select,a,textarea,button} tags in the DOM tree when the page
>>>>> has been loaded.
>>>>>
>>>>> I timed this function for one of my pages (containing a single big
>>>>> table with around 300 rows, with each row having about six links).
>>>>> When the function is registered, the fireDomReadyHandlers in
>>>>> wicket-event.js takes 2400 ms to execute, compared to 700 ms when not
>>>>> registered. In firefox, the corresponding numbers are about 470 ms and
>>>>> 400 ms.
>>>>>
>>>>> Hence, there seems to be quite a performance penalty involved in
>>>>> loading ajax pages with lots of links in IE7.
>>>>> I'm a bit worried about this overhead, particularly since I have a
>>>>> rather fast machine (a lot better than most of the end users anyway).
>>>>> I would not be surprised if clients see double page load times.
>>>>>
>>>>> Have anyone on this list experienced similar problems?
>>>>> Is this a known issue? (I have not been able to find anything similar
>>>>> on the mailing list)
>>>>> Any suggestions or pointers are welcome.
>>>>>
>>>>> best regards, Peter
>>>>>
>>>>> /PS By the way, I am using wicket 1.3.5.
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>
>>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: wicket-ajax and IE performance problems for pages with many links
Posted by Johan Compagner <jc...@gmail.com>.
Buttons and links dont make much sense yes.
Dont remember why we should do this.
Will check the code
On 16/04/2009, Igor Vaynberg <ig...@gmail.com> wrote:
> this code is there so we can track focus and properly restore it after
> ajax modifies the dom. i am not sure why we need to track and restore
> focus on anchors, it is only important when you are typing so that the
> cursor doesnt move elsewhere - so only for textfields and textareas.
>
> johan, matej says you wanted to track focus for anchors, whats the deal?
>
> -igor
>
> 2009/4/16 Peter Gardfjäll <pe...@gmail.com>:
>> Hi James,
>>
>> I'm pretty sure that links are part of the problem.
>> To verify this, try replacing all <a> tags with e.g. <span> and see if
>> you can spot any difference in response time.
>> Alternatively, try replacing/commenting out ajax components/behaviors
>> on your page to prevent wicket-ajax.js from being pulled into the
>> page.
>>
>> cheers, Peter
>>
>> On Thu, Apr 16, 2009 at 3:52 PM, James Carman
>> <jc...@carmanconsulting.com> wrote:
>>> Peter,
>>> I have experienced similar problems just recently. I didn't narrow it
>>> down
>>> to the fact that the links were the problem, as you have, though! I have
>>> been racking my brains trying to figure this thing out. My page is
>>> similar,
>>> a table with lots of cells in them that are links. I've turned off CSS
>>> and
>>> other stuff trying to find the bottleneck. I didn't think for a moment
>>> that
>>> it might be the links.
>>>
>>> James
>>>
>>> 2009/4/16 Peter Gardfjäll <pe...@gmail.com>
>>>
>>>> Hi all,
>>>>
>>>> I am working on a wicket application intended to be executed both on
>>>> FF3 and IE7.
>>>> While working on this application I have discovered that the rendering
>>>> of some pages are a lot slower in IE.
>>>> The pages that were significantly slower on IE have a couple of things
>>>> in common: they are ajax-enabled and have lots of links.
>>>> These pages all appear to freeze for a while after all data has been
>>>> transferred, but before the page becomes responsive.
>>>>
>>>> The reason (or at least one of the reasons) is that wicket-ajax.js,
>>>> which gets pulled in whenever an Ajax component/behavior is added to a
>>>> page, registers a function
>>>> (addDomReadyEvent(Wicket.Focus.attachFocusEvent)) that traverses all
>>>> {input,select,a,textarea,button} tags in the DOM tree when the page
>>>> has been loaded.
>>>>
>>>> I timed this function for one of my pages (containing a single big
>>>> table with around 300 rows, with each row having about six links).
>>>> When the function is registered, the fireDomReadyHandlers in
>>>> wicket-event.js takes 2400 ms to execute, compared to 700 ms when not
>>>> registered. In firefox, the corresponding numbers are about 470 ms and
>>>> 400 ms.
>>>>
>>>> Hence, there seems to be quite a performance penalty involved in
>>>> loading ajax pages with lots of links in IE7.
>>>> I'm a bit worried about this overhead, particularly since I have a
>>>> rather fast machine (a lot better than most of the end users anyway).
>>>> I would not be surprised if clients see double page load times.
>>>>
>>>> Have anyone on this list experienced similar problems?
>>>> Is this a known issue? (I have not been able to find anything similar
>>>> on the mailing list)
>>>> Any suggestions or pointers are welcome.
>>>>
>>>> best regards, Peter
>>>>
>>>> /PS By the way, I am using wicket 1.3.5.
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: wicket-ajax and IE performance problems for pages with many links
Posted by James Carman <jc...@carmanconsulting.com>.
2009/4/17 Peter Gardfjäll <pe...@gmail.com>:
> Sure,
> here goes. I have added both the java and the js file to the same Java package:
You da man! Thank you very much! That's a pretty slick trick you did
by extending the ajax behavior superclass so that the ajax javascript
files get included before yours. I'm putting that one in my back
pocket to use later. Very slick, indeed!
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: wicket-ajax and IE performance problems for pages with many
links
Posted by Kuga <kv...@infoblox.com>.
Hi,
I have checked the 1.4-rc2 or 1.3.6, and have not seen this patch. Can
anyone please confirm the exact release in which this issue is fixed.
Thanks
Kuga
--
View this message in context: http://www.nabble.com/wicket-ajax-and-IE-performance-problems-for-pages-with-many-links-tp23078336p23664596.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: wicket-ajax and IE performance problems for pages with many links
Posted by Jason Lea <ja...@kumachan.net.nz>.
I have tracked down the issues in slow IE performance when adding focus
events to 1000's of elements.
I created a simple page with 1000 normal links using a listview, then
measured the performance of the wicket-ajax.js
Wicket.Focus.attachFocusEvent method. It would take about 3000ms on
page load, and around 500ms on each ajax response (tested using a simple
ajax link that does nothing in the onClick() method).
When the focus event is added to an element in IE, wicket-event.js
Wicket.Event.getId will add an id to any element that does not have
one. This takes 2200ms for my test page.
If use setOutputMarkupId(true) on my links, then Wicket.Event.getId
doesn't create one, and the Wicket.Focus.attachFocusEvent time drops to
700ms the ajax response time is unaffected.
NOTE: if you create millions of links, make sure you use
.setOutputMarkupId(true) so this focus code doesn't have to create one
for you.
We can get these numbers down by fixing a function in wicket-ajax.js
Wicket.Focus.setFocusOnElements:
setFocusOnElements: function (elements)
{
// we need to cache array length because IE will try to recalculate
// the collection of elements every time length() is called
which can be quite expensive
// if the collection is a result of getElementsByTagName or a
similar function.
var len=elements.length;
for (var i=0; i< len; i++)
{
if (elements[i].wicketFocusSet != true)
{
Wicket.Event.add(elements[i],'focus',Wicket.Focus.setFocus);
Wicket.Event.add(elements[i],'blur',Wicket.Focus.blur);
elements[i].wicketFocusSet = true;
}
}
},
Fetching the elements.length once will bring the numbers down to 220ms
for page load and 30ms for ajax update.
Igor committed the "var len=elements.length;" change into 1.3.x and
1.4.x already, so that should be all good :)
As a comparision... firefox takes 70ms for Wicket.Focus.attachFocusEvent
on page load and 5ms for ajax response.
-jason lea
James Carman wrote:
> Okay, since this code does show that the problem is with the focus
> stuff and we have conflicting goals here, what are we going to do to
> move forward? Obviously, the IE JS engine is way too darn slow to
> handle this code. Is there some optimization we can do here? Should
> we file a JIRA? Is there one change in particular that made this so
> slow in IE? Do we back that out until a better alternative is known?
> Why am I asking so many questions? :) Sorry, too much coffee this
> morning.
>
> 2009/4/17 Peter Gardfjäll <pe...@gmail.com>:
>
>> Sure,
>> here goes. I have added both the java and the js file to the same Java package:
>>
>> WicketAjaxJsPatch.java
>> ==================
>>
>> /**
>> * {@link IBehavior} that should be added to {@link Page}s that need to prevent
>> * the page load performance penalty incurred when wicket-ajax.js traverses all
>> * <a> tags in the page markup.
>> *
>> * <p/>
>> * For background information, see <a
>> href="http://www.nabble.com/wicket-ajax-and-IE-performance-problems-for-pages-with-many-links-td23078336.html"
>> * >this mailing list thread</a>
>> * <p/>
>> * This behavior simply makes sure that our patch gets applied to wicket-ajax.js
>> * (by forcing wicket-ajax.js to be added to the page head prior to
>> * wicket-ajax-patch.js).
>> *
>> */
>> public class WicketAjaxJsPatch extends AbstractDefaultAjaxBehavior {
>>
>> @Override
>> public void renderHead(IHeaderResponse response) {
>> super.renderHead(response);
>> response.renderJavascriptReference(new ResourceReference(
>> WicketAjaxJsPatch.class, "wicket-ajax-patch.js"));
>> }
>>
>> @Override
>> protected void respond(AjaxRequestTarget target) {
>> // Does nothing. The fact that we are extending
>> // AbstractDefaultAjaxBehavior means that we will pull in
>> // wicket-event.js and wicket-ajax.js. The job of this behavior is to
>> // make sure that our wicket-ajax-patch.js script gets added to the page
>> // head after those scripts.
>> }
>> }
>>
>>
>> wicket-ajax-patch.js
>> ===============
>>
>> /**
>> * Overrides the attachFocusEvent function registered by wicket-ajax.js.
>> * The original version traverses all anchor and button tags on the page
>> * which incurs a major performance penalty on pages with many links.
>> * This version skips these elements in the scanning.
>> */
>> if (typeof(Wicket) != "undefined") {
>> if (typeof(Wicket.Focus) != "undefined") {
>> // Deregister old attachFocusEvent function
>> handlers = Wicket.Event.domReadyHandlers;
>> filteredHandlers = new Array();
>> for(i = 0; i < handlers.length; i++) {
>> if (handlers[i] != Wicket.Focus.attachFocusEvent) {
>> filteredHandlers.push(handlers[i]);
>> }
>> }
>> Wicket.Event.domReadyHandlers = filteredHandlers;
>>
>> // Redefine and re-register attachFocusEvent
>> Wicket.Focus.attachFocusEvent=function() {
>> Wicket.Focus.setFocusOnElements(document.getElementsByTagName("input"));
>> Wicket.Focus.setFocusOnElements(document.getElementsByTagName("select"));
>> Wicket.Focus.setFocusOnElements(document.getElementsByTagName("textarea"));
>> //Wicket.Focus.setFocusOnElements(document.getElementsByTagName("button"));
>> //Wicket.Focus.setFocusOnElements(document.getElementsByTagName("a"));
>> }
>> Wicket.Event.addDomReadyEvent(Wicket.Focus.attachFocusEvent);
>> }
>> }
>>
>>
>> Attaching the behavior
>> =================
>> What I do then is to add the WicketAjaxJsPatch to the page by doing.
>>
>> page.add(new WicketAjaxJsPatch());
>>
>>
>> It seems to be doing its job for me. Please tell me if it doesn't work.
>>
>> cheers, Peter
>>
>>
>> On Fri, Apr 17, 2009 at 12:15 PM, James Carman
>> <jc...@carmanconsulting.com> wrote:
>>
>>> Did that code actually work for you? I tried adding this js, but i
>>> couldn't get it to show up in the correct place. And, when I did, it
>>> didn't seem to improve much. Care to share your code?
>>>
>>> 2009/4/17 Peter Gardfjäll <pe...@gmail.com>:
>>>
>>>> I have written a simple WicketAjaxJsPatch Behavior which simply adds
>>>> the aforementioned javascript to the page.
>>>> In our application, we have several pages that suffer from the same problem.
>>>> It would be tedious to have to update all of these pages one-by-one.
>>>> So is there any way for me to add this Behavior to my parent page
>>>> (which other pages extend) and still have the javascript rendered last
>>>> in the head?
>>>>
>>>> regards, Peter
>>>>
>>>> 2009/4/17 Peter Gardfjäll <pe...@gmail.com>:
>>>>
>>>>> Thanks Igor,
>>>>>
>>>>> the suggested workaround seems to work fine. However, it is not enough
>>>>> to just override the attachFocusEvent function -- you also need to
>>>>> deregister the previously registered function. I did as follows (I
>>>>> apologize for the lack of elegance, I'm not a js expert):
>>>>>
>>>>> if (typeof(Wicket) != "undefined") {
>>>>> if (typeof(Wicket.Focus) != "undefined") {
>>>>> // Deregister old attachFocusEvent function
>>>>> handlers = Wicket.Event.domReadyHandlers;
>>>>> filteredHandlers = new Array();
>>>>> for(i = 0; i < handlers.length; i++) {
>>>>> if (handlers[i] != Wicket.Focus.attachFocusEvent) {
>>>>> filteredHandlers.push(handlers[i]);
>>>>> }
>>>>> }
>>>>> Wicket.Event.domReadyHandlers = filteredHandlers;
>>>>>
>>>>> // Redefine and re-register attachFocusEvent
>>>>> Wicket.Focus.attachFocusEvent=function() {
>>>>> Wicket.Focus.setFocusOnElements(document.getElementsByTagName("input"));
>>>>> Wicket.Focus.setFocusOnElements(document.getElementsByTagName("select"));
>>>>> Wicket.Focus.setFocusOnElements(document.getElementsByTagName("textarea"));
>>>>> //Wicket.Focus.setFocusOnElements(document.getElementsByTagName("button"));
>>>>> //Wicket.Focus.setFocusOnElements(document.getElementsByTagName("a"));
>>>>> }
>>>>> Wicket.Event.addDomReadyEvent(Wicket.Focus.attachFocusEvent);
>>>>> }
>>>>> }
>>>>>
>>>>>
>>>>> By the way, I believe that this is, or has the potential of becoming,
>>>>> a major stumbling block for others.
>>>>> Should it be regarded as a bug?
>>>>>
>>>>> kind regards, Peter
>>>>>
>>>>>
>>>>> On Thu, Apr 16, 2009 at 6:23 PM, Igor Vaynberg <ig...@gmail.com> wrote:
>>>>>
>>>>>> you can try adding this to the head after wicket-ajax.js
>>>>>>
>>>>>> <script>
>>>>>> if (Wicket!="undefined") {
>>>>>> if (Wicket.Focus!="undefined") {
>>>>>> Wicket.Focus.attachFocusEvent=function() {
>>>>>> Wicket.Focus.setFocusOnElements(document.getElementsByTagName("input"));
>>>>>> Wicket.Focus.setFocusOnElements(document.getElementsByTagName("select"));
>>>>>> Wicket.Focus.setFocusOnElements(document.getElementsByTagName("textarea"));
>>>>>> //Wicket.Focus.setFocusOnElements(document.getElementsByTagName("button"));
>>>>>> //Wicket.Focus.setFocusOnElements(document.getElementsByTagName("a"));
>>>>>> }
>>>>>> }
>>>>>> }
>>>>>>
>>>>>>
>>>>>> -igor
>>>>>>
>>>>>> On Thu, Apr 16, 2009 at 9:16 AM, James Carman
>>>>>> <jc...@carmanconsulting.com> wrote:
>>>>>>
>>>>>>> So, we understand what's slowing us down? Any way to turn that stuff
>>>>>>> off on our end to get stuff working? I've got a release going out the
>>>>>>> door that's slow as heck on IE right now.
>>>>>>>
>>>>>>> On Thu, Apr 16, 2009 at 12:03 PM, Igor Vaynberg <ig...@gmail.com> wrote:
>>>>>>>
>>>>>>>> this code is there so we can track focus and properly restore it after
>>>>>>>> ajax modifies the dom. i am not sure why we need to track and restore
>>>>>>>> focus on anchors, it is only important when you are typing so that the
>>>>>>>> cursor doesnt move elsewhere - so only for textfields and textareas.
>>>>>>>>
>>>>>>>> johan, matej says you wanted to track focus for anchors, whats the deal?
>>>>>>>>
>>>>>>>> -igor
>>>>>>>>
>>>>>>>> 2009/4/16 Peter Gardfjäll <pe...@gmail.com>:
>>>>>>>>
>>>>>>>>> Hi James,
>>>>>>>>>
>>>>>>>>> I'm pretty sure that links are part of the problem.
>>>>>>>>> To verify this, try replacing all <a> tags with e.g. <span> and see if
>>>>>>>>> you can spot any difference in response time.
>>>>>>>>> Alternatively, try replacing/commenting out ajax components/behaviors
>>>>>>>>> on your page to prevent wicket-ajax.js from being pulled into the
>>>>>>>>> page.
>>>>>>>>>
>>>>>>>>> cheers, Peter
>>>>>>>>>
>>>>>>>>> On Thu, Apr 16, 2009 at 3:52 PM, James Carman
>>>>>>>>> <jc...@carmanconsulting.com> wrote:
>>>>>>>>>
>>>>>>>>>> Peter,
>>>>>>>>>> I have experienced similar problems just recently. I didn't narrow it down
>>>>>>>>>> to the fact that the links were the problem, as you have, though! I have
>>>>>>>>>> been racking my brains trying to figure this thing out. My page is similar,
>>>>>>>>>> a table with lots of cells in them that are links. I've turned off CSS and
>>>>>>>>>> other stuff trying to find the bottleneck. I didn't think for a moment that
>>>>>>>>>> it might be the links.
>>>>>>>>>>
>>>>>>>>>> James
>>>>>>>>>>
>>>>>>>>>> 2009/4/16 Peter Gardfjäll <pe...@gmail.com>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> Hi all,
>>>>>>>>>>>
>>>>>>>>>>> I am working on a wicket application intended to be executed both on
>>>>>>>>>>> FF3 and IE7.
>>>>>>>>>>> While working on this application I have discovered that the rendering
>>>>>>>>>>> of some pages are a lot slower in IE.
>>>>>>>>>>> The pages that were significantly slower on IE have a couple of things
>>>>>>>>>>> in common: they are ajax-enabled and have lots of links.
>>>>>>>>>>> These pages all appear to freeze for a while after all data has been
>>>>>>>>>>> transferred, but before the page becomes responsive.
>>>>>>>>>>>
>>>>>>>>>>> The reason (or at least one of the reasons) is that wicket-ajax.js,
>>>>>>>>>>> which gets pulled in whenever an Ajax component/behavior is added to a
>>>>>>>>>>> page, registers a function
>>>>>>>>>>> (addDomReadyEvent(Wicket.Focus.attachFocusEvent)) that traverses all
>>>>>>>>>>> {input,select,a,textarea,button} tags in the DOM tree when the page
>>>>>>>>>>> has been loaded.
>>>>>>>>>>>
>>>>>>>>>>> I timed this function for one of my pages (containing a single big
>>>>>>>>>>> table with around 300 rows, with each row having about six links).
>>>>>>>>>>> When the function is registered, the fireDomReadyHandlers in
>>>>>>>>>>> wicket-event.js takes 2400 ms to execute, compared to 700 ms when not
>>>>>>>>>>> registered. In firefox, the corresponding numbers are about 470 ms and
>>>>>>>>>>> 400 ms.
>>>>>>>>>>>
>>>>>>>>>>> Hence, there seems to be quite a performance penalty involved in
>>>>>>>>>>> loading ajax pages with lots of links in IE7.
>>>>>>>>>>> I'm a bit worried about this overhead, particularly since I have a
>>>>>>>>>>> rather fast machine (a lot better than most of the end users anyway).
>>>>>>>>>>> I would not be surprised if clients see double page load times.
>>>>>>>>>>>
>>>>>>>>>>> Have anyone on this list experienced similar problems?
>>>>>>>>>>> Is this a known issue? (I have not been able to find anything similar
>>>>>>>>>>> on the mailing list)
>>>>>>>>>>> Any suggestions or pointers are welcome.
>>>>>>>>>>>
>>>>>>>>>>> best regards, Peter
>>>>>>>>>>>
>>>>>>>>>>> /PS By the way, I am using wicket 1.3.5.
>>>>>>>>>>>
>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
>
Re: wicket-ajax and IE performance problems for pages with many links
Posted by James Carman <jc...@carmanconsulting.com>.
Okay, since this code does show that the problem is with the focus
stuff and we have conflicting goals here, what are we going to do to
move forward? Obviously, the IE JS engine is way too darn slow to
handle this code. Is there some optimization we can do here? Should
we file a JIRA? Is there one change in particular that made this so
slow in IE? Do we back that out until a better alternative is known?
Why am I asking so many questions? :) Sorry, too much coffee this
morning.
2009/4/17 Peter Gardfjäll <pe...@gmail.com>:
> Sure,
> here goes. I have added both the java and the js file to the same Java package:
>
> WicketAjaxJsPatch.java
> ==================
>
> /**
> * {@link IBehavior} that should be added to {@link Page}s that need to prevent
> * the page load performance penalty incurred when wicket-ajax.js traverses all
> * <a> tags in the page markup.
> *
> * <p/>
> * For background information, see <a
> href="http://www.nabble.com/wicket-ajax-and-IE-performance-problems-for-pages-with-many-links-td23078336.html"
> * >this mailing list thread</a>
> * <p/>
> * This behavior simply makes sure that our patch gets applied to wicket-ajax.js
> * (by forcing wicket-ajax.js to be added to the page head prior to
> * wicket-ajax-patch.js).
> *
> */
> public class WicketAjaxJsPatch extends AbstractDefaultAjaxBehavior {
>
> @Override
> public void renderHead(IHeaderResponse response) {
> super.renderHead(response);
> response.renderJavascriptReference(new ResourceReference(
> WicketAjaxJsPatch.class, "wicket-ajax-patch.js"));
> }
>
> @Override
> protected void respond(AjaxRequestTarget target) {
> // Does nothing. The fact that we are extending
> // AbstractDefaultAjaxBehavior means that we will pull in
> // wicket-event.js and wicket-ajax.js. The job of this behavior is to
> // make sure that our wicket-ajax-patch.js script gets added to the page
> // head after those scripts.
> }
> }
>
>
> wicket-ajax-patch.js
> ===============
>
> /**
> * Overrides the attachFocusEvent function registered by wicket-ajax.js.
> * The original version traverses all anchor and button tags on the page
> * which incurs a major performance penalty on pages with many links.
> * This version skips these elements in the scanning.
> */
> if (typeof(Wicket) != "undefined") {
> if (typeof(Wicket.Focus) != "undefined") {
> // Deregister old attachFocusEvent function
> handlers = Wicket.Event.domReadyHandlers;
> filteredHandlers = new Array();
> for(i = 0; i < handlers.length; i++) {
> if (handlers[i] != Wicket.Focus.attachFocusEvent) {
> filteredHandlers.push(handlers[i]);
> }
> }
> Wicket.Event.domReadyHandlers = filteredHandlers;
>
> // Redefine and re-register attachFocusEvent
> Wicket.Focus.attachFocusEvent=function() {
> Wicket.Focus.setFocusOnElements(document.getElementsByTagName("input"));
> Wicket.Focus.setFocusOnElements(document.getElementsByTagName("select"));
> Wicket.Focus.setFocusOnElements(document.getElementsByTagName("textarea"));
> //Wicket.Focus.setFocusOnElements(document.getElementsByTagName("button"));
> //Wicket.Focus.setFocusOnElements(document.getElementsByTagName("a"));
> }
> Wicket.Event.addDomReadyEvent(Wicket.Focus.attachFocusEvent);
> }
> }
>
>
> Attaching the behavior
> =================
> What I do then is to add the WicketAjaxJsPatch to the page by doing.
>
> page.add(new WicketAjaxJsPatch());
>
>
> It seems to be doing its job for me. Please tell me if it doesn't work.
>
> cheers, Peter
>
>
> On Fri, Apr 17, 2009 at 12:15 PM, James Carman
> <jc...@carmanconsulting.com> wrote:
>> Did that code actually work for you? I tried adding this js, but i
>> couldn't get it to show up in the correct place. And, when I did, it
>> didn't seem to improve much. Care to share your code?
>>
>> 2009/4/17 Peter Gardfjäll <pe...@gmail.com>:
>>> I have written a simple WicketAjaxJsPatch Behavior which simply adds
>>> the aforementioned javascript to the page.
>>> In our application, we have several pages that suffer from the same problem.
>>> It would be tedious to have to update all of these pages one-by-one.
>>> So is there any way for me to add this Behavior to my parent page
>>> (which other pages extend) and still have the javascript rendered last
>>> in the head?
>>>
>>> regards, Peter
>>>
>>> 2009/4/17 Peter Gardfjäll <pe...@gmail.com>:
>>>> Thanks Igor,
>>>>
>>>> the suggested workaround seems to work fine. However, it is not enough
>>>> to just override the attachFocusEvent function -- you also need to
>>>> deregister the previously registered function. I did as follows (I
>>>> apologize for the lack of elegance, I'm not a js expert):
>>>>
>>>> if (typeof(Wicket) != "undefined") {
>>>> if (typeof(Wicket.Focus) != "undefined") {
>>>> // Deregister old attachFocusEvent function
>>>> handlers = Wicket.Event.domReadyHandlers;
>>>> filteredHandlers = new Array();
>>>> for(i = 0; i < handlers.length; i++) {
>>>> if (handlers[i] != Wicket.Focus.attachFocusEvent) {
>>>> filteredHandlers.push(handlers[i]);
>>>> }
>>>> }
>>>> Wicket.Event.domReadyHandlers = filteredHandlers;
>>>>
>>>> // Redefine and re-register attachFocusEvent
>>>> Wicket.Focus.attachFocusEvent=function() {
>>>> Wicket.Focus.setFocusOnElements(document.getElementsByTagName("input"));
>>>> Wicket.Focus.setFocusOnElements(document.getElementsByTagName("select"));
>>>> Wicket.Focus.setFocusOnElements(document.getElementsByTagName("textarea"));
>>>> //Wicket.Focus.setFocusOnElements(document.getElementsByTagName("button"));
>>>> //Wicket.Focus.setFocusOnElements(document.getElementsByTagName("a"));
>>>> }
>>>> Wicket.Event.addDomReadyEvent(Wicket.Focus.attachFocusEvent);
>>>> }
>>>> }
>>>>
>>>>
>>>> By the way, I believe that this is, or has the potential of becoming,
>>>> a major stumbling block for others.
>>>> Should it be regarded as a bug?
>>>>
>>>> kind regards, Peter
>>>>
>>>>
>>>> On Thu, Apr 16, 2009 at 6:23 PM, Igor Vaynberg <ig...@gmail.com> wrote:
>>>>> you can try adding this to the head after wicket-ajax.js
>>>>>
>>>>> <script>
>>>>> if (Wicket!="undefined") {
>>>>> if (Wicket.Focus!="undefined") {
>>>>> Wicket.Focus.attachFocusEvent=function() {
>>>>> Wicket.Focus.setFocusOnElements(document.getElementsByTagName("input"));
>>>>> Wicket.Focus.setFocusOnElements(document.getElementsByTagName("select"));
>>>>> Wicket.Focus.setFocusOnElements(document.getElementsByTagName("textarea"));
>>>>> //Wicket.Focus.setFocusOnElements(document.getElementsByTagName("button"));
>>>>> //Wicket.Focus.setFocusOnElements(document.getElementsByTagName("a"));
>>>>> }
>>>>> }
>>>>> }
>>>>>
>>>>>
>>>>> -igor
>>>>>
>>>>> On Thu, Apr 16, 2009 at 9:16 AM, James Carman
>>>>> <jc...@carmanconsulting.com> wrote:
>>>>>> So, we understand what's slowing us down? Any way to turn that stuff
>>>>>> off on our end to get stuff working? I've got a release going out the
>>>>>> door that's slow as heck on IE right now.
>>>>>>
>>>>>> On Thu, Apr 16, 2009 at 12:03 PM, Igor Vaynberg <ig...@gmail.com> wrote:
>>>>>>> this code is there so we can track focus and properly restore it after
>>>>>>> ajax modifies the dom. i am not sure why we need to track and restore
>>>>>>> focus on anchors, it is only important when you are typing so that the
>>>>>>> cursor doesnt move elsewhere - so only for textfields and textareas.
>>>>>>>
>>>>>>> johan, matej says you wanted to track focus for anchors, whats the deal?
>>>>>>>
>>>>>>> -igor
>>>>>>>
>>>>>>> 2009/4/16 Peter Gardfjäll <pe...@gmail.com>:
>>>>>>>> Hi James,
>>>>>>>>
>>>>>>>> I'm pretty sure that links are part of the problem.
>>>>>>>> To verify this, try replacing all <a> tags with e.g. <span> and see if
>>>>>>>> you can spot any difference in response time.
>>>>>>>> Alternatively, try replacing/commenting out ajax components/behaviors
>>>>>>>> on your page to prevent wicket-ajax.js from being pulled into the
>>>>>>>> page.
>>>>>>>>
>>>>>>>> cheers, Peter
>>>>>>>>
>>>>>>>> On Thu, Apr 16, 2009 at 3:52 PM, James Carman
>>>>>>>> <jc...@carmanconsulting.com> wrote:
>>>>>>>>> Peter,
>>>>>>>>> I have experienced similar problems just recently. I didn't narrow it down
>>>>>>>>> to the fact that the links were the problem, as you have, though! I have
>>>>>>>>> been racking my brains trying to figure this thing out. My page is similar,
>>>>>>>>> a table with lots of cells in them that are links. I've turned off CSS and
>>>>>>>>> other stuff trying to find the bottleneck. I didn't think for a moment that
>>>>>>>>> it might be the links.
>>>>>>>>>
>>>>>>>>> James
>>>>>>>>>
>>>>>>>>> 2009/4/16 Peter Gardfjäll <pe...@gmail.com>
>>>>>>>>>
>>>>>>>>>> Hi all,
>>>>>>>>>>
>>>>>>>>>> I am working on a wicket application intended to be executed both on
>>>>>>>>>> FF3 and IE7.
>>>>>>>>>> While working on this application I have discovered that the rendering
>>>>>>>>>> of some pages are a lot slower in IE.
>>>>>>>>>> The pages that were significantly slower on IE have a couple of things
>>>>>>>>>> in common: they are ajax-enabled and have lots of links.
>>>>>>>>>> These pages all appear to freeze for a while after all data has been
>>>>>>>>>> transferred, but before the page becomes responsive.
>>>>>>>>>>
>>>>>>>>>> The reason (or at least one of the reasons) is that wicket-ajax.js,
>>>>>>>>>> which gets pulled in whenever an Ajax component/behavior is added to a
>>>>>>>>>> page, registers a function
>>>>>>>>>> (addDomReadyEvent(Wicket.Focus.attachFocusEvent)) that traverses all
>>>>>>>>>> {input,select,a,textarea,button} tags in the DOM tree when the page
>>>>>>>>>> has been loaded.
>>>>>>>>>>
>>>>>>>>>> I timed this function for one of my pages (containing a single big
>>>>>>>>>> table with around 300 rows, with each row having about six links).
>>>>>>>>>> When the function is registered, the fireDomReadyHandlers in
>>>>>>>>>> wicket-event.js takes 2400 ms to execute, compared to 700 ms when not
>>>>>>>>>> registered. In firefox, the corresponding numbers are about 470 ms and
>>>>>>>>>> 400 ms.
>>>>>>>>>>
>>>>>>>>>> Hence, there seems to be quite a performance penalty involved in
>>>>>>>>>> loading ajax pages with lots of links in IE7.
>>>>>>>>>> I'm a bit worried about this overhead, particularly since I have a
>>>>>>>>>> rather fast machine (a lot better than most of the end users anyway).
>>>>>>>>>> I would not be surprised if clients see double page load times.
>>>>>>>>>>
>>>>>>>>>> Have anyone on this list experienced similar problems?
>>>>>>>>>> Is this a known issue? (I have not been able to find anything similar
>>>>>>>>>> on the mailing list)
>>>>>>>>>> Any suggestions or pointers are welcome.
>>>>>>>>>>
>>>>>>>>>> best regards, Peter
>>>>>>>>>>
>>>>>>>>>> /PS By the way, I am using wicket 1.3.5.
>>>>>>>>>>
>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>
>>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: wicket-ajax and IE performance problems for pages with many links
Posted by James Carman <ja...@carmanconsulting.com>.
I will try it when I get to work. Thanks a bunch!
On Apr 17, 2009 6:37 AM, "Peter Gardfjäll" <pe...@gmail.com>
wrote:
Sure,
here goes. I have added both the java and the js file to the same Java
package:
WicketAjaxJsPatch.java
==================
/**
* {@link IBehavior} that should be added to {@link Page}s that need to
prevent
* the page load performance penalty incurred when wicket-ajax.js traverses
all
* <a> tags in the page markup.
*
* <p/>
* For background information, see <a
href="
http://www.nabble.com/wicket-ajax-and-IE-performance-problems-for-pages-with-many-links-td23078336.html
"
* >this mailing list thread</a>
* <p/>
* This behavior simply makes sure that our patch gets applied to
wicket-ajax.js
* (by forcing wicket-ajax.js to be added to the page head prior to
* wicket-ajax-patch.js).
*
*/
public class WicketAjaxJsPatch extends AbstractDefaultAjaxBehavior {
@Override
public void renderHead(IHeaderResponse response) {
super.renderHead(response);
response.renderJavascriptReference(new ResourceReference(
WicketAjaxJsPatch.class, "wicket-ajax-patch.js"));
}
@Override
protected void respond(AjaxRequestTarget target) {
// Does nothing. The fact that we are extending
// AbstractDefaultAjaxBehavior means that we will pull in
// wicket-event.js and wicket-ajax.js. The job of this behavior is to
// make sure that our wicket-ajax-patch.js script gets added to the
page
// head after those scripts.
}
}
wicket-ajax-patch.js
===============
/**
* Overrides the attachFocusEvent function registered by wicket-ajax.js.
* The original version traverses all anchor and button tags on the page
* which incurs a major performance penalty on pages with many links.
* This version skips these elements in the scanning.
*/
if (typeof(Wicket) != "undefined") { if (typeof(Wicket.Focus) !=
"undefined") { // Deregister ...
Attaching the behavior
=================
What I do then is to add the WicketAjaxJsPatch to the page by doing.
page.add(new WicketAjaxJsPatch());
It seems to be doing its job for me. Please tell me if it doesn't work.
cheers, Peter
On Fri, Apr 17, 2009 at 12:15 PM, James Carman
<jc...@carmanconsulting.com> wrote: > Did that code actually work for you?
I tried adding this js...
Re: wicket-ajax and IE performance problems for pages with many links
Posted by Peter Gardfjäll <pe...@gmail.com>.
Sure,
here goes. I have added both the java and the js file to the same Java package:
WicketAjaxJsPatch.java
==================
/**
* {@link IBehavior} that should be added to {@link Page}s that need to prevent
* the page load performance penalty incurred when wicket-ajax.js traverses all
* <a> tags in the page markup.
*
* <p/>
* For background information, see <a
href="http://www.nabble.com/wicket-ajax-and-IE-performance-problems-for-pages-with-many-links-td23078336.html"
* >this mailing list thread</a>
* <p/>
* This behavior simply makes sure that our patch gets applied to wicket-ajax.js
* (by forcing wicket-ajax.js to be added to the page head prior to
* wicket-ajax-patch.js).
*
*/
public class WicketAjaxJsPatch extends AbstractDefaultAjaxBehavior {
@Override
public void renderHead(IHeaderResponse response) {
super.renderHead(response);
response.renderJavascriptReference(new ResourceReference(
WicketAjaxJsPatch.class, "wicket-ajax-patch.js"));
}
@Override
protected void respond(AjaxRequestTarget target) {
// Does nothing. The fact that we are extending
// AbstractDefaultAjaxBehavior means that we will pull in
// wicket-event.js and wicket-ajax.js. The job of this behavior is to
// make sure that our wicket-ajax-patch.js script gets added to the page
// head after those scripts.
}
}
wicket-ajax-patch.js
===============
/**
* Overrides the attachFocusEvent function registered by wicket-ajax.js.
* The original version traverses all anchor and button tags on the page
* which incurs a major performance penalty on pages with many links.
* This version skips these elements in the scanning.
*/
if (typeof(Wicket) != "undefined") {
if (typeof(Wicket.Focus) != "undefined") {
// Deregister old attachFocusEvent function
handlers = Wicket.Event.domReadyHandlers;
filteredHandlers = new Array();
for(i = 0; i < handlers.length; i++) {
if (handlers[i] != Wicket.Focus.attachFocusEvent) {
filteredHandlers.push(handlers[i]);
}
}
Wicket.Event.domReadyHandlers = filteredHandlers;
// Redefine and re-register attachFocusEvent
Wicket.Focus.attachFocusEvent=function() {
Wicket.Focus.setFocusOnElements(document.getElementsByTagName("input"));
Wicket.Focus.setFocusOnElements(document.getElementsByTagName("select"));
Wicket.Focus.setFocusOnElements(document.getElementsByTagName("textarea"));
//Wicket.Focus.setFocusOnElements(document.getElementsByTagName("button"));
//Wicket.Focus.setFocusOnElements(document.getElementsByTagName("a"));
}
Wicket.Event.addDomReadyEvent(Wicket.Focus.attachFocusEvent);
}
}
Attaching the behavior
=================
What I do then is to add the WicketAjaxJsPatch to the page by doing.
page.add(new WicketAjaxJsPatch());
It seems to be doing its job for me. Please tell me if it doesn't work.
cheers, Peter
On Fri, Apr 17, 2009 at 12:15 PM, James Carman
<jc...@carmanconsulting.com> wrote:
> Did that code actually work for you? I tried adding this js, but i
> couldn't get it to show up in the correct place. And, when I did, it
> didn't seem to improve much. Care to share your code?
>
> 2009/4/17 Peter Gardfjäll <pe...@gmail.com>:
>> I have written a simple WicketAjaxJsPatch Behavior which simply adds
>> the aforementioned javascript to the page.
>> In our application, we have several pages that suffer from the same problem.
>> It would be tedious to have to update all of these pages one-by-one.
>> So is there any way for me to add this Behavior to my parent page
>> (which other pages extend) and still have the javascript rendered last
>> in the head?
>>
>> regards, Peter
>>
>> 2009/4/17 Peter Gardfjäll <pe...@gmail.com>:
>>> Thanks Igor,
>>>
>>> the suggested workaround seems to work fine. However, it is not enough
>>> to just override the attachFocusEvent function -- you also need to
>>> deregister the previously registered function. I did as follows (I
>>> apologize for the lack of elegance, I'm not a js expert):
>>>
>>> if (typeof(Wicket) != "undefined") {
>>> if (typeof(Wicket.Focus) != "undefined") {
>>> // Deregister old attachFocusEvent function
>>> handlers = Wicket.Event.domReadyHandlers;
>>> filteredHandlers = new Array();
>>> for(i = 0; i < handlers.length; i++) {
>>> if (handlers[i] != Wicket.Focus.attachFocusEvent) {
>>> filteredHandlers.push(handlers[i]);
>>> }
>>> }
>>> Wicket.Event.domReadyHandlers = filteredHandlers;
>>>
>>> // Redefine and re-register attachFocusEvent
>>> Wicket.Focus.attachFocusEvent=function() {
>>> Wicket.Focus.setFocusOnElements(document.getElementsByTagName("input"));
>>> Wicket.Focus.setFocusOnElements(document.getElementsByTagName("select"));
>>> Wicket.Focus.setFocusOnElements(document.getElementsByTagName("textarea"));
>>> //Wicket.Focus.setFocusOnElements(document.getElementsByTagName("button"));
>>> //Wicket.Focus.setFocusOnElements(document.getElementsByTagName("a"));
>>> }
>>> Wicket.Event.addDomReadyEvent(Wicket.Focus.attachFocusEvent);
>>> }
>>> }
>>>
>>>
>>> By the way, I believe that this is, or has the potential of becoming,
>>> a major stumbling block for others.
>>> Should it be regarded as a bug?
>>>
>>> kind regards, Peter
>>>
>>>
>>> On Thu, Apr 16, 2009 at 6:23 PM, Igor Vaynberg <ig...@gmail.com> wrote:
>>>> you can try adding this to the head after wicket-ajax.js
>>>>
>>>> <script>
>>>> if (Wicket!="undefined") {
>>>> if (Wicket.Focus!="undefined") {
>>>> Wicket.Focus.attachFocusEvent=function() {
>>>> Wicket.Focus.setFocusOnElements(document.getElementsByTagName("input"));
>>>> Wicket.Focus.setFocusOnElements(document.getElementsByTagName("select"));
>>>> Wicket.Focus.setFocusOnElements(document.getElementsByTagName("textarea"));
>>>> //Wicket.Focus.setFocusOnElements(document.getElementsByTagName("button"));
>>>> //Wicket.Focus.setFocusOnElements(document.getElementsByTagName("a"));
>>>> }
>>>> }
>>>> }
>>>>
>>>>
>>>> -igor
>>>>
>>>> On Thu, Apr 16, 2009 at 9:16 AM, James Carman
>>>> <jc...@carmanconsulting.com> wrote:
>>>>> So, we understand what's slowing us down? Any way to turn that stuff
>>>>> off on our end to get stuff working? I've got a release going out the
>>>>> door that's slow as heck on IE right now.
>>>>>
>>>>> On Thu, Apr 16, 2009 at 12:03 PM, Igor Vaynberg <ig...@gmail.com> wrote:
>>>>>> this code is there so we can track focus and properly restore it after
>>>>>> ajax modifies the dom. i am not sure why we need to track and restore
>>>>>> focus on anchors, it is only important when you are typing so that the
>>>>>> cursor doesnt move elsewhere - so only for textfields and textareas.
>>>>>>
>>>>>> johan, matej says you wanted to track focus for anchors, whats the deal?
>>>>>>
>>>>>> -igor
>>>>>>
>>>>>> 2009/4/16 Peter Gardfjäll <pe...@gmail.com>:
>>>>>>> Hi James,
>>>>>>>
>>>>>>> I'm pretty sure that links are part of the problem.
>>>>>>> To verify this, try replacing all <a> tags with e.g. <span> and see if
>>>>>>> you can spot any difference in response time.
>>>>>>> Alternatively, try replacing/commenting out ajax components/behaviors
>>>>>>> on your page to prevent wicket-ajax.js from being pulled into the
>>>>>>> page.
>>>>>>>
>>>>>>> cheers, Peter
>>>>>>>
>>>>>>> On Thu, Apr 16, 2009 at 3:52 PM, James Carman
>>>>>>> <jc...@carmanconsulting.com> wrote:
>>>>>>>> Peter,
>>>>>>>> I have experienced similar problems just recently. I didn't narrow it down
>>>>>>>> to the fact that the links were the problem, as you have, though! I have
>>>>>>>> been racking my brains trying to figure this thing out. My page is similar,
>>>>>>>> a table with lots of cells in them that are links. I've turned off CSS and
>>>>>>>> other stuff trying to find the bottleneck. I didn't think for a moment that
>>>>>>>> it might be the links.
>>>>>>>>
>>>>>>>> James
>>>>>>>>
>>>>>>>> 2009/4/16 Peter Gardfjäll <pe...@gmail.com>
>>>>>>>>
>>>>>>>>> Hi all,
>>>>>>>>>
>>>>>>>>> I am working on a wicket application intended to be executed both on
>>>>>>>>> FF3 and IE7.
>>>>>>>>> While working on this application I have discovered that the rendering
>>>>>>>>> of some pages are a lot slower in IE.
>>>>>>>>> The pages that were significantly slower on IE have a couple of things
>>>>>>>>> in common: they are ajax-enabled and have lots of links.
>>>>>>>>> These pages all appear to freeze for a while after all data has been
>>>>>>>>> transferred, but before the page becomes responsive.
>>>>>>>>>
>>>>>>>>> The reason (or at least one of the reasons) is that wicket-ajax.js,
>>>>>>>>> which gets pulled in whenever an Ajax component/behavior is added to a
>>>>>>>>> page, registers a function
>>>>>>>>> (addDomReadyEvent(Wicket.Focus.attachFocusEvent)) that traverses all
>>>>>>>>> {input,select,a,textarea,button} tags in the DOM tree when the page
>>>>>>>>> has been loaded.
>>>>>>>>>
>>>>>>>>> I timed this function for one of my pages (containing a single big
>>>>>>>>> table with around 300 rows, with each row having about six links).
>>>>>>>>> When the function is registered, the fireDomReadyHandlers in
>>>>>>>>> wicket-event.js takes 2400 ms to execute, compared to 700 ms when not
>>>>>>>>> registered. In firefox, the corresponding numbers are about 470 ms and
>>>>>>>>> 400 ms.
>>>>>>>>>
>>>>>>>>> Hence, there seems to be quite a performance penalty involved in
>>>>>>>>> loading ajax pages with lots of links in IE7.
>>>>>>>>> I'm a bit worried about this overhead, particularly since I have a
>>>>>>>>> rather fast machine (a lot better than most of the end users anyway).
>>>>>>>>> I would not be surprised if clients see double page load times.
>>>>>>>>>
>>>>>>>>> Have anyone on this list experienced similar problems?
>>>>>>>>> Is this a known issue? (I have not been able to find anything similar
>>>>>>>>> on the mailing list)
>>>>>>>>> Any suggestions or pointers are welcome.
>>>>>>>>>
>>>>>>>>> best regards, Peter
>>>>>>>>>
>>>>>>>>> /PS By the way, I am using wicket 1.3.5.
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: wicket-ajax and IE performance problems for pages with many links
Posted by James Carman <jc...@carmanconsulting.com>.
Did that code actually work for you? I tried adding this js, but i
couldn't get it to show up in the correct place. And, when I did, it
didn't seem to improve much. Care to share your code?
2009/4/17 Peter Gardfjäll <pe...@gmail.com>:
> I have written a simple WicketAjaxJsPatch Behavior which simply adds
> the aforementioned javascript to the page.
> In our application, we have several pages that suffer from the same problem.
> It would be tedious to have to update all of these pages one-by-one.
> So is there any way for me to add this Behavior to my parent page
> (which other pages extend) and still have the javascript rendered last
> in the head?
>
> regards, Peter
>
> 2009/4/17 Peter Gardfjäll <pe...@gmail.com>:
>> Thanks Igor,
>>
>> the suggested workaround seems to work fine. However, it is not enough
>> to just override the attachFocusEvent function -- you also need to
>> deregister the previously registered function. I did as follows (I
>> apologize for the lack of elegance, I'm not a js expert):
>>
>> if (typeof(Wicket) != "undefined") {
>> if (typeof(Wicket.Focus) != "undefined") {
>> // Deregister old attachFocusEvent function
>> handlers = Wicket.Event.domReadyHandlers;
>> filteredHandlers = new Array();
>> for(i = 0; i < handlers.length; i++) {
>> if (handlers[i] != Wicket.Focus.attachFocusEvent) {
>> filteredHandlers.push(handlers[i]);
>> }
>> }
>> Wicket.Event.domReadyHandlers = filteredHandlers;
>>
>> // Redefine and re-register attachFocusEvent
>> Wicket.Focus.attachFocusEvent=function() {
>> Wicket.Focus.setFocusOnElements(document.getElementsByTagName("input"));
>> Wicket.Focus.setFocusOnElements(document.getElementsByTagName("select"));
>> Wicket.Focus.setFocusOnElements(document.getElementsByTagName("textarea"));
>> //Wicket.Focus.setFocusOnElements(document.getElementsByTagName("button"));
>> //Wicket.Focus.setFocusOnElements(document.getElementsByTagName("a"));
>> }
>> Wicket.Event.addDomReadyEvent(Wicket.Focus.attachFocusEvent);
>> }
>> }
>>
>>
>> By the way, I believe that this is, or has the potential of becoming,
>> a major stumbling block for others.
>> Should it be regarded as a bug?
>>
>> kind regards, Peter
>>
>>
>> On Thu, Apr 16, 2009 at 6:23 PM, Igor Vaynberg <ig...@gmail.com> wrote:
>>> you can try adding this to the head after wicket-ajax.js
>>>
>>> <script>
>>> if (Wicket!="undefined") {
>>> if (Wicket.Focus!="undefined") {
>>> Wicket.Focus.attachFocusEvent=function() {
>>> Wicket.Focus.setFocusOnElements(document.getElementsByTagName("input"));
>>> Wicket.Focus.setFocusOnElements(document.getElementsByTagName("select"));
>>> Wicket.Focus.setFocusOnElements(document.getElementsByTagName("textarea"));
>>> //Wicket.Focus.setFocusOnElements(document.getElementsByTagName("button"));
>>> //Wicket.Focus.setFocusOnElements(document.getElementsByTagName("a"));
>>> }
>>> }
>>> }
>>>
>>>
>>> -igor
>>>
>>> On Thu, Apr 16, 2009 at 9:16 AM, James Carman
>>> <jc...@carmanconsulting.com> wrote:
>>>> So, we understand what's slowing us down? Any way to turn that stuff
>>>> off on our end to get stuff working? I've got a release going out the
>>>> door that's slow as heck on IE right now.
>>>>
>>>> On Thu, Apr 16, 2009 at 12:03 PM, Igor Vaynberg <ig...@gmail.com> wrote:
>>>>> this code is there so we can track focus and properly restore it after
>>>>> ajax modifies the dom. i am not sure why we need to track and restore
>>>>> focus on anchors, it is only important when you are typing so that the
>>>>> cursor doesnt move elsewhere - so only for textfields and textareas.
>>>>>
>>>>> johan, matej says you wanted to track focus for anchors, whats the deal?
>>>>>
>>>>> -igor
>>>>>
>>>>> 2009/4/16 Peter Gardfjäll <pe...@gmail.com>:
>>>>>> Hi James,
>>>>>>
>>>>>> I'm pretty sure that links are part of the problem.
>>>>>> To verify this, try replacing all <a> tags with e.g. <span> and see if
>>>>>> you can spot any difference in response time.
>>>>>> Alternatively, try replacing/commenting out ajax components/behaviors
>>>>>> on your page to prevent wicket-ajax.js from being pulled into the
>>>>>> page.
>>>>>>
>>>>>> cheers, Peter
>>>>>>
>>>>>> On Thu, Apr 16, 2009 at 3:52 PM, James Carman
>>>>>> <jc...@carmanconsulting.com> wrote:
>>>>>>> Peter,
>>>>>>> I have experienced similar problems just recently. I didn't narrow it down
>>>>>>> to the fact that the links were the problem, as you have, though! I have
>>>>>>> been racking my brains trying to figure this thing out. My page is similar,
>>>>>>> a table with lots of cells in them that are links. I've turned off CSS and
>>>>>>> other stuff trying to find the bottleneck. I didn't think for a moment that
>>>>>>> it might be the links.
>>>>>>>
>>>>>>> James
>>>>>>>
>>>>>>> 2009/4/16 Peter Gardfjäll <pe...@gmail.com>
>>>>>>>
>>>>>>>> Hi all,
>>>>>>>>
>>>>>>>> I am working on a wicket application intended to be executed both on
>>>>>>>> FF3 and IE7.
>>>>>>>> While working on this application I have discovered that the rendering
>>>>>>>> of some pages are a lot slower in IE.
>>>>>>>> The pages that were significantly slower on IE have a couple of things
>>>>>>>> in common: they are ajax-enabled and have lots of links.
>>>>>>>> These pages all appear to freeze for a while after all data has been
>>>>>>>> transferred, but before the page becomes responsive.
>>>>>>>>
>>>>>>>> The reason (or at least one of the reasons) is that wicket-ajax.js,
>>>>>>>> which gets pulled in whenever an Ajax component/behavior is added to a
>>>>>>>> page, registers a function
>>>>>>>> (addDomReadyEvent(Wicket.Focus.attachFocusEvent)) that traverses all
>>>>>>>> {input,select,a,textarea,button} tags in the DOM tree when the page
>>>>>>>> has been loaded.
>>>>>>>>
>>>>>>>> I timed this function for one of my pages (containing a single big
>>>>>>>> table with around 300 rows, with each row having about six links).
>>>>>>>> When the function is registered, the fireDomReadyHandlers in
>>>>>>>> wicket-event.js takes 2400 ms to execute, compared to 700 ms when not
>>>>>>>> registered. In firefox, the corresponding numbers are about 470 ms and
>>>>>>>> 400 ms.
>>>>>>>>
>>>>>>>> Hence, there seems to be quite a performance penalty involved in
>>>>>>>> loading ajax pages with lots of links in IE7.
>>>>>>>> I'm a bit worried about this overhead, particularly since I have a
>>>>>>>> rather fast machine (a lot better than most of the end users anyway).
>>>>>>>> I would not be surprised if clients see double page load times.
>>>>>>>>
>>>>>>>> Have anyone on this list experienced similar problems?
>>>>>>>> Is this a known issue? (I have not been able to find anything similar
>>>>>>>> on the mailing list)
>>>>>>>> Any suggestions or pointers are welcome.
>>>>>>>>
>>>>>>>> best regards, Peter
>>>>>>>>
>>>>>>>> /PS By the way, I am using wicket 1.3.5.
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: wicket-ajax and IE performance problems for pages with many links
Posted by Peter Gardfjäll <pe...@gmail.com>.
I have written a simple WicketAjaxJsPatch Behavior which simply adds
the aforementioned javascript to the page.
In our application, we have several pages that suffer from the same problem.
It would be tedious to have to update all of these pages one-by-one.
So is there any way for me to add this Behavior to my parent page
(which other pages extend) and still have the javascript rendered last
in the head?
regards, Peter
2009/4/17 Peter Gardfjäll <pe...@gmail.com>:
> Thanks Igor,
>
> the suggested workaround seems to work fine. However, it is not enough
> to just override the attachFocusEvent function -- you also need to
> deregister the previously registered function. I did as follows (I
> apologize for the lack of elegance, I'm not a js expert):
>
> if (typeof(Wicket) != "undefined") {
> if (typeof(Wicket.Focus) != "undefined") {
> // Deregister old attachFocusEvent function
> handlers = Wicket.Event.domReadyHandlers;
> filteredHandlers = new Array();
> for(i = 0; i < handlers.length; i++) {
> if (handlers[i] != Wicket.Focus.attachFocusEvent) {
> filteredHandlers.push(handlers[i]);
> }
> }
> Wicket.Event.domReadyHandlers = filteredHandlers;
>
> // Redefine and re-register attachFocusEvent
> Wicket.Focus.attachFocusEvent=function() {
> Wicket.Focus.setFocusOnElements(document.getElementsByTagName("input"));
> Wicket.Focus.setFocusOnElements(document.getElementsByTagName("select"));
> Wicket.Focus.setFocusOnElements(document.getElementsByTagName("textarea"));
> //Wicket.Focus.setFocusOnElements(document.getElementsByTagName("button"));
> //Wicket.Focus.setFocusOnElements(document.getElementsByTagName("a"));
> }
> Wicket.Event.addDomReadyEvent(Wicket.Focus.attachFocusEvent);
> }
> }
>
>
> By the way, I believe that this is, or has the potential of becoming,
> a major stumbling block for others.
> Should it be regarded as a bug?
>
> kind regards, Peter
>
>
> On Thu, Apr 16, 2009 at 6:23 PM, Igor Vaynberg <ig...@gmail.com> wrote:
>> you can try adding this to the head after wicket-ajax.js
>>
>> <script>
>> if (Wicket!="undefined") {
>> if (Wicket.Focus!="undefined") {
>> Wicket.Focus.attachFocusEvent=function() {
>> Wicket.Focus.setFocusOnElements(document.getElementsByTagName("input"));
>> Wicket.Focus.setFocusOnElements(document.getElementsByTagName("select"));
>> Wicket.Focus.setFocusOnElements(document.getElementsByTagName("textarea"));
>> //Wicket.Focus.setFocusOnElements(document.getElementsByTagName("button"));
>> //Wicket.Focus.setFocusOnElements(document.getElementsByTagName("a"));
>> }
>> }
>> }
>>
>>
>> -igor
>>
>> On Thu, Apr 16, 2009 at 9:16 AM, James Carman
>> <jc...@carmanconsulting.com> wrote:
>>> So, we understand what's slowing us down? Any way to turn that stuff
>>> off on our end to get stuff working? I've got a release going out the
>>> door that's slow as heck on IE right now.
>>>
>>> On Thu, Apr 16, 2009 at 12:03 PM, Igor Vaynberg <ig...@gmail.com> wrote:
>>>> this code is there so we can track focus and properly restore it after
>>>> ajax modifies the dom. i am not sure why we need to track and restore
>>>> focus on anchors, it is only important when you are typing so that the
>>>> cursor doesnt move elsewhere - so only for textfields and textareas.
>>>>
>>>> johan, matej says you wanted to track focus for anchors, whats the deal?
>>>>
>>>> -igor
>>>>
>>>> 2009/4/16 Peter Gardfjäll <pe...@gmail.com>:
>>>>> Hi James,
>>>>>
>>>>> I'm pretty sure that links are part of the problem.
>>>>> To verify this, try replacing all <a> tags with e.g. <span> and see if
>>>>> you can spot any difference in response time.
>>>>> Alternatively, try replacing/commenting out ajax components/behaviors
>>>>> on your page to prevent wicket-ajax.js from being pulled into the
>>>>> page.
>>>>>
>>>>> cheers, Peter
>>>>>
>>>>> On Thu, Apr 16, 2009 at 3:52 PM, James Carman
>>>>> <jc...@carmanconsulting.com> wrote:
>>>>>> Peter,
>>>>>> I have experienced similar problems just recently. I didn't narrow it down
>>>>>> to the fact that the links were the problem, as you have, though! I have
>>>>>> been racking my brains trying to figure this thing out. My page is similar,
>>>>>> a table with lots of cells in them that are links. I've turned off CSS and
>>>>>> other stuff trying to find the bottleneck. I didn't think for a moment that
>>>>>> it might be the links.
>>>>>>
>>>>>> James
>>>>>>
>>>>>> 2009/4/16 Peter Gardfjäll <pe...@gmail.com>
>>>>>>
>>>>>>> Hi all,
>>>>>>>
>>>>>>> I am working on a wicket application intended to be executed both on
>>>>>>> FF3 and IE7.
>>>>>>> While working on this application I have discovered that the rendering
>>>>>>> of some pages are a lot slower in IE.
>>>>>>> The pages that were significantly slower on IE have a couple of things
>>>>>>> in common: they are ajax-enabled and have lots of links.
>>>>>>> These pages all appear to freeze for a while after all data has been
>>>>>>> transferred, but before the page becomes responsive.
>>>>>>>
>>>>>>> The reason (or at least one of the reasons) is that wicket-ajax.js,
>>>>>>> which gets pulled in whenever an Ajax component/behavior is added to a
>>>>>>> page, registers a function
>>>>>>> (addDomReadyEvent(Wicket.Focus.attachFocusEvent)) that traverses all
>>>>>>> {input,select,a,textarea,button} tags in the DOM tree when the page
>>>>>>> has been loaded.
>>>>>>>
>>>>>>> I timed this function for one of my pages (containing a single big
>>>>>>> table with around 300 rows, with each row having about six links).
>>>>>>> When the function is registered, the fireDomReadyHandlers in
>>>>>>> wicket-event.js takes 2400 ms to execute, compared to 700 ms when not
>>>>>>> registered. In firefox, the corresponding numbers are about 470 ms and
>>>>>>> 400 ms.
>>>>>>>
>>>>>>> Hence, there seems to be quite a performance penalty involved in
>>>>>>> loading ajax pages with lots of links in IE7.
>>>>>>> I'm a bit worried about this overhead, particularly since I have a
>>>>>>> rather fast machine (a lot better than most of the end users anyway).
>>>>>>> I would not be surprised if clients see double page load times.
>>>>>>>
>>>>>>> Have anyone on this list experienced similar problems?
>>>>>>> Is this a known issue? (I have not been able to find anything similar
>>>>>>> on the mailing list)
>>>>>>> Any suggestions or pointers are welcome.
>>>>>>>
>>>>>>> best regards, Peter
>>>>>>>
>>>>>>> /PS By the way, I am using wicket 1.3.5.
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: wicket-ajax and IE performance problems for pages with many links
Posted by Peter Gardfjäll <pe...@gmail.com>.
Thanks Igor,
the suggested workaround seems to work fine. However, it is not enough
to just override the attachFocusEvent function -- you also need to
deregister the previously registered function. I did as follows (I
apologize for the lack of elegance, I'm not a js expert):
if (typeof(Wicket) != "undefined") {
if (typeof(Wicket.Focus) != "undefined") {
// Deregister old attachFocusEvent function
handlers = Wicket.Event.domReadyHandlers;
filteredHandlers = new Array();
for(i = 0; i < handlers.length; i++) {
if (handlers[i] != Wicket.Focus.attachFocusEvent) {
filteredHandlers.push(handlers[i]);
}
}
Wicket.Event.domReadyHandlers = filteredHandlers;
// Redefine and re-register attachFocusEvent
Wicket.Focus.attachFocusEvent=function() {
Wicket.Focus.setFocusOnElements(document.getElementsByTagName("input"));
Wicket.Focus.setFocusOnElements(document.getElementsByTagName("select"));
Wicket.Focus.setFocusOnElements(document.getElementsByTagName("textarea"));
//Wicket.Focus.setFocusOnElements(document.getElementsByTagName("button"));
//Wicket.Focus.setFocusOnElements(document.getElementsByTagName("a"));
}
Wicket.Event.addDomReadyEvent(Wicket.Focus.attachFocusEvent);
}
}
By the way, I believe that this is, or has the potential of becoming,
a major stumbling block for others.
Should it be regarded as a bug?
kind regards, Peter
On Thu, Apr 16, 2009 at 6:23 PM, Igor Vaynberg <ig...@gmail.com> wrote:
> you can try adding this to the head after wicket-ajax.js
>
> <script>
> if (Wicket!="undefined") {
> if (Wicket.Focus!="undefined") {
> Wicket.Focus.attachFocusEvent=function() {
> Wicket.Focus.setFocusOnElements(document.getElementsByTagName("input"));
> Wicket.Focus.setFocusOnElements(document.getElementsByTagName("select"));
> Wicket.Focus.setFocusOnElements(document.getElementsByTagName("textarea"));
> //Wicket.Focus.setFocusOnElements(document.getElementsByTagName("button"));
> //Wicket.Focus.setFocusOnElements(document.getElementsByTagName("a"));
> }
> }
> }
>
>
> -igor
>
> On Thu, Apr 16, 2009 at 9:16 AM, James Carman
> <jc...@carmanconsulting.com> wrote:
>> So, we understand what's slowing us down? Any way to turn that stuff
>> off on our end to get stuff working? I've got a release going out the
>> door that's slow as heck on IE right now.
>>
>> On Thu, Apr 16, 2009 at 12:03 PM, Igor Vaynberg <ig...@gmail.com> wrote:
>>> this code is there so we can track focus and properly restore it after
>>> ajax modifies the dom. i am not sure why we need to track and restore
>>> focus on anchors, it is only important when you are typing so that the
>>> cursor doesnt move elsewhere - so only for textfields and textareas.
>>>
>>> johan, matej says you wanted to track focus for anchors, whats the deal?
>>>
>>> -igor
>>>
>>> 2009/4/16 Peter Gardfjäll <pe...@gmail.com>:
>>>> Hi James,
>>>>
>>>> I'm pretty sure that links are part of the problem.
>>>> To verify this, try replacing all <a> tags with e.g. <span> and see if
>>>> you can spot any difference in response time.
>>>> Alternatively, try replacing/commenting out ajax components/behaviors
>>>> on your page to prevent wicket-ajax.js from being pulled into the
>>>> page.
>>>>
>>>> cheers, Peter
>>>>
>>>> On Thu, Apr 16, 2009 at 3:52 PM, James Carman
>>>> <jc...@carmanconsulting.com> wrote:
>>>>> Peter,
>>>>> I have experienced similar problems just recently. I didn't narrow it down
>>>>> to the fact that the links were the problem, as you have, though! I have
>>>>> been racking my brains trying to figure this thing out. My page is similar,
>>>>> a table with lots of cells in them that are links. I've turned off CSS and
>>>>> other stuff trying to find the bottleneck. I didn't think for a moment that
>>>>> it might be the links.
>>>>>
>>>>> James
>>>>>
>>>>> 2009/4/16 Peter Gardfjäll <pe...@gmail.com>
>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> I am working on a wicket application intended to be executed both on
>>>>>> FF3 and IE7.
>>>>>> While working on this application I have discovered that the rendering
>>>>>> of some pages are a lot slower in IE.
>>>>>> The pages that were significantly slower on IE have a couple of things
>>>>>> in common: they are ajax-enabled and have lots of links.
>>>>>> These pages all appear to freeze for a while after all data has been
>>>>>> transferred, but before the page becomes responsive.
>>>>>>
>>>>>> The reason (or at least one of the reasons) is that wicket-ajax.js,
>>>>>> which gets pulled in whenever an Ajax component/behavior is added to a
>>>>>> page, registers a function
>>>>>> (addDomReadyEvent(Wicket.Focus.attachFocusEvent)) that traverses all
>>>>>> {input,select,a,textarea,button} tags in the DOM tree when the page
>>>>>> has been loaded.
>>>>>>
>>>>>> I timed this function for one of my pages (containing a single big
>>>>>> table with around 300 rows, with each row having about six links).
>>>>>> When the function is registered, the fireDomReadyHandlers in
>>>>>> wicket-event.js takes 2400 ms to execute, compared to 700 ms when not
>>>>>> registered. In firefox, the corresponding numbers are about 470 ms and
>>>>>> 400 ms.
>>>>>>
>>>>>> Hence, there seems to be quite a performance penalty involved in
>>>>>> loading ajax pages with lots of links in IE7.
>>>>>> I'm a bit worried about this overhead, particularly since I have a
>>>>>> rather fast machine (a lot better than most of the end users anyway).
>>>>>> I would not be surprised if clients see double page load times.
>>>>>>
>>>>>> Have anyone on this list experienced similar problems?
>>>>>> Is this a known issue? (I have not been able to find anything similar
>>>>>> on the mailing list)
>>>>>> Any suggestions or pointers are welcome.
>>>>>>
>>>>>> best regards, Peter
>>>>>>
>>>>>> /PS By the way, I am using wicket 1.3.5.
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: wicket-ajax and IE performance problems for pages with many links
Posted by Igor Vaynberg <ig...@gmail.com>.
you can try adding this to the head after wicket-ajax.js
<script>
if (Wicket!="undefined") {
if (Wicket.Focus!="undefined") {
Wicket.Focus.attachFocusEvent=function() {
Wicket.Focus.setFocusOnElements(document.getElementsByTagName("input"));
Wicket.Focus.setFocusOnElements(document.getElementsByTagName("select"));
Wicket.Focus.setFocusOnElements(document.getElementsByTagName("textarea"));
//Wicket.Focus.setFocusOnElements(document.getElementsByTagName("button"));
//Wicket.Focus.setFocusOnElements(document.getElementsByTagName("a"));
}
}
}
-igor
On Thu, Apr 16, 2009 at 9:16 AM, James Carman
<jc...@carmanconsulting.com> wrote:
> So, we understand what's slowing us down? Any way to turn that stuff
> off on our end to get stuff working? I've got a release going out the
> door that's slow as heck on IE right now.
>
> On Thu, Apr 16, 2009 at 12:03 PM, Igor Vaynberg <ig...@gmail.com> wrote:
>> this code is there so we can track focus and properly restore it after
>> ajax modifies the dom. i am not sure why we need to track and restore
>> focus on anchors, it is only important when you are typing so that the
>> cursor doesnt move elsewhere - so only for textfields and textareas.
>>
>> johan, matej says you wanted to track focus for anchors, whats the deal?
>>
>> -igor
>>
>> 2009/4/16 Peter Gardfjäll <pe...@gmail.com>:
>>> Hi James,
>>>
>>> I'm pretty sure that links are part of the problem.
>>> To verify this, try replacing all <a> tags with e.g. <span> and see if
>>> you can spot any difference in response time.
>>> Alternatively, try replacing/commenting out ajax components/behaviors
>>> on your page to prevent wicket-ajax.js from being pulled into the
>>> page.
>>>
>>> cheers, Peter
>>>
>>> On Thu, Apr 16, 2009 at 3:52 PM, James Carman
>>> <jc...@carmanconsulting.com> wrote:
>>>> Peter,
>>>> I have experienced similar problems just recently. I didn't narrow it down
>>>> to the fact that the links were the problem, as you have, though! I have
>>>> been racking my brains trying to figure this thing out. My page is similar,
>>>> a table with lots of cells in them that are links. I've turned off CSS and
>>>> other stuff trying to find the bottleneck. I didn't think for a moment that
>>>> it might be the links.
>>>>
>>>> James
>>>>
>>>> 2009/4/16 Peter Gardfjäll <pe...@gmail.com>
>>>>
>>>>> Hi all,
>>>>>
>>>>> I am working on a wicket application intended to be executed both on
>>>>> FF3 and IE7.
>>>>> While working on this application I have discovered that the rendering
>>>>> of some pages are a lot slower in IE.
>>>>> The pages that were significantly slower on IE have a couple of things
>>>>> in common: they are ajax-enabled and have lots of links.
>>>>> These pages all appear to freeze for a while after all data has been
>>>>> transferred, but before the page becomes responsive.
>>>>>
>>>>> The reason (or at least one of the reasons) is that wicket-ajax.js,
>>>>> which gets pulled in whenever an Ajax component/behavior is added to a
>>>>> page, registers a function
>>>>> (addDomReadyEvent(Wicket.Focus.attachFocusEvent)) that traverses all
>>>>> {input,select,a,textarea,button} tags in the DOM tree when the page
>>>>> has been loaded.
>>>>>
>>>>> I timed this function for one of my pages (containing a single big
>>>>> table with around 300 rows, with each row having about six links).
>>>>> When the function is registered, the fireDomReadyHandlers in
>>>>> wicket-event.js takes 2400 ms to execute, compared to 700 ms when not
>>>>> registered. In firefox, the corresponding numbers are about 470 ms and
>>>>> 400 ms.
>>>>>
>>>>> Hence, there seems to be quite a performance penalty involved in
>>>>> loading ajax pages with lots of links in IE7.
>>>>> I'm a bit worried about this overhead, particularly since I have a
>>>>> rather fast machine (a lot better than most of the end users anyway).
>>>>> I would not be surprised if clients see double page load times.
>>>>>
>>>>> Have anyone on this list experienced similar problems?
>>>>> Is this a known issue? (I have not been able to find anything similar
>>>>> on the mailing list)
>>>>> Any suggestions or pointers are welcome.
>>>>>
>>>>> best regards, Peter
>>>>>
>>>>> /PS By the way, I am using wicket 1.3.5.
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>
>>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: wicket-ajax and IE performance problems for pages with many links
Posted by James Carman <jc...@carmanconsulting.com>.
So, we understand what's slowing us down? Any way to turn that stuff
off on our end to get stuff working? I've got a release going out the
door that's slow as heck on IE right now.
On Thu, Apr 16, 2009 at 12:03 PM, Igor Vaynberg <ig...@gmail.com> wrote:
> this code is there so we can track focus and properly restore it after
> ajax modifies the dom. i am not sure why we need to track and restore
> focus on anchors, it is only important when you are typing so that the
> cursor doesnt move elsewhere - so only for textfields and textareas.
>
> johan, matej says you wanted to track focus for anchors, whats the deal?
>
> -igor
>
> 2009/4/16 Peter Gardfjäll <pe...@gmail.com>:
>> Hi James,
>>
>> I'm pretty sure that links are part of the problem.
>> To verify this, try replacing all <a> tags with e.g. <span> and see if
>> you can spot any difference in response time.
>> Alternatively, try replacing/commenting out ajax components/behaviors
>> on your page to prevent wicket-ajax.js from being pulled into the
>> page.
>>
>> cheers, Peter
>>
>> On Thu, Apr 16, 2009 at 3:52 PM, James Carman
>> <jc...@carmanconsulting.com> wrote:
>>> Peter,
>>> I have experienced similar problems just recently. I didn't narrow it down
>>> to the fact that the links were the problem, as you have, though! I have
>>> been racking my brains trying to figure this thing out. My page is similar,
>>> a table with lots of cells in them that are links. I've turned off CSS and
>>> other stuff trying to find the bottleneck. I didn't think for a moment that
>>> it might be the links.
>>>
>>> James
>>>
>>> 2009/4/16 Peter Gardfjäll <pe...@gmail.com>
>>>
>>>> Hi all,
>>>>
>>>> I am working on a wicket application intended to be executed both on
>>>> FF3 and IE7.
>>>> While working on this application I have discovered that the rendering
>>>> of some pages are a lot slower in IE.
>>>> The pages that were significantly slower on IE have a couple of things
>>>> in common: they are ajax-enabled and have lots of links.
>>>> These pages all appear to freeze for a while after all data has been
>>>> transferred, but before the page becomes responsive.
>>>>
>>>> The reason (or at least one of the reasons) is that wicket-ajax.js,
>>>> which gets pulled in whenever an Ajax component/behavior is added to a
>>>> page, registers a function
>>>> (addDomReadyEvent(Wicket.Focus.attachFocusEvent)) that traverses all
>>>> {input,select,a,textarea,button} tags in the DOM tree when the page
>>>> has been loaded.
>>>>
>>>> I timed this function for one of my pages (containing a single big
>>>> table with around 300 rows, with each row having about six links).
>>>> When the function is registered, the fireDomReadyHandlers in
>>>> wicket-event.js takes 2400 ms to execute, compared to 700 ms when not
>>>> registered. In firefox, the corresponding numbers are about 470 ms and
>>>> 400 ms.
>>>>
>>>> Hence, there seems to be quite a performance penalty involved in
>>>> loading ajax pages with lots of links in IE7.
>>>> I'm a bit worried about this overhead, particularly since I have a
>>>> rather fast machine (a lot better than most of the end users anyway).
>>>> I would not be surprised if clients see double page load times.
>>>>
>>>> Have anyone on this list experienced similar problems?
>>>> Is this a known issue? (I have not been able to find anything similar
>>>> on the mailing list)
>>>> Any suggestions or pointers are welcome.
>>>>
>>>> best regards, Peter
>>>>
>>>> /PS By the way, I am using wicket 1.3.5.
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: wicket-ajax and IE performance problems for pages with many links
Posted by Igor Vaynberg <ig...@gmail.com>.
this code is there so we can track focus and properly restore it after
ajax modifies the dom. i am not sure why we need to track and restore
focus on anchors, it is only important when you are typing so that the
cursor doesnt move elsewhere - so only for textfields and textareas.
johan, matej says you wanted to track focus for anchors, whats the deal?
-igor
2009/4/16 Peter Gardfjäll <pe...@gmail.com>:
> Hi James,
>
> I'm pretty sure that links are part of the problem.
> To verify this, try replacing all <a> tags with e.g. <span> and see if
> you can spot any difference in response time.
> Alternatively, try replacing/commenting out ajax components/behaviors
> on your page to prevent wicket-ajax.js from being pulled into the
> page.
>
> cheers, Peter
>
> On Thu, Apr 16, 2009 at 3:52 PM, James Carman
> <jc...@carmanconsulting.com> wrote:
>> Peter,
>> I have experienced similar problems just recently. I didn't narrow it down
>> to the fact that the links were the problem, as you have, though! I have
>> been racking my brains trying to figure this thing out. My page is similar,
>> a table with lots of cells in them that are links. I've turned off CSS and
>> other stuff trying to find the bottleneck. I didn't think for a moment that
>> it might be the links.
>>
>> James
>>
>> 2009/4/16 Peter Gardfjäll <pe...@gmail.com>
>>
>>> Hi all,
>>>
>>> I am working on a wicket application intended to be executed both on
>>> FF3 and IE7.
>>> While working on this application I have discovered that the rendering
>>> of some pages are a lot slower in IE.
>>> The pages that were significantly slower on IE have a couple of things
>>> in common: they are ajax-enabled and have lots of links.
>>> These pages all appear to freeze for a while after all data has been
>>> transferred, but before the page becomes responsive.
>>>
>>> The reason (or at least one of the reasons) is that wicket-ajax.js,
>>> which gets pulled in whenever an Ajax component/behavior is added to a
>>> page, registers a function
>>> (addDomReadyEvent(Wicket.Focus.attachFocusEvent)) that traverses all
>>> {input,select,a,textarea,button} tags in the DOM tree when the page
>>> has been loaded.
>>>
>>> I timed this function for one of my pages (containing a single big
>>> table with around 300 rows, with each row having about six links).
>>> When the function is registered, the fireDomReadyHandlers in
>>> wicket-event.js takes 2400 ms to execute, compared to 700 ms when not
>>> registered. In firefox, the corresponding numbers are about 470 ms and
>>> 400 ms.
>>>
>>> Hence, there seems to be quite a performance penalty involved in
>>> loading ajax pages with lots of links in IE7.
>>> I'm a bit worried about this overhead, particularly since I have a
>>> rather fast machine (a lot better than most of the end users anyway).
>>> I would not be surprised if clients see double page load times.
>>>
>>> Have anyone on this list experienced similar problems?
>>> Is this a known issue? (I have not been able to find anything similar
>>> on the mailing list)
>>> Any suggestions or pointers are welcome.
>>>
>>> best regards, Peter
>>>
>>> /PS By the way, I am using wicket 1.3.5.
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: wicket-ajax and IE performance problems for pages with many links
Posted by Peter Gardfjäll <pe...@gmail.com>.
Hi James,
I'm pretty sure that links are part of the problem.
To verify this, try replacing all <a> tags with e.g. <span> and see if
you can spot any difference in response time.
Alternatively, try replacing/commenting out ajax components/behaviors
on your page to prevent wicket-ajax.js from being pulled into the
page.
cheers, Peter
On Thu, Apr 16, 2009 at 3:52 PM, James Carman
<jc...@carmanconsulting.com> wrote:
> Peter,
> I have experienced similar problems just recently. I didn't narrow it down
> to the fact that the links were the problem, as you have, though! I have
> been racking my brains trying to figure this thing out. My page is similar,
> a table with lots of cells in them that are links. I've turned off CSS and
> other stuff trying to find the bottleneck. I didn't think for a moment that
> it might be the links.
>
> James
>
> 2009/4/16 Peter Gardfjäll <pe...@gmail.com>
>
>> Hi all,
>>
>> I am working on a wicket application intended to be executed both on
>> FF3 and IE7.
>> While working on this application I have discovered that the rendering
>> of some pages are a lot slower in IE.
>> The pages that were significantly slower on IE have a couple of things
>> in common: they are ajax-enabled and have lots of links.
>> These pages all appear to freeze for a while after all data has been
>> transferred, but before the page becomes responsive.
>>
>> The reason (or at least one of the reasons) is that wicket-ajax.js,
>> which gets pulled in whenever an Ajax component/behavior is added to a
>> page, registers a function
>> (addDomReadyEvent(Wicket.Focus.attachFocusEvent)) that traverses all
>> {input,select,a,textarea,button} tags in the DOM tree when the page
>> has been loaded.
>>
>> I timed this function for one of my pages (containing a single big
>> table with around 300 rows, with each row having about six links).
>> When the function is registered, the fireDomReadyHandlers in
>> wicket-event.js takes 2400 ms to execute, compared to 700 ms when not
>> registered. In firefox, the corresponding numbers are about 470 ms and
>> 400 ms.
>>
>> Hence, there seems to be quite a performance penalty involved in
>> loading ajax pages with lots of links in IE7.
>> I'm a bit worried about this overhead, particularly since I have a
>> rather fast machine (a lot better than most of the end users anyway).
>> I would not be surprised if clients see double page load times.
>>
>> Have anyone on this list experienced similar problems?
>> Is this a known issue? (I have not been able to find anything similar
>> on the mailing list)
>> Any suggestions or pointers are welcome.
>>
>> best regards, Peter
>>
>> /PS By the way, I am using wicket 1.3.5.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: wicket-ajax and IE performance problems for pages with many links
Posted by James Carman <jc...@carmanconsulting.com>.
Peter,
I have experienced similar problems just recently. I didn't narrow it down
to the fact that the links were the problem, as you have, though! I have
been racking my brains trying to figure this thing out. My page is similar,
a table with lots of cells in them that are links. I've turned off CSS and
other stuff trying to find the bottleneck. I didn't think for a moment that
it might be the links.
James
2009/4/16 Peter Gardfjäll <pe...@gmail.com>
> Hi all,
>
> I am working on a wicket application intended to be executed both on
> FF3 and IE7.
> While working on this application I have discovered that the rendering
> of some pages are a lot slower in IE.
> The pages that were significantly slower on IE have a couple of things
> in common: they are ajax-enabled and have lots of links.
> These pages all appear to freeze for a while after all data has been
> transferred, but before the page becomes responsive.
>
> The reason (or at least one of the reasons) is that wicket-ajax.js,
> which gets pulled in whenever an Ajax component/behavior is added to a
> page, registers a function
> (addDomReadyEvent(Wicket.Focus.attachFocusEvent)) that traverses all
> {input,select,a,textarea,button} tags in the DOM tree when the page
> has been loaded.
>
> I timed this function for one of my pages (containing a single big
> table with around 300 rows, with each row having about six links).
> When the function is registered, the fireDomReadyHandlers in
> wicket-event.js takes 2400 ms to execute, compared to 700 ms when not
> registered. In firefox, the corresponding numbers are about 470 ms and
> 400 ms.
>
> Hence, there seems to be quite a performance penalty involved in
> loading ajax pages with lots of links in IE7.
> I'm a bit worried about this overhead, particularly since I have a
> rather fast machine (a lot better than most of the end users anyway).
> I would not be surprised if clients see double page load times.
>
> Have anyone on this list experienced similar problems?
> Is this a known issue? (I have not been able to find anything similar
> on the mailing list)
> Any suggestions or pointers are welcome.
>
> best regards, Peter
>
> /PS By the way, I am using wicket 1.3.5.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>