Field experience proves - the earlier performance is tackled in development lifecycle the better results achieved. Below are most frequent practices that were most helpful in my engagement with the customers.
Architecture/Design phase
- Set performance scope using Performance Frame
- Set performance objectives - Performance Testing Objectives Document Template
- Generate and distribute performance engineering principles document to the dev team (this sample was generated using Guidance Explorer)
- Conduct performance design inspection (this sample document was generated using Guidance Explorer)
Coding phase
- Conduct static code analysis for performance issues - Performance Code Review Tool – Practices Checker
- Conduct manual performance code inspection using checklist document (this sample was generated using Guidance Explorer)
- Analyze program's flow early in development - Use Sysinternals DebugView To Diagnose The Application
Unit testing phase
- Conduct performance smoke test for your application - Stress Test ASP.NET Web Application With Free WCAT Tool
- Analyze IIS behavior - Identify ASP.NET, Web Services, And WCF Performance Issues By Examining IIS Logs
- Analyze Database behavior using SQL Server profiler - How To: Use SQL Profiler and Using SQL Server Profiler
- Analyze Client Side JavaScript behavior - Profiling JavaScript With Ajax View Tool: Spot Poor Performance Client Script In No Time
- Analyze ASP.NET behavior - Use Performance Counters Templates To Streamline Performance Analysis
- Analyze HTTP traffic from end user's angle - Improve Web Application Performance By Reducing Number Of Http Requests - Fiddler To The Rescue
Performance Sins (performance anti-patterns)
- Performance Sin - Chatty Database Access And Loops (Plus Another Free Performance Tool)
- Performance Sin - Using Exceptions To Control Flow
- ASP.NET Performance Sin - Serving Images Dynamically (Or Another Reason To Love Fiddler)