PR effect from .net viewstate info - Page 2

Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

Threaded View

Re: PR effect from .net viewstate info

Big Bill wrote:
Quoted text here. Click to load it

text and markup, the raw file if you like.

Here is my example:

"The Climbing Dictionary" abseil adze portaledge  filetype:htm


then search for

"The Climbing Dictionary" abseil adze portaledge filetype:htm

and you don't get the SERP anymore. Portaledge is around 111K through
the file which totals 163K. Interestingly (SEODave made this point
earlier where he points out that the break is variable) the cache
version shows the complete file but claims it is 101K.

Anyway, bottom line, the Google robot does not index the whole of a file
although it is possible that it may index more text with subsequent
visits. This may be dependent on the speed of the server, perhaps the
robot closes the connection after a set time?

Re: PR effect from .net viewstate info

On Tue, 16 Nov 2004 17:22:20 GMT, SEO Dave

Quoted text here. Click to load it

They did say there were exceptions arguably chosen according to some
sort of merit (my words). So some larger pages would get fully cached.
Hope I'm expressing myself properly here.


Quoted text here. Click to load it

         home of SEO that's shiny!

Re: PR effect from .net viewstate info

On Tue, 16 Nov 2004 17:22:20 GMT, SEO Dave

Quoted text here. Click to load it
Quoted text here. Click to load it

But then you have to consider that Google, in the past, has shared
hints about character counts and about how many characters for certain
thoughts could be in your favor - beyond that then not likely to be in
your favor on Google.

You can make the <title></title> of your page 120 characters long or
even 150 ... but Google always hinted they liked the first 60
characters best. Now Google may display or cache a few of the
additional characters you slipped into the <title> ... but we also
know Google highlighting terms does not mean they are counting *that*
particular instance either.

Recall how one-word domain names would have bits highlighted as to
"matching" but not necessarily "counting"? So what you see on Google
isn't necessarily, nor never been, "what you get smiled upon" in

Couple in that I agreed with Cat in the past about the top part of the
page. I imagine there are still some old articles on the Web sharing
how, back in 1995 to 1998 time frame, the advice for doing "well" on
metacrawlers and Yahoo was to have the first X number of characters of
your page being the "richest". Cat leans to 100 to 150 characters [or
words?], I seem to recall being told the first 200 to 250 words is
what you wanted to focus on. I've also shared on here about Yahoo
Groups owners being allotted 2,000 characters for their spiel or
welcome message but a Yahoo employee sharing that Yahoo would only use
the first 1,000 in the Group's Search facility so to bear that in
mind. Not necessarily new advice as I stated it has been floating
around one way or another [in terms of character/word count thoughts
in relation to the top of the page] for almost a decade now.

This is why I agreed with others that the footer area is the weakest
section of the page. I've never expected that area to really help out
longer pages say of 65 to 100k size range except for maybe keyword
density thoughts.

