GOV.UK is the online home for the UK government, so we have to make sure that it works for everyone regardless of their device or connection speed. This means we’re always looking for ways to improve performance and user experience, as well as the code beneath.
How we used jQuery on GOV.UK
jQuery was used widely across our applications both in public facing scripts and test files. We relied on a number of jQuery features, notably Ajax handling (to reload parts of the page dynamically), but we were generally using it to make our code simpler.
The main disadvantage of using jQuery is that it has to be included in the page assets, which can slow down how quickly a site loads. GOV.UK's pages vary in size, but the homepage is around 246 kB - 32 kB (13%) of which was jQuery. That’s not a huge amount, but it’s worth considering the performance impact, especially for users on low-specification devices.
The scale of the problem
GOV.UK was reliant on an old version of jQuery. We knew that we needed to upgrade, but we also knew that jQuery was causing performance issues on some parts of GOV.UK.
We decided that rather than upgrade, it would be best to remove jQuery. This was a huge task. We had at least 200 scripts, some of them only a few lines long, others hundreds, plus many more tests that also used jQuery.
How we did it
Firstly, we stopped adding any new jQuery to GOV.UK to stop the task getting larger.
We also made some hard decisions. Two of our applications contained a large amount of jQuery but don’t provide many public facing pages to GOV.UK. Rather than block progress, we gave these applications their own copy of the library, so that the majority of GOV.UK could still be made jQuery free.
This was punctuated by our COVID-19 work and other priorities, but by the start of 2022 we were in a position to start considering options for finally removing jQuery from GOV.UK.
The final push
We created a development version of the site without any jQuery that we could use to test each application. This allowed us to check for errors caused by any jQuery code that we might have missed, as well as provide the first real opportunity to measure the performance impact of our change. This testing was thorough and time-consuming and happily revealed few problems.
In late March 2022 we were finally ready to deploy our change to the live site. This required careful timing to first deploy those applications that received their own jQuery. Although including jQuery twice didn’t cause any errors, it did unnecessarily inflate the asset size for users and we were keen to not have that in place for long. Once those applications were deployed we were able to deploy the change to remove jQuery - a successful if nerve-wracking process.
From a developer perspective removing jQuery has been a long but worthwhile process. Rewriting our code has taught us a lot about it and we’ve expanded and improved our tests. In many places we’ve been able to restructure and improve our code, and in some cases remove scripts that were no longer needed.