Whether you're coding in ASP or straight HTML, you want your page to display to your users as quickly as possible. If your page displays slowly, your users might give up and go elsewhere.
First, remember that when a person asks to view one of your webpages, you are literally sending that physical file from your server to your visitor's home machine. That is how they see the page - they get a copy on their machine and their browser parses and displays that file. So the larger your file, the longer it will take for them to receive and display the information. So you want to make that file as physically small as possible.
That means you STRIP OUT YOUR COMMENTS. Yes, comments are great for working with your code, in your test environment. But you don't want comments on your live server! Every single line of comment you add is another line of unnecessary garbage that is taking up time as the file is sent down to your visitors. You want that live, production file to be as small as possible, so the transfer of the file goes as quickly as it can.
The same goes for tons of extra white space, tabs, etc. Each of those characters takes up physical space in the file. You want your file to be as efficient as it can be in a live environment.
Next, take a good look at your table structure. A lot of people go insane with tables, building trillions of nested tables. Every time you create a table, the web browser has to wait until it reaches the end of the table before it can figure out how to display that table properly. Let's say you have a giant page with a series of tables. If you put all of those tables into one "master table" - then the entire table set has to be fully read and loaded before any of it displays! If instead you have each table as a separate entity, the system can show each table as it is complete. Sure, the page will draw in one table, then the next, then the next, in progression. But at least the user sees SOMETHING to know that the page is loading - instead of seeing nothing at all until the very end.
Make sure you use as few graphics as possible, and that each graphic is run through an optimization utility to make the file itself as small as possible. Again, the user has to load down every single graphic file to their home system before they can see it. The more graphics you force them to load, the slower the page will be.
Of course, it goes without saying to have the fastest server you can afford, on a nice, large pipe. If you write incredibly efficient pages, and then your server is dog-slow, you are going to lose visitors. If nobody visits your site because it is too slow, then all the work you have done has gone to waste.
It's worth it to test out your pages on a dial-up connection. Just because you have a cable or high speed connection, you need to remember that many of your visitors do not. There are several utilities on the web that can tell you how slowly your pages will load on dial-up. Flash and cute programming are nice - but if they mean your site is not used by 50% of the web populations, they are harming you.
Coding for Fast Database Connections