MediaWiki was built to serve wikis the size of Wikipedia, but its default configuration on a fresh install is deliberately conservative. Out of the box, every article view triggers a chain of work: PHP parses the raw wikitext, expands templates recursively, resolves parser functions and Lua modules, runs database queries against the page, revision, and text tables, then assembles the final HTML skin. On a small personal wiki this is invisible. Once you accumulate heavily templated articles, category trees, and a few thousand pages, that per-request parsing cost becomes the dominant factor in your Time To First Byte, and visitors start noticing multi-second page loads.

On a managed shared account you cannot touch the server's global PHP or MariaDB configuration, but MediaWiki exposes nearly all of its performance tuning through LocalSettings.php and the caching backends your hosting plan already provides. The work is to identify which layer is slow, then enable the caches that eliminate repeated computation.

Diagnosing where the time goes

Before changing anything, confirm the bottleneck. MediaWiki has a built-in profiler that attributes wall-clock time to parsing, database, and cache operations. Append ?forceprofile=1 to any article URL after enabling debug output, but the safer approach on a live site is to add a temporary block to LocalSettings.php using File Manager (the file lives in your wiki's document root, typically public_html/wiki/LocalSettings.php):

// Temporary: only enable for your own IP
if ( $_SERVER['REMOTE_ADDR'] === 'YOUR.IP.ADDR.ESS' ) {
    $wgDebugToolbar = true;
    $wgShowDebug = true;
}

The debug toolbar prints a breakdown at the foot of the page: total parse time, number of database queries, and how many objects were served from cache versus recomputed. If parse time dominates, your fix is the parser cache and OPcache. If you see hundreds of database queries per page, the object cache and message cache are the targets. Also watch your account's error_log in the wiki root or under ~/logs for repeated warnings about failed cache connections, which silently force MediaWiki back to slow database-backed caching.

A second signal comes from cPanel or DirectAdmin resource usage graphs. CloudLinux enforces per-account CPU and Entry Process (EP) limits. If your wiki hits faults in the LVE stats, page loads are being throttled because uncached parsing is burning CPU. Reducing that CPU cost through caching often resolves what looks like a raw performance ceiling.

OPcache and PHP selector settings

Every MediaWiki request loads a large set of PHP files. Without an opcode cache, PHP recompiles that source on every hit. OPcache stores the compiled bytecode in memory and delivers the single biggest, lowest-effort speedup available. On CloudLinux accounts you enable and size it through the PHP Selector.

In cPanel Jupiter, open Select PHP Version, switch to the Extensions tab, and confirm opcache is checked. Then move to the Options tab and adjust the values you are permitted to change. Sensible targets for a busy wiki:

opcache.enable = On
opcache.memory_consumption = 128
opcache.max_accelerated_files = 16000
opcache.validate_timestamps = On
opcache.revalidate_freq = 60

MediaWiki's codebase contains thousands of PHP files across core and extensions, so a low max_accelerated_files value causes cache eviction and thrashing. Raising it to 16000 keeps the whole application resident. In DirectAdmin Evolution the same controls appear under PHP Version Selector with an Options panel.

Pick a modern interpreter while you are there. MediaWiki 1.39 and 1.41 run substantially faster on PHP 8.1 or 8.2 than on 8.0, thanks to the JIT and general engine improvements. Set the version in MultiPHP Manager (cPanel) for the specific domain hosting your wiki, then verify with the debug toolbar that request times dropped. Memory and execution limits belong in a .user.ini file in your wiki root rather than any global file:

memory_limit = 256M
max_execution_time = 120
post_max_size = 32M
upload_max_filesize = 32M

The 256M limit matters because template-heavy parsing and image thumbnailing can exhaust the default 128M, producing blank pages logged as fatal memory errors in your error_log.

Parser cache, object cache, and Redis

The parser cache is where MediaWiki saves the fully rendered HTML of a page so it never re-parses wikitext for anonymous readers. By default it uses the database, which is functional but slow. Redis, if offered on your plan (many Hostiso shared plans include a per-account Redis instance you provision from cPanel), turns this into an in-memory operation.

Check whether the PHP Redis extension is enabled in the Select PHP Version Extensions tab, then look for a Redis icon in cPanel to obtain your socket path or host/port and password. Configure MediaWiki to route its main, parser, and session caches to Redis in LocalSettings.php:

$wgObjectCaches['redis'] = [
    'class'   => 'RedisBagOStuff',
    'servers' => [ '127.0.0.1:6379' ],
    'password' => 'YOUR_REDIS_PASSWORD',
    'persistent' => true,
];

$wgMainCacheType    = 'redis';
$wgParserCacheType  = 'redis';
$wgMessageCacheType = 'redis';
$wgSessionCacheType = 'redis';
$wgSessionsInObjectCache = true;

If your plan uses a Unix socket instead of TCP, set the server entry to the socket path provided in cPanel. Should Redis be unavailable, do not leave the object cache at its default. Configure the file-based APC-style fallback or, at minimum, enable the accelerated local cache so message parsing is not repeated on every request:

$wgMainCacheType   = CACHE_ACCEL; // uses APCu if the extension is enabled
$wgParserCacheType = CACHE_DB;

Enable APCu through the same PHP Selector Extensions tab. It gives a meaningful boost for message and interface caching even without Redis. After enabling any cache backend, watch the error_log: a mistyped password or wrong socket makes MediaWiki log connection failures and revert to database caching, which mimics the original slowness and confuses your testing.

LiteSpeed edge caching and static delivery

The layers above make PHP faster; LiteSpeed lets you skip PHP entirely for anonymous visitors. Because Hostiso runs LiteSpeed Web Server, you can serve cached HTML from the edge. MediaWiki cooperates with this when you tell it that anonymous page views are cacheable and set correct headers. In LocalSettings.php:

$wgUseCdn = true;
$wgCdnMaxAge = 1800;
$wgUseFileCache = false; // let Redis + LiteSpeed handle it

Then create or edit the .htaccess in your wiki root to hand static assets and cacheable responses to LiteSpeed, while never caching logged-in sessions:

<IfModule LiteSpeed>
    CacheLookup on

    # Do not cache when a MediaWiki session or token cookie is present
    RewriteEngine On
    RewriteCond %{HTTP_COOKIE} (mediawiki_session|UserID|Token) [NC]
    RewriteRule .* - [E=Cache-Control:no-cache]
</IfModule>

# Long-lived caching for versioned static resources
<IfModule mod_expires.c>
    ExpiresActive On
    ExpiresByType image/png "access plus 1 month"
    ExpiresByType image/svg+xml "access plus 1 month"
    ExpiresByType text/css "access plus 1 week"
    ExpiresByType application/javascript "access plus 1 week"
</IfModule>

The cookie condition is the important safety valve: it prevents LiteSpeed from serving a cached anonymous page to a logged-in editor, which would show stale content or leak another user's view. MediaWiki's ResourceLoader already appends version hashes to the load.php URLs for CSS and JavaScript, so the long expiry above is safe and drastically cuts repeat-visitor requests. If your plan exposes the LiteSpeed Cache options in cPanel, confirm public caching is on for the domain.

Finally, reduce the parsing workload itself at the application level. In the wiki's Special:Version page, review installed extensions and disable any parser-hook extension you do not use, since each one is invoked during every parse. If you rely on Scribunto Lua modules, they benefit enormously from the Redis object cache and OPcache combination above. After each change, purge the parser cache from Special:MassMessage is not the tool here; instead run the maintenance action by editing and saving a template, or clear Redis from the cPanel Redis panel, then re-test with the debug toolbar. Layer the fixes in order (OPcache, PHP version, object cache, LiteSpeed) and measure after each, so you know which change delivered the improvement and can back it out cleanly if the error_log reports trouble.