Roy Tang

Some time ago, one of my many intrepid followers pointed out that this blog tested poorly on web page performance according to this Speed Testing Tool. Now, I’m of the opinion that for a personal blog such as this, web performance isn’t really a mission-critical sort of thing, but as a software developer who has often had to work hard to optimize the web applications we delivered to our clients, it kind of became a matter of pride :p

30 Jun 2016 1:30amClose

I also ran the site through Google PageSpeed Insights. The results were mostly the same, but the Google site gave me results faster, so this was the one I referenced for subsequent testing. The most important problems to address were:

• Optimizing image sizes
• Removing render-blocking JS and CSS in above-the fold content
• Leverage browser caching (through the use of HTTP headers)
• Minify CSS and Javascript

All of these are familiar to me since they are very common performance optimizations done in web applications. However, this blog is running on WordPress, which means I should try to look for existing WordPress-based solutions instead of hacking the code myself. (I used to run a custom-built Django-based blog system here, but I got tired of maintaining it myself so I went for tried-and-true WordPress). Here are the optimizations I ended up doing:

1. Upgraded to the default WordPress Twenty-Sixteen Theme. Not strictly necessary for optimization, but I was previously using the Twenty-Twelve Theme, and the problem with using older themes is that they may not be using newer web development techniques to improve performance. Also, Twenty-Sixteen looked better haha. And yes, I do use the default WordPress themes. Too lazy (as of yet) to look for a nice custom theme, and I don’t have the design chops myself to build it, so it will do for now.
2. For the image size problem, I found that the biggest offender was the Sketching Daily post where I broke down how I do my daily sketches. The problem was that I was uploading full-size images of the drawings and they were being inlined into the post – which meant the browser was loading the full-size image even though it was shown in a smaller size on the post itself. Instead, I manually changed the settings of each image in the post to use one of the smaller-size images generated by WordPress on upload. 

   

   

   30 Jun 2016 1:30amClose
   Choosing “Large” here meant the Large one would be inlined, while I could still set the image to link to the full-size one on click. The full size image is a whole fifteen times larger than the “large” image! It’s something I need to remember in the future if I ever upload huge images again. I also found a link that described how to set the default image size (so that it doesn’t default to full size all the time), but I don’t think it’s necessary for now.
3. To further help with image optimization, I installed the WP Smush plugin, which automatically optimizes (“smushes”) uploaded images. I found that WP Smush reduces the uploaded image sizes by around 10-15% on average, it’s not too bad.
4. Next was render-blocking JavaScript. If you’re not familiar, any <script include="... " /> tag in your HTML blocks the rendering of any content below the tag itself until the content of the JS has finished executing. The typical solutions are either to (a) move the script tags to below the content (“below the fold”) or (b) add an “async” or “defer” attribute to the script tag. It turns out that there was already a plugin that did (b), Async Javascript. So I gave it a go, but for some reason it wasn’t working. After a bit of debugging, I found that there was an “aj_enabled” option that wasn’t being set. I couldn’t figure out any settings page to update it, so I went ahead and edited the plugin directly to set the value: 

   

   

   30 Jun 2016 1:30amClose
   It’s generally a bad idea to hack the local copy of your WordPress plugins, since you have to check the impact every time the plugin has a new version, but I decided to live with it for now. After the update, sure enough the JS no longer blocked page rendering.
5. Lastly, I installed the W3 Total Cache plugin. I disabled the WP Super Cache plugin I was using before since they would probably have some sort of conflict. In addition to page caching, this plugin addresses a couple of other issues: it supports HTML/JS/CSS minification (reduces file sizes and HTTP requests) and it allows adding the expiry headers to static content (to leverage browser caching). If you’ve done any work on website performance, the settings for the plugin are straightforward to understand, but I also referenced the guide at this link. The plugin looks okay, but there’s an unfortunate side effect: the minified JS created by the plugin does not respect Async Javascript, so it blocks above the fold content from rendering. It’s a problem I’ll have to try to resolve in the future.

After the above changes, I retest the site:

30 Jun 2016 1:30amClose

Much improvement indeed! There’s still a few issues to iron out, but for the most part I’m happy with the results (and my pride has been satisfied :p). I may revisit this issue at a future date to see if there’s anything else I can improve on.