We will be talking about the main points recommended to optimizing your WordPress for speed and scale with Web.Eng’s system.

The items are not in any specific order, but we have seen if they are generally applied, it makes a huge difference in how fast a site is and how many CPU/memory resources are conserved (ie. scale better).

This overview goes into using terminal to debug and confirm some things like cache, but some commands could be substituted by looking at the requested page header responses via the browser.

This article covers the following topics:

  • Page Caching
  • XHR request to admin-ajax.php
  • Transients Object Caching
  • HTTP/2
  • Nginx-Only

PAGE CACHING LAYER (MOST IMPORTANT)

This layer primarily involved hitting the page caching stack of our layers.

To confirm, this is simply looking for the X-Cache-Status: HIT header in the page response.

Via command line this would be:

curl -I -X GET http://www.example.com/ | grep -i "HTTP/\|Cache\|Cookie"

After running that command twice, it should give a response like so:

HTTP/1.1 200 OK
X-Cache-Config: 0 0  
X-Cache-Status: HIT

If it shows X-Cache-Status: MISS or X-Cache-Status: BYPASS then that means some something is causing it to be skipped, usually due to a PHPSESSID cookie being set, like below:

Set-Cookie: PHPSESSID=XXXXXXXXX; path=/
Set-Cookie: wordpress_test_cookie=WP+Cookie+check; path=/

Try to avoid setting a session cookie when the pages don’t have to be dynamic. A helpful command to find what theme or plugin is causing it is

cd ~/sites/www.example.com/
find ./wp-content/ -type f -name '*.php' -exec grep -H "session_start(" {} \;

STOP DOING AJAX POST/GET REQUESTS TO ADMIN-AJAX.PHP

Upon requesting the homepage or certain pages on the site, there are sometimes plugins or themes which do XHR request to admin-ajax.php

Request URL: /wp-admin/admin-ajax.php 
Request Method: POST 
Status Code: 200

Under high traffic load, these have a tendency to overload the server resources due to every POST request to it not being cache-able. This means that a dynamic php worker will have to server ever single one of these requests and use up a lot of the servers CPU.

The first thing to do is to find that they are happening, then to locate which Plugin or Theme is hooking into WordPress that displays them.

Our recommended plan of action is to then remove or disable them, as it’s more important for the site to remain up, rather than overloading the resources so no other visitors are able to visit the site.

REDIS OBJECT CACHE

Transients API, say no to MySQL.

This off-loads queries being made into the Redis object store, so it speeds up and helps overall site performance.

We have a custom drop-in plugin replacement which off-loads the WordPress Transient API to make sure these don’t go into the Database. Please contact support if you’d like that installed on a specific site.

HTTP/2 – BECOME ONE WITH IT.

HTTP/2 is an update to the protocol by the Internet Engineering Task Force (IETF). You’ll get a nice performance boost with compatible clients, and anything that doesn’t support it will gracefully fallback to the old protocol. The performance gain is achieved by only requiring one persistent connection to the server in order to load the website’s assets. Other benefits are prioritization of higher resources, header compression, and multiplexing (multiple requests over the same connection).

In order to support HTTP/2, an SSL certificate will need to be installed on your application. Once that’s done you may contact support for further instructions.

NGINX-ONLY

Switching your site to Nginx-only can help alleviate load caused by too many dynamic PHP requests with a built-in pressure-release valve. All Web.Eng WordPress websites are run from the NGINX framework.

HELPFUL TOOLS/COMMANDS

  • Pingdom – You can see how long the entire site takes to load; helpful to see which assets (js/images/css) take a while to load.
  • Query Monitor – This plugin is useful for finding slow queries on the front and back end. We recommend enabling the plugin as needed.
  • NewRelic – (VPS ONLY) We can connect New Relic so you can get some detailed reporting about your application performance.
  • (VPS ONLY) To view CPU & RAM live, you can use htop (via SSH)
  • Use curl to check the headers of the site: 
    curl -I -X GET http://www.example.com/

    In the header response, `X-Cache-Status: HIT` could be used to verify if that page cache is hit.