How DNN Page Output Caching Works

how tdnn page output caching works

How DNN Page Output Caching Works

DNNCorp_logo_lrgCaching is a critical feature for DNN  performance and ability to scale. In fact page output caching was one of DNN Professionals signature features when it was released.

Documentation on what caching means as a whole to DNN is currently left to the depths of the code. So let me shed a little light on how caching and more specifically Page Output Caching work in DNN.

Caching is broken up into 3 sections in DNN

  1. Page Caching
  2. Core Caching
  3. Module Caching

1. Page Output Caching

Page output caching is the idea of delivering the entire html payload from cache instead of rendering the page and requesting data from the SQL server or from individual module cache locations.

Because this function happens so early in the http request pipeline it will speed up the performance of your site by a huge degree and something that I think every site needs. Page output caching will also remove viewstate from the page completely reducing the payload.

All of the settings for Page Output Caching are found in page settings under advanced > cache settings.

Knowing generally how page output caching works I think it’s worth discussing what it can’t do in order to better illustrate the situations you may run into.

  • Like module caching this feature will not operate when a user is authenticated.
  • Only works for GET requests and not POST requests
  • Search engines do not get cached pages.
  • Pages are cached by TabId and up to  250 variations will be cached based on querystring differences.
  • You must explicitly enable page output caching on every page by setting it’s duration.
  • In page settings you can set a querystring modifier to either enable or disable page output caching. But this setting only works on a page by page basis with no way of having a host or portal level setting.

2. Core Caching

The core framework of DNN uses memory to store many of the primary subsystems and there is no way to change this storage location. (Not that you would want too)

  • Host & Portal Settings
  • Pages
    • Hierarchy
    • Page Settings
    • Modules on Page
  • Modules
    • Module Definitions
    • Module Settings
  • Users
  • Roles
  • Files Management
  • … and more …

So be aware that the larger your site becomes the more memory it will consume in order to operate.

3. Module Caching

Module caching default settings is found on the Host Settings > Advanced Settings > Performance Settings. These settings include:

  1. Page State Persistence
  2. Module Cache Provider
  3. Page Output Cache Provider
  4. Cache Setting
  5. Authenticated Cacheability

Module caching has been part of the framework for a while and is one of the better documented sections. There are a few details that are omitted from that article.

Unless your server is starved for memory I would recommend setting these all too: Page*, Memory, Heavy, ServerNoCache respectively.

An important limitation to understand is that none* of the settings effect authenticated users. So not just admin users but regular registered users as well.

*Page State Persistence is more of a core function but it’s worth detailing how it effects modules. This setting will GREATLY reduce the html sent down the pipe for each page. However by removing the View State from the page and keeping it in memory it will cause issues with AJAX functions where the code uses view state in order to keep track of paging or some other arbitrary variable. It will run for authenticated and anonymous users alike. But if you don’t use modules like that then I would experiment with enabling this feature.

Antonio Chagoury

Hi, I'm Antonio, Founder and CEO of Maxiom Technology (formerly Inspector IT).I'm a technology executive and entrepreneur who has achieved consistent success in driving growth, generating revenue, and enhancing value in domestic and international markets through technology product innovations.

  • Posted at 1:20 am, January 2, 2014

    Thanks for sharing this information Jonathan, caching is grey area when it comes to documentation and this article is awesome. It should go right on the wiki.

    A couple questions for you:

    1) Regarding Output Caching, you write, “Search Engines do not get cached pages.”

    Why is this? One of the factors search engines use to rank your website is speed, and in my experience, output caching improves page speed by 5x. Is there anyway to override this setting? Where is it in the source, I’d be happy to make a pull request.

    2) Sometimes I see a red box around the module caching settings that says “Inherited.” Any idea where this comes from?

    Lastly, I posted a couple questions for you on GitHub. I love the File Watching and Log Watching modules and want to contribute. File Watcher especially.

    Keep up the blogging, the Dnn community needs more good bloggers, the community seems to be quieter than before.

  • Posted at 7:53 pm, January 2, 2014


    1) Good question. My thought is that they wanted to make sure search engines always got the latest and greatest versions when doing their indexing. However I’ve found that many times search engines themselves can crush your site like a DDoS and should be getting cached pages. Unfortunately page output caching is in the closed source.

    2) That comes from the web.config setting for the default location for page output cache. Normally it’ll show inherited unless explicitly modified it on that page.

    Thank you for your feedback. I’ll check out the requests on Github.

  • Posted at 10:19 pm, December 31, 2014

    Nice information. Thanks for clearing this up for me.

    Sidebar : I’ve read elsewhere that enabling token replacement in the HTML module stops the module caching. How is this handled by the DNN ‘page’ caching – or using the iis dynamic caching?

    How about caching for the DNN Reports module?