X-Cart handles product imagery through a layered system that is easy to misjudge on shared hosting. Every image you upload is kept as a full-resolution original, and X-Cart then generates multiple resized derivatives on demand: category listing thumbnails, product page zoom images, cart line-item icons, and any custom dimensions declared by your theme or modules. Those derivatives are written to a filesystem cache and reused on later requests. A catalog with a few thousand products can therefore hold tens of thousands of physical files, and the count grows every time a theme changes its image dimensions or you install a module that requests a new size.
On a Managed Cloud Shared Hosting account running LiteSpeed on CloudLinux, the practical constraints are disk quota and, more importantly, the inode (file count) limit. Image caches are the single most common reason an account with modest storage usage still trips its inode ceiling. Because you operate as an unprivileged hosting user, the levers available are the X-Cart admin dashboard, the cPanel or DirectAdmin File Manager, .user.ini for PHP behavior, .htaccess for delivery rules, and phpMyAdmin for verifying settings. Everything below stays inside those boundaries.
Where the storage actually goes: originals versus the thumbnail cache
X-Cart separates permanent media from regenerable media, and understanding that split tells you what is safe to clear. Original uploads live under the images directory, typically /home/USERNAME/public_html/images/ with product originals in a detailed subtree. Generated derivatives are placed in a cache area under /home/USERNAME/public_html/var/images/ (older 5.x installs) or a comparable images/T/ and cache path depending on version. The files under the cache path are disposable: X-Cart can rebuild any of them from the originals, so deleting them frees space and inodes without data loss.
Before deleting anything, measure. In cPanel File Manager, browse to public_html/var/, select the images cache folder, and note its size, or open Metrics > Errors and the disk usage panel to see totals. In DirectAdmin, the File Manager shows folder sizes directly. To confirm the cache is the culprit rather than the originals, compare the size of images/ against var/images/. When the cache dwarfs the originals, a stale accumulation from an old theme is usually the cause.
Clear the cache the supported way rather than by mass-deleting through File Manager, because X-Cart tracks derivatives in the database and orphaned records can trigger regeneration loops. In the admin dashboard go to My Addons or Store setup > Cache management depending on version, and use the Clean up cache / Re-deploy the store action. Re-deployment rebuilds the resource cache and prunes obsolete image sizes. If the interface is unreachable because the account is over quota, delete the contents of the cache subfolder in File Manager first to free space, then log in and run a proper re-deploy so the database and filesystem agree again.
To stop the cache from ballooning in the first place, limit how many distinct sizes your store requests. Each theme dimension multiplies your file count by the number of products. In Look & Feel and the active theme's image settings, remove custom image sizes you are not displaying, and avoid installing multiple gallery or zoom modules that each declare their own dimensions. Fewer declared sizes means a smaller multiplier on every future upload.
Serving smaller images: WebP conversion and cache headers
Modern X-Cart 5.5+ builds can generate and serve WebP derivatives when the GD or Imagick extension on your selected PHP version supports it. Confirm support first: in cPanel open Select PHP Version (PHP Selector on CloudLinux), pick a current branch such as PHP 8.1 or 8.2, and ensure the gd and, if available, imagick extensions are enabled. WebP encoding in GD requires that the library was compiled with WebP support, which the managed PHP builds include. In DirectAdmin the equivalent is PHP Version Selector / Extensions.
With a capable PHP version active, enable WebP output in the X-Cart admin under the performance or image settings section of your theme, then re-deploy the store so derivatives regenerate in the new format. X-Cart emits a <picture> element with WebP sources and a fallback, so browsers that lack support still receive JPEG or PNG. Do not attempt server-wide conversion tricks; keep the format decision inside X-Cart so its cache manifest stays consistent.
Delivery matters as much as format. Add long-lived caching and compression rules for static media in the .htaccess file at your document root so LiteSpeed returns images with correct headers:
<IfModule mod_expires.c>
ExpiresActive On
ExpiresByType image/webp "access plus 1 year"
ExpiresByType image/avif "access plus 1 year"
ExpiresByType image/jpeg "access plus 1 year"
ExpiresByType image/png "access plus 1 year"
ExpiresByType image/svg+xml "access plus 1 year"
</IfModule>
<IfModule mod_headers.c>
<FilesMatch "\.(webp|avif|jpe?g|png|gif|svg)$">
Header set Cache-Control "public, max-age=31536000, immutable"
</FilesMatch>
</IfModule>AVIF is worth mentioning but manage expectations: encoding AVIF requires a very recent Imagick or libavif that shared PHP builds may not expose, and encoding is CPU-heavy enough that it can hit the CloudLinux LVE CPU and entry-process limits during bulk regeneration. If your PHP version does not list AVIF support in Select PHP Version, treat WebP as your target format and leave AVIF to a CDN that can transcode on the edge.
Upload limits, regeneration load, and LVE-safe tuning
Bulk image imports and large source files run into PHP limits before they run into disk. Rather than editing any file under /etc/, set per-account values in a .user.ini placed in your X-Cart document root. LiteSpeed reads it per directory:
upload_max_filesize = 32M
post_max_size = 40M
max_execution_time = 120
max_input_time = 120
memory_limit = 256MValues must respect the ceilings your plan enforces; if a setting is capped, the panel-configured maximum wins and your override is silently clamped. After saving, allow a minute for LiteSpeed to pick up the change, then verify with a phpinfo page or the admin's system requirements screen.
Regeneration is the hidden CPU cost. When you re-deploy or import a large catalog, X-Cart resizes every image, and on CloudLinux that work counts against your CPU and physical memory LVE limits. If you see 508 (resource limit reached) responses or the process stalls, run the operation in smaller batches: import a few hundred products, let the cache build during normal browsing, then continue. Avoid triggering a full re-deploy during peak traffic. If a batch fails, the local error_log in the affected directory records the fatal or timeout, which is more precise than the browser's generic message.
Offloading media to a CDN to protect disk, inodes, and bandwidth
The most effective way to keep image growth from threatening your account is to serve media from a CDN edge while keeping originals on the host. X-Cart supports a CDN base URL in its performance settings, so once you point a pull-zone at your store, static assets are rewritten to the CDN hostname. A pull CDN caches copies on demand: it fetches an image from your server once, stores it at the edge, and serves every later request from there. Your account still holds the master files, but repeat bandwidth and connection load move off the origin.
Set this up by creating a pull zone with your CDN provider pointed at your primary domain, then entering the CDN hostname in X-Cart's admin under the performance or CDN configuration field and re-deploying so asset URLs regenerate. Keep the .htaccess caching headers above in place, because the CDN honors your origin Cache-Control when deciding how long to retain each object. If your CDN offers on-the-fly format conversion, you can let it deliver WebP or AVIF at the edge even when your PHP build cannot encode AVIF locally, which sidesteps the LVE cost of edge-heavy formats entirely.
X-Cart on shared hosting does not provide native S3-style object storage offload without a supported module, so treat true object storage as out of scope unless a marketplace addon explicitly integrates it; a CDN pull zone delivers most of the same relief within the tools your account already exposes. For the broader pattern of finding which limit you are actually hitting before deciding to move to a larger plan, the walkthrough on finding the real resource bottleneck on shared hosting applies directly to inode-heavy image caches.
Work through these in order: measure the cache, prune unused theme sizes, clear and re-deploy, enable WebP on a supported PHP version, add caching headers, tune uploads through .user.ini, and finally offload delivery to a CDN. Each step lowers either file count or bandwidth, and together they keep an image-heavy X-Cart store comfortably inside shared hosting limits.