You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Dirk Forchel <di...@exedio.com> on 2016/09/22 11:20:00 UTC
Concerns about different render strategies and latency
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-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Concerns about different render strategies and latency
Posted by Dirk Forchel <di...@exedio.com>.
The crux of the matter so far was the AjaxBehavior which wasn't stateless. We
will use Wicket 7.4.0 from now on and try to make all relevant pages
stateless.
I found this part of the documentation, which is quite new
https://github.com/apache/wicket/blob/master/wicket-user-guide/src/docs/guide/ajax/ajax_7.gdoc
and a good starting point for refactoring our application.
Thank you Martin.
--
View this message in context: http://apache-wicket.1842946.n4.nabble.com/Concerns-about-different-render-strategies-and-latency-tp4675545p4675556.html
Sent from the Users forum mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Concerns about different render strategies and latency
Posted by Martin Grigorov <mg...@apache.org>.
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 <di...@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-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>