Re: Deploy on production: optimization tip & tricks
Hi, On Sun, Nov 25, 2012 at 11:54 AM, Oscar Besga Arcauz 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" escribió: - > Para: users@wicket.apache.org > De: "Serban.Balamaci" > 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 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/N
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" escribió: - Para: users@wicket.apache.org De: "Serban.Balamaci" 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 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 pag
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 ). 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
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
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