Insights How do performance metrics affect frontend website builds and content pop?

There is a balancing act needed when creating a site, in terms of the way we build and the way we create content. We need to balance the content and media of the site with performance and SEO. If you lean more towards lots of content and media this can add a lot of weight to the page slowing it down, meaning your fantastic site is less likely to get views on it. But if you lean the other way and make a very performant website it might not achieve its goals of trying to sell or inform users. There are many ways to approach these challenges both from a content creation point of view and from the frontend build.

Images generally make up the main bulk of any website, they are a great tool for showing off your branding and culture to the users of your site. This means a lot of effort is needed to mitigate the impact of images on performance. We have multiple options to optimise the performance of images, one of the best is to serve up multiple versions of a single image, creating different sizes and file types to get the best optimisation for the variety of devices users will use to visit your website. 

As a part of the majority of our web builds, the resizing is done for us, we can set the various sizes during the build phase and any image selected will have multiple sizes and file types created for you. This means on mobile we load a smaller image then on desktop, and we use different file types to better compress the images. To orchestrate the serving up of these multiple images, we use the Picture tag, a piece of html that browsers give us to achieve this, an example of which can be seen below.

In the example above you can see comments showing off the mobile images and the 2 different file types. Webp is a fairly new file type that a lot of browsers can use, which generally creates smaller image file sizes than jpg, but we keep jpg as a fallback in case a user's browser does not know what to do with this file type.

This is a great solution, but it does have a few drawbacks. The main one being the more variations you have per image the more code you need to put on the page, you can start racking up the line count quite quickly per image. So even though we are able to mitigate the impact of images on page speed, if we do this too much we start affecting the overall page size. This can then negatively affect cumulative layout shift (CLS), specifically if you have loads of dom elements (each html tag being a dom element) the longer it takes the browser to read and understand the html, before it can then start showing anything on page or download other assets.

Having a video as part of a hero block on a page is also another example of where you need to carefully plan your content in respect to performance. A video in terms of branding and messaging can be a fantastic way to get a lot of information on a page, but there needs to be some rules of thumb to mitigate the amount of slowdown this can cause. One of the best ways is to use a third party like youtube or vimeo, it does something similar to what we do with images by creating multiple versions of the video and adjusting which one it shows as you stream the content. But if you want to have a hero video you generally want qualities that third parties are not very well equipped to handle, namely a muted looped autoplaying video.

The next best option is to then self host the video, but we need to mitigate the issues this inherently comes with. For instance a good rule of thumb is to have a short video of say no longer then around 10-12 seconds and/or the video files size being less than 3MBs, which can be hard to achieve depending on the video. You can see an example of a hero video on our home page.

Even though a video streams its content, meaning it doesn’t affect the perceived performance, it does drastically affect the largest contentful paint metric. Lighthouse will mark the length of largest contentful paint at the end of the video loading, with this metric making up 25% of the score in lighthouse (page speed insights) and this lead to a potential bad score hit. So if you are planning on having a video on a page you need to carefully think about what else is on the page so you can still get an overall good score. This might mean moving some content onto a new page for instance to shorten this page up, slightly mitigating the hit to performance.

There is a constant balance between the content, the way we build, and performance of a site. Some pages you will put a lot more effort into than others, like the main landing pages of your site, for instance the homepage. You want to fit as much branding in as possible while still achieving good performance. While other pages that you signpost to, you can lean a little more on content and less on performance, for example you might want a page for a gallery and/or videos, not something you would link to directly from a search engine, but a great page to signpost to.

This is difficult to get right the first time; with content driving design, design driving content, and performance also influencing decisions as you go along, it can get quite complicated. But as sites grow and evolve we can tweak them as they go, keeping an eye on this is important to make sure your site achieves its goals.