Why UVdesk feels slow on shared hosting
UVdesk is built on Symfony, and that single fact explains most of the performance behavior you observe on a shared account. Every request that hits the agent panel, the customer portal, or the ticket list passes through Symfony's kernel, which resolves routing, the service container, Doctrine ORM hydration, and Twig template rendering. When the framework runs in development mode, or when the compiled cache is stale or missing, Symfony rebuilds large portions of that container on nearly every request. The result is a helpdesk that spends most of its time compiling configuration instead of answering the actual query.
Two other factors compound this on managed shared hosting with LiteSpeed and CloudLinux. First, PHP without OPcache re-parses and recompiles every .php file on each hit, and UVdesk plus its vendor tree contains thousands of files. Second, ticket-heavy installs accumulate large uv_ticket, uv_thread, and uv_ticket_type tables, and the default listing queries can scan far more rows than they return once you cross a few thousand tickets. None of these problems require server-level access to fix. They live inside the application's environment configuration, the PHP selector, the database, and a small set of .htaccess and .user.ini directives you fully control as an unprivileged user.
Before changing anything, confirm where the time actually goes. Open ~/public_html/var/log/ (or the var/log folder inside your UVdesk document root) and read prod.log or dev.log. A flood of deprecation notices, container rebuild messages, or repeated Doctrine warnings tells you the app is not running lean. In cPanel, Metrics → Errors and the per-domain error_log file surface PHP timeouts and memory exhaustion, which often masquerade as "slow" pages when a request is really being killed mid-render. Establish that baseline first so every later change can be measured against it.
Run in prod mode and warm the Symfony cache
The largest single win is making sure UVdesk runs in production environment mode with a pre-compiled cache. UVdesk reads its environment from the .env file (or from app/config depending on your release) at the project root. Using cPanel File Manager, enable "Show Hidden Files (dotfiles)" from the settings gear, then open .env and confirm these values:
APP_ENV=prod
APP_DEBUG=0Running with APP_ENV=dev or APP_DEBUG=1 forces the profiler, verbose logging, and full container rebuilds on every request, which can triple response time. After switching to prod, the old compiled cache in var/cache/dev becomes irrelevant, but a stale var/cache/prod can also cause errors or slow first hits. Rename the existing var/cache/prod folder to prod_old through File Manager and let Symfony rebuild it on the next request. If your host provides Terminal in cPanel under a user shell (still unprivileged), you can warm it deliberately, but the folder-rename method works without any shell.
Permissions matter here. The web server must be able to write to var/cache and var/log. In File Manager, select those folders, choose Permissions, and set them to 0755 for directories and 0644 for files. On CloudLinux the PHP process runs as your own user, so avoid 0777 entirely; it is both unnecessary and a security risk. Once prod mode is active and the cache is fresh, reload the agent dashboard twice. The first load compiles, the second should be dramatically faster. That gap between first and second load is your proof that container caching is now doing its job.
Enable OPcache, Redis, and sensible PHP limits
With prod mode handled, turn to the PHP runtime. In cPanel go to Select PHP Version (or in DirectAdmin, PHP Selector / Extensions) and confirm UVdesk runs on PHP 8.1 or 8.2, matching its supported range. In the Extensions tab, enable opcache, redis, intl, and igbinary if present. OPcache stores compiled bytecode in memory so the vendor tree is parsed once, not on every request. You cannot edit php.ini globally, but you can set most OPcache options through the PHP Options screen or a per-directory .user.ini placed in your document root:
opcache.enable=1
opcache.memory_consumption=192
opcache.max_accelerated_files=20000
opcache.validate_timestamps=1
opcache.revalidate_freq=60
memory_limit=256M
max_execution_time=120
realpath_cache_size=4096K
realpath_cache_ttl=600The high max_accelerated_files value matters because Symfony and its bundles ship far more files than the default 10,000 slots. The generous realpath_cache reduces filesystem stat calls, which is a real cost on a framework with deep vendor/ nesting. Give the changes a moment, since .user.ini is re-read on the interval defined by user_ini.cache_ttl, typically 300 seconds.
If your plan includes Redis (check Redis in DirectAdmin or the cPanel feature list), point UVdesk's cache and sessions at it instead of the filesystem. Filesystem caching on shared storage is slower and contends with other I/O. Configure the Symfony cache DSN and session handler in .env or your framework config, using the socket path or host and port your panel provides:
REDIS_URL=redis://127.0.0.1:6379
# session handler via .user.ini
session.save_handler=redis
session.save_path="tcp://127.0.0.1:6379?database=0"Moving sessions to Redis removes lock contention that otherwise serializes concurrent agent requests behind file locks in var/sessions. This philosophy of layering OPcache, an object cache, and a fast session store mirrors the approach we outline for another Symfony-adjacent helpdesk in our FreeScout performance and caching guide, and the same reasoning applies to UVdesk.
LiteSpeed headers, .htaccess, and database hygiene
LiteSpeed serves your static assets and can compress and cache responses without any server-side configuration on your part. UVdesk keeps its public assets under the public/ (or web/) directory. Add browser caching and compression rules to the .htaccess in that directory so agent and customer browsers stop re-downloading CSS, JS, and images on every navigation:
<IfModule LiteSpeed>
CacheLookup on
</IfModule>
<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/jpeg "access plus 1 month"
ExpiresByType image/svg+xml "access plus 1 month"
ExpiresByType font/woff2 "access plus 1 year"
</IfModule>
<IfModule mod_deflate.c>
AddOutputFilterByType DEFLATE text/html text/css application/javascript application/json
</IfModule>Do not attempt full-page LiteSpeed caching for the authenticated agent panel; ticket views are per-user and cookie-sensitive, so a cached page would leak one agent's view to another. Static asset caching and compression are the safe, high-value wins here. If you use a CDN, point it only at the public/ assets path and leave the dynamic routes uncached.
Finally, address the database, which becomes the dominant cost once ticket volume grows. Open phpMyAdmin from your control panel and inspect the uv_ticket and uv_thread tables. Run SHOW TABLE STATUS to see row counts and check that these tables use InnoDB rather than MyISAM. Confirm indexes exist on the columns the listing filters and sorts by, typically status, priority, created_at, and the foreign keys that join threads to tickets. You can add a covering index safely from phpMyAdmin's Structure tab, for example an index on (status, created_at) to accelerate the default open-ticket queue. Use the Operations tab to run Optimize table after bulk deletions to reclaim fragmented space. Avoid any statement touching global variables; those require privileges you do not hold and will simply error out. Between prod-mode caching, OPcache, a Redis session store, LiteSpeed asset rules, and a handful of targeted indexes, a UVdesk install that felt sluggish under a few thousand tickets returns to sub-second dashboard loads without a single root-level change.