Rebuilding “The Bagnall Centre” With The JAMstack
Recently we were asked to take over The Bagnall Centre website, and migrate the site away from their previous agencies proprietary CMS. The old website was flaky and unreliable, so we needed something robust & secure that we could maintain easily and our client could update. We chose the JAMstack (JavaScript, APIs & Markup).
Why JAMstack?
Why did we choose the JAMstack over something like WordPress? The primary reasons were the increased security & low maintenance over the old solution. JAMstack is secure by default, when all you have is HTML/CSS/JS there is very little that can be compromised. The JAMstack was definitely the way to go, which left us with 2 choices: Hugo or Gatsby. We typically jump between one or the other depending on requirements & complexity. We opted for Hugo due to the simplicity of the site, and the existing markup/css we could easily port over.
Moving To Hugo
As we’re now using the JAMstack, there are features from the previous site that need to be rewritten to remove the dependency of server side PHP that was being used to power the search, login, timetable and contact forms across the site.
The search was rewritten to use Algolia, which combined with their instantsearch.js library, was a joy to implement. It’s fast, easily customisable and offers some great features through their dashboard that the old website didn’t have access to.
The contact forms were replaced with Netlify Forms, allowing us more flexibility with how we handle form submissions.
One of our many reasons for writing The Bagnall Centre website in Hugo was down to the way we recieved the source code.
Unfortunatly we where denied access to the CMS, forcing us to download each webpage individually giving us only the HTML, CSS & images to work with.
With access to the live site we proceeded to piece together repeating elements of the the site with partials and HTML layouts, placing content in markdown files as we went.
Quickly the site took shape, giving us time to make markup, security & performance improvements.
Security
The first thing we noticed is that the old website was not served over HTTPS. A must have considering the old website provided users the ability to “login” with their username & password. This led us to check the HTTP security headers, for which we used securityheaders.io. We found that none of the recommendations had been met, scoring the site as an “F”.
To rectify this, we added the following security headers which brings the new score up to an A:
- X-Content-Type-Options
- X-Frame-Options
- X-XSS-Protection
- Referrer-Policty
- Strict-Transport-Security
jQuery
We also detected an outdated version of jQuery (1.7.2) which contained 2 security vulnerabilities. This was an easy fix with an upgrade to the latest jQuery (3.3.1).
Performance
Improving performance was more of a challenge, as the current website was already reasonably optimized. Making every performance gain no matter how small still important.
We ran the site through numerous performance measuring tools such as GTMetrix, Lighthouse, Webpage test & Google page speed to get an accurate idea of what, if any performance upgrades we could make.
JavaScript
Where applicable we rewrote small jQuery functions as JavaScript in favour of any small speed gains we could find.
For example from:
function handleFormInjection () {
var textarea = $('textarea#message');
if (!textarea.length && !window.location.search.length) {
return;
}
textarea.val(
'I would like to book onto ' + getUrlParameter('course') + ' on ' +
getUrlParameter('day') + ' starting at ' + getUrlParameter('time') +
' with ' + getUrlParameter('associate')
);
}
to:
function handleFormInjection () {
var textarea = document.querySelector('textarea#message');
if (!textarea || !window.location.search.length) {
return;
}
textarea.value = `I would like to book onto ${getUrlParameter('course')} on ${getUrlParameter('day')} starting at ${getUrlParameter('time')} with ${getUrlParameter('associate')}`;
}
Further to this we removed any unnecessary libraries and replaced them with a native equivalent as an example we removed mailchimp’s validation and replaced it with HTML 5 Form validation.
Any blocking scripts in the header we moved to the footer making the initial load faster.
CSS
Not too much time was spent on the styling as we had the CSS already written from the handover. Rewriting & optimizing repeating elements proved to reduce the overall file size & load times marginally.
Netlify (Hosting)
Hosting was an easy choice, Netlify offers several tools and services making JAMStack sites a pleasure to work on.
One of Netlify’s many tricks is it’s post processing which handles the asset optimizing for the site from pretty urls to image compression.
Post processing also handles the minification & bundling of CSS & JS meaning we did not need to spend time updating our build process.
Accessibility
Since the design of the original site was unchanged our accessibility improvements hinged on Improving markup to be more semantic and screen reader friendly.
We used an online tool (Tenon.io) to test the site for bad Accessibility practices, going through the report we updated the site by adding Alt tags, updating links and buttons content to be more informative, adding labels to form elements and setting the page language.
