“A long long time ago, I can still remember how…”
You all know that song. It’s now two years ago when I moved my website the last time from one provider to another. And no, this blog post doesn’t talk about another move. It’s just a small update on how my website is performing and what I did the last few days and weeks to make it perform and look better.
Back in April 2018, I published a blog post about my website now being serverless. The reason why I wanted to go serverless was website performance. I stumbled across some Tweets, talking about the search functionality on a website, not using a word or tag cloud, etc. All of this has led to the fact that I have dealt with the topic more intensively and at that time moved my website to a new hosting provider. In the end, I decided to go serverless with my website. But that wasn’t easy. I love WordPress as a blog tool or publishing platform, or whatever you would call it. It is easy, flexible, and you can do so many things with WordPress.
But WordPress is based on PHP for the frontend and MySQL as the backend database. And that’s all dynamic content. Each blog post you read, every function on the website will be executed or rendered dynamically. That’s not speaking for high performance directly. There are some techniques, such as caching plugins, or other tweaking tools, to make the website performing better. But it’s still dynamic content in the end.
So, what happened then?
Small changes in the area of costs
My website is still serverless, that didn’t change. But over time, my current provider, Shifter, did some changes in technology, created new hosting plans, added new features, etc. I was aware of these changes and news, and I wanted to benefit from it. Well, my website will benefit more of it, but you know what I mean. The greatest benefit was for my wallet. I was running my website on a legacy plan (so they called it), and now, they have tiered plans (tier 1 – tier 3) in two categories, static and headless. You can get more information on their website.
Running my website now costs less, and that’s some serious money less. The technology behind the hosting didn’t change much. It is still a WordPress instance that can bin started at any time to create and edit content. And it’s still an artifact being generated after stopping that instance. Out of that artifact, the content will be converted to static content and then be pushed out to Amazon CloudFront.
Minor changes in design
Some of you might have noticed my announcement on Twitter in regards to a new logo. That was one small change. I wanted to create a new brand, at least going into the direction of a brand. That meant to have at least a nice looking logo, matching colors, etc.
And that’s the logo in question:
It’s looking nice, in my opinion. It is an easy logo, nothing complex, nothing too fancy. Just a clean logo. It’s not only the logo but also the matching colors. You might also have noticed the blue-ish backdrop color. It should represent the logo or my brand colors, and it should also be an allusion to heaven, where the clouds are, you know? The rest of the website is still in the contrasting colors white and black, where black is used for the menu as a clear navigation point, and white being used for all the content containers (text, images, sidebars, and footers).
Image handling
A huge topic in terms of website performance is the loading of graphics and images. There are some plugins and also online services that can optimize your images. That can be done during upload within the WordPress media library (with a plugin), or with an external service. I’m currently using Imagify, both as a plugin and also web-based. You can set the quality level you want, and Imagify does the rest. It crunches your images to optimize their size. Imagine the loading speed of a 4 MB picture compared to 400 kB! Image size matters when talking about website performance. When you can have images loaded faster, why not? But it’s not just about the size of the image, it’s also about the image format.
You might have heard about the new WebP image format, developed by Google. I’m trying to use images in the WebP format where ever possible. There is only one catch. The Apple Safari browser doesn’t like that format (yet). At least for some time, I’m trying to serve images in different ways, so that all browsers can display them to you and also benefit from the filesize of the images served.
In HTML, yes also in WordPress, you can serve images with the <picture> tag. That means that you can primarily service WebP based images, but you have a fallback to PNG in case the browser doesn’t support WebP.
<picture> <source srcset="/wp-content/uploads/2020/05/yourimage.webp" type="image/webp" /> <img class="alignnone size-full" src="/wp-content/uploads/2020/05/yourimage.png" alt="Your Image" width="300" height="100" /> </picture>
During the write of this blog post, I’ve found out that the new WordPress Gutenberg editor isn’t as bad as I thought, when I used it the very first time after release (to be honest, I switched back to the classic editor, until today…). As my <picture> tags getting removed, as soon as I switch back to the WYSIWYG editor, I found out that you can add custom HTML blocks in the Gutenberg editor. That really helps because you can put that image code into a specific container without having tags removed when rendering the written text. Nice!
I didn’t find a good plugin yet which helps with inserting images as WebP with a PNG as a fallback. I’ll do that manually in the “Text” section of the blog post, with the code shown above. That’s some additional effort, but it’s worth it.
Sure, there are also other ways to serve WebP as the image format of choice. For example, if you’re running an Apache or Nginx server, you can create rewrite rules in the htaccess file. Another way is to use a CDN like Cloudflare, they mostly have options to set which enables the WebP image to be served. But in my case, both options are a no-go because I only have access to my WordPress instance, and the static content is served through AWS CloudFront CDN, so a bit of tinkering was needed.
Big changes in performance
I have invested a lot of time to further improve the website performance. It was already very good from the beginning. Static content is most of the time faster than dynamic content. But over time, and with some “improvements” from my side, the performance wasn’t at that level where I wanted to have it.
There are a lot of benchmarking and testing tools out there on the internet. But two of the best, at least in my personal opinion, are GTmetrix and Google PageSpeed Insights. The tools are easy to use, but they will give you good insights into what is going on on your website, what is not loading correctly or even loading slow, and also give you some advice on which screws have to be tightened or loosened, to tune-up your website performance. And I tell you, I did a lot of testing and fine-tuning.
The following pain points were the most effective to fine-tune in my case:
- Defer parsing of JavaScript
- Minify CSS
- Specify image dimensions
- Optimize images
There is still some space for further improvements, but unfortunately, that’s not directly under my control because it’s mostly external content. One example is Disqus. As I’m operating a website based on static content, I can’t use the WordPress integrated comments feature. I had to somehow outsource that feature. I opted in with Disqus. In GTmetrix, there’s still an issue with “Leverage browser caching”, which shows exactly the external content from Disqus.
Good numbers!
For me, the results now are good. They are not perfect but good. And as there is still space for further improvements, there is also still some work to do. But let’s crunch some numbers now!
This image shows the Google PageSpeed result on a Desktop:
This image shows the Google PageSpeed result on a mobile device:
This image shows the GTmetrix performance result:
Another result from GTmetrix, Page timings:
Another result from GTmetrix, Page sizes, and request counts:
Another result from GTmetrix, Page speed, and YSlow results:
Conclusion
First, I wanted to thank my hosting provider, Shifter, for their support. They are easy to reach through chat, and they usually respond within a few hours by mail. They help you to solve an issue, they are not only referring to blog posts or knowledge base articles. Also, they have a fairly priced offering which should cover all your needs. AWS CloudFront is integrated, no need to create complex setup, you’ll get it out of the box. What I also like at Shifter is the automatic core updates for WordPress and PHP. It’s a managed service. Whenever you start your WordPress instance, it’s fully updated and you’re ready to go.
It took me some weeks to fine-tune the website performance. But it was worth it. I had do fix some misconfiguration which I did by myself back in the days, and I also optimized the image handling and some CSS and JS stuff. All that helped to improve the website performance and loading time. I’m really happy with the result, and somehow glad that I didn’t reach the end of the road yet in terms of performance.