Some have shared they  felt the links shared at/near the bottom
[navigation style or in the footer] were treated differently [in terms
of weight or value in the SE's eyes] than those, say, shared in the
middile even. At least I recall reading posts about that on WMW and
some other forums over the past year. Also was a theory that footer
links were treated more favorably when shared as a sentence versus a
string of links. I don't know about that though.


Re: PR effect from .net viewstate info

On Mon, 15 Nov 2004 19:48:32 -0500, "vMike"

Quoted text here. Click to load it

Well then that's easy as it won't be hardly at all as Google appears
far far more concerned about off-page considerations than in-page.


       home of SEO that's shiny!

Re: PR effect from .net viewstate info

On Mon, 15 Nov 2004 14:04:44 -0500, "vMike"

Quoted text here. Click to load it

hmmm.  That's a lot of ugly viewstate to be cranking across *any*
dial-up connection ---- even if you have good PR for the page!     You
may have a larger issue than just PR on your hands here, Mike.

I assume because you are interested in PR that you will be serving
those pages to mostly dial-up folks,  since dial up comprises the vast
majority of search engine users.    I'd seriously consider attempting
to prune down your vState first.    Not because of PR issues though,
but solely for performance ones.

Crikey,you're looking at 10 seconds time for a 36k dialup user to DL
*just* the viewstate string, and that's not including the real page
elements!       I personally will rarely wait more than 10-15 secs for
a page to load after I've clicked an SE result link, and I'm a patient
man.      Any more than 10-15 secs, and I hit the 'back' button and go
to the next result.    Most dial-up folks hate huge pages, more than I

I think the average user waits like 5-7 secs for a page to appear
before hitting the back button. ( anyone have those statistics handy?)
So I'd suggest, that at a minimum, you should probably design the
pages you want a good PR for with viewstate turned off.

here's some interesting points I considered while preparing to do an site for someone:


ViewState and Performance

By default ViewState is enabled in an ASP.NET application. Developers
should be aware that any data in ViewState automatically makes a round
trip to the client. Because the round trips contribute to a
performance overhead, it is important to make judicious use of

This is especially important when your application contains complex
controls such as a DataList or DataGrid but is generally true when you
are presenting considerable information via a server control. An
example might be presented a list of countries for selection ... you
don't want to impose the overhead of transferring all the country text
back and forth from server to client and vice versa more than is
strictly necessary. It will significantly impact on response times if
you don't disable the ViewState either for the page as a whole or for
the specific controls causing the unnecessary overhead.

Whenever you complete a web forms page you should review the controls
in the page and consider what is being passed in the ViewState and
whether you really need all that information to be passed. To optimise
Web page size you may want to disable ViewState in the following
cases, amongst others:

   when a page does not postback to itself

   when there are no dynamically set control properties

   when the dynamic properties are set with each request of the page

ASP.NET provides you with complete flexibility to disable ViewState.
As already discussed you are able to disable ViewState at the control
and page level. Additionally you may disable ViewState at the
application and machine level via the web.config and machine.config
files via the following directive:

    <Pages enableViewState="false"/>  

Session State or ViewState?

There are certain cases where holding a state value in ViewState is
not the best option. The most commonly used alternative is Session
state, which is generally better suited for:

Large amounts of data.
   As ViewState increases the size of both the HTML page sent to the
browser and the size of form posted back, it's a poor choice for
storing large amounts of data.

Sensitive data that is not already displayed in the UI.
   While the ViewState data is encoded and may optionally be
encrypted, your data is most secure if it is never sent to the client.
So, Session state is a more secure option.

Objects not readily serialized into ViewState, for example, DataSet.
   As already discussed the ViewState serializer is optimized for a
small set of common object types. Other types that are serializable
may be persisted in ViewState, but are slower and can generate a very
large ViewState.


anyway, I'd be interested in how you decide to resolve this, if you
dont mind posting some follow up, as I find myself now wrestling with
viewstate too.


BTW, good fritz onion article here on how 2.0 addresses and
improves the ugly viewstate issue:

Re: PR effect from .net viewstate info

Quoted text here. Click to load it

I am trying to figure out ways to reduce it but, so far I haven't had a lot
of luck, but I will keep working on it.

Thanks for the input.

Re: PR effect from .net viewstate info

On Wed, 17 Nov 2004 16:28:20 -0500, "vMike"

Quoted text here. Click to load it
 no prob.    I'm in the same boat as you with asp, so I know what
youre wrestling with.   But I always try to keep all pages under
10-15k total.   From scanning our web logs, we noticed that for pages
weighing over 35k, the number of hits drops by 20-35% over the smaller
10-15k pages.    

I'm not totally sure this is related to page weight, but I do know I
now work real hard to make all pages under 20k just from a visitor
retention perspective.  I would prefer to have them all under 10k, but
it's tough sometimes.

anyhoo, I feel your pain.  good luck and check back in if you find a
good way to reduce your viewstate.   Im all ears.

Re: PR effect from .net viewstate info

Quoted text here. Click to load it
Had some major breakthroughs yesterday on viewstate. Using Override
SaveViewState and LoadViewState. I can put just the things I need in the
viewstate of my base page and turn it off for controls. I have cut it in
half and think I can get it down by another half. Gives me a bit of
spaghetti code but saves a lot on page weight. Still in the testing stages
but I think I can at least cut it way back.

Re: PR effect from .net viewstate info

Quoted text here. Click to load it
I was able to get the viewstate down to about 2.5K. I may be able to squeeze
it a bit more. The way I handled it was to save just the specific
information I needed in viewstate (instead of everything) then override the
save and load view state. I had to set the page to enableviewstate true but
set most of my controls to false. It requires more server process time
(mostly trips to the database files which are cached anyway)  and there are
some weird things that happen with imageclick (especially after the second
postback) but I think the page load time is about 1/2 to 2/3 of what it was
before so it is worth it.   Thanks for all the help. Now to see it effects


Re: PR effect from .net viewstate info

On Sun, 21 Nov 2004 14:42:16 -0500, "vMike"

Quoted text here. Click to load it

2.5K?  nice!  that's totally manageable from a dialup user/download
perspective.   well done.

I'm in for a viewstate optimize session after the new year, myself.

separate asp SEO question for you, mike ( or any others who want to
jump in) :

From a SEO perspective, how are you planning to handle having google
find/index/spider your dynamic pages?    I haven't resolved this in my
head just yet because I still haven't fully grokked how google
actually spiders dynamic sites.   (There are a couple of threads going
on in the NG now about the "depth" to which google will index down
into dynamic sites and there seems to be no solid agreement on how
google does this exactly)

Right now Im leaning towards just fully re-generating the actual HTML
pages once every 2 weeks for the whole site and uploading them,
instead of dynamically generating them per request on the fly.
seems a bit silly, I know, but in this case, the company I am working
for, values a high google ranking *MUCH* more importantly than the
easy of dynamic asp page maintenance. Since the database Im working
with changes quite slowly over time, Im thinking that :

a.  I need the volume of pages for a better overall google PR.
b.  I can then tweak individual pages to many different keyword
phrases for the search engines.

how are you planning to handle the google indexing aspect?


Re: PR effect from .net viewstate info

Quoted text here. Click to load it

Here is what I have done in that regard, it was recent so I am not sure of
the results yet. I have put hrefs on my pages to pages without dynamic links
and  I am using httpcontext.current.rewritepath in my global file to take an
incoming request and rewrite it. For example, instead of
/mypage.aspx?_var1=10 I can have mypage10.aspx or better yet
my-foo-products-page.aspx. Then use the rewrite to direct the page to
mypage.aspx?_var=10. It comes in extremely handy and enables you to call
pages virually anything you want. You need put the rewrite in the
Application_BeginRequest event. Another method I have seen is creating
directories like /mypage/myproduct10 and then you put a default page in that
directory and use redirect or server transfer to mypage.aspx?_var=10 but I
have not tried that yet. The first method works well for me.

Hope this helps. I am not positive it helps in the search results yet as I
have recently made the changes. I noticed the SE have spidered the pages, I
need to give it a month or so to see the results.


Site Timeline