Re: Deploy on production: optimization tip tricks
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
Re: Deploy on production: optimization tip tricks
Hi, On Sun, Nov 25, 2012 at 11:54 AM, Oscar Besga Arcauz obe...@isdefe.eswrote: 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
Re: Deploy on production: optimization tip tricks
(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-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
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=/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
