On Sun, Nov 25, 2012 at 11:54 AM, Oscar Besga Arcauz <obe...@isdefe.es>wrote:

> Thank you !
> Some of these improvements are already implemented on my site.
> I've been looking forward to implement wicket-specific optimizations
> (althought I'm discovering that wicket alone it's default optimized on
> deployment mode )
> And as you already said, perfomance is an art where no silver bullets are
> common; but a search for balance and tradeoffs.
> For example, I've said that using (1) code will . Well, for one side it
> will dinamically minify the resulting html code downloaded by browser. But
> these settings will make page processing slower.

These particular settings are actually not a problem.
They are used during the reading of the markup templates. Once read the
templates are cached and used for the lifetime of the application.

> So it's up to you to choose the rigth approach.
> (1)
>             getMarkupSettings().setStripComments(true);
>             getMarkupSettings().setCompressWhitespace(true);
>             getMarkupSettings().setStripWicketTags(true);
>     > > > Oscar Besga Arcauz  < < <
> -----"Serban.Balamaci" <thespamtr...@gmail.com> escribió: -----
> Para: users@wicket.apache.org
> De: "Serban.Balamaci" <thespamtr...@gmail.com>
> Fecha: 15/11/2012  22:45
> Asunto: Re: Deploy on production: optimization tip & tricks
> Hi Oscar,
> Probably nobody responded because this is not a simple topic but with many
> implications and turns. There are many optimizations that can be done not
> necessarily related to wicket.
> I'd recomend http://stevesouders.com/ blog, http://www.bookofspeed.com/ ,
> http://www.guypo.com/
> But ok I'll play along and add my 2 cents:
> 1. Setting Caching  headers on the web response is for certain something
> that you'd want to do. Set a long expire date for JS and CSS file like
> months even 1year. But you'd also want the users to receive the latest css
> and JS files you make with a new release. So it's good to mix up the
> resource name with some kind of version token(I use the app version nr in
> the css/js files name something like <link rel="stylesheet" type="text/css"
> href="https://portal.isdefe.es/2.14/css/site.css"; />).
> Also most important optimizations that give the user the impression of
> speed
> are related to loading the JS files. While JS files are being downloaded
> the
> PAGE RENDERING is STOPPED. So it's a good idea to put them at the page's
> bottom and using the css and html to render the page in an usable(nice
> looking) state and then, while the user is reading and figuring out the
> content, the JS "enhancements" like sliding menus etc are loading in the
> "background". Otherwise keeping the JS at the top results in the so called
> "WhitePageOfDeath" in which the user sees a blank page while the header JS
> files are being downloaded.
> You can achieve the same thing as putting the JS at the page bottom but
> while keeping the JS files at the head with the "defer" attribute easily
> like . That means the rendering will not be blocked but the JS will execute
> on DomReady event.
> 2. Minification and merging JS files into one:
> A. Most today's browsers are limited to making at most 6 parallel requests
> to a certain domain. So you don't want to have more js files merged into a
> single one so you don't wait for another wave of free connections. There is
> also the RoundTripTime overhead associated with making a new call to the
> server.
> B. The the bigger a text file is, the better it's compression ratio will
> be.
> So you'd get some benefit from merging all the js files into one and the
> gzip compression will be greater and also the minification gain. I
> recommend
> the *wro4j* project as it has lots of minification plugins.
> Unfortunately Wicket's component nature where every component can
> contribute
> it's own separate JS file makes it harder to have a single big minified JS
> file for all the page.
> 3. Using CDNs have the benefit of lower latency and also introducing
> another
> domain and thus increasing those 6 max nr of connections. Using some famous
> CDN like you did for JQuery also increases the probability of user already
> having Jquery in the cache from another site that he visited before(that's
> why I'm a fan of not also including the JQuery library in a minified
> package
> of all your site's JS files).
> Using asynchronous loading for 3rd party scripts like g+, facebook, ga are
> mandatory also these days.
> 4. Caching before the web server layer - using a caching proxy like Varnish
> or Apache/Nginx with a caching module to save maybe DB generated image
> resources maybe can be a good idea also.
> The topic is far far from being exhausted so I think that's the reason why
> nobody is playing along with responding.
> Personally I'm curios if an enhancement of providing "Transfer-Encoding:
> chunked" and keeping the JS resources in the head with the "defer"
> attribute(so the browser quickly receives the header and can begin the
> download of JS files) while a slow DB prevents us from returning the full
> html. But I'm afraid it might be a mess with not really huge gains in
> performance and wicket by it's component nature means we don't know the
> required js resources in the page's head until all the components have been
> added to the page and got a chance to contribute there needed resources.
> I'm also curious what the future holds in terms of the SPDY protocol since
> optimizing for it and might go against today's best practicies of splitting
> resources across many domains.
> --
> View this message in context:
> http://apache-wicket.1842946.n4.nabble.com/Deploy-on-production-optimization-tip-tricks-tp4653774p4653928.html
> Sent from the Users forum mailing list archive at Nabble.com.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org

Martin Grigorov
Training, Consulting, Development
http://jWeekend.com <http://jweekend.com/>

Reply via email to