Zammad Performance & Caching on Shared Hosting: Reality Check, Asset Delivery, and Browser Cache Tuning

Why Zammad is not a typical shared-hosting app

Before touching a single caching directive, it helps to be honest about what Zammad actually is. Zammad is a Ruby on Rails application. It does not run as a PHP script that the web server invokes on each request. Instead it runs as a set of persistent background processes: a Rails web worker (usually Puma), a Scheduler process that handles recurring jobs, an Elasticsearch instance for search, a PostgreSQL database, WebSocket connections for the live agent interface, and Redis for job queuing and session data. All of these expect to be launched and supervised by an init system and to keep running between requests.

That architecture collides directly with the boundaries of a managed shared account. On our LiteSpeed and CloudLinux platform you operate as an unprivileged hosting user. You cannot install system packages, register services with the process manager, or bind long-lived listeners the way Zammad's installer expects. The PHP Selector, MultiPHP Manager, and .user.ini tools that dominate most of our documentation simply do not apply, because Zammad executes no PHP at all. If your Zammad instance is already reachable, it is almost certainly running on a VPS or dedicated node and being served through a domain that points at that backend. Understanding this distinction is the difference between chasing settings that can never take effect and tuning the parts of the stack you genuinely control.

So there are two realistic scenarios. In the first, Zammad lives on a separate server and your shared account only proxies or points a domain at it. In that case your performance levers are DNS, HTTP delivery, and browser caching for the static assets your account can serve. In the second scenario, the slowness you see is inside the Rails application itself, which means the tuning lives in Zammad's own settings and its Redis and Elasticsearch layers rather than in anything cPanel or DirectAdmin exposes. Both are worth walking through, because the diagnosis determines where you should spend effort.

Diagnosing where the slowness actually comes from

Slow Zammad page loads fall into a small number of categories, and browser developer tools tell you which one you are facing in under a minute. Open the agent interface, press F12, and switch to the Network tab with "Disable cache" unchecked so you see real repeat-visit behavior. Reload and sort by time. Three patterns matter.

If the very first document request (the HTML shell) takes several seconds while everything else is fast, the delay is server-side rendering or a slow database and Elasticsearch query inside Rails. No amount of front-end caching fixes that, because the response is dynamic and per-agent. If instead the HTML returns quickly but dozens of JavaScript and CSS bundles each take hundreds of milliseconds and re-download on every visit, you have a static asset delivery problem that caching headers solve directly. If requests to a WebSocket endpoint (often /ws) stall or fail, the live push channel is being blocked or buffered, which makes the interface feel frozen even when data is present.

The second diagnostic tool is Zammad's own logging. On the backend, Rails writes to log/production.log inside the Zammad application directory. Each request line records the total time and a breakdown of view rendering versus ActiveRecord database time. A line showing a large "ActiveRecord" figure points at PostgreSQL; a large "Elasticsearch" or search time points at the index; a large "Views" figure points at rendering volume. On a shared account you will not have shell access to that file, but if you administer the Zammad node you should read it before assuming caching is the answer. On the shared side, your only equivalent is the domain's logs/ directory and the account error_log, which capture proxy and rewrite failures but not Rails internals.

Do not skip this step. The most common wasted effort is adding .htaccess cache rules to speed up a page whose slowness is entirely a five-second database query on another machine. Confirm the category first, then act.

Tuning static delivery, LiteSpeed, and browser cache headers

When your account serves Zammad's static assets (either because you front the app with a proxy or host the compiled public/assets bundle), the wins come from browser and edge caching rather than a PHP page cache. Zammad fingerprints its compiled assets with content hashes in the filename, which means a bundle named with a hash never changes content without changing its name. That makes those files safe to cache aggressively and for a long time.

If you can place a .htaccess file in the directory that serves the assets, set long-lived cache headers for the fingerprinted files while keeping the HTML document uncached:

<IfModule mod_expires.c>
  ExpiresActive On
  ExpiresByType application/javascript "access plus 1 year"
  ExpiresByType text/javascript "access plus 1 year"
  ExpiresByType text/css "access plus 1 year"
  ExpiresByType image/svg+xml "access plus 6 months"
  ExpiresByType image/png "access plus 6 months"
  ExpiresByType font/woff2 "access plus 1 year"
</IfModule>

<IfModule mod_headers.c>
  <FilesMatch "\.(js|css|woff2|svg|png)$">
    Header set Cache-Control "public, max-age=31536000, immutable"
  </FilesMatch>
  <FilesMatch "\.(html|json)$">
    Header set Cache-Control "no-cache, must-revalidate"
  </FilesMatch>
</IfModule>

Compression matters even more than expiry for first-load speed. LiteSpeed honors compression settings, so enable gzip or Brotli for text-based assets:

<IfModule mod_deflate.c>
  AddOutputFilterByType DEFLATE text/html text/css application/javascript
  AddOutputFilterByType DEFLATE application/json image/svg+xml
</IfModule>

LiteSpeed's built-in static file cache and its efficient handling of keep-alive connections already help here, and unlike the LSCache plugin used for WordPress and other PHP CMSs, you are relying on plain static serving rather than a page-cache module. That is the correct approach for Zammad, because its dynamic pages are per-agent and must never be shared from a public cache. If you proxy the whole application through your account, make sure the proxy does not buffer the WebSocket upgrade; a mishandled Upgrade header is the usual cause of a frozen agent view, and it is a delivery bug rather than a caching one. The techniques mirror what we cover for PHP help desks in our UVdesk performance and caching guide, though the OPcache and PHP layers there have no equivalent in Zammad.

Application-level optimizations inside Zammad

When diagnosis points at Rails rather than delivery, the improvements live in Zammad's admin interface and its supporting services, all reachable through the settings the application itself exposes. Start with search. Zammad relies heavily on Elasticsearch, and a mis-sized or unindexed instance turns overview and search pages sluggish. In the admin panel under Settings, confirm the Elasticsearch integration reports as active and that the index has finished building; a partial reindex leaves queries falling back to slow database scans.

Reduce rendering volume next. Agent overviews that load thousands of tickets with many columns are expensive to render on every poll. Trim overview column counts and tighten their conditions so each view returns a bounded result set. Fewer active overviews per role means fewer background refresh queries competing for the same worker. Similarly, disable or narrow triggers, schedulers, and automation rules that run frequently but rarely change anything, since each one consumes Scheduler cycles that would otherwise serve interactive requests.

Redis and job processing deserve attention because a backed-up queue makes the whole interface feel slow even when individual pages render quickly. Zammad uses background jobs for notifications, email processing, and search indexing. If those jobs pile up, agents see stale data and delayed updates. Keeping Redis healthy and the Scheduler process running is the equivalent of the queue tuning we describe for PHP help desks in the FreeScout queue and caching guide. Finally, keep Zammad reasonably current: newer releases ship meaningful query and asset-bundling improvements, and running an outdated version often reintroduces performance problems that were already fixed upstream. If your account only fronts a Zammad node, coordinate these application changes with whoever administers that backend, because they cannot be applied from cPanel or DirectAdmin.