Clientexec is a billing and client management platform rather than a media-heavy CMS, so its storage footprint tends to grow invisibly. The pressure does not come from a gallery or page builder; it comes from accumulated ticket attachments, knowledge base images, uploaded logos and theme assets, PDF invoices, and the email piping that drops files into the system every day. On a Managed Cloud Shared Hosting account you cannot touch the server configuration, but you have full control over the document root, PHP limits through .user.ini, caching and compression through .htaccess, and the delivery path through a CDN. Those four levers are enough to keep a Clientexec install lean and fast without root access.

Before changing anything, understand where the bytes actually live and how Clientexec references them. The most common pain points are oversized uploaded images that are never resized, attachment folders that never get pruned, and static theme assets that are re-downloaded on every page load because no browser caching headers are set. Each of these is fixable from inside cPanel Jupiter or DirectAdmin Evolution.

Where Clientexec stores media and why disk usage climbs

Start by mapping the install. A typical Clientexec root sits under /home/youruser/public_html or a subfolder such as /home/youruser/public_html/billing. The directories that grow over time are predictable. Open cPanel → Files → File Manager (or DirectAdmin → File Manager) and inspect these paths relative to your install root:

/custom/templates/        theme images, logos, CSS, JS
/includes/images/         product and knowledge base images
/download/                files attached to products/invoices
/mail/attachments/        inbound ticket attachments via email piping
/log/                     application and error logs

In cPanel, the fastest way to see what is consuming space is the disk usage viewer: cPanel → Files → Disk Usage. It walks the home directory and ranks folders by size, which quickly exposes a runaway attachments directory or a log folder that has not rotated in a year. DirectAdmin users can reach a similar view under Account Manager → Disk Usage, or sort by size directly in File Manager.

Two things drive uncontrolled growth. First, Clientexec stores uploaded images at their original dimensions and relies on HTML or CSS to scale them in the browser, so a 4000×3000 phone photo attached to a ticket stays at full size on disk and on the wire. Second, email piping continually deposits attachments, and nothing deletes them automatically when a ticket closes. Over months this produces gigabytes of dead weight. The practical response is to cap what can be uploaded, clear what is stale, and compress what must stay. Review log files in /log/ as well; a verbose error log left enabled can balloon independently of any media, and trimming it is a quick win in File Manager by downloading a copy for reference and then truncating the live file.

Tuning upload limits and PHP memory with .user.ini

Clientexec's image and attachment uploads are governed entirely by PHP directives, and on CloudLinux with LiteSpeed you adjust those per-site without any server access. The cleanest approach is the PHP Selector. In cPanel go to Software → Select PHP Version → Options; in DirectAdmin go to Extra Features → Select PHP Version → Options. From there you can set upload_max_filesize, post_max_size, memory_limit, and max_execution_time through the UI, and the panel writes them for you.

If you prefer to manage values in the document root, create or edit a .user.ini file in your Clientexec root. LiteSpeed honors it per directory:

# /home/youruser/public_html/.user.ini
upload_max_filesize = 8M
post_max_size = 12M
memory_limit = 256M
max_execution_time = 120
max_input_time = 120

The reasoning behind these numbers matters more than the numbers themselves. Set upload_max_filesize to the largest legitimate attachment you expect a client to send; 8M comfortably covers screenshots and PDFs while rejecting raw camera files that offer no support value. post_max_size must always exceed upload_max_filesize because the POST body carries the file plus form fields, so keep a few megabytes of headroom. memory_limit at 256M gives PHP room to process image uploads and render invoice PDFs without exhausting itself. Changes to .user.ini are not instant because LiteSpeed caches the file; the refresh interval is typically a few minutes, so verify by uploading a test attachment rather than assuming the edit took hold immediately. Confirm the active values in cPanel → PHP Info or a temporary phpinfo() page, which you should delete afterward.

Capping uploads at the PHP layer protects storage better than any in-app setting because it rejects the oversized file before it ever reaches disk. Pair this with periodic housekeeping: use File Manager to sort /mail/attachments/ by date, and remove files tied to long-closed tickets after confirming your backup policy covers them.

Compression, browser caching, and WebP delivery via .htaccess

LiteSpeed reads Apache-style directives, so your .htaccess in the Clientexec root controls both bandwidth and repeat-visit performance. The single highest-impact change is far-future caching on static assets. Clientexec's templates pull the same logos, CSS, and JS on every admin and client-area page, and without cache headers the browser refetches them constantly.

# Browser caching for static media
<IfModule mod_expires.c>
  ExpiresActive On
  ExpiresByType image/jpeg "access plus 1 year"
  ExpiresByType image/png "access plus 1 year"
  ExpiresByType image/gif "access plus 1 year"
  ExpiresByType image/webp "access plus 1 year"
  ExpiresByType image/svg+xml "access plus 1 year"
  ExpiresByType text/css "access plus 1 month"
  ExpiresByType application/javascript "access plus 1 month"
</IfModule>

# Compress text-based responses
<IfModule mod_deflate.c>
  AddOutputFilterByType DEFLATE text/html text/css text/plain
  AddOutputFilterByType DEFLATE application/javascript application/json
  AddOutputFilterByType DEFLATE image/svg+xml
</IfModule>

Compression only helps text formats; JPEG, PNG, and WebP are already compressed, so do not waste cycles deflating them. If you want modern image formats, Clientexec has no built-in WebP or AVIF conversion pipeline, which means you convert images once and serve them conditionally. Pre-convert your theme images and knowledge base graphics locally or with cPanel's image tools (cPanel → Files → Images offers basic scaling), upload the .webp versions alongside the originals, then let .htaccess serve WebP to browsers that advertise support:

# Serve .webp when a matching file exists and the browser accepts it
<IfModule mod_rewrite.c>
  RewriteEngine On
  RewriteCond %{HTTP_ACCEPT} image/webp
  RewriteCond %{REQUEST_FILENAME}.webp -f
  RewriteRule \.(jpe?g|png)$ %{REQUEST_URI}.webp [T=image/webp,E=accept:1,L]
</IfModule>
Header append Vary Accept env=accept

This pattern keeps the original JPEG or PNG as a fallback for older clients while modern browsers transparently receive the smaller WebP. Because Clientexec does not rename or regenerate these files, the conversion is a one-time task you repeat only when you change branding or add KB imagery. Avoid AVIF unless you can generate it reliably; the encoding is slower and the fallback logic is identical, so the practical gain over WebP on a billing portal is marginal.

Offloading static assets to a CDN

Once caching and compression are in place, the final lever is moving delivery off your hosting account entirely. A CDN reduces origin bandwidth and speeds up the client area for geographically distributed customers, both of which matter for a portal clients log into daily. Because Clientexec serves assets from standard URLs under your domain, a pull-zone CDN such as Cloudflare integrates without code changes. If your account uses the Cloudflare option in cPanel (Software → Cloudflare) or you point your nameservers at Cloudflare, enable caching on static extensions and let the CDN pull from your origin on first request.

Keep two boundaries firm. First, never route authenticated billing responses or invoice PDFs through aggressive CDN caching; those are per-user and must stay dynamic. Scope your CDN page rules to paths like /custom/templates/ and /includes/images/ so only genuinely static content is cached. Second, confirm the Vary: Accept header survives the CDN, otherwise WebP negotiation can serve the wrong format to a cached audience; Cloudflare respects it when Polish is off, so leave automatic image rewriting disabled if you are managing WebP yourself. With upload limits capped, stale attachments pruned, caching and WebP configured in .htaccess, and static paths offloaded to a CDN, a Clientexec install stays within its disk quota and loads quickly without ever requiring root-level intervention.