I was enjoying some success with my website, ranqit.com when, after a spike in traffic on the 4th of July, I noticed a substantial decrease in traffic shown in this graph:

I wondered if there was a lack of interest in the site. Was there a new competitor? Had Google stopped sending me search traffic?

A quick search on Google’s Webmaster Tools showed that search traffic was consistent throughout the slump, so I ruled out lower clicks. Bounce rate was consistent, there were just fewer visits. What was up?

One thing I noticed was that my site was taking considerably longer to load each page. Using a webpage speed test analysis tool (free), I was able to determine that it took over 20 seconds to load each page and most of that time was the .Net engine hitting the database and building the page (what they call “Time to first byte”) so the user doesn’t even see anything on their browser. This was clearly unacceptable, so I looked for a solution.

What I came up with was page caching or the ASP tag OutputCache. This setting stores the output from the .Net engine for the page in a cache so that it doesn’t have to recreate the page every time a user views it. This is fine because, while the site is dynamic and user-driven, most of the pageviews are from people just looking to view content, not change content.

But Ranqit uses one URL for many different content pages with a query string. I was able to get around this by utilizing the “VaryByParam” parameter in the code so that the engine considers every page with a unique set of parameters a different page. So that:

http://ranqit.com/Ranqings/Default.aspx?currentRanqing=logos

and

http://ranqit.com/Ranqings/Default.aspx?currentRanqing=facebook status messages

are cached separately.

Here’s the code (placed above the ASP:Content tag:

<%@ OutputCache Duration=”165000″ VaryByParam=”*” Location=”Server” %>

But I still wanted the page to refresh every time a user did change something, so I forced refresh of the page using:

string cachedURL = “/Ranqings/Default.aspx”;
HttpResponse.RemoveOutputCacheItem(cachedURL);

The result is a perfectly functioning site without an obnoxious wait time. Revisiting the analysis tool showed that the “Time before first byte” was cut to nearly zero after this implementation. Woo hoo! And, traffic resumed, showing a marked increase after implementation (early August):