Why did we rebuild our site?
Often a rebuild of a site is triggered by either significant design changes, or replatforming/changing the underlying CMS. In this case, neither was the case! The site still looks just the same as before, and it's still powered by the headless CMS, Kontent. So why the need to rebuild?
Our old site was built on a very early version of .NET Core, as a dynamic web application in Microsoft Azure. This was getting a little long in the tooth and the .NET Core version was past 'end of life' so a bunch of website code was going to need to be written at some point soon anyway.
Some other APIs and bit of functionality had also been retired over the previous four years, such as Kontent's 'Smart Recommendations API' that we used for sections such as 'Keep Reading' at the bottom of this post. It has since been improved and replaced with a direct integration with Recombee, so was going to need to be reimplemented.
Being a decoupled headless site and written on .NET Core, it was quite lightweight too, so we were able to run it on minimal cloud infrastructure, especially when it sat behind the CloudFlare CDN. This was great, but... the issue was when we did need more resources. For example, during a significant traffic spike (or in some cases, just a particularly popular email newsletter going out) our poor little site occasionally got quickly overwhelmed, and crashed. This was obviously not on!
Finally, we had audited our site and identified that there were some areas of the site that were going to need rework anyway. For example, we wanted to upgrade our Portfolio to add searching and filtering, update some of our design system across the entire site, and clean up some bugs that had crept in while removing some old components that were never used (and accordingly reduce code debt).
But of course there's another reason... we love an excuse to try out some new tech!
Why did we choose Jamstack?
We're already using a composable DXP architecture, so we weren't limited to a particular implementation language/technology to use. We chose .NET Core MVC four years ago, but now we had another opportunity to freely select the most suitable technology available today.
We looked at what tech stack could potentially solve some of the problems we were having:
- Stability and scalability: we only want/need minimal infrastructure, but we do need to be able to handle occasional traffic spikes without having to scale up our resources in advance. And we never, ever, wanted our website to crash again.
- Speed: our page speed, especially for pages which hadn't been visited recently, wasn't great, and over the last four years it's become even more important to have a lightning-fast website, for SEO and user experience reasons.
- Serviceability: we wanted to be able to maintain, update, and upgrade our site as easily as possible in the future, and not be stuck in another 'end of life' situation.
It just so happens that these benefits, and of course the fact that we're using a headless CMS with all the right APIs and SDKs, map perfectly to the benefits of the Jamstack.
Our flavour of JAM
Of course, the Jamstack is more of an approach than a specific technology. For our particular stack, we selected:
- Gatsby.js as our SSG (Static Site Generator) since it has excellent first-party integration support with Kontent, and simplifies dynamic preview site builds with its Gatsby Cloud service.
- Netlify for many things, including production builds, hosting, access control, CDN, serverless functions and online forms.
This is not your typical project. So what did the process of rebuilding our own website front end on a different tech stack while not changing the design or the CMS look like?
In a nutshell, we:
- audited the site and identified any issues or areas that needed to be changed or improved
- identified any systems that would need to be switched – for example our online forms service Formstack, which we switched out for native HTML forms and Netlify Forms as a headless forms API
- estimated its time required, and put together a project plan
- figured out our MVP (minimum viable product) for launch
- allocated it to some developers
- (got delayed repeatedly because it's an internal project and it never seemed to be able to compete with our clients 😜)
- built it, connected to the exact same Kontent headless CMS environment that was still powering our existing site (this was REALLY helpful for QA/testing)
- (we did set up a separate environment in Kontent towards the end for testing content and migration of any minor content model changes)
- deployed production builds of the new site to a subdomain, and connected up all the webhooks and API integrations
The day before launch, we literally had both websites, existing and rebuild, running side by side on different domains, driven by the exact same CMS environment, content types and content items.
To launch, it was then as simple as flicking a switch in Cloudflare. No downtime, no content freeze, no content migration. No SEO impact (except positive!). And in the event that something went wrong (which it didn't), we could just switch back again.
The Jamstack rebuild experience
- Fantastic development experience, in the words of our devs, it's "so much nicer to work with".
- Speed! Everyone noticed when we launched it how much snappier it was.
- SEO impact - we're very proud of having a Lighthouse score of 100 for SEO.
- Integrations – due to everything being API-first, the integrations are really simple and reliable with Algolia, Zapier, Recombee, and Netlify.
- Upgrading from here on in is really nice! Upgrading Gatsby from v3 to v4 during development took less than a day, and upgrading Kontent (the headless CMS) isn't even a thing, it's SaaS so it's always up to date.
- The preview experience (previewing your unpublished content on a preview site) can be challenging with a statically generated site. We use Gatsby Cloud, but when you get particularly busy with your content edits, it can queue builds sometimes.
- Site build/publish times – this is the classic tradeoff between a static site that builds in advance then provides blazing fast page loads, versus server-side rendering (SSR) which might be slower to load, but you don't have to wait for the site to rebuild when you publish new content. Having said that, our site still builds and deploys published content in well under a minute.
- Some of the existing content models from years ago created some restrictions. For example, some SVG (vector) images in inline components were not able to provide an absolute height and width which is required for Gatsby Image components. If we were building from scratch knowing we were building for Gatsby, we would have modelled images differently.
When you're building against an existing CMS that is going to stay, there's years worth of content in there that you have to work with. Of course, being a headless CMS, the content is highly structured so you can actually do this successfully! But remember, you can't significantly change the content model, or structure, in the CMS. If something does need to change, you should only make additions to the content model. Don't change or delete existing types or fields, or you might break the current site.
Kontent does have a great feature we used to keep fields in the system – moving them to their own tab, which we labelled 'Deprecated' to make it very clear to content editors that they were not the fields they were looking for. A little skull-and-cross-bones emoji doesn't go astray either!
Go ahead and bounce around our site, and see what you think! We're particularly chuffed with the lightning fast page loads within the site, as you click around from page to page. Make sure you check out our new forms too, by dropping us a line on the contact us page. 😉
Want to dig deeper into Headless CMS?Download the Marketer's Guide to Headless CMS
Looking for experts in the Jamstack?Chat with our team
Want more? Here are some other blog posts you might be interested in.