How We Improved Our Front-End Performance
When we relaunched the Project A Ventures website a few weeks ago, we tried to carefully consider the performance impact for every change we implemented. Today, we would like to share some of the steps we took in order to improve our front-end performance.
The relaunch of our website was technical in nature, there was no redesign. Driving forces for this decision were performance and usability issues whose solution wouldn’t affect the design at large. Admittedly, for a full-fledged website, using the Ghost blogging platform as CMS wasn’t the best choice. It’s simply too limited, and customizing the CMS to meet the requirements of a complete website brings up quite a number of issues. As we were looking for a suitable alternative, we stumbled upon Kirby, a flexible, file-based CMS. In his most recent post, Jonathan already pointed out the benefits Kirby has to offer and why we already decided to use it for our website and some of our ventures.
Improving Front-End Performance
Let’s first take a look at some general measures we took to improve our front-end performance.
Reducing CSS and JavaScript
One of the most basic steps was to rewrite and reduce all CSS and JavaScript. We split the JavaScript functionalities into tiny, maintainable ECMAScript 6 modules. To create reusable components we use Sass and stick to a BEM-like naming convention.
HTTPS
We also decided to always use HTTPS for several reasons. Besides benefits in terms of security, HTTPS might also have an impact on your page ranking, thus supporting SEO. Moreover, if you want to benefit from HTTP/2 in the future, you will have to use HTTPS anyway. Some of the advantages HTTP/2 provides are multiplexing, header compression, and server push functionality.
Gulp build process
To optimize our assets, we now use a gulp build process similar to the one included in our open source front-end starter package. The build process automates the optimization of images, such as PNG, JPG, and SVG. In addition, it optimizes the website’s JavaScript and CSS.
Progressive JPGs
To enhance the perceived speed with which the website loads, we decided to only use progressive JPGs. Requiring very little effort, progressive JPGs are among the easiest improvements regarding the user experience. Still they are not yet used that frequently.
Load JavaScript asynchronously
In addition, we load JavaScript asynchronously so that rendering won’t be blocked and to prevent a possible front-end SPOF (Single Point Of Failure).
DNS prefetch metatags
To move the DNS lookup to the background and to save some additional milliseconds, we added DNS prefetch metatags. For this purpose we use this script by Paul Kinlan to get the list of domains for prefetching. Sure, DNS requests don’t occupy a lot of bandwidth, but latency can be quite high. This is especially important with respect to mobile networks. By prefetching DNS results, we can reduce latency.
Kirby Plugins
In addition to the general measures described above, we use two Kirby plugins to further optimize our front-end performance.
Detect Plugin by Studio Dumbar
This plugin enables you to load device-dependent code snippets or template parts. We decided to not load web fonts for mobile devices in order to avoid additional performance hits and to provide our content as fast as possible. Moreover, we only load background videos for desktop devices; mobile devices will just get a static background image. Background videos don’t make a lot of sense on mobile devices since there is no “autoplay” functionality.
MinifyHTML plugin by Ian Cox
True to its name, this plugin minifies the HTML code in the background before it’s sent to the user. It’s only a micro-optimization to save some bytes, but its implementation is effortless so there’s no reason not to do it. You can simply add the plugin to Kirby’s plugin folder and it will do the rest.
More plugins you might want to take a look at
There are quite a number of plugins Kirby has to offer these days. As far as performance optimization goes, there are two more plugins which might be interesting: the CDN and cachebuster plugins.
Our Results
With all these improvements we were able to increase our PageSpeed Index significantly. Our page speed index rose from 70/100 before the relaunch to 90/100 afterwards. The website’s user experience index even rose from 72/100 to 100/100. So we are completely in the green range by now.
If you’re interested in more details, you might want to take a look at our website’s performance test on webpagetest.org.
Next Steps and Ideas
In the course of our relaunch, we already implemented the “low-hanging fruits” and made serious improvements to our front-end performance. Yet, there are still a few things left that would even further enhance our front-end performance. The next steps we are considering involve speeding up the initial rendering and the displaying of content. In this context, we plan to load web fonts asynchronously and to convert critical CSS (including “above the fold”) into inline CSS and include it in the markup.
Even further, we are considering removing more third-party scripts or only including those which comply with our defined SLA, comprising async loading, fast server response, appropriate cache header, and enabled compression. At the moment, only pixels for Google Analytics and Facebook are left.
As soon as HTTP/2 is in use, we will review our current performance best practices and adapt them accordingly. HTTP/2 will make some best practices obsolete. Others might even increase the page load time or slow down rendering. Some additional information on HTTP/2 can be found here and here.
