Enable Gzip Compression in cPanel for Faster Page Loads

If you've ever run your site through Google PageSpeed Insights or GTmetrix and seen "Enable text compression" sitting in the red, you're leaving free performance on the table. Gzip (and its newer cousin, Brotli) can shrink your HTML, CSS, and JavaScript by 60-80% before they're sent over the wire, and turning it on in cPanel usually takes less than two minutes. Here's how to check whether it's already running, turn it on if it isn't, and avoid the couple of ways this can go sideways.

Symptom: "Enable Text Compression" or Slow Time-to-First-Byte

You'll usually run into this one of three ways:

• A PageSpeed audit flags "Enable text compression" with a list of your CSS/JS files and how many KB you'd save.
• Your site feels sluggish on mobile or slower connections even though server CPU and RAM look fine.
• You migrated to a new server or reset your hosting account and compression that used to be on is suddenly off.

This is a server-response-size problem, not a caching or database problem — it sits in a different bucket from typical WordPress speed fixes like image optimization or a caching plugin. Compression works on every response your server sends, images excluded (they're already compressed in their own format), so it's worth checking even if you've already installed a caching plugin.

Cause: Compression Isn't Enabled at the Web Server Level

Gzip and Brotli compress text-based responses (HTML, CSS, JS, JSON, XML, SVG) before they leave your server. The browser decompresses them on arrival — nearly instant on modern devices — and the total bytes transferred drop dramatically. If it's off, one of these is usually why:

• cPanel's "Optimize Website" feature was never turned on for the account.
• A previous .htaccess edit or a security plugin overwrote the compression rules.
• The account moved to a new server during a migration, and per-account settings didn't carry over.
• A CDN or reverse proxy in front of your site (Cloudflare, for example) is set to pass through origin headers without adding its own compression, and the origin isn't compressing either.

Fix 1: Turn On Optimize Website in cPanel

This is the fastest path for anyone on shared or reseller hosting, and it's the first thing to check before touching any files.

1. Log in to cPanel and search for Optimize Website in the search bar (it's under the Software section).
2. You'll see three options: Disabled, Compress all content, and Compress the specified MIME types.
3. Select Compress all content for the simplest setup, or pick specified MIME types if you want to exclude things like already-compressed archives.
4. Click Update Settings. This applies immediately — no restart needed, no downtime.

Under the hood, this writes an mod_deflate (or mod_brotli, depending on your server's Apache/LiteSpeed build) directive into your account's configuration. You don't need to touch .htaccess for this to work.

Fix 2: Enable Gzip Manually via .htaccess

If "Optimize Website" isn't available on your plan, or you're on a VPS running Apache directly, you can add compression rules yourself. Back up your existing .htaccess first, then add this block near the top:

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

Don't add image MIME types like image/jpeg or image/png here — they're already compressed, and running gzip over them wastes CPU for zero benefit and can occasionally make the file slightly larger.

Fix 3: Enable Brotli If Your Server Supports It

Brotli generally compresses 15-20% better than gzip for text content, and most modern browsers support it. If your server runs LiteSpeed or a recent Apache/Nginx build with mod_brotli, you can layer it on top:

<IfModule mod_brotli.c>
  AddOutputFilterByType BROTLI_COMPRESS text/html text/css text/javascript
</IfModule>

If you're not sure whether your server has Brotli compiled in, stick with gzip via "Optimize Website" — it's supported everywhere and the performance gap between the two is small enough that it's not worth chasing on a shared hosting box.

Verifying Compression Is Actually Working

Don't just trust the cPanel toggle — confirm the response headers. From a terminal:

curl -I --compressed https://yourdomain.com/

Look for Content-Encoding: gzip or Content-Encoding: br in the output. If it's missing, something upstream (a CDN, a caching layer, or a misconfigured .htaccess) is stripping it before the response reaches the browser.

Common Pitfalls

• Compressing already-compressed files. Adding DEFLATE rules for images, PDFs, or ZIP files wastes CPU and can bloat file size slightly. Stick to text-based MIME types.
• Cloudflare double-handling. If you're behind Cloudflare, it usually compresses responses at the edge regardless of your origin settings — that's fine, and you should still enable it at the origin too, since Cloudflare occasionally passes requests straight through on cache misses.
• Security plugins overwriting .htaccess. Some WordPress security plugins regenerate .htaccess on their own schedule. If your compression rules keep vanishing, use cPanel's "Optimize Website" instead — it lives outside .htaccess and survives plugin rewrites.
• LiteSpeed servers ignoring mod_deflate syntax. If you're on LiteSpeed Web Server, use the LiteSpeed Cache plugin's compression setting instead of raw Apache directives — LiteSpeed reads a slightly different config format for some directives.

Prevention: Keep It Working After Migrations and Updates

Compression settings are easy to lose track of because they're invisible when working correctly. A few habits keep it from silently breaking:

• After any site migration (including moving to SkyServer), re-check "Optimize Website" — account-level settings don't always transfer automatically.
• Re-run the curl -I --compressed check after any .htaccess regeneration from a plugin or one-click installer.
• If you manage multiple accounts on a VPS via WHM, enable compression at the Apache/Nginx global config level so new accounts inherit it by default instead of relying on every user to turn it on manually.

Frequently Asked Questions

Will enabling compression slow down my server's CPU?

The CPU cost of gzip compression is small — a few milliseconds per request on modern hardware — and it's paid once per response, not per visitor session. The bandwidth savings almost always outweigh the CPU cost, even on modest shared hosting plans.

Do I need to compress images too?

No. JPEG, PNG, and WebP are already compressed formats, so running gzip over them typically saves nothing and occasionally adds a few bytes. Focus compression rules on HTML, CSS, JavaScript, and other plain-text formats.

My "Optimize Website" setting shows compression is on, but PageSpeed still flags it. Why?

Check whether a CDN or caching layer in front of your site (Cloudflare, a page cache, or a reverse proxy) is serving a cached copy of the response that predates the setting change. Purge the CDN cache and any server-side page cache, then re-test with curl -I --compressed.

Is Brotli better than gzip, and should I switch entirely?

Brotli usually compresses 15-20% smaller than gzip for text content, but the difference matters more on high-traffic sites than small brochure sites. If your server supports it, enabling both (with Brotli as the primary) is safe — servers automatically fall back to gzip for browsers that don't support Brotli.

Does this help with images and video, or only text?

Gzip and Brotli only help with text-based content. For images, the equivalent win comes from proper compression at upload time (WebP/AVIF formats, resizing before upload) and for video, from using an external host or CDN rather than serving raw files from your hosting account.