Why Redraw of the whole page when paginating?

[urs]

Hi, please look at the ASP.NET 2 site
http://www.prismatest.ch/catalog/EM.ASPX
(user=prismashop, password=minicooper). Use the ">" Button to go to the
next pages.

You will notice that the page goes all white every time after pressing
the ">" Button, and redraws itself only after all parts of the page
have been downloaded. This means the page stays white for several
seconds.

On most other sites, the current page stays on screen until the very
last moment, that means it never becomes all white. Altough the page
itself does not load faster than usual, the user experience is much
better, since he can always see "something". When the page goes all
white, the result is somewhat "flickering" and indicates a "slowness".

For example, take a look at this site:
http://www.citydisc.ch/s/search.cfm?...group_detail=0

Altough the site is quite slow, the page stays on-screen until the very
last moment when paginating, giving the user a better experience.

Does anyone know why this is happing? Is there a certain HTML or css
tag which causes this behaviour? I used lots of DIVs and SPANs and
stayed away from TABLEs where not appropriate (except for the title
bar). I also use lots of CSS. Is this the price I have to pay for
building a page with a "modern" apprach?

Thanks for any insight
Urs

[Edwin Knoppert]

There is a (poor working) option to do a similar thing in asp.net

However, i'm curious why 'these' websites refresh differently.
I see a total refresh on ordinary sites as well, so??

<ur*@prismanet.ch> schreef in bericht
news:11**********************@g14g2000cwa.googlegr oups.com...

Hi, please look at the ASP.NET 2 site
http://www.prismatest.ch/catalog/EM.ASPX
(user=prismashop, password=minicooper). Use the ">" Button to go to the
next pages.

You will notice that the page goes all white every time after pressing
the ">" Button, and redraws itself only after all parts of the page
have been downloaded. This means the page stays white for several
seconds.

On most other sites, the current page stays on screen until the very
last moment, that means it never becomes all white. Altough the page
itself does not load faster than usual, the user experience is much
better, since he can always see "something". When the page goes all
white, the result is somewhat "flickering" and indicates a "slowness".

For example, take a look at this site:
http://www.citydisc.ch/s/search.cfm?...group_detail=0

Altough the site is quite slow, the page stays on-screen until the very
last moment when paginating, giving the user a better experience.

Does anyone know why this is happing? Is there a certain HTML or css
tag which causes this behaviour? I used lots of DIVs and SPANs and
stayed away from TABLEs where not appropriate (except for the title
bar). I also use lots of CSS. Is this the price I have to pay for
building a page with a "modern" apprach?

Thanks for any insight
Urs

[urs]

yes, the pages refresh totally on other sites, but there, not the whole
browser screen remains white for several seconds.

[Patrice]

My first thought would be that it depends on the buffering option used
server side...

--
Patrice

<ur*@prismanet.ch> a écrit dans le message de
news:11**********************@f14g2000cwb.googlegr oups.com...

yes, the pages refresh totally on other sites, but there, not the whole
browser screen remains white for several seconds.

[urs]

buffering option? which buffe? where would I change that?

[Patrice]

Ok likely not that then as this is likely on by default ?

Else see either the IIS configuration (this is in the options tab for the
IIS application configuration) or if you have something like
Response.Buffer=False in your code.

Bascially it either accumulates all the response in a buffer allowing to
send this in one shot when the page is ready.
Else this is sent in several chunk and the browser may not at first have
enough info to display something else than a blank page.

Not sure but could worth a try...

--
Patrice

<ur*@prismanet.ch> a écrit dans le message de
news:11*********************@f14g2000cwb.googlegro ups.com...

buffering option? which buffe? where would I change that?

[Edwin Knoppert]

Isn't this?:

Response.flush
<Do other heavy tasks like page.databind etc..>
Response.flush


"Patrice" <no****@nowhere.com> schreef in bericht
news:OU**************@TK2MSFTNGP10.phx.gbl...

Ok likely not that then as this is likely on by default ?

Else see either the IIS configuration (this is in the options tab for the
IIS application configuration) or if you have something like
Response.Buffer=False in your code.

Bascially it either accumulates all the response in a buffer allowing to
send this in one shot when the page is ready.
Else this is sent in several chunk and the browser may not at first have
enough info to display something else than a blank page.

Not sure but could worth a try...

--
Patrice

<ur*@prismanet.ch> a écrit dans le message de
news:11*********************@f14g2000cwb.googlegro ups.com...

buffering option? which buffe? where would I change that?

[CJ]

