Nginx, nginx, nginx

1. Enable Gzip compression for HTML, CSS and JavaScript files

As you know, the HTML, CSS, and JavaScript files used to build pages on modern websites can be huge. In most cases, Web servers can compress these and other text files instantly to save network bandwidth.

One way to see if the Web server is compressing files is to use the browser’s developer tools. For many browsers, you can access these tools using the F12 key, and the information is on the Network TAB. Here’s an example:

As you can see in the lower left, there is no compression: the text file is 1.15MB in size, and a lot of data is transferred.

By default, compression is disabled in NGINX, but depending on your installation or Linux distribution, some Settings may be enabled in the default nginx.conf file. Here, we enable gzip compression in the NGINX configuration file:

gzip on;
gzip_types application/xml application/json text/css text/javascript application/javascript;
gzip_vary on;
gzip_comp_level 6;
gzip_min_length 500;
Copy the code

As you can see in the screen shot below, the compressed data transfer is only 260 KB, a reduction of about 80%! For each new user on the page, you can save about 917 KB of data transfer. For our WooCommerce installation, 62 MB per day, or 1860 MB per month.

2. Set the cache header

When the browser retrieves a file for a web page, it keeps the copy in the local disk cache so that when you visit the page again, it doesn’t have to retrieve the file from the server. Each browser uses its own logic to decide when to use a local copy of a file and when to retrieve it again if it has changed on the server. However, as the site owner, you can set cache controls and expiration headers in the HTTP response you send to make your browser’s caching behavior more efficient. In the long run, you’ll get a lot of unnecessary HTTP requests.

First, you can set long cache expiration times for fonts and images, which may not change very often (and when they do, they usually get new file names). In the following example, we instruct the client browser to keep fonts and images in the local cache for a month:

location ~* \.(? :jpg|jpeg|gif|png|ico|woff2)$ { expires 1M; add_header Cache-Control "public"; }Copy the code

3. Enable HTTP / 2

HTTP / 2 is the next generation protocol for serving web pages, designed to make better use of the web and host servers. According to Google Docs, it loads pages faster:

The resulting protocol is more network friendly because of theHTTP / 1.xCompared with the use ofTCPFewer connections. This means less competition with other traffic and longer connection life, which can make better use of available network capacity.

NGINX 1.9.5 and later (and NGINX Plus R7 and later) support the HTTP / 2 protocol, all you need to do is enable it. To do this, include arguments in the HTTP2 listen directive in your NGINX configuration file:

listen 443 ssl http2;
Copy the code

Note that in most cases you also need to enable TLS to use HTTP / 2.

You can verify that you (or any site) support HTTP / 2 with the http2. Pro service:

4. Optimize the log

Treat yourself to a drink of your choice, sit comfortably, and think: When was the last time you checked your access log file? Last week, last month, never? Even if you use it for routine monitoring of your site, you may only focus on errors (400 and 500 status codes, etc.) and not on successful requests.

By reducing or eliminating unnecessary logging, you can save disk storage, CPU, and I/O operations on your server. Not only does this make your server a little faster – if you deploy to the cloud, the freed I/O throughput and CPU cycles may save lives for other virtual machines or applications on the same virtual machine.

There are several different ways to reduce and optimize logging. Here, we focus on three.

Method 1: Disable logging of page resource requests

This is a quick and easy solution if you don’t need to log requests to retrieve common page resources such as images, JavaScript files, and CSS files. All you need to do is create a new block whose location matches these file types and disable logging in it. (You can also add this access_log directive to the location block above our setup header.) Cache-Control

location ~* \.(? :jpg|jpeg|gif|png|ico|woff2|js|css)$ { access_log off; }Copy the code

Method 2: Disable logging of successful requests

This is a more powerful approach because it discards queries with or response code and logs only errors. It is a little more complicated than approach 1 because it depends on how NGINX logging is configured. In our example, we use the Ubuntu Server release contained in the standard nginx. Conf, therefore, no matter how virtual host, all requests are recorded to * * / var/log/nginx/access. * * in the log. 2*xx*“3*xx*

Using an example from the official NGINX documentation, let’s turn on conditional logging. Create a variable $loggable and set it to 0 to request with and code, and otherwise to. This variable is then referenced as a condition in the instruction. 2*xx*“3*xx*“1“access_log

This is the original directive in the HTTP context in ** /etc/nginx.conf ** :

access_log /var/log/nginx/access.log;
Copy the code

Add a map block and reference it from the access_log directive:

map $status $loggable {
    ~^[23] 0;
    default 1;
}

access_log /var/log/nginx/access.log combined if=$loggable;
Copy the code

Note that although this is the default logging format, you need to specify it explicitly when including the if parameter.

Method 3: Minimize I/O operations with buffering

Even if you log all requests, you can minimize I/O operations by turning on the access log buffer. With this instruction, NGINX waits for the log data to be written to disk until the 512 KB buffer is filled or one minute has elapsed since the last flush, whichever comes first.

access_log /var/log/nginx/access.log combined buffer=512k flush=1m;
Copy the code

5. Limit the bandwidth of a particular URL

If the server serves large files (or small but very popular files, such as forms or reports), it may be useful to set the maximum speed at which the client can download the files. If your site is already under high network load, limiting download speeds leaves more bandwidth to keep critical parts of your application responsive. This is a very popular solution used by hardware manufacturers – you may have to wait longer to download a 3GB driver for your printer, but you can still download it while thousands of other people download it.

Use the limit_rate directive to limit the bandwidth of a specific URL. Here, we limit the transfer rate of each file under **/ Download ** to 50 KB per second.

location /download/ {
    limit_rate 50k;
}
Copy the code

You may also want to limit the rate only for large files, which can be done using the limit_rate_after directive. In this example, the first 500 KB of each file (from any directory) is transferred without speed limits, and everything thereafter is capped at 50 KB/s. This speeds up delivery of key parts of the site while slowing down other parts.

location / {
    limit_rate_after 500k;
    limit_rate 50k;
}
Copy the code

Note that the rate limit applies to a single HTTP connection between the browser and NGINX, so do not prevent users from using the download manager to resolve the rate limit.

Finally, you can limit the number of concurrent connections or request rates to the server. See our documentation for more information.