I write a blog. I write it for myself. Specifically, my future self to remind me of the specifics of my travels. I chose to use the Twenty Sixteen WordPress theme because it is responsive, accessible, and very simple looking. In fact, it is so simple looking that I was shocked to learn that my implementation of it only got an 81/100 score on the performance report from Google's Lighthouse.
That caused me to set off on a quest to try to get this number to 100/100. Along the way, I learned that my host, Pantheon does a number of the industry best practices for better performance for me. There were also some simple things I could do without much effort and some much more complex things that would require a lot more time investment that I was willing to commit to try to get to the magic '100' score. I learned along the way that you can hit a point of diminishing returns on chasing that number and have to figure out what is ‘good enough’ for your site.
What Pantheon Does for Me
Not having a ton of experience with frontend tuning, I was quite honestly not sure where to even start. Luckily, my colleagues at Pantheon already had built a handy guide on this, the Frontend Performance Guide.
The first topic it addressed was "Reduce Server Response Time". Being on Pantheon, it turns out I didn't have to do anything for this section! Since Pantheon's Global CDN is automatically in front of my site and I am the only 'logged in' visitor ever, the default caching is exactly what I needed. I just verified that the cache age was above zero and my cache-control was higher than zero as well and I was all set. I did this with `$ curl -I` but Pantheon actually provides a GUI for this for sites on the platform, called Varnish Check.
If I would have needed to dig in further on cache hits or had a slightly different use case where logged in user performance would come into play, Pantheon provides tools to help. For example, they give me New Relic APM Pro as part of my plan. With this tool, I can dig into the code execution and see where the problems lay. They also provide me Redis running as a service for backend object caching. If I had logged in users, they would be bypassing my frontend cache and I would want a cache above the database to make sure that everything was efficient as possible when they were logged in. I felt my performance experience as the sole logged in user was OK, so I decided not to mess with that.
Also, very importantly, I am using PHP7 on Pantheon. This is standard on all new sites and any site can jump to this version with ease. PHP7 means 30%+ faster speeds than the same site on PHP 5.6, with no other work needed.
Some Simple Things I Could Do for Quick Wins
Above The Fold Optimization out of the box has nothing turned on, which I liked. Unlike some of the other tools I tested, which came with preset options that I was not really sure of what they did, I had to go through and specify what I wanted. In my case, I minify-ed HTML, CSS, and JS. I also moved the JS and CSS to load from the footer, so time to first paint would get even faster. A few box clicks later, I was cruising along at a pretty nice speed.
More Complex Things If I Really Wanted to Get to "100"
In the frontend performance guide was 'Compress Images'. This is pretty simple on my front page, since there is only one image. Going through my posts, I found I really only had a handful of other images that were in my file system and they were as small as I could get them already. The rest were sourced from other websites, with the largest target by far being Twitter, which is where the real performance issues came from on posts.
I use a markdown editor for writing blog posts and one of my favorite features is the automatic unfurl of Twitter links. Just pop the full URL in there and ‘bam’, embedded tweets, which all have images. This has some serious performance overhead and the results on posts with multiple tweets shows a 'real issue' in Google’s opinion. Now, I could painstakingly recreate each of these tweets and do it in an optimized way, but in reality, I would not trade the convenience of getting these embeds with a simple URL for any increase in performance.
I also could further improve performance, theoretically, by going through and marking which scripts are absolutely critical and only serving those first. There is also further manual optimization I could do if I was willing to start messing around with wp_enqueue_style() and wp_enqueue_script(). I have no plans to dig further into those right now. Basically, I hit a point I think is 'good enough' and moved on with my life.
Other Considerations and Thoughts
"Between 92 & 96"
I think I ran somewhere close to 100 performance tests using Lighthouse. Without changing anything at all, I saw fluctuations of up to 5 points. At one point, I even scored a 97. I think this is one of those instances where I can just accept that the internet is not a static thing and tools that give one result at one point in time are not necessarily going to get you the exact same number every time.
Functionality vs Performance
To reach this speed boost I had to give up one of my favorite little features. With any site, adding functionality means adding overhead. In my case, I have a plugin that loads in an emoji when the page loads. Before optimizing, I could reload and have a fresh emoji appear with every paint. After optimization, I get a new emoji only when I navigate to a new page. Reloading the same page just paints the same emoji over and over again. Here I could leverage the open source plugin and start monkeying with it to get the behaviour I want, or I could just turn these optimizations back off. Neither seems like something I want to spend more time on. Since it does show me an emoji, I am OK with the performance/functionality trade off with this.
Chasing a Number vs Good Enough
At the end of the day, I realized a few major things. First off, this stuff can be infuriating. Don’t pull your hair out when you hit issues. Google the problem and see it as a chance to level up your skills.
It is OK to say "good enough". I had hoped to get to a score of 100 just because that seems like a cool thing to get. However, when it comes down to it, I would much rather spend my time helping other people than spend it shaving another 500 milliseconds load time off my blog.
This experience reinforced one of my favorite truths: “the perfect is the enemy of the good”. We should all evaluate what we're doing vs how much time/effort it takes to hit certain goals. In my case, I wanted to learn some stuff and get a faster site. Mission accomplished. There's no such thing as perfect - I got better at both and that's good enough.
And lastly, I feel pretty fortunate that I am working on Pantheon through all this. The platform gave me a lot of advantages before I even started, providing some pre-implemented solutions for parts which would have taken me hours to configure on my own. WordPress and Pantheon are a pretty awesome combination.
Pantheon Website Health Check