<pages buffer="true" /> in the system.web section of web.config should
flush the buffer
response.flush is more for long running processes where you want to
show some form of status, update

[Edwin Knoppert]

Not sure what that does yet.
I include a meta no-chache in allmost all my pages.
Hopefully yours will not overrule that ???
"CJ" <Ch*************@gmail.com> schreef in bericht
news:11**********************@g44g2000cwa.googlegr oups.com...

<pages buffer="true" /> in the system.web section of web.config should
flush the buffer
response.flush is more for long running processes where you want to
show some form of status, update

[CJ]

There's a great article here..

http://msdn.microsoft.com/library/de...netchapt06.asp

regards-

[Steven Cheng[MSFT]]

Thanks for all of your informative inputs,

Hi Urs,

As other guys have mentioned, such behavior ( client browser screen keep
blank before the complete page content being rendered) is caused by the
response output buffering setting of the serverside dynamic document (like,
asp, asp.net , jsp.....). And for ASP.Net page, the output buffer is by
default enabled for performance consideration. Since using output buffer
can keep the output stream content be flushed to client at one time so as
to as avoid multiple round trip to client side..... And as you've seen,
one disadvantage of using output buffer is that when page's content is
large and require some time to flush out, the client side's user experience
is not quite good. So it's up to you to determine whether to turn on it or
not (according to your webpage 's size and clientside network
environment....)

In ASP.NET 2.0, we can define the output buffer programmatically in code or
statically through the @Page directive or web.config's <pages> setting, e.g:

<pages
buffer="[True|False]"

<%@Page buffer="true"...... %>

Please feel free to post here if there're anything else unclear.

Thanks,

Steven Cheng
Microsoft Online Support

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)

--------------------
| From: "CJ" <Ch*************@gmail.com>
| Newsgroups: microsoft.public.dotnet.framework.aspnet
| Subject: Re: Why Redraw of the whole page when paginating?
| Date: 11 Dec 2005 06:35:31 -0800
| Organization: http://groups.google.com
| Lines: 6
| Message-ID: <11*********************@g47g2000cwa.googlegroups. com>
| References: <11**********************@g14g2000cwa.googlegroups .com>
| <43**********************@text.nova.planet.nl>
| <11**********************@f14g2000cwb.googlegroups .com>
| <eU**************@tk2msftngp13.phx.gbl>
| <11*********************@f14g2000cwb.googlegroups. com>
| <OU**************@TK2MSFTNGP10.phx.gbl>
| <43**********************@text.nova.planet.nl>
| <11**********************@g44g2000cwa.googlegroups .com>
| <dn**********@azure.qinip.net>
| NNTP-Posting-Host: 24.154.126.239
| Mime-Version: 1.0
| Content-Type: text/plain; charset="iso-8859-1"
| X-Trace: posting.google.com 1134311736 5604 127.0.0.1 (11 Dec 2005
14:35:36 GMT)
| X-Complaints-To: gr**********@google.com
| NNTP-Posting-Date: Sun, 11 Dec 2005 14:35:36 +0000 (UTC)
| In-Reply-To: <dn**********@azure.qinip.net>
| User-Agent: G2/0.2
| X-HTTP-UserAgent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1;
.NET CLR 1.1.4322),gzip(gfe),gzip(gfe)
| Complaints-To: gr**********@google.com
| Injection-Info: g47g2000cwa.googlegroups.com; posting-host=24.154.126.239;
| posting-account=Jrsw2Q0AAAA50b2YYg1AaivhxIyK00D5
| Path:
TK2MSFTNGXA02.phx.gbl!TK2MSFTNGP08.phx.gbl!newsfee d00.sul.t-online.de!t-onli
ne.de!border2.nntp.dca.giganews.com!border1.nntp.d ca.giganews.com!nntp.gigan
ews.com!postnews.google.com!g47g2000cwa.googlegrou ps.com!not-for-mail
| Xref: TK2MSFTNGXA02.phx.gbl
microsoft.public.dotnet.framework.aspnet:364090
| X-Tomcat-NG: microsoft.public.dotnet.framework.aspnet
|
| There's a great article here..
|
|
http://msdn.microsoft.com/library/de...us/dnpag/html/
scalenetchapt06.asp
|
| regards-
|
|

[urs]

Steven, thanks for your answer. I tried the following:
- Disabled buffering, but then the response times increased
dramatically. So this cannot be a solution.

