How FluxBB Actually Handles Media and Storage
FluxBB is a lightweight forum engine, and its media footprint reflects that design. Out of the box the only user-generated binary content it stores is avatars. There is no native attachment system, no gallery, no automatic thumbnail generator, and no image resizing pipeline baked into the core. That matters because a great deal of generic "image optimization" advice assumes a CMS with an upload manager and a thumbnail cache directory to prune. FluxBB simply does not have those surfaces, so optimizing its media means working with the pieces that genuinely exist: the avatar store, any smilie and style images shipped with your board, and the way LiteSpeed serves all of it.
Avatars live in the img/avatars/ directory under your FluxBB root (for example /home/youruser/public_html/forum/img/avatars/). When a member uploads an avatar, FluxBB validates the file type, checks it against the maximum dimensions and byte size you configure, and saves it named after the user ID with the original extension (42.png, 42.jpg, or 42.gif). It does not re-encode the image, strip metadata, or produce a smaller cached copy. Whatever a user uploads within your limits is exactly what every page view then serves. On shared hosting this is the single largest lever you control, because an unconstrained avatar directory on a busy board quietly accumulates megabytes and inflates the inode count that CloudLinux measures against your account limits.
The style and smilie images in style/imgs/ and img/smilies/ are static assets that ship with FluxBB or an installed extension. They are small, they rarely change, and the optimization opportunity there is purely about caching and compression at the web server rather than storage reduction. Keep that distinction in mind as you work: avatars are a storage problem, static theme assets are a delivery problem, and the tools for each are different.
Controlling Avatar Uploads and Disk Usage in the AdminCP
Every storage decision for avatars begins in the FluxBB administration area. Log in as an administrator and open Admin → Settings → Features. The relevant controls are grouped there: Allow avatars, Maximum avatar width, Maximum avatar height, and Maximum avatar size. The dimension fields are measured in pixels and the size field in bytes. FluxBB rejects any upload that exceeds any one of these three values, which gives you a hard ceiling on what a single avatar can cost you.
Sensible values for a shared account are 80 by 80 pixels and a maximum size of 15360 bytes (15 KB). That range keeps avatars crisp on modern displays while capping the per-file cost. If you currently allow 150 by 150 at 100 KB, tightening these numbers does not retroactively shrink existing files, but it stops the directory from growing with oversized uploads going forward. For the board to accept and write avatar files at all, the img/avatars/ directory must be writable; on CloudLinux a permission of 0755 on the directory is correct, and you should never set it to 0777.
To audit what is already stored, open cPanel File Manager (or DirectAdmin File Manager), navigate to img/avatars/, and sort by size. You will frequently find a handful of legacy uploads from before limits were tightened, plus avatars belonging to deleted accounts that FluxBB did not clean up. FluxBB removes an avatar when a user is deleted through the AdminCP, but avatars orphaned by database migrations or manual row deletion stay on disk. You can safely remove a file in img/avatars/ when no user row references that ID; the forum simply falls back to showing no avatar for that member. Before deleting in bulk, confirm the matching user IDs in phpMyAdmin with a query against the users table:
SELECT id, username FROM users WHERE id IN (42, 108, 211);Any numeric filename in the avatar folder that does not return a row is an orphan and is safe to delete. Doing this reclaims both disk space and inodes, and inodes are the quieter of the two limits that trip up shared accounts.
Serving WebP and Setting Cache Headers with .htaccess
Because FluxBB will not convert images for you, the practical way to deliver modern formats on shared hosting is content negotiation at the web server. The idea is to pre-generate a .webp version of a static asset, place it alongside the original, and let the server hand the WebP copy to browsers that accept it while everyone else still receives the original file. This works cleanly for your style sprites, smilies, logo, and any fixed decorative images, since those are assets you control and can convert once with any desktop tool before uploading via File Manager.
Add the following to the .htaccess file in your FluxBB root. LiteSpeed reads Apache-style directives, so these rules apply without any server-level change:
<IfModule mod_rewrite.c>
RewriteEngine On
# Serve a .webp twin when the browser accepts it and the file exists
RewriteCond %{HTTP_ACCEPT} image/webp
RewriteCond %{REQUEST_FILENAME}\.webp -f
RewriteRule ^(.+)\.(jpe?g|png)$ $1.$2.webp [T=image/webp,E=accept:1,L]
</IfModule>
<IfModule mod_headers.c>
Header append Vary Accept env=accept
</IfModule>The Vary: Accept header is important so that caches and the CDN do not serve a WebP file to a client that cannot decode it. For a file such as logo.png, upload logo.png.webp next to it and the rule does the rest.
Separately, set long-lived cache headers on all static image types so repeat visitors and the CDN stop re-fetching unchanged assets. Add this block to the same .htaccess:
<IfModule mod_expires.c>
ExpiresActive On
ExpiresByType image/webp "access plus 1 month"
ExpiresByType image/png "access plus 1 month"
ExpiresByType image/jpeg "access plus 1 month"
ExpiresByType image/gif "access plus 1 month"
</IfModule>
<IfModule mod_headers.c>
<FilesMatch "\.(webp|png|jpe?g|gif|css|js)$">
Header set Cache-Control "public, max-age=2592000"
</FilesMatch>
</IfModule>If your LiteSpeed account exposes the LiteSpeed Cache options in cPanel, the static-file expiry is also honored there, but keeping the rules in .htaccess means the behavior travels with the site if you migrate. One caution: user avatars change when a member re-uploads, and FluxBB keeps the same filename. A one-month cache on img/avatars/ can therefore show a stale avatar. Scope the aggressive caching to theme assets and apply a shorter window to the avatar folder with a nested .htaccess inside img/avatars/ that sets max-age=86400.
CDN Offload and PHP Upload Limits
A CDN is the highest-value media change available to a shared account because it moves repeat image delivery off your origin entirely. FluxBB generates relative paths for its own assets, so a reverse-proxy CDN such as Cloudflare works without touching the database. Point your domain's DNS at the CDN, enable caching for static extensions, and the Cache-Control and Vary headers you already set will govern edge behavior correctly. This offloads avatars, smilies, and style images while keeping dynamic forum pages served from origin. If you ever relocate the board to a new domain, the pathing concerns are similar in spirit to those covered in our guide on rewriting serialized settings, sessions, and image paths, though FluxBB's relative asset handling makes it far simpler.
Finally, align PHP upload limits with your avatar policy using a .user.ini file in the FluxBB root, which the PHP Selector honors on CloudLinux without any server access. Since avatars are capped at kilobytes, modest values are appropriate and protect the account from abusive large POST requests:
upload_max_filesize = 2M
post_max_size = 4M
memory_limit = 128MThese ceilings sit comfortably above FluxBB's own 15 KB avatar limit while preventing a misconfigured or exploited upload from consuming resources. Confirm the active values in cPanel's MultiPHP INI Editor or DirectAdmin's PHP settings after the file is saved; .user.ini changes take effect after the PHP process recycle window, typically within a few minutes. Together, tightened avatar limits, orphan cleanup, WebP twins for static assets, correct cache headers, and a CDN give FluxBB a lean, fast media layer entirely within the boundaries of an unprivileged hosting account.