20 tips para mejorar el rendimiento de aplicaciones ASP.NET

Me tomé la libertad de hacer una traducción libre (con algunos comentarios míos agregados) de "20 Tips to Improve ASP.net Application Performance":

1. Deshabilitar el estado de sesión: Si no se usa, entonces es mejor desactivarlo puesto que aparte de consumir recursos del servidor, generalmente también lo hace en el tráfico HTTP entre servidor y cliente al propagar el ID de la sesión. Esta opción se puede desactivar a nivel de la aplicación (elemento sessionState del web.config) o para páginas individuales (propiedad EnableSessionState).
2. Activa el buffer de la página: Para reducir la comunicación entre cliente y servidor es mejor enviar los contenidos en bloque.
   

   When you run your ASP.NET application by using the ASP.NET process model, it is even more important to have buffering enabled. The ASP.NET worker process first sends responses to IIS in the form of response buffers. After the ISAPI filter is running, IIS receives the response buffers. These response buffers are 31 KB in size., After IIS receives the response buffers, it then sends that actual response back to the client. With buffering disabled, instead of using the entire 31-KB buffer, ASP.NET can only send a few characters to the buffer. This causes extra CPU processing in both ASP.NET as well as in IIS. This may also cause memory consumption in the IIS process to increase dramatically.

3. Evitar la validación en el lado del servidor: En el artículo original el autor recomienda realizar la validación sólo en el cliente (javascript), pero en mi opinión, esto es un error, puesto que depender solamente de javascript para este tipo de cosas es como no hacer nada.
4. Usar el control Repeater y evitar en lo posible el uso de los controles DataList, DataGrid y DataView: Los últimos no son recomendados porque generan mucho código HTML, pero en ASP.NET 2 esto se puede solventar usando los Control Adapters o usando otra forma para desarrollar aplicaciones ASP.NET.
5. Usar HttpResponse.IsClientConnected: Verficar si el cliente todavía sigue conectado antes de realizar operaciones costosas.
   

   Consider using the HttpResponse.IsClientConnected property to verify if the client is still connected before processing a request and performing expensive server-side operations. However, this call may need to go out of process on IIS 5.0 and can be very expensive. If you use it, measure whether it actually benefits your scenario.

6. Usar HTTPServerUtility.Transfer en lugar de Response.Redirect: El último envía las cabeceras necesarias (Location) al cliente y éste hace una nueva petición al servidor Web en base a esa cabecera.
7. Usar siempre Page.IsValid cuando se trabaja con los controles de validación: Esto principalmente se debe a lo que comentaba en el punto 3, la única forma de asegurar que los datos cumplen con las reglas de validación definidas en esos controles -- de validación --, es verificando el valor de esa propiedad.
8. Desplegar las aplicaciones en modo Release: Esto es para que se hagan las optimizaciones necesarias al momento de compilar la página y/o aplicación, además de otros
   Leer el siguiente importantes aspectos.
9. Deshabilitar el seguimiento de página: No hay ninguna razón válida para que esta característica esté habilitada en una aplicación en producción.
10. Page.IsPostBack es tu amigo: Hay acciones/código que puede evitarse cuando el cliente realiza una petición (envía la página a través del método POST).
11. Minimizar el número de excepciones: En una aplicación y escenario ideal no habrá este tipo de problemas, pero como nosotros siempre nos equivocamos por el mismo hecho de ser humanos, tenemos que tomar medidas necesarias para reducir al mínimo posible el número de excepciones que genera una aplicación. Una lectura recomendada al respecto.
12. Usar la cache: Poner en cache aquellos datos que no cambian mucho. Por otro lado, usar el cache de salida para páginas o partes de páginas que no cambian frecuentemente.
13. Usar/crear cache por petición: Usar HttpContext.Items para mantener los datos que se necesitan en las diferentes etapas del proceso que sigue una página ASP.NET antes de llegar al cliente.
14. Usar StringBuilder para operaciones intensivas con cadenas.
15. Deshabilitar el ViewState: Toda la "magia" de los controles de servidor de ASP.NET dependen de esta característica: los datos se serializan en campos ocultos que se envían/reciben en cada petición. Así que si alguien quiere "venderles" ASP.NET con la idea de que hacer aplicaciones de escritorio es igual que hacer aplicaciones Web, ya saben cuáles son los inconvenientes.
16. Usar paginación: Sólo recuperar los datos necesarios para la página que se visualiza, de preferencia esto se debe realizar desde la base de datos.
17. Usar App_offline.htm para actualizar las aplicaciones.
18. Usar ControlState en lugar del ViewState para los controles: En el artículo original se recomienda el uso del control de estado, pero hasta donde sé, da lo mismo usar uno u otro, porque el control de estado también tiene los mismos inconvenientes que el ViewState con la única diferencia que éste no puede deshabilitarse.
19. Usar el bloque finally para asegurarse que todos los recursos son liberados adecuadamente, aunque también se puede usar la instrucción using para este caso.
20. Usar Option Strict y Option Explicit, supongo que alguno que desarrolle en VB.NET puede justificar esta parte.

Si alguien está interesado en leer información más útil y específica para mejorar el rendimiento de las aplicaciones ASP.NET, puede darle una mirada a Improving ASP.NET Performance y Scalable Apps with Asynchronous Programming in ASP.NET.