Compression is one of the few performance changes that is genuinely free: the server sends a smaller file, the browser expands it, and the page arrives faster. cPanel's Optimize Website tool switches it on in two clicks. It is disabled by default, so this is a change worth making on almost every account.
Enabling compression
- Log in to cPanel from My Products & Services.
- Under Software, open Optimize Website.
- Choose one of the three options:
- Disabled - the default. No compression.
- Compress All Content - the simplest choice and the right one for most sites.
- Compress the specified MIME types - compress only the types you list.
- Click Update Settings.
The change applies immediately. There is no need to restart anything.
Which option should you pick?
Compress All Content for a normal website. Apache is sensible about what it compresses, and the overhead is negligible on modern hardware.
Choose specified MIME types only if you have a specific reason - for example a site that serves mostly large media files, where you want to compress the text and leave everything else alone. A sensible list:
text/html
text/plain
text/css
text/xml
text/javascript
application/javascript
application/json
application/xml
image/svg+xmlAn important limitation
cPanel states this on the page itself, and it catches people out:
This setting changes mod_deflate usage by Apache only. Use the MultiPHP INI Editor interface to manage zlib compression on PHP scripts.
In other words, Optimize Website handles what Apache serves directly - your stylesheets, scripts and static HTML. Output generated by PHP is governed separately. If you want that compressed too, open Software → MultiPHP INI Editor, switch to Editor Mode and add:
zlib.output_compression = OnOnly do this if your application is not already compressing its own output. Compressing twice produces broken pages.
Checking that it worked
The response header Content-Encoding: gzip is the proof.
curl -I -H "Accept-Encoding: gzip" https://yourdomain.comOr in the browser: press F12, open the Network tab, reload the page, click the document request and look under Response Headers. You should see content-encoding: gzip, and the transferred size will be visibly smaller than the resource size.
Where compression fits among performance fixes
Compression is worth doing, but be realistic about its place. In rough order of impact on a typical site:
| Change | Typical impact | Effort |
|---|---|---|
| Page caching | Very large - skips PHP and the database entirely | Low |
| Compressing and resizing images | Large on image-heavy sites | Medium |
| Removing unused plugins | Large, and reduces resource usage | Low |
| Enabling compression | Moderate and consistent, on every page | Two minutes |
| Browser caching headers | Moderate for repeat visitors | Medium |
| Newer PHP version | Moderate | Low, with testing |
Compression is the best return on two minutes of work on this list. It is not a substitute for caching.
Troubleshooting
| Symptom | Cause and fix |
|---|---|
No Content-Encoding header after enabling |
You are testing a file type not on your MIME list, or a caching layer or CDN is serving an older copy. Clear the cache and retest a plain HTML or CSS file. |
| Pages render as garbled characters | Output is being compressed twice - typically Apache plus zlib.output_compression plus a caching plugin. Pick one and disable the others. |
| Site slower after enabling | Very unusual. Check you have not added already-compressed image or video types to the MIME list. |
| Speed test still reports "enable text compression" | The flagged files are probably served by a third party, such as an external font or analytics script. You cannot compress what you do not host. |
| Downloads arrive corrupted | An archive or binary type has been added to the compression list. Remove it. |
| Setting will not save | A conflicting rule in .htaccess may be interfering. Check for an existing mod_deflate block and remove the duplicate. |
Frequently asked questions
Will this break anything?
Very unlikely. Compression is a decades-old, universally supported feature, and browsers that cannot handle it simply receive the uncompressed version. The one real risk is compressing twice.
Does it use my CPU allocation?
Compression costs a small amount of CPU per request and saves I/O and bandwidth. On a normal website the trade is strongly worthwhile.
My caching plugin already does this. Do I need it too?
No, and enabling both can double-compress. Check what your plugin is doing first; if it already sets gzip on your pages, leave Optimize Website disabled or restrict it to static files the plugin does not handle.
What about Brotli?
Brotli generally compresses better than gzip. This tool controls Apache's mod_deflate specifically. If Brotli matters to you, it is usually delivered through a CDN in front of the site.
Should I compress my images this way?
No. Reduce image file sizes properly instead - resize to the dimensions actually displayed, and export in a modern format such as WebP. That saves far more than gzip ever would.
Does compression help SEO?
Indirectly. Page speed is a ranking factor and affects how many visitors stay, so anything that makes pages arrive faster helps.
