Example Performance Audit
Discover how optimizations improved the speed of a Kirby CMS-built website, reducing the Time to First Byte by 1.0 seconds and the Webpagetest Speed Index by 3.7 seconds.
Making the website load faster
Let's assume you noticed your website is taking longer to load than you would like, had a performance check done with Google Lighthouse, or found your website within the reports provided by my service. That's the right moment to get me in the boat. Optimisations can be planned during development, but with Kirby's great flexibility, it's not a big issue to apply them later.
Please look at the example below.
Before
Time to First Byte
The website is taking 1.302s to render the HTML within Kirby.
Largest Contenful Paint
At 1.962s the biggest chunk of layout is painted by the browser - the hero image in the gallery.
Speed Index
Images block the web-font (12), delaying the website to look usable. FCP at 1.762s (green line).
Page Weight
A total of almost 3MB has been loaded.
Performed Optimizations
- Activate Kirby's built-in page cache.
- As it is only one and small in size, preloading the font to unblock the drawing and avoid a re-draw on a swap can be done. Preloading fonts is not always a good idea.
- Switch from JPG to WebP-encoded images as the file size is smaller and they have the same visual quality given adjusted quality settings.
- Eager load only the first visible image and UI elements. Lazy-load all other images. I did use the JS lib unlazy for a bit more control, but the native browser support would do it as well.
- Define Srcsets for the images depending on breakpoints with a blurred src as default.
After
Time to First Byte
Kirby's rendering is much quicker now. In more complex setups, the built-in page cache would not work, and a different approach would be required.
Largest Contentful Paint
Comparing the time from TTFB to LCP, not much was gained. This is because the same resources are needed at that point in the timeline.
Speed Index
The website looks usable faster, with the FCP at 0.712s (green line), mainly due to the improved TTFB. The Speed Index is better because of the added lazy loading for images.
Page Weight
The separation between eager and lazy loading allows the browser to prioritize what resources are needed first. After ~400 KB and 1.015s the website is fully interactive.
Summary
Activating the caching in Kirby resulted in a huge win of around 1.000s. This project is relatively simple, so the caching was easy to implement. However, adding an equally effective caching layer is more challenging in projects with a headless setup, authenticated users, similar show-stoppers, or too many pages read in a single request. But I have done that often enough to publish a few plugins focused on performance.
Improving the TTFB with caching is often overlooked and is one of my specialities.
Pushing the Speed Index from around average to within the top 10 percentile of web pages will make a noticeable difference to your customers. This improvement was due to adding lazy loading to images that were not within the first view fold, proper image Srcset definitions and switching to WebP for encoding.
Reducing the bandwidth footprint like above is a relatively easy task for me in Kirby CMS.
What's included in the box?
1) If you hire me to create an Audit for your website, you will receive an online analysis with an aggregated, Kirby-specific list of hints as a sharable document link and a PDF.
2) You can optionally give me access to your website's source code so I can create a code review for you. It will be added to the written document. I will point out where to make changes with what priority, explain why a change is necessary and a time/cost estimation.
I will also check best practices in general.
3) Ideally, you will hire me to implement those improvements and refactor your website's code, allowing me to finish the job by creating and sharing an updated set of automated performance reports to verify that the changes made yielded the expected improvements.