Category Archives: technical

Brotli Compression

Most servers use gzip to compress text files before they are sent across the internet. This makes the files smaller, and then the web browser will automatically unzip them. The lose in the zipping and unzipping time is more than made up for in performance gains – at least for text files. This is because text files are pretty inefficient in terms of space used.

Brotli is a generic-purpose lossless compression algorithm that compresses data using a combination of a modern variant of the LZ77 algorithm, Huffman coding and 2nd order context modeling, with a compression ratio comparable to the best currently available general-purpose compression methods. It is similar in speed with deflate but offers more dense compression. Now, while that sounds impressive, do remember that most of the bandwidth hogs on web pages are media, which should not be gzipped as they are already compressed, so if you have gzip enabled fro text files, then there are small gains to be got from shifting to Brotli, but don’t expect massive gains unless you are a text only site. Still every little counts and, if it’s easy enough to install, then why not.

The only downside I see with Brotli compression is, most popular web servers have not incorporated it as part of their features.
That means, to enable Brotli compression, you need to check first if your hosting provider allows it or not.

Prerequisites
I’m not sure if there is a technical reason behind this, but all the browsers I tested with require HTTPS in order to enable Brotli support.
• Apache/NGINX installed.
• HTTPS enabled.
• Access to your Apache/NGINX installation (no shared hosting)
• Brotli binary installed

Installing Brotli

apt-get install brotli

Setting up on Apache

Apache has supported brotli since version 2.4.26 by way of the mod_brotli module.
However, I can’t find any information on this so we are installing this module by kjdev

Install the Module

git clone --depth=1 --recursive https://github.com/kjdev/apache-mod-brotli.git
cd apache-mod-brotli
./autogen.sh
./configure
make
install -D .libs/mod_brotli.so /usr/lib/apache2/modules/mod_brotli.so -m 644
cd /etc/apache2/mods-available
echo "LoadModule brotli_module /usr/lib/apache2/modules/mod_brotli.so" > brotli.load

 

This has added the .load file to the mods available. We need to create an accompanying config file called brotli.conf, adding:

<IfModule brotli_module>
  BrotliCompressionLevel 10
  BrotliWindowSize 22
  AddOutputFilterByType BROTLI text/html text/plain text/css application/x-javascript
<IfModule brotli_module>

 

Enable the module

a2enmod brotli
service apache2 restart

 

You should now see in the response header that the page is compressed with brotli (br):

Setting up on Nginx

Google has released a Nginx Brotli module
Download the module

cd /usr/local/src
git clone https://github.com/google/ngx_brotli.git
cd ngx_brotli
git submodule update --init --recursive

 

Rebuild Nginx with our new module
You should run nginx -V to get your config string and add:

cd /opt/nginx-1.13.1/  (or your own path)
./configure YOUR CONFIG STRING --add-module=/usr/local/src/ngx_brotli
make
make install

 

Finally, add to your nginx.conf file

http {
    brotli on;
    brotli_static on;
}

 

In conclusion, the setup for both Apache and Nginx is pretty painless. If the browser does not support brotli it can always fallback to the ever faithful gzip.

Does your browser support Brotli?
Browsers which support Brotli send ‘br’ along with ‘gzip’ in accept-encoding request header. If Brotli is enabled succesful on your web server, you will get response in Brotli compressed format.

HTTP/2 200
server: nginx
date: Thu, 11 Apr 2019 21:01:27 GMT
content-type: text/html
content-length: 32395
last-modified: Thu, 04 Apr 2019 13:49:47 GMT
etag: "3c420-585b4a4af8fe6-br"
accept-ranges: bytes
cache-control: max-age=0
expires: Thu, 11 Apr 2019 21:01:27 GMT
vary: Accept-Encoding,User-Agent
content-encoding: br
strict-transport-security: max-age=31536000

You may also check here, if your server support Brotli.

In combiniation with Swift, you may disable GZIP in Settings->Caching->General and add these rules in Settings->General->Tweaks: Custom Htaccess 

