wicket buffers your output, which may affect the time it takes the browser to get the initial markup. eg the markup is not streamed as wicket is rendering but is sent in one large chunk once the render on serverside is complete.
you can change the render strategy to ONE_PASS_RENDER but then you will lose features like redirect-after-post, the ability to use RestartResponseException mid-render, etc. -igor On Wed, Feb 24, 2010 at 2:14 PM, Corbin, James <[email protected]> wrote: > Yes Igor, I understand that, but some of our display pages initially take a > very long time to initially render. For example, we have editors that take > upwards of 30 seconds to render initially. Subsequent renders are obviously > quicker. > > I guess what I am trying to say, are there any best practices for reducing > the initial load time of pages. > > > > -----Original Message----- > From: Igor Vaynberg [mailto:[email protected]] > Sent: Wednesday, February 24, 2010 2:58 PM > To: [email protected] > Subject: Re: Speeding Up HTML Parse??? > > On Wed, Feb 24, 2010 at 1:26 PM, Corbin, James <[email protected]> > wrote: >> I'm profiling our Wicket Application using Google's Speed Tracer Plugin >> (nice plugin). >> >> >> >> The profiling tool is showing most of the time spent in two areas, >> >> >> >> 1) Parsing HTMlL > > this measures the browser's speed not wickets.... > > besides, where does most of the time browserside should go? shouldnt > it be parsing html? thats what browsers do... > > -igor > > > >> >> 2) Javascript Valuation (mostly with YUI). >> >> >> >> What are some of the best practices around developing code that >> minimizes the impact of parsing HTML in Wicket? >> >> >> >> We haven't had a lot of time to optimize our code and now are starting >> to look at that aspect of our application. >> >> >> >> Thanks, >> >> >> >> J.D. >> >> >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
