Quantcast
Channel: Foliotek Development Blog » Performance Category Posts
Viewing all articles
Browse latest Browse all 6

Improving Site Performance by Avoiding Unnecessary Postbacks

0
0

Today I was once again reminded at how an unnecessary postback can hurt your site’s performance quite significantly. The main purpose of the postback is to send the page you’re viewing back to the server. If you’ve entered anything on the page, that’s quite important, because otherwise the server will never know what you changed. However, when the purpose is merely to navigate somewhere else, the postback is probably unnecessary.

In the case I ran across today, there were four tabs on a page. Two of the tabs happened to have quite a bit of information on them, making the page size pretty big. The other two tabs were very small. What I noticed is that clicking between tabs sometimes took a really long time, but it didn’t matter which tab I was clicking on, but on which tab I was coming from. That’s what demonstrated the issue.

The Problem

The tabs were postbacks rather than simple redirects to new pages. However, the code behind was issuing a redirect and changing one query string variable. I also noticed that if I came from a tab with a lot of content and navigated to a tab with very little content, it would take awhile, but when I refreshed the page, it didn’t take long at all.

So, why did the postback take so long?  In this case, there was a lot on content, but probably a pretty large viewstate as well.  It’s also good to eliminate unnecessary viewstates on controls when the page can get pretty big.  Most of the time it’s not a big deal, but it definitely was in this case.

Now, here at work, I have very fast upload and download speeds, but the typical user has far slower speeds, so I needed to program for them. Download is usually much faster the uploads as well, so the postback that uploaded the large page back to the server was the problem.

The Resolution

I rewrote the tabs to avoid the postback entirely and just redirect to the url that the code behind was building anyway. This saved a ton of time and really improved the performance on the page. (For C#, this basically mean using HTML Anchor (“a”) tags or ASP HyperLinks rather than ASP LinkButtons)

The result was a click that was taking 40-50 seconds started taking 3-7 seconds.  Yeah, it’s still long, but this was on my development machine and the pages were large, so production will see a much better improvement.

Conclusion

So, if there’s a chance the page could be pretty large, it’s worth investigating the possibility of converting navigation elements from linkbuttons and anything else that cause postbacks to strict a tags.


Viewing all articles
Browse latest Browse all 6

Latest Images

Trending Articles





Latest Images