AddOutputFilterByType BROTLI_COMPRESS text/plain text/css text/html application/json application/javascript application/x-javascript text/xml application/xml application/xml+rss text/javascript
SetOutputFilter BROTLI_COMPRESS
SetEnvIfNoCase Request_URI \.(?:gif|jpe?g|png)$ no-brotli

 

If you are unsure of how to enable Brotli on your server, then hopefully this helps!

Proxy caching with Cloudflare

What is proxy caching

Speed is important. Even if you have optimized your site already, the load times can vary based on the physical location. You may also have a good server, but you can still improve TTFB and page load time with proxy caching.

Many sites are using Cloudflare as a CDN, however you can also use it to cache your pages, and let Cloudflare serve them to your visitors. It means, that on the first visit Cloudflare will cache the page content as well, so following requests won’t even hit your server. Of course if you are using Cloudflare for page caching you will need to enable Auto Purge for Cloudflare.

NOTE: only Cloudflare Business and Enterprise packages let you to bypass the cache based on cookies, however in most cases you can also use this feature with their free plan, but your logged in users will get the same cached pages. Of course My Account, Cart, Checkout (and any excluded) pages won’t be cached.

Let’s see how can Cloudflare caching can improve the speed of an already optimized site.

Environment:
Siteground StartUp Hosting (Bulgaria)
WordPress 5.0.3
OceanWP + Elementor (Business demo content installed)

Configuration

Swift Performance

Enable Auto Purge and set API credentials to let Swift Performance clear cache if it is necessary

Also enable Proxy Cache and set the Proxy Cache Maxage to 1 year (30879000)

Cloudflare

Add a Page rule in Cloudflare to cache everything

Testing

We will test the site loading speed with GT Metrix from 2 locations: Vancouver, Canada and Hong Kong, China. We will choose Chrome desktop browser for the tests.

First test

Swift Performance is inactive, Cloudflare standard caching enabled. Even if Cloudflare is active, it caches only static content, not the page itself.

Location Fully loaded time Onload Contentful paint Test link
Vancouver 1.5s 1.5s 1.2s
Hong Kong 1.9s 1.8s 1.8s

With Swift Performance

We activated Swift Performance and configured it. We already improved the speed, but is it enough? Not for us…

Location Fully loaded time Onload Contentful paint Test link
Vancouver 1.3s 1.2s 0.9s
Hong Kong 1.6s 1.4s 1.3s

Proxy cache enabled

Lets see what happens if we let Cloudflare cache the page itself.

Location Fully loaded time Onload Contentful paint Test link
Vancouver 0.7s 0.6s 286ms
Hong Kong 0.5s 286ms 224ms

Conclusion #1

The most important factor for user experience is Contentful paint time. We decreased it to 2-300ms, which is almost instant load. That means when the user clicks your link in Google results, the page will be shown instantly on their device.

But there is an other important aspect: load time on 3G

Testing on 3G

We will test the site loading speed with GT Metrix from 2 locations: Vancouver, Canada and Hong Kong, China. We will choose Chrome desktop browser for the tests again, but now we limit the connection speed to 3G

First test

Swift Performance is inactive, Cloudflare standard caching enabled. Even if Cloudflare is active, it caches only static content, not the page itself.

Location Fully loaded time Onload Contentful paint Test link
Vancouver 10.7s 9.8s 4.2s
Hong Kong 12.5s 11.2s 7.0s

With Swift Performance

We activated Swift Performance and configured it. Lets see if it is good enough this time…

Location Fully loaded time Onload Contentful paint Test link
Vancouver 5.8s 5.6s 3.3s
Hong Kong 5.6s 5.4s 3.3s

Proxy cache enabled

Lets see what happens if we let Cloudflare to cache the page itself.

Location Fully loaded time Onload Contentful paint Test link
Vancouver 4.4s 4.2s 2.2
Hong Kong 4.4s 4.2 2.1s

Conclusion #2

We decreased the rendering time (contentful paint) to 2.2s. If you imagine yourself with your phone in your hand, you just clicked to a link somewhere, and you need to wait 5-7s to see the content, or only ~2s you can imagine the difference 🙂