New Topic

cPanel & WHM Feature Requests Topic Web Servers

Category Web Servers

Tags brotli

Configure Brotli per-account

ServerG shared this idea ago

Open Discussion

As a server administrator, I would like to be able to configure Brotli on a per-domain basis, allowing each cPanel User to enable or disable it per-account, so that I can offer Brotli support without causing problems for users that don't require it.

=================

mod_brotli has been recently released in the April 3 EasyApache update: https://forums.cpanel.net/threads/easyapache-4-update-april-3-2018.625739/

Unfortunately installing mod_brotli configures serverwide rules. This results in a 'double compression' issue with websites which use pre-compressed gzip css and JS files. Websites fail to load on Brotli enabled browsers (Chrome) and show the error ERR_CONTENT_DECODING_FAILED.

Instead of serverwide rules it would be better if mod_brotli.conf simply loaded the Brotli module and allowed the user to enable / disable brotli compression themselves via .htaccess. Eventually this could be controlled by the 'Optimize Website' plugin in the frontend of cPanel, which could generate the .htaccess rules for the cPanel user.

This would bring mod_brotli inline with the way mod_deflate works on cPanel and immediately resolve the 'double compression' issues encountered by allowing users to enable / disable brotli compression.

I like this idea 0

Replies (4)

Web Guy ●

Is there any update regarding this feature? It seems to me that it's a very important feature. It would let me enable Brotli only on accounts/websites that I know can use it.

My concern is, if I enable Brotli in Easy Apache 4 and that enables it server wide, then a number of my sites may have problems (gzip stops working or maybe site failing to load at all).

What I think we need is a Cpanel solution to enable Brotli (in the Optimize Website page), with a fall back to Gzip for browsers who don't support Brotli.

Reply URL

BlogLogistics ●

@Web Guy I have Brotli enabled in EA4 (server wide). It is not interfering with websites that don't "use" it. Gzip, etc. does work still. Connections that are using brotli as well as those not, still all work. Requests from connections using brotli will get that, those not requesting such connections won't use brotli.

URL

Greg ●

I can't remember off the top of my head what you must do but there is a way you can make brotli ignore files that have already been compressed then all you need to do is disable the default compression for the server / accounts and let brotli take over.

e.g. disable compression via cpanel and also say you have wordpress site, disable compression there in htaccess or any cache / performance plugins and then brotli will be used.

Not a perfect solution but may help til better support is released

URL

kdean ●

If you're just dealing with Wordpress sites. I did the following.

Installed brotli via EasyApache.

Commented out the lines in /etc/apache2/conf.d/brotli.conf

to not enable it server-wide.

For non-wordpress sites you should be able to copy the contents of the brotli.conf into the .htaccess of a site.

For wordpress, if you use W3 Total Cache to pre-build cache files, Brotli support is built in and can be assigned individually to HTML / XML files & CSS & JS in case you want to mix and match gzip and brotli. This is done in the Browser Cache section. Brotli is slower than gzip for on-the-fly compression, so if you're not using pre-built cached files you may want to stick with gzip.

Note the W3 Total Cache plugin requires the Brotli PHP Extension to be installed. I installed with the following instructions:

https://yeahlinux.com/install-brotli-apache-module-and-php-extension-in-cpanel-ea-4/

Couple this with minification of at least css & js files and you can really speed things up. Currently don't recommend page minification with W3TC due to a bug with the minified pages not including the media query string properly to force busting of the cache when css and js is updated.

Reply URL

Web Guy ●

Thanks for the replies. :)

Yep, I'm running a mix of Joomla and Wordpress sites. Both platforms are Gzipping, together with Cpanel Optimize Websites feature.

I get the idea, so I disable Gzip on Cpanel and sites, then the EA4/server Brotli should take over and do its stuff.

But don't we still have a problem for older browsers that don't support Brotli (genuine question, I really don't know)? I.E. If a browser doesn't support Brotli, then completely non (huge) compressed files will be served to it.

Reply URL

kdean ●

Most browsers have been compatible for a while so users getting uncompressed files is likely negligible.

https://caniuse.com/#feat=brotli

Using the pre-compressed file method on wordpress I mentioned allows you to do both so an older browser could request gzip and newer brotli.

Reply URL

Web Guy ●

Wow, great info in both your replies, thanks :)

I use Swift Performance, similar to W3. I'm getting great first visit loading speeds on WP sites, on desktops. Just trying to squeeze out every possible performance tweak to get my mobile sites loading under 2 secs. Not easy!

The biggest thing I've found that improved perceived loading / first meaning paint is making critical CSS files (and load the other/non above the fold CSS at the end). Amazing difference.

Anyway, thanks for the info re Brotli. I'll check it all out.

Hopefully Cpanel will implement a true / easy solution at some point, would be a lot less hassle!

URL

Fix Ourselves ●

# Rules to correctly serve gzip compressed CSS and JS files.

# Requires both mod_rewrite and mod_headers to be enabled.

# Serve brotli compressed CSS files if they exist and the client accepts gzip.

RewriteCond %{HTTP:Accept-encoding} br

RewriteCond %{REQUEST_FILENAME}\.br -s

RewriteRule ^(.*)\.css $1\.css\.br [QSA]

# Serve gzip compressed CSS files if they exist and the client accepts gzip.

RewriteCond %{HTTP:Accept-encoding} gzip

RewriteCond %{REQUEST_FILENAME}\.gz -s

RewriteRule ^(.*)\.css $1\.css\.gz [QSA]

# Serve brotli compressed JS files if they exist and the client accepts gzip.

RewriteCond %{HTTP:Accept-encoding} br

RewriteCond %{REQUEST_FILENAME}\.br -s

RewriteRule ^(.*)\.js $1\.js\.br [QSA]

# Serve gzip compressed JS files if they exist and the client accepts gzip.

RewriteCond %{HTTP:Accept-encoding} gzip

RewriteCond %{REQUEST_FILENAME}\.gz -s

RewriteRule ^(.*)\.js $1\.js\.gz [QSA]

# Serve correct content types, and prevent mod_deflate double gzip.

RewriteRule \.css\.gz$ - [T=text/css,E=no-gzip:1]

RewriteRule \.js\.gz$ - [T=text/javascript,E=no-gzip:1]

RewriteRule \.css\.br$ - [T=text/css,E=no-gzip:1]

RewriteRule \.js\.br$ - [T=text/javascript,E=no-gzip:1]

# Serve correct encoding type.

Header set Content-Encoding gzip

# Force proxies to cache gzipped & non-gzipped css/js files separately.

Header append Vary Accept-Encoding

</FilesMatch>

# Serve correct encoding type.

Header set Content-Encoding br

# Force proxies to cache gzipped & non-gzipped css/js files separately.

Header append Vary Accept-Encoding

</FilesMatch>

</IfModule>

URL