Today, we've had a long discussion at our site about dos and don'ts using Wicket. And it came up, that the default render strategy REDIRECT_TO_BUFFER used for Wicket applications might not be the best solution for everyone. >From a SEO point of view, what's bothering me much more than the additional parameter (which I could probably handle fine using a canonical tag), is the fact that every page request immediately responds with a 302-redirect having the parameter appended. As far as I know, having 302 redirect with every request, for any URL is a really bad thing not only if you want to have your pages correctly crawled, indexed and good ranked. But this is not the main problem as long as we could use the ONE_PASS_RENDER strategy for bots and crawlers provided with a different WebPageRender. The main problem is the latency for our web application. For each web page access, apart from the processing time that is needed on the server to process the request, there is a delay involved for each request to reach to the server and a delay for the response. If we use the REDIRECT_TO_BUFFER strategy this latency is one and a half time greater than for one request only. In order to make our web application faster and reduce its latency we must reduce the number of requests for each webpage. This way, each redirect after a GET request might not be a good practise. I would like to know how what is the best practise or the best render strategy to use with these requirements in mind. What are flaws or drawbacks. Thanks.
-- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Concerns-about-different-render-strategies-and-latency-tp4675545.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
