The project

The 2024 website build deadline had been very short (a couple of weeks!), and the site was hastily assembled in-house to get something out there for people to get the information they needed as quickly as possible and book tickets ahead of the start of the festival.

It was dropped onto a hosted Wordpress account and a theme quickly created. Unfortunately it had to go live and be used before it could be thoroughly checked for performance and accessibility issues, but it did a job. Once the 2024 festival was over, I was brought in to rebuild the site from the ground up, re-designing, re-platforming, and re-architecting in the process.

Our aims

• Move away from Wordpress
• Collate any branding and colour palettes
• Set up new hosting
• Build from the ground-up to make it fast
• Build with future expansion in mind
• Make the branding and website flexible for future festivals.

The brand

The first thing we needed to do was to gather up all existing branding and colour palettes.

It was functional, but without the fun. We decided to brighten things up a bit, and the first port of call was to update the logo a little to make it more flexible, easier to use moving forwards and a little bolder. Here's a comparison, with the new logo in grayscale - the idea being that we can use any three colours with it each year.

Other tweaks we made we to remove the '24' on the original so it became more of a Halifax Digital Festival logo in general, instead of being tied to a specific festival year. We also tightended up the line-height between the festival name, made the border a little thicker between the device and the name so it more closely matched the thick borders of the device better.

Once this was done, we made the updated logo allow us to easily change the frame, text and border colours to a dark colour choice, the X area to use a light choice, and the 'depth' of the device to use a 'mid' colour.

The 2024 theme

Once we'd got the logo in a good starting place, the next big choice was how many colours we were going to need for the theme, and where we'd apply them to the site and logo. This would form the basis of each year's colour scheme so we needed to make sure we got it bang on this time around.

We decided on colour themes containing a light, mid, dark colours, with another for text content, and two faded/transparent colours that could be used for backgrounds and so on.

Colour contrast

The great thing about the technical approach we've taken here is that it allows us to easily theme each year differently - we can start by simply providing a new set of colours to give it a really different feeling.

The 2025 theme?

And we can do this for each year that comes too. The great thing about how we architected the site is that we can have a 'global' colour theme set per year, and if you want to go back through the archived year's pages, they'll be in the correct theme for that year. This should give it a nice feeling of variety without having to do too many changes each year.

The new site feels better on bigger screens. It's bolder, brighter, bigger.

And it feels better on mobile too. It's smaller, but still spacious.

We also tried to keep the theme running throughout, making both the events pages more usable, more spacious and better laid out.

Performance

Page weight and resources

We're always focussed on accessibility and performance, and this site is no exception. Overall the old site didn't do bad on the performance side, partly due to being hosted on a fast Content Delivery Network (CDN) which helped give it a speedy response time and pretty decent Core Web Vitals scores. There were, however, other issues we knew we needed to fix.

Firstly, we needed to do everything reasonable we could to get all those CWV scores in the green zones, and we also needed to slim down some of the pages, specifically the speakers page; this page loaded every single speaker's image for the year in one go on page load which totalled a staggering 25MB!

With a sensible touch of loading="lazy" applied, we hugely reduced the initial page load because most images were only loaded as they were about to scroll into view. The lowered the initial page weight to an astonishing 0.387MB, a 98% smaller page load!

Using clever preloading of vital assets, the odd fetchpriority="high", and opting to choose a small file sized variable webfont, we managed to generally improve page weight and load times throughout.

Page weight comparisons

Core Web Vitals (Old site)

Mobile

Desktop

Core Web Vitals (New site)

Mobile

Desktop

Tech used

• Static site generation with Eleventy
• CSS transformations with PostCSS
• Front end build tasks with Gulp
• Hosted on Vercel
• Code stored on GitHub

Reyt good