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:
Sent from the Users forum mailing list archive at

To unsubscribe, e-mail:
For additional commands, e-mail:

Reply via email to