Why might an ASP.Net website load slowly? [closed]

Question

Anecdotally, I've visited many .aspx website that require a significant amount of load time for each page.

Is my experience unique?

If not, why might an ASP.Net website load slowly?

Edit: It's now about 7 years later (12/29/2017). The good news is I don't see this problem much anymore, maybe because Google started penalizing sites that load too slowly. I now use ASP.NET MVC with good results, currently running on Vultr private virtual servers (Azure was way too slow when we tried it.) Some of the worst offenders I see now are the CMS systems like Wordpress and Drupal, probably running on hardware that's too slow or underspecced for the amount of traffic the site gets. -HK1

Answer 1

Five possibilities I can think of (aside from some advanced caching techniques and such):

• Improper sizing of the web server for ASP.NET (i.e. thought a server sized for classic ASP would be fine)

• Forgetting to remove <compilation debug="true"/> from the web.config and getting less than optimal code.

• JIT for the first visit

• Code embedded in the page (as opposed to the compiled code-behind) that requires compilation before and in addition to the JIT.

• ViewState (for ASP.NET WebForms) gets too big.

Answer 2

As apparently this might be answer worthy.

Could be many factors at play. The site you're using this very moment is built on .NET, and it typically is very fast (minus downtimes/maintenance periods).

The developers of those sites you go to might be pushing tons of data to you, or slow connections, or overloaded servers, etc. etc. etc. It could also be perception at play. Also, maybe insane javascript at play and you're running IE? Or flash?

Answer 3

If you don't really know what you are doing, ASP.NET WebForms allows you to create a web application by dropping controls onto a form, even going as far as hiding the stateless nature of http. It works, but that sort of development is never going to produce efficient code, especially if your data access layer involves generated queries selecting everything from a sql express database with no indexes.

There are plenty of fast asp.net websites out there, developed by people who understand how web applications really work. That includes this site - it uses ASP.NET MVC which provides a lot more control over handling of individual requests and doesn't show the .aspx extension.

Answer 4

Just speculation here as I've noticed the same thing. I suspect that .asp sites tend (notice the word tend) to be self hosted on a company's servers, as opposed to hosted at or in data centers. So they're often run on hardware and connections not really designed for high speed web traffic. I suspect cold fusion driven sites also suffer from this.

Answer 5

You are most certainly imagining this. :)

A lot of factors come into play with any software. The architecture, the redundancy of the code flow, the quality of the code, etc. Too many to even begin listing.

Do you want proof that ASP is good for enterprise level usage? This very site (and all of the SE) websites are made using ASP.Net - specifically MVC.

When was the last time this site was slow? I've been here for over a year and never once have I noticed things chugging along despite its massive userbase.

Answer 6

When a website loads (application.start event), it takes time to load everything into memory. Depending on the IIS settings, after about 20-30 minutes of inactivity, it will unload. I've not come across a decent way to keep the application running constantly without having some service doing a GET every 10+ minutes.

A poorly designed backend/datalayer can make anything run slow (no matter how fast the computer running it). Profiling will help you identify where the problems are.

Answer 7

The viewstate can really slow down the postbacks. If you have sever large drop down lists on a page you should not use the view state on them.

The viewstate lets you pretend you're working on a stateful winforms app. That can get you into trouble sometimes.

Answer 8

All of the above are likely true. The biggest single factor affecting the performance in the ASP.NET site that I worked on though was that everything relating to it was old. The .NET framework version, the servers, the database infrastructure, and the code itself were all aging badly.

I suspect many ASP.NET sites tend to be corporate sites. These don't get a lot of love, since they tend to just work. People don't rewrite them until they have to, which is often a very long time down the road.

I know the site that I worked with that used ASP.NET got a huge speedup just by moving to the newest version of the framework, which had much more efficient JITing and sane caching defaults.

The other thing that I've seen that a lot of ASP.NET sites do not know how to scale properly. They don't have proper load balancing set up because designing their site to work correctly with web gardens is not common or well-documented in the community. If you don't design your site for web gardens from the beginning, you can't use the built-in scale-out mechanism that IIS has. Software load balancing with Windows NLB is not very common and is complex to manage. (This harkens back to the fact that ASP.NET tends to be corporate software, and tends to be managed by the company running the site rather than IT professionals who know how to configure this stuff correctly.)

Hardware load balancing with F5s is very very expensive, but seems to be the most common and simple mechanism for scaling out ASP.NET sites within corporate networks. I think among the open source crowd the expectation is that you build in load balancing from the beginning using freely available open source tools that automatically scale out based on usage. This is not common in the ASP.NET world from what I've seen.