Front end performance

Why fast and light websites matter

Speedy websites are better for any organisation, but are especially important for Barnardo's.

Not everyone has an iPhone or Samsung

Below is a list of some of the device manufacturers we see in our analytics. They are almost all very cheap phones, and we know many of them are used by refugee and immigrant communities. Many of the models don't have 3G, and have a pre-installed browser with limited capabilities.

These devices can't download, parse, compile, render or execute code at anything near the speed of a top of the range phone, and they stand no chance with a big JavaScript bundle.

Data is expensive for a lot of people

At Barnardo's we know a lot of people who come to us for help don't have home internet. They rely on their data plan which is often pay as you go (PAYG). When that runs out they have to use free, often insecure wifi or do without.

The median weight of web pages delivered to phones is just over 2 megabytes. Somebody who can afford a £5 per month top up, paying 10p per megabyte, can only see 25 web pages at that weight. And that's if they don't use email, social media or messaging apps.

All web pages on Barnardo's products should be less than 100 kilobytes.

Making phones work hard consumes battery

Developers must be mindful of end users' battery life. From The potential for empowering homeless people through digital technology (2013, PDF):

One fundamental problem that homeless and vulnerable people currently face is the issue of recharging their devices. Many homeless people put themselves in danger in order to access power for their devices, trespassing private property and using outdoor power sockets. Examples in the UK are difficult to find, but in the US, many homeless people resort to trespassing. This puts them at risk of altercations, violence, or even arrest.

Obviously, using heavy JavaScript to render sites on client devices will take its toll on a user's battery, but so will other very common techniques. Sending large images and using CSS max-width:100% to to force a browser to resize an image creates a measurable delay while the user's phone consumes CPU cycles to do this. Instead, resize images at build time and use HTML responsive images so the browser can choose the correct size.

Network performance is bad for everyone some of the time

No matter how expensive your device or how many megabytes in your data plan, there are times when wifi dips or when mobile internet signal wobbles around the slow end of 3G. A light website has a better chance of delivery to users' devices under poor network conditions.

Conversions are better on fast websites

Faster web pages and interactions are strongly correllated with improved results. The evidence is overwhelming.

If your site is for delivering information, more people will see it on a fast web site.

If your site is for increasing contact, more people will get in touch from a fast web site.

If your site collects donations, more people will donate on a fast website.

Perceived performance

Every web page and interaction should feel fast. However the phrase 'perceived performance' often means using tricks to make a slow website feel fast, whether by making the waiting seem shorter or doing heavy lifting in the background (often making a page unresponsive). At Barnardo's we insist upon actual performance.

Measuring performance

Developers are free to choose the tools they prefer for measuring performance, however all pages must pass core web vitals in the Chrome User Experience Report (CrUX). A brand new site must pass core web vitals in a lab test.

Product owners and developers must continually monitor the performance of their sites and fix any issues that arise.

For experimenting and refining page performance we recommend using Cloudflare workers and WebPageTest to test ideas before deployment.

Architecture constraints

Developers must apply the rule of least power when assessing front end technology for a web site or app.

Static site generators must be the first technology assessed, ruling out any that can't be deployed with 0kb of JavaScript, and preferring those that start with 0kb of JavaScript by default.

When client side JavaScript is needed use progressive enhancement, or progressively enhanced islands architecture. For example partial hydration in Astro and 11ty <is-land>.

Fully client-side rendered JavaScript frameworks are not suitable for any Barnardo's product or our users, therefore must not be considered. Server side rendering with full hydration is strongly discouraged, and should only be considered as a last resort.

Reading list

Suggested feeds