Phorum is a lightweight, flat-file-configured discussion board that stores messages, users, and settings in MySQL while rendering pages through templated PHP. On a busy board the slow pages are rarely the fault of the code itself. They come from three recurring sources: PHP recompiling the same scripts on every request, MySQL repeatedly scanning message and thread tables, and the web server delivering fully dynamic responses even to logged-out guests who could safely be served a cached copy. Each of these is fixable from inside a normal hosting account, without touching server configuration or requiring elevated privileges.

Before changing anything, it helps to understand where time is actually going. Load a thread listing while watching the response, then reload it. If the second load is barely faster than the first, PHP is doing full work every time and OPcache is likely the missing piece. If the page slows down noticeably only when many people post or search at once, the bottleneck is in the database. And if a page that shows the same content to every anonymous visitor still takes hundreds of milliseconds, you are paying for dynamic generation you do not need. The sections below address each cause in the order that gives the biggest return for the least effort.

Diagnosing where the time goes with error_log and timing

Start by confirming Phorum is not silently throwing warnings, because repeated notices and failed includes add measurable latency and flood the log. In cPanel open File Manager and browse to your Phorum root (commonly public_html/forum). Look for an error_log file in that directory and in the parent. Repeated entries about deprecated functions, undefined indexes, or missing template files each represent wasted PHP cycles on every affected request. Fixing the underlying cause, or upgrading to a PHP version Phorum tolerates cleanly, removes that overhead.

To measure real page cost without server tools, add a lightweight timer to a copy of Phorum's common.php only on a staging copy, or simply use your browser's developer tools Network tab and read the Time-To-First-Byte for list.php and read.php. TTFB is dominated by PHP execution plus database round trips, so it is the number that responds to the tuning in this article. Record a baseline for a guest hitting a large thread and for a logged-in user posting a reply. Those two numbers tell you whether to prioritize read caching or write-path database work.

Phorum also keeps its configuration in include/config.php. Two directives there directly affect performance and are safe to review: the cache directory and the cache-related flags. Confirm the configured cache path exists and is writable by your account. A misconfigured or unwritable cache directory means Phorum silently regenerates everything, which looks like a code problem but is really a filesystem permissions problem you can fix in File Manager by setting the directory to 0755.

OPcache and PHP Selector tuning through the control panel

The single most effective change for any PHP forum is enabling and sizing OPcache so compiled bytecode is reused across requests. On CloudLinux hosting you control this per-account. In cPanel open Select PHP Version (the PHP Selector), or in DirectAdmin open Select PHP Version under the account tools. First choose a modern branch that Phorum runs on; the 5.x Phorum core is sensitive to newer PHP, so test carefully on a staging subdomain before switching the live version, and watch error_log for fatal errors after the change.

Once on a working version, switch to the Options (or Extensions) tab and enable opcache. Then set the OPcache tunables that the panel exposes. Reasonable values for a mid-sized board are:

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

Keeping validate_timestamps on with a 60-second revalidate window means you still see file edits within a minute, which matters while you tune templates. Once the board is stable you can raise revalidate_freq to reduce stat calls. If the PHP Selector does not expose a directive you need, create a .user.ini file in the Phorum root and add the same lines there; LiteSpeed and PHP-FPM read per-directory .user.ini for PHP_INI_USER and PHP_INI_PERDIR settings. A sensible .user.ini also raises the limits Phorum needs during large imports or attachment handling:

memory_limit = 256M
max_execution_time = 60
realpath_cache_size = 4096K
realpath_cache_ttl = 120

The realpath cache values matter more than people expect on shared hosting, because Phorum includes many small files per request and each uncached path resolution is a filesystem hit. After saving, reload a forum page twice and compare TTFB against your baseline; a correctly primed OPcache typically cuts PHP time substantially on the second load.

LiteSpeed full-page caching and .htaccess rules for guests

