You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Oscar Besga Arcauz <ob...@isdefe.es> on 2012/11/11 19:44:54 UTC
Deploy on production: optimization tip & tricks
Hi wickers !
Thanks to your previous help, I'm about to launch a website based on wikcet.
I'm making some final optimizations, some general-web-server related;
as seen in http://developer.yahoo.com/performance/rules.html or cookie-free elements http://serverfault.com/questions/234891/how-to-configure-cookieless-virtual-host-in-apache2 .
Other are tomcat related, like gzip compression ( http://techxplorer.com/2010/09/17/enabling-gzip-compression-in-tomcat/ and http://viralpatel.net/blogs/enable-gzip-compression-in-tomcat/ ) or general clues ( http://www.mulesoft.com/tomcat-jsp )
For wicket I've found this slideshare http://www.slideshare.net/dashorst/keep-your-wicket-application-in-production
and to use this (bellow) because scripts in this way in various components are 'crunched' into one script on page renderization:
response.render(OnDomReadyHeaderItem.forScript("foobar")); // Also can use OnLoadHeaderItem
Do you havew any other optimization tip & tricks (aplication config, etc.) ?
I'm thinking to write a wiki page summarizing responses, a 'Deployment' section ...
> > > Oscar Besga Arcauz < < <
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Deploy on production: optimization tip & tricks
Posted by Martin Grigorov <mg...@apache.org>.
Hi,
On Sun, Nov 25, 2012 at 11:54 AM, Oscar Besga Arcauz <ob...@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" <th...@gmail.com> escribió: -----
> Para: users@wicket.apache.org
> De: "Serban.Balamaci" <th...@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-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
>
>
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com <http://jweekend.com/>
Re: Deploy on production: optimization tip & tricks
Posted by Oscar Besga Arcauz <ob...@isdefe.es>.
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" <th...@gmail.com> escribió: -----
Para: users@wicket.apache.org
De: "Serban.Balamaci" <th...@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-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: Deploy on production: optimization tip & tricks
Posted by "Serban.Balamaci" <th...@gmail.com>.
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="/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-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Deploy on production: optimization tip & tricks
Posted by Oscar Besga Arcauz <ob...@isdefe.es>.
(I respond myself, which is not a good policy )
I've been playing with wicket api, and now I'm doing this
public final static String GOOGLE_URL = "//ajax.googleapis.com/ajax/libs/jquery/1.8.2/jquery.min.js";
@Override
public void init() {
super.init();
/*
...
*/
if (getConfigurationType() == RuntimeConfigurationType.DEPLOYMENT){
getMarkupSettings().setStripComments(true);
getMarkupSettings().setCompressWhitespace(true);
getMarkupSettings().setStripWicketTags(true);
//Use Google CDN
getJavaScriptLibrarySettings().setJQueryReference( new UrlResourceReference(Url.parse(GOOGLE_URL)););
}
}
> > > Oscar Besga Arcauz < < <
-----Oscar Besga Arcauz/ISNOTES@ISNOTES escribió: -----
Para: users@wicket.apache.org
De: Oscar Besga Arcauz/ISNOTES@ISNOTES
Fecha: 11/11/2012 19:45
Asunto: Deploy on production: optimization tip & tricks
Hi wickers !
Thanks to your previous help, I'm about to launch a website based on wikcet.
I'm making some final optimizations, some general-web-server related;
as seen in http://developer.yahoo.com/performance/rules.html or cookie-free elements http://serverfault.com/questions/234891/how-to-configure-cookieless-virtual-host-in-apache2 .
Other are tomcat related, like gzip compression ( http://techxplorer.com/2010/09/17/enabling-gzip-compression-in-tomcat/ and http://viralpatel.net/blogs/enable-gzip-compression-in-tomcat/ ) or general clues ( http://www.mulesoft.com/tomcat-jsp )
For wicket I've found this slideshare http://www.slideshare.net/dashorst/keep-your-wicket-application-in-production
and to use this (bellow) because scripts in this way in various components are 'crunched' into one script on page renderization:
response.render(OnDomReadyHeaderItem.forScript("foobar")); // Also can use OnLoadHeaderItem
Do you havew any other optimization tip & tricks (aplication config, etc.) ?
I'm thinking to write a wiki page summarizing responses, a 'Deployment' section ...
> > > Oscar Besga Arcauz < < <
---------------------------------------------------------------------
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