Hi Sean,
Are you asking for general advice in ASP.NET development of your own code or are you saying you are having performance problems with mojoPortal?
If using mojoPortal are you also using your own custom features?
Are you perceiving the slowness on a dev machine or a production machine. If your site is hosted on a shared hosting environment with a lot of other sites it could be starved for resources and its performance can be affected by other sites running on the machine.
In oder to optimize performance you have to be able to measure it, I use the MS ACT (Application Center Test) load tester that shipped with VS 2003 Enterprise Architect version. I mean if the page is loading extremely slow and you percieve there must be a problem in the code, it is possible to resolve it without load testing but once you get to the point where it runs reasonably well and you are just trying to increase performance you really need a load tester so you can measure before and after each change and make sure requests per second on the same test are going up not down as a result of the change.
To find slow running code that is a candidate for optimization I use RedGate Ants profiler. It can show you how often various sections of code are executed as well as how long they take so it helps in tracking down place where you can optimize and get the most improvement for your effort.
There are a number of common development mistakes to avoid which can cause drastic performance problems.
1. Too many database hits in serving a request. The more features on a page the more likely its making more db hits. Make approriate use of caching and don't look things up uneccesarily. If you do get data from the db and you will need it again during the request put the data in the HttpContext, don't retrieve it over and over every time you need it. Like in mojoportal we need access to the user data in many features and controls but during a request we only look it up once from the db. So the first use of the user data puts it in the HttpContext.Items collection and then any subsequent uses get it from there so we don't hit the db again for the same data in serving the request.
2. Retrieving more data than needed. Don't populate grids with hundreds or thousands of rows. Users can only digest a page at a time and its much more efficient if you retrieve just the needed page of data. Don't be tempted to brign back all the data in a DataSet then use the grid to page through it.
3. Forgetting to close DataReaders or connections after use. Very common mistake that can kill performance.
4. Don't make additional data lookups in the databinding events of a grid, I see this fairly often. The data for the grid needs some extra value not in the main data so on the databind event code loooks it up. So for every row in the grid it makes another db hit. Avoid this type of thing and fix the underlying data to bring back everything you need all at once.
3. Use of large graphic files - I've seen people upload images right out of the camera and put them on the page, they see its too big so they set a width and height that makes it look smaller but the images is still a 1MB (or more) payload which makes the page slow. In general be aware of the total payload size of a page with all its images and html. Kepp it small as possibole for best performance.
4. When building for production deployment make sure you Rebuild in Release mode and don't deploy it built in debug mode. Also make sure in Web.config <compilation debug="false".... if its true it loads debug symbols and makes it slower.
I'm sure there are more but those are the ones that pop into my head immediately.
Hope it helps,
Joe