Wikis get slow as content grows. Pages render slower; searches lag; admin operations time out. Most wikis hit performance limits before they hit content limits.
This page covers where wikis get slow and the patterns for fixing it.
Wiki markup → HTML conversion. For complex pages with macros, plugins, transclusions, this can be slow.
Indexing many pages; querying with complex filters. Search performance often the most-visible bottleneck.
Page reads, writes, history queries. Standard database concerns. See DatabasePerformanceMonitoringHub.
Pages with thousands of lines, hundreds of links, embedded content. Each render is expensive.
Each plugin adds overhead. Plugin-heavy wikis are slower than minimalist ones.
Page lists, sidebars showing recent changes, categorical views. As page count grows, these get slow.
Rendered HTML cached. Re-rendering only when source changes.
For most wikis, this is essential. Without it, every page view re-renders.
Parts of a page (sidebar, navigation, transclusions) cached separately. Updates to one part don't invalidate the whole.
Common queries cached. Avoid hitting the database for every page navigation.
For mostly-read public wikis, CDN caches rendered pages. Massive performance win.
For internal wikis, CDN may not apply.
When does cached content become stale? Page edited; plugin reconfigured; user permissions changed.
Cache invalidation strategies:
For wikis, event-based is usually right — cache until something changes.
For long pages, load only the visible portion initially. Load more as user scrolls.
For wiki sidebars: load related content on demand.
Page lists, search results: paginated. Don't return 10,000 items.
Plugins that don't need to render synchronously: defer. Load page; load plugin output asynchronously.
For very expensive operations, render in background. Show "rendering..." until done.
Missing indexes on commonly-queried fields slow everything. Profile slow queries; add indexes.
Database connections expensive. Pool them. See DatabaseConnectionSecurity.
Search is often the slowest piece.
Index pages incrementally. Don't rebuild from scratch on each change.
Indexes get large. Plan for it.
Common queries optimized. Filters that match many pages need indexes.
For large wikis, dedicated search (Elasticsearch, Solr) outperforms database-backed search dramatically.
See ElasticsearchFundamentals and WikiSearchOptimization.
Pages with thousands of lines render slowly. Consider:
Pages including content from many other pages. Each transclusion adds rendering time.
A page using 20 plugins. Each plugin runs on render. Combined, very slow.
Audit plugin usage. Remove unused; combine where possible.
Page A links to B which links back to A. Plugins that follow links can recurse.
Limit recursion depth.
How many pages can the wiki handle before performance degrades?
For most wikis: a few thousand pages is fine. Tens of thousands need work. Hundreds of thousands need real engineering.
Reads scale well; writes scale less. Many concurrent edits compete for locks.
For most internal wikis, concurrent-user count is limited; this isn't an issue.
More plugins = more risk. Audit; remove dead.
Page render times; search times; database query times. Monitor.
Database slow-query log. Find slow operations; optimize.
For specific slow pages, profile to find the bottleneck.
Performance degrades over time. Periodic review catches drift.
For most wikis: