I have a number data-driven web based applications that serve both internal and public users and would like to gauge how fast you would expect a page to be created (in milliseconds) in order to maintain user satisfaction and scalability.
So, how fast does a page have be created to maintain a fast site?
The sites are developed in ASP classic, with a SQL Server backend generating XML recordsets that I render using XSLT. Not the most efficient technique and pages take between 7ms to 120ms to create (i.e. Timer interval between first line of code and the 'Response.Write') depending on the complexity of the page. Slower pages are due to the database running bigger and more complex queries. Even if I re-wrote all the ASP classic to ASP.NET there will not be any significant improvement to the overall page render speed.
I've often heard Jeff say he wants SO to be the fastest site, and his blogs have discussed optimisation of his code and database but how far do you have to go in optimising your the code? Is shaving off milliseconds by using StringBuffer instead of String + String a good use of my time?
[Clarification]
At what point do you start to think "This page is taking too long to create?". Is it over 20ms, over 200ms or is it OK for a page to take over a second to build? What are your "target times?"
This depends entirely on your audience and targets - I've worked on apps with a target 'onload' event at <4secs, and on apps where the time on server is expected to be <1ms. It can go either way - but whatever you do you need to be aware that whatever performance optimisations you do at the server-side level are likely to be dwarfed by both network performance, still the major bottleneck with the web, and perceptive load times.
Yahoo has some excellent guidelines for general website performance, especially on the perceptive load area.
Hopefully you're already smart enough to be caching what you can and doing the little things like avoiding massive chains of Response.Writes...