- In the master page, I put a <% response.flush() %> after the header.
However, this doesn't significantly reduce the duration of the white
screen. I guess this is since what acutally takes long is the PreRender
phase (about 0.3-0.5 sec to gather all the data to be displayed). The
embedded response.flush will only be executed in the Render phase.
What I don't understand: AFAIK the browser doesn't begin rendering the
page until it receives the beginning of the response from the server.
But if the response buffer is enabled, there shouldn't be *any*
response from the server until everything is in place and ready to be
sent. I verifyed this by setting HttpResponse.Filter, and it is true.
Is there anything else, something like a "starting signal" be sent from
ASP.NET? Can I improve this behaviour somehow?

What I also noticed: Only IE6 shows this behaviour. In Firefox, in most
cases, the browser doesn't show the white page. Is firefox simply
better programmed, or does it receive some different signals from IIS?

Thanks for your investigations
Urs

[Steven Cheng[MSFT]]

Thanks for your response Urs,

I don't think there will have much difference between the FireFox or IE's
behavie on handling buffered web page response. We can test through a very
large asp.net page that use a large for ...... loop to write out bunch of
data and enable output buffer, both firefox and IE will provide blank
screen until it start receving data from server....

So far I can't get some other options for the buffered web pages, however,
if the page's content is mostly static, enable caching can help client
experience much better when they visit the page multiple times....

Regards,

Steven Cheng
Microsoft Online Support

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)
--------------------
| From: ur*@prismanet.ch
| Newsgroups: microsoft.public.dotnet.framework.aspnet
| Subject: Re: Why Redraw of the whole page when paginating?
| Date: 13 Dec 2005 01:46:29 -0800
| Organization: http://groups.google.com
| Lines: 24
| Message-ID: <11**********************@f14g2000cwb.googlegroups .com>
| References: <11**********************@g14g2000cwa.googlegroups .com>
| <11*********************@g47g2000cwa.googlegroups. com>
| <Bx*************@TK2MSFTNGXA02.phx.gbl>
| NNTP-Posting-Host: 213.200.246.99
| Mime-Version: 1.0
| Content-Type: text/plain; charset="iso-8859-1"
| X-Trace: posting.google.com 1134467200 32087 127.0.0.1 (13 Dec 2005
09:46:40 GMT)
| X-Complaints-To: gr**********@google.com
| NNTP-Posting-Date: Tue, 13 Dec 2005 09:46:40 +0000 (UTC)
| In-Reply-To: <Bx*************@TK2MSFTNGXA02.phx.gbl>
| User-Agent: G2/0.2
| X-HTTP-UserAgent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8)
Gecko/20051111 Firefox/1.5,gzip(gfe),gzip(gfe)
| Complaints-To: gr**********@google.com
| Injection-Info: f14g2000cwb.googlegroups.com; posting-host=213.200.246.99;
| posting-account=hmlk0A0AAABA00P_j215TrNL0lU6v41c
| Path:
TK2MSFTNGXA02.phx.gbl!TK2MSFTNGP08.phx.gbl!newsfee d00.sul.t-online.de!t-onli
ne.de!border2.nntp.dca.giganews.com!novia!nx01.iad 01.newshosting.com!newshos
ting.com!216.196.98.140.MISMATCH!border1.nntp.dca. giganews.com!nntp.giganews
.com!postnews.google.com!f14g2000cwb.googlegroups. com!not-for-mail
| Xref: TK2MSFTNGXA02.phx.gbl
microsoft.public.dotnet.framework.aspnet:364452
| X-Tomcat-NG: microsoft.public.dotnet.framework.aspnet
|
| Steven, thanks for your answer. I tried the following:
| - Disabled buffering, but then the response times increased
| dramatically. So this cannot be a solution.
|
| - In the master page, I put a <% response.flush() %> after the header.
| However, this doesn't significantly reduce the duration of the white
| screen. I guess this is since what acutally takes long is the PreRender
| phase (about 0.3-0.5 sec to gather all the data to be displayed). The
| embedded response.flush will only be executed in the Render phase.
| What I don't understand: AFAIK the browser doesn't begin rendering the
| page until it receives the beginning of the response from the server.
| But if the response buffer is enabled, there shouldn't be *any*
| response from the server until everything is in place and ready to be
| sent. I verifyed this by setting HttpResponse.Filter, and it is true.
| Is there anything else, something like a "starting signal" be sent from
| ASP.NET? Can I improve this behaviour somehow?
|
| What I also noticed: Only IE6 shows this behaviour. In Firefox, in most
| cases, the browser doesn't show the white page. Is firefox simply
| better programmed, or does it receive some different signals from IIS?
|
| Thanks for your investigations
| Urs
|
|