Fragment caching

HTML and CSS XSLT JavaScript Images Soft Etc

There is no need to cache the whole page—you can store just a part of it. That could be the part that requires the highest server load, or the section that is known to change rarely. It is possible to cache more than one section.

Technical
digression

Caching a regular Microsoft ASP.NET page is easy—you only need to have directory @OutputCache with several properties that allow making different cache versions. However, any ASP.NET page may include individual usercontrols, or server controls. The usual example is authorization form (before ASP.NET 2.0, programmers had to write their own scripts for it). Such elements are actually ASP.NET pages with equal capabilities for caching.

For example, a programmer creates a page with two server controls—an entrance form and a news list—and caches the news section until the next items appear. In this case, the page viewed by users is several pieces put together.

Also see Caching Portions of an ASP.NET Page at MSDN.

Real life example
Here the first page of Russian Acronym Vocabulary. It has several sections that are not static.

Blocks 1 and 4 display random words from the vocabulary. The section provides a different set each time the page is reloaded (words change independently of each other).

Other two sections concern the current data base. Block 2 shows the number of words already in the vocabulary and the number of words submitted by users, still waiting to be verified and added by the site editors. Block 3, the largest one, displays the latest added acronyms and their meanings.

What’s left is plain—Block 5 counts the number of visits to the site, and the rest of the page is static (just except copyright date).

Only two of the five mentioned blocks require data updates. And only they need to connect to the data base. We know that these sections do not have to be reloaded as often as the page itself will be requested by users. So, instead of making SQL requests every time, the server caches the result and saves it into a file:

<list>
    <item>
        <sokr>NPV</sokr>
        <value>no par value</value>
        <comment>stock exchange<br />
        for example: NPV stock price</comment>
    </item>
    . . .
    <item>
        <sokr>OLPC</sokr>
        <value>One Laptop Per Child</value>
        <site href="http://laptop.org/"/>
    </item>
</list>

As soon as the moderator adds new abbreviations to the vocabulary, this cached list can be reloaded. But it doesn’t have to, until the next request for the page.

Maybe not?

In some situations caching is unnecessary, even if it feels the opposite. For instance, with XSLT-produced HTML you would want to compile an XSLT file and cache it for good. But if you take a look at libxslt library, you’ll see that it is extremely difficult to create the library suitable for repeated usage, and parsing the script just another time is much easier.

See related discussions from xslt@gnome.org archive:

Libxslt: xsl:include/import cache? — 4 December 2001

Deep-copy of xsltStylesheetPtr? — 18 September 2004

Most importantly, cache has to make sense to users. Nevertheless, it shouldn’t keep any “secrets” from those who fill it with information either. This means that cache must be completely automated—it has to update when information becomes outdated (the cache itself is responsible for determining when) and there must be no ‘Clear Cache’ buttons in the admin interface.

Order a design...

Fragment caching 23 November 2005