Improving performance of a WordPress site (1): Getting ready

• July 31 2023
• 4 min. read

Performance is important. Performance will keep people coming back to your site. Performance is very hard to get right, specially for mobile devices.

I'm particularly interested in seeing how my blog (https://publishing-project.rivendellweb.net) does in mobile.

The first step is to check what the browser tells me:

Running PageSpeed Insights will produce both mobile and desktop reports. What I find most interesting is the differences between mobile and desktop and between runs on different browsers.

It also provides both the results of the Chrome User Experience (CrUX) for the site and the artificial results from Lighthouse.

Unfortunately, there is no CrUX data for my site on mobile devices (but there is a CrUX report for desktop that we'll cover later).

Rather than running the PageSpeed report on the browsers, I've chosen to run Lighthouse from the command line hoping to get more consistent results.

I will also use PageSpeed Insights to compare with the results I get locally. I expect the PSI results to be worse.

Preparing to run #

Since I'll be using Lighthouse to measure performance

Both commands will run the same code.

We ask for reports in JSON and HTML (the default Lighthouse format)

the --view flag will open the default browser with the HTML report.

The --output-path is based on shell variables that I built to be able to run both commands at the same time.

The other parameter is the URL we want to run. We type that in the command line. If I were really lazy I would hardcode it into the commands.

lighthouse --formFactor mobile \
--output json \
--output html  \
--view \
--output-path lighthouse-reports/$outputString  $inputUrl

The only difference in the desktop command is the inclusion of --screenEmulation.disable. Without this parameter Lighthouse complains.

lighthouse --formFactor desktop \
--screenEmulation.disabled \
--output json \
--output html  \
--view --output-path lighthouse-reports/$outputString  $inputUrl

I've also built a Bash shell script to run both commands at the same time.

#!/usr/bin/env bash

# variables
formFactor=( "desktop" "mobile" )
inputUrl=$1
outputString=$(date +%Y%m%d-%H%M)


for i in "${formFactor[@]}"
do
  if [[ "${i}" == "desktop" ]]
  then
    echo 'running desktop code'
    lighthouse --formFactor desktop \ 
    --screenEmulation.disabled \ 
    --output json \ 
    --output html \ 
    --view \  --output-path lighthouse-reports/$outputString-desktop  \ 
    $inputUrl
  else  
    echo 'running mobile code'
    lighthouse --formFactor mobile \ 
    --output json \ --output html \  --view \ 
    --output-path \ 
    lighthouse-reports/$outputString-mobile \ 
    $inputUrl

  fi
done

Methodology #

Before we make any changes, we need to establish a baseline we can compare to after running any changes.

I ran two separate commands to test Lighthouse on mobile and desktop and I ran the PageSpeed Insights against the site.

After each run I've added a table with the results. The PWA section is pass/fail since it doesn't assign a numeric score.

I will repeat the tests after each change I make to see if they improve performance and, if so, by how much.

All these optimizations are done against a WordPress installation running pre-release code. It is possible that performance regressions were introduced during the WordPress development process.

Several of these optimizations require plugins, which introduce its own performance questions and challenges.

Baseline Run #

Now that we've decided what to do. Let's get started.

The baseline results look like this.

I'm surprised at the differences in the results of running the tests in different environments. I would expect them to be more consistent

Edit on Github