Your Flashcloud hosting already compresses responses before they leave the server. LiteSpeed Web Server supports both gzip and Brotli natively and applies them automatically. There's nothing to install or configure to get compressed HTML, CSS, and JavaScript on every page load. If a speed test tool flags "enable compression," it's almost always measuring something else. Sometimes it's checking a plugin setting that doesn't reflect what's actually happening at the server level.
This is part of the same server-level stack described in How we make your site fast: LiteSpeed plus LSCache handle the heavy lifting before WordPress or any plugin gets involved.
Why you don't need a compression plugin
Gzip and Brotli both shrink text-based responses (HTML, CSS, JS, SVG, JSON) before they're sent over the network, and the browser decompresses them on arrival. Brotli generally compresses somewhat smaller than gzip at equivalent settings. Both are supported at the web server level on Flashcloud, and LiteSpeed negotiates whichever one the visitor's browser supports through the standard Accept-Encoding request header.
Because this happens at the server, it applies to every request automatically: static files, dynamic PHP output, WordPress pages, anything. A WordPress plugin that claims to "enable compression" is either redundant or, in some cases, working against the server by trying to compress a response twice.
How to verify it's working
You don't need to trust that it's on. You can check the response headers directly.
Using curl
curl -sI -H "Accept-Encoding: br,gzip" https://yourdomain.com/
Look for a content-encoding header in the response. It should read br (Brotli) or gzip. If your terminal doesn't have a recent curl build with Brotli support, you'll still see gzip fall back correctly. That's expected and still means compression is active.
Using browser devtools
Open devtools, go to the Network tab, reload the page, and click any HTML or JS request. Check the response headers for content-encoding. You can also add a "Content-Encoding" column to the Network panel directly for a quicker scan across many requests.
When a page speed tool still flags it
If a third-party audit tool says compression is missing, check these before assuming something's broken:
- The tool tested a redirect, not the final page. A 301 or 302 response won't carry a compressed body. Test the final URL after any redirect resolves.
- The asset is already compressed. Images, fonts, and video files are typically stored pre-compressed and gzip or Brotli won't shrink them further. Some tools flag this incorrectly as a missed opportunity.
- A CDN or proxy is stripping the header. If you're running Cloudflare in proxy mode from the portal's Cloudflare CDN page, traffic passes through Cloudflare's edge before reaching your browser. Seeing compression at the edge instead of the origin is normal and doesn't mean origin compression is off.
- The response is genuinely tiny. Servers often skip compression on responses under roughly 1KB, since compressing that little data isn't worth the overhead.
If you're troubleshooting a slow site
Compression is rarely the actual bottleneck once you've confirmed it's active. It's one piece of a much larger stack. If pages still feel slow, the usual culprits are heavier: unoptimized images, too many active plugins, or a theme loading excess scripts. Work through My WordPress site is slow for a full diagnostic pass, and if you're running a store, Running a WooCommerce store covers the caching behavior specific to cart and checkout pages.
Before making any server-level or plugin changes while troubleshooting, it's worth testing on a copy of the site first. See Using WordPress staging for the safe workflow.