ASP.NET ViewState Abuse
Wednesday, October 23, 2013
I was recently asked to look into a public-facing web page that loaded in a couple of seconds, but took over 15 seconds to submit a form on the page. What I found was yet another disastrous result from an ASP.NET Web Forms developer who didn’t take the time to understand how the framework operates.
The first thing I did was view the source, and I was greeted by this…
“That’s a big view state,” I thought. Then I scrolled… and I scrolled… and I found out what I was up against. It was scary. Here it is zoomed out (yep, that’s text!)… and this isn’t even a quarter of it…
After inspecting the traffic, it turns out the entire page is over 2MB in size. And a postback was sending 1MB of data to the server and then downloading another 2MB!
But why did it take much longer to post the form than it did to load the original page? It’s because most of us use internet connections that provide a much higher downstream bandwidth than upstream. In my part of the world, the typical residential download speed is 10mbps while the typical upload speed is 512kbps. Doing some quick math, it takes a second or two to download a 2MB page; while a 1MB postback to the server takes… 15 seconds!
A bloated view state is probably the most common problem in poorly performing Web Forms pages. It’s common because Web Forms makes it easy for developers to create web applications without knowing anything about web development. But the framework itself is a leaky abstraction that, in the end, requires developers to have intimate knowledge of its inner workings. It also requires intimate knowledge of the one thing it’s trying to hide from its developers… the web itself.
I was recently asked to look into a public-facing web page that loaded in a couple of seconds, but took over 15 seconds to submit a form on the page. What I found was yet another disastrous result from an ASP.NET Web Forms developer who didn’t take the time to understand how the framework operates.
The first thing I did was view the source, and I was greeted by this…
“That’s a big view state,” I thought. Then I scrolled… and I scrolled… and I found out what I was up against. It was scary. Here it is zoomed out (yep, that’s text!)… and this isn’t even a quarter of it…
After inspecting the traffic, it turns out the entire page is over 2MB in size. And a postback was sending 1MB of data to the server and then downloading another 2MB!
But why did it take much longer to post the form than it did to load the original page? It’s because most of us use internet connections that provide a much higher downstream bandwidth than upstream. In my part of the world, the typical residential download speed is 10mbps while the typical upload speed is 512kbps. Doing some quick math, it takes a second or two to download a 2MB page; while a 1MB postback to the server takes… 15 seconds!
A bloated view state is probably the most common problem in poorly performing Web Forms pages. It’s common because Web Forms makes it easy for developers to create web applications without knowing anything about web development. But the framework itself is a leaky abstraction that, in the end, requires developers to have intimate knowledge of its inner workings. It also requires intimate knowledge of the one thing it’s trying to hide from its developers… the web itself.