Compression reduces the bytes transferred for text resources such as HTML, CSS and JavaScript. A website may already receive gzip or Brotli compression from its web server or CDN, so measure the existing response before adding another compression layer.
IN THIS ARTICLE
What you need before you begin
Choose a public text page to test and note whether the site uses a caching plugin, LiteSpeed or a CDN. Keep a copy of the current .htaccess file. Compression does not usually help already compressed images or archives, and it does not correct slow application queries.
01 Check and enable website compression in cPanel
- Open browser developer tools, reload the page and inspect its response headers. Look for
Content-Encoding, which may already begziporbr. - If cPanel provides Optimize Website, open it and review the current setting. Choose the appropriate compression option for text content supported by the server, then save.
- Reload an uncached test response and inspect the encoding again. If a CDN serves the response, also confirm the origin setting through your normal support or developer workflow.
- Leave PHP
zlib.output_compressionalone unless the application or hosting configuration specifically requires it. Turning on both PHP and server compression without checking their interaction can break output.
02 Example: inspect compression on a real page response
From your workstation, request a public text page with curl and ask it to negotiate supported compression. Replace example.com with the website. This command downloads a normal GET response, displays its headers and discards the body locally.
curl --silent --show-error --compressed \
--connect-timeout 10 --max-time 20 \
--dump-header - --output /dev/null https://example.com/
Read the result: Look for Content-Encoding such as gzip or br. A CDN or reverse proxy may apply the encoding, so this describes the response received by the client rather than proving a particular cPanel setting is responsible. curl supports only the compression algorithms included in its build.
Compare equivalent requests to the same page before and after a reviewed configuration change. Images and archives may already be compressed and need no additional encoding. If the application deliberately disables compression for a sensitive response, investigate its reason before overriding the setting.
Confirm the expected result
Check the homepage, CSS, scripts, downloads and a form submission. Compare transferred size on equivalent requests, allowing for browser and CDN caches.
What if compression breaks pages or Optimize Website is missing?
If pages become blank, corrupted or repeatedly download incorrectly, revert the compression change and restore the relevant configuration backup. A missing Optimize Website tool can mean the server handles compression elsewhere; ask support rather than pasting arbitrary handler directives.