Hi,

The page id is in the url for a reason - it keeps the state of your page.
If the page is stateless then there is no pageId and no redirect. So both
bots are happy and performance is better.
But Wicket's power is in its state management. If you render a stateful
page without the pageId then the state is gone if the user refreshes the
page with F5/Ctrl+r.

You have the following options:
1) use ONE_PASS_RENDER strategy and see whether this leads to any bugs.
Usually changing the strategy should be transparent but better test well
before rolling out
2) refactor your app to be stateless. Since 7.4.0 even the Ajax components
and behaviors could be stateless, so it is not impossible
3) Use HTTP2 enabled web server. This reduces the latency by other means

Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov

On Thu, Sep 22, 2016 at 1:20 PM, Dirk Forchel <dirk.forc...@exedio.com>
wrote:

> 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
>
>

Reply via email to