I started messing around with my WordPress by first adding in a layer of security in Adding Nginx in Front of WordPress. After putting Nginx in front of my WordPress, I decided that I would further secure it by also Building a Static WordPress. That’s great and all but maybe it was time to make Nginx give me some performance gains rather than just some security controls. That is exactly what we’re going to do in this blog post. Now that Nginx is sitting in front of WordPress, we can use it to control some of the performance aspects.
Generating a Baseline Performance Report
First thing’s first though. Let’s first get us a baseline of where the site is at and what needs work. Google’s PageSpeed is a great tool for finding out what’s slowing down your site. Below is the report for this blog.
Figuring Out What to Fix
As you scroll down the report, there are a number of things to correct. An example of such things would be the Opportunities section:
Adding a Caching Policy
An initial first step to correct some performance issues, would be to enable caching policies on the Nginx server. Given that we’re serving mostly all static content now, there’s no need to cache any content that we serve up. Nginx is already serving static data so we don’t need to rely on a backend. Let’s modify the static path’s caching policy for clients by adding the cache-control response header:
...
location /status {
return 200 "healthy\n";
}
location / {
try_files $uri $uri/ /index.html;
add_header 'Cache-Control' "public,max-age=31536000,stale-while-revalidate=360";
#proxy_pass https://wordpress;
#proxy_ssl_verify off;
#proxy_set_header Host live-blog.shellnetsecurity.com;
#proxy_set_header X-Forwarded-For $remote_addr;
}
location /sitemap {
proxy_pass https://wordpress;
proxy_ssl_verify off;
proxy_set_header Host live-blog.shellnetsecurity.com;
proxy_set_header X-Forwarded-For $remote_addr;
}
...
This example configuration snippet shows that we are adding the Cache-Control response header to the requests to “/”. This means we’re doing what we planned and are only telling clients to cache data that isn’t sent to the backend WordPress server. Additional parameters that can be supplied to Cache-Control are documented here.
Enable Gzip Compression
By default, even with gzip on, Nginx will not compress all files. Let’s add some additional content to our http config block (note the additional gzip directives bolded listed below gzip on):
http {
proxy_set_header X-Real-IP $proxy_protocol_addr;
proxy_set_header X-Forwarded-For $proxy_protocol_addr;
sendfile on;
tcp_nopush on;
tcp_nodelay on;
keepalive_timeout 65;
types_hash_max_size 2048;
include /usr/local/nginx/conf/mime.types;
default_type application/octet-stream;
access_log /dev/stdout;
error_log /dev/stdout;
gzip on;
<strong> gzip_vary on;
gzip_min_length 1000;
gzip_proxied expired no-cache no-store private auth;
gzip_types text/plain text/css text/xml text/javascript application/x-javascript application/xml;
gzip_disable "MSIE [1-6]\.";
</strong> resolver kube-dns.kube-system.svc.cluster.local;
include /etc/nginx/sites-enabled/*;
}
With those changes added to our Nginx configuration, restart Nginx for the changes to take effect.
Testing Our Page Again
Now that those changes should be live in your Nginx, let’s check how we did again on PageSpeed.