Speed gets treated as an engineering problem. We think it is a brand problem.
When a site loads quickly, the business behind it feels capable. Pages snap into place, interactions respond as expected, and nothing stutters or drifts. That is a quiet kind of confidence, and it shapes how the brand is perceived long before any of the visual design has registered.
When a site is slow, every other piece of effort gets undermined. The logo can be perfect and the photography stunning. None of it lands properly if the page takes four seconds to render, or shifts under the user as it loads.
The bit most teams miss
Performance and brand are usually owned by different people. Brand sits with marketing. Performance sits with engineering. The result is that performance gets treated as a technical hygiene factor, not a design decision, and it gets fixed at the end of the build rather than designed into the work.
We treat it the other way around. Performance is part of the brief from the first conversation. It shapes what the page does, what gets loaded, what gets deferred, and where we draw the line on motion, imagery, and dependencies. The end result is a site that feels coherent in a way users notice without being able to put their finger on it.
What this looks like in practice
When we design and build a website, we make decisions on behalf of performance throughout the process, not at the end of it. A few examples of how that plays out.
We choose static-first frameworks where we can. The Bodkin site itself is built with Astro, which generates HTML at build time and ships almost no JavaScript by default. That’s deliberate. It means the page is responsive the moment it lands in the browser, not after a stack of scripts has finished initialising.
We treat images as a design system, not a free-for-all. Every image is sized, formatted, and served at the right resolution for the device. Hero images are optimised aggressively. Decorative imagery is loaded lazily. We avoid uploading unconstrained assets through a CMS and trusting it will work out at scale.
We are conservative with motion. Motion can absolutely be a brand asset. It can also tank a page. We use animation deliberately, on specific moments where it earns its place, and we measure its cost. We don’t animate things just because animation is the default.
We are careful with third parties. Most performance disasters we audit are caused by tag managers, marketing tools, and analytics scripts. We help clients understand what those tools cost and how to load them in ways that do not block the user experience.
Accessibility belongs in the same conversation
Accessibility and performance are usually treated as separate concerns. They are deeply linked. A slow site is a less accessible site. A site that loads features piecemeal is harder to use with a screen reader. A site that hides reflows and unexpected jumps inside lazy-loaded content is worse for everyone, but especially worse for users on slower connections, older devices, or assistive technology.
We aim for WCAG 2.2 AA conformance on every site we build. We test using CollectivAlly, an accessibility tool that we have helped develop and that we use in our own QA process. Building accessibility in from the start, rather than retrofitting it at the end, is the only way to do this without hidden compromises.
The point is that none of these are technical hygiene factors. They are brand signals. Users would never put it in those words, but they feel it.
The cost of getting this wrong
A slow, fragile, hard-to-use website is one of the most expensive brand mistakes a business can make. It quietly costs you confidence with every visitor, including the ones who came specifically to be impressed. It damages search performance through Core Web Vitals. It undermines the work the rest of the brand is doing.
We have audited sites where the brand identity was clearly considered, the visual design was thoughtful, and the photography was excellent, and the whole thing was failing because the site weighed eighteen megabytes on landing.
Fixing that is not a technical project. It is a brand project, dressed up in technical language.
How we think about this with clients
When we start a website project, we don’t promise the fastest site on the internet. We promise a site that is fast enough, every time, on every device, and that holds that performance as the business grows.
That commitment shapes every decision in the build. It is also the reason most of our recent web work feels coherent in a way that is hard to copy. The visual quality is doing some of the work. The performance is doing more of it than people realise.
If your current site looks the part but feels slow, fragile, or hard to maintain, we should talk. Start a conversation with us, or read more about how we approach websites near Bath.
