Speeding Up WordPress

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.

PageSpeed mobile numbers

I guess those numbers aren’t terrible but I’m sure they could be better.

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:

Opportunities section of report

In addition, there are some diagnostic items that show up:

Example cache policy items

Fixing Some of the Items

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;
         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]\.";
         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.

Updated PageSpeed details.

The numbers aren’t amazingly stellarly awesomer but they are better. If you look at the overall scoring, we jumped from a 66 to a 72. The final problem left is not something we can correct using Nginx. There are a number of first and third party scripts that are loading and slowing the site down. Next steps will involve researching those scripts and attempting to determine if there are any that can be removed. Until next time!