Please note, first byte time can be a tricky item to measure due to latency  - The latency includes network latency (the time taken for the request and response to travel over the network) and server latency (the time taken for the server to process the request.), so if you are using a test tool that is a different location that suffers from latency this can be thrown off e.g. using a US based test tool on a website hosting in Australia latency will often be terrible (roundtrip latency can be a few hundred miliseconds per resource, when you add up the resources on a page this is substantial)

However, assuming you tested from the same site and using the same tool, your problem is that your 6.1.5 instance is not running correctly - if it's taking 1 minute to deliver a page something is badly wrong (even if it's taking 1 minute after an app recycle, unless you're running a huge site with many modules/users/portals that is too long). In general 6.x performance is comparable to 5.x performance (in some cases, particularly if using the resouce management capabilities it is much faster - see http://www.dotnetnuke.com/Resources/B... ), so it suggests something is wrong with you 6.1.5 instance & any performance tweaks now would be somewhat redundant as you need to find the reason why the page load is dramatically slower

First of all I would use the advice on this page to check various logs to see if you can get any insight - http://www.dotnetnuke.com/Resources/W...

Next, if you dont get any useful information it's important to look at the datbase using sql profiler as the majority of "slow" sites have a database issue, either a very slow running query or some deadlocking issues (see various wiki articles at http://www.dotnetnuke.com/Resources/W... for some advice)

Note: once you find and solve the slow page load problem, http://www.dotnetnuke.com/Resources/W... has some suggestions to further optimise performance.

viewstate is a part of every asp.net webforms page and does not exist as a seperate routable entry. It is also a hidden field, so search engine spiders such as google will automatically ignore it i.e. indexing only happens on content visible to users. If you are seeing 404 errors it means a page cannot be found, so no viewstate will be seen - if there is a problem executing a page it will have an exception such as a 500 and the search engine will try to index it.

Sometimes you can get issues where search engines try to pretend to be a user and do postbacks to further index content - this can cause viewstate exceptions but generally isnt something to worry about (google only recently started to do this). However if you are seeing many then you may want to block the requests via a robots.txt file e.g. take a look at dotnetnuke.com/robots.txt and you'll see we dont allow spidering of content directly - the search engine must index based on the page results being returned via the virtualised default.aspx i.e. how the users see the site.