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.
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
