Speeding up your wiki

Pages on OborWiki load pretty fast, but it’s possible to speed things up even more.¹

All four of the options below are things that I have to enable, via a server-side config file. Wiki owners can’t alter these settings themselves—yet.² So if you want any of these things configured for your wiki, let me know.

The HTML cache

If the HTML cache is enabled, PmWiki caches the rendered HTML that is output by the markup processing engine. (But only the HTML output of the page itself, not any headers, footers, sidebars, etc.) This has two caveats.

1. There are severe restrictions on what sorts of pages are eligible for caching (to pick just one example, any page with a (:title: directive on it cannot be cached, nor can any page that has includes or pagelists on it; on most wikis, this excludes many pages).
2. If any part of a page’s content is generated dynamically (server-side) on the basis of other wiki pages (e.g., via pagelists), the cached HTML is not automatically re-rendered and re-cached when these other pages are changed; caching only takes place when a page is saved.

Together, these two caveats make the HTML cache simultaneously very limiting, and largely irrelevant, on most wikis. Nonetheless, enabling it can result in a significant speedup in load times on some wikis; if its limitation doesn’t apply, then it can be a boon.

Added 2017-12-14: The HTML cache can also cause problems with stylesheets attached via the StylePage recipe (the stylesheets will often fail to load), and thus prevent the use of webfonts on your wiki.

IMS caching

If If-Modified-Since caching is enabled, a browser can cache wikipages. (Note that this is different from the HTML cache or FastCache, both of which are server-side caching solutions that save PmWiki from having to re-render a page from PmWiki source into HTML; in contrast, IMS is client-side caching, which saves a client from having to retrieve the page from the server.)

IMS caching is not the same as “unconditional” client-side caching for a duration specified when a remote asset (such as an image) is first retrieved; it still involves a round-trip from client to server and back. Nonetheless, if the page has not been modified since the client last retrieved it, it saves both the time it would have required PmWiki to render the page, and the time it would have required to download the page. (The former is usually greater than the latter, for clients on First-World broadband networks—and on slow networks with low bandwidth, latency is usually also poor, which is no less a problem with IMS caching enabled as without it.)

IMS caching has a drawback similar to the HTML cache: if some part of a page is built up from other pages (or parts of other pages), and those other pages get modified, the page itself is not considered to be modified and so the client will not re-retrieve it. (A common case of this involves making modifications to the sidebar, to Site.PageActions, etc.) But if such “structural” modifications are made only rarely, IMS caching can be a significant speedup with little drawback. (Unlike the HTML cache, IMS cachine applies to all of a wiki’s pages.)

(Added 2017-12-13) Similarly, if the content of your page is dependent on server-side code which is then modified (e.g., if some config file settings are changed), this will not cause the page to be considered “modified” and clients will still see the old version. (This limitation applies to the HTML cache as well.)

Disabling PageListProtect

When the PageListProtect option (enabled by default across all of OborWiki) is active, then users who don’t have read access to a page also do not see that page in pagelists (including search results). (If PageListProtect is disabled, users may be able to see the existence of inaccessible-to-them pages; note that this in no way allows users to actually view pages that they lack read access to.)

Despite being good security practice, PageListProtect significantly slows down construction of pagelists (as each page’s permissions must be checked when a pagelist is constructed). For wikis with no “secret” pages (pages whose existence, and not merely their content, is meant to be hidden from those who haven’t been granted read access), disabling PageListProtect is a costless performance boost, speeding up the generation of any page that contains at least one pagelist.

FastCache

FastCache is a PmWiki addon, available on OborWiki³, that essentially allows a wiki to enjoy the performance of a totally static site, while still being as editable as ever.

FastCache is a more powerful and capable version of the HTML cache, freed of the HTML cache’s first limitation—any page is eligible for FastCache. The entire, final, HTML output of a page is cached, and serving pages from that cache is done by the webserver⁴, bypassing PmWiki and PHP entirely. (If you want to see an example of how a PmWiki-based site with FastCache enabled performs, check out https://www.readthesequences.com.)

When a page is edited, the cached version is invalidated; the next time that page is requested by any client, the rendered output is cached anew, and any subsequent requests are served from the cache again. Of course, this has the same drawback as the HTML cache: what if a page is partially constructed from the content of other pages, and those pages get updated? FastCache’s solution to this problem is an optional feature that invalidates all the pages in the cache when any page is edited—a bit of a nuclear option, but certainly a reliable one.

In the default configuration of FastCache, pages are served only to non-logged-in visitors, and only in response to GET (not POST) requests, that contain no GET parameters. (These settings may be changed, but strange behavior—of an obvious or not-so-obvious sort—may result.)

FastCache is of little use for wikis that get edited often, especially if such a wiki’s pages are substantially interdependent (via transclusion, pagelists, etc.). However, for wikis that consist largely of static content, which is edited rarely, FastCache can provide a tremendous reduction in page load times.