Phorum does not ship a LiteSpeed Cache plugin the way WordPress does, so you enable full-page caching at the web-server layer through .htaccess, and you must be careful to cache only responses that are identical for every visitor. Logged-in users see personalized elements, so the safe target is anonymous guests who have no Phorum session cookie. Phorum sets session cookies with names beginning phorum_session, which gives you a reliable signal to bypass the cache.

Add rules to the .htaccess in your Phorum directory that cache GET requests for guests and skip everything else:

<IfModule LiteSpeed>
CacheLookup on

RewriteEngine On
# Do not cache when a Phorum session cookie is present
RewriteCond %{HTTP_COOKIE} phorum_session [NC]
RewriteRule .* - [E=Cache-Control:no-cache]

# Do not cache POST, login, or admin actions
RewriteCond %{REQUEST_METHOD} POST [NC,OR]
RewriteCond %{REQUEST_URI} (login|register|admin|control)\.php [NC]
RewriteRule .* - [E=Cache-Control:no-cache]

# Cache guest GET pages for 120 seconds
RewriteCond %{REQUEST_METHOD} GET
RewriteCond %{HTTP_COOKIE} !phorum_session [NC]
RewriteRule \.php$ - [E=Cache-Control:max-age=120]
</IfModule>

A short 120-second window keeps thread listings fresh enough for an active community while absorbing traffic spikes and search-engine crawlers, which are often the heaviest anonymous load. Verify the cache is working by requesting a page as a guest and checking the response headers in the Network tab for x-litespeed-cache: hit after the first request. If you never see a hit, confirm no earlier rule in the file is setting a cookie or a Cache-Control: no-cache header globally.

Static assets deserve their own long-lived caching so browsers and the CDN stop re-requesting Phorum's CSS, JavaScript, and template images. Add a browser-cache block in the same .htaccess:

<IfModule mod_expires.c>
ExpiresActive On
ExpiresByType text/css "access plus 1 month"
ExpiresByType application/javascript "access plus 1 month"
ExpiresByType image/png "access plus 1 month"
ExpiresByType image/gif "access plus 1 month"
</IfModule>

Phorum's own cache, Redis object storage, and database housekeeping

Phorum has an internal caching layer configured in include/config.php. The $PHORUM['cache'] and $PHORUM['cache_layer'] directives control whether repeated queries for message trees, user data, and settings are served from a store instead of MySQL. On the default file cache layer, ensure the cache directory is present and writable, then enable caching of user records and banlists, which are among the most repeated lookups on a busy board. If your hosting plan offers Redis, you can point Phorum's cache layer at it for far faster object retrieval than the filesystem; provision the Redis instance from the cPanel or DirectAdmin feature that exposes it, note the socket or host and port your panel provides, and set the matching cache layer in the Phorum config. Redis keeps hot data in memory and survives across requests, which removes a large share of small repetitive queries.

Database maintenance is the last piece and it runs entirely from phpMyAdmin in your control panel. Over time Phorum's message tables accumulate deleted rows and fragmented indexes that slow every listing query. Select your Phorum database, tick the message and thread tables, and run OPTIMIZE TABLE from the operations dropdown, or execute it directly in the SQL tab:

OPTIMIZE TABLE phorum_messages, phorum_search;

Adjust the table prefix to match your install. Then confirm the indexes Phorum relies on still exist by browsing the Structure tab of phorum_messages; the columns used for thread grouping and sorting should be indexed. If a slow query keeps appearing in your log, use phpMyAdmin's SQL tab to run EXPLAIN on it and check that it uses an index rather than a full table scan. Because you cannot change server-wide MySQL settings on shared hosting, the effective levers are keeping tables optimized, letting Phorum's cache and Redis absorb repeat reads, and letting LiteSpeed serve guests without touching PHP or MySQL at all.

Work through these layers in order and re-measure TTFB after each. OPcache and the guest page cache usually deliver the visible win, while Redis and table optimization keep the board fast as it grows, all from tools available to a standard hosting account.