A software publisher whose website is its first sales channel, and the one thing it didn't have time to build.

eEAT fits temperature sensors in cold rooms and fridges, mostly in hotels and restaurants. What it replaces is very concrete: the manual temperature log, written by hand, used to prove compliance with food hygiene standards. The readings flow continuously to a service hosted in Switzerland, and an alert goes out when a value goes out of range.

And most of their clients come through online search. So their website isn't a showcase: it's the top of their sales funnel.

The site ran on WordPress, loaded with plugins stacked up over the years, and it was slow to display.

It was maintained in-house, by people whose job is precisely building software. But those people had their own tools to deliver to their clients. The website was the one thing they had no bandwidth for, and that's exactly why they came to us.

Yet loading time counts in how Google ranks a site. For a company whose traffic comes from there, a slow site isn't a comfort issue: it's lost revenue you never see go by.

A custom-built site, rendered on the server: the content goes out in the delivered HTML, before any script runs. That's what makes a page display fast, and it's also what an indexing robot reads without having to execute anything.

Around it, the details that do the rest: images go through the framework's optimiser and come out as WebP at the right dimensions, the font is preloaded so text doesn't jump, the sitemap and crawl file are served correctly.

The redesign was also an opportunity to rework the design.

The question usually asked of a performance project is: what did you remove? An animation, a carousel, a tracking tool, a font? Because a fast site is supposed to be one where something was sacrificed.

Here the answer is: nothing. There was no painful trade-off, no feature turned down. Leaving WordPress and its pile of plugins was enough.

It's less heroic than a sacrifice, and more useful to know: on many sites, slowness isn't the price of a feature someone wanted. It's the price of a pile-up nobody decided on.

Speed gets you into the rankings. It doesn't get you cited.

So the site carries, in its code, seventeen questions with their answers, marked up as such, a breadcrumb trail, rated reviews, and the site's identity. That markup is precisely what an answer engine looks for when it composes an answer rather than a list of links.

A fast, silent site loads quickly to say nothing. Performance opens the door; structured content is what gets you in.

We weren't the ones who made performance a criterion. It was their number one criterion, stated as such before the project began.

That changes everything. A web project usually arrives with ten desirable qualities and no ranking between them: that's what produces sites that do everything halfway. When the client arrives with a single criterion and sticks to it, every technical trade-off has an obvious answer.

The rest of the work was going to see them. We're in Geneva, they're in Lausanne: it would have been easy to do everything by video call. An on-site workshop, with the right people in the room, gave the foundation that architecture, design and development then built on.

[What the redesign changed in rankings and traffic hasn't been measured on our side, and the old site was never benchmarked. The figures exist in their own analytics tools: it's up to them to provide them.]