Hi,
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 jWeekend Training, Consulting, Development http://jWeekend.com <http://jweekend.com/>
