2 women at a desk in an office

In the first blog post we covered "How and why we removed jQuery from GOV.UK", let’s now turn our attention to what performance difference it has made for users. Please read that blog post before this one.

Image data versus compressed data

As mentioned previously, the jQuery library was only 32 Kb of compressed and minified (when white space removed from code and repeated words substituted) JavaScript. Now I know what you may be thinking, that doesn’t sound like a lot of data, especially compared to images which can be multiple megabytes in size. But when it’s on every page, from a web performance perspective, it equates to a lot of data. It’s also worth mentioning that there’s a big difference between image data and compressed JavaScript data. Browsers and devices handle the 2 data types very differently.

JavaScript is known as a “render-blocking” resource. This means when a browser encounters JavaScript it goes through a multistep process which involves it being downloaded, then uncompressed, before it’s finally parsed and executed. This all happens within a device’s available Central Processing Unit (CPU) and memory. These tasks can be very slow and energy intensive depending on the device and connection.

Unfortunately, during this time, the actual drawing of pixels to the device’s screen has to be paused until the execution of the JavaScript is completed. Upon completion the browser can then continue to paint pixels for the rest of the page.

Images and image data aren’t “render-blocking”, meaning parts of the webpage can be painted to the page while additional image data is being downloaded in parallel. Therefore, a 32 Kb image has much less of a performance impact than 32 Kb of compressed JavaScript. This is especially true for users on low specification devices that are generally slower, older and less expensive.

We will focus on these users for the rest of the blog post.

Helping users with low specification devices

Lower specification devices are often considered to be older laptops and tablets, or ‘budget’ mobile devices (often Android devices on a limited data plan).

Since these users have the slowest devices, they’ll need the most help to make sure their visit to GOV.UK is as fast, efficient and as cheap as possible. Last October, Ofcom estimated 2 million households were "experiencing affordability issues with either their fixed broadband and/or smartphone", so our work here has the potential to reduce their internet costs.

Image of a load time distribution graph from Real User Monitoring data for GOV.UK over the month of May 2022, showing our 75th percentile load time is 0.824 seconds and that some users see a load time as big as 2.35 seconds.

At this point, it’s worth mentioning that the anonymous Real User Monitoring (RUM) data we collect from user devices shows that GOV.UK is already a very quick website. For the majority of users, the site loads in less than 1 second. But the distribution graph (seen above) also shows that there are some users that see a page load time of up to 2.35 seconds. Examining these users’ RUM performance data more closely, we see:

  • 75% of users are based in the UK
  • 35% of users are on an Android device
  • it’s taking almost 2 seconds for the first page pixels to display on their screens (this is called the start render metric)

From the statistics above, we can assume it’s highly likely that many of these Android users are on low specification devices where CPU speed and memory capacity is limited.

With that assumption in mind, what performance impact will removing 32 kB of compressed JavaScript have?

Testing the impact

This is where our “lab-based” performance testing is very useful. We run tests every day on GOV.UK pages using specific simulated devices and connection speeds. Because we can repeat these tests every day, it allows us to monitor what the changes we are making to the site are doing for real users visiting GOV.UK.

For example, for a simulated user visiting the Universal Credit start page on a low specification device and 2G mobile connection, we can clearly see from the graph where the jQuery change was made.

a graph of page render time performance over the past 3 months for the Universal Credit start page. In the graph, the performance difference can be clearly seen as a reduction in time when the jQuery change was made.

The reason why the Universal Credit page was chosen is because it’s the most visited page on GOV.UK according to our analytics data, so it is important that it loads quickly for all users, no matter what device or connection they are using. As the graph above shows, the time it took for the page to completely draw the pixels to the screen (visually complete) dropped from 11.3 seconds to 9.4 seconds (a 17% improvement).

As well as visually complete Improvements, page load time improvements were also clearly seen. The graph below shows the time until the page has fully loaded dropped from 20.42 seconds to 18.75 seconds (an 8% improvement) and total page load time dropped from 19.44 seconds to 17.75 seconds (a 9% improvement).

a graph of page render time performance over the past 3 months for the Universal Credit start page. In the graph, the performance difference can be clearly seen as a reduction in time when the jQuery change was made.

Finally, we also see a significant improvement in the page’s interactive performance metrics, meaning a user can interact with the page a lot sooner. Interactivity metrics are important to users as they show when the user can first interact with the page. Being able to interact with a page gives users confidence that the page is still working.

The graph below shows time to interactivity dropped from 11.34 seconds to 9.43 seconds (an improvement of 17%), and the devices First CPU idle dropped from 11.32 seconds to 9.42 seconds (an improvement of 17%).

a graph of interactive performance metrics over the past 3 months for the Universal Credit start page. In the graph, the performance difference can be clearly seen as a reduction in times when the jQuery change was made.

Improving GOV.UK for everyone

Improving web performance is often made up of lots of smaller incremental changes over time. So it’s been great to see support for this change from the wider web performance community.

As you can see from our performance monitoring results above, we have improved page performance for many users who struggle on low specification devices and slow connections, even though GOV.UK is already a very quick website for the majority of users. It may sound like 32 kb of JavaScript is nothing on today’s modern web with quick devices and fast broadband connections. But for a certain cohort of users, it makes a big difference to how they experience GOV.UK.

Subscribe to Inside GOV.UK

If you’re interested in this work, why not join the team? Apply to work at GDS

Original source – Inside GOV.UK

Comments closed