Performance Is a Brand Signal: Core Web Vitals as Reputation

A friend who runs a luxury brand consultancy told me something a few years ago that changed how I think about web performance. She said that the customers she works with, high-net-worth individuals shopping for second homes, yachts, fine art, unconsciously test brands for friction. If the brand's website is slow, they will not articulate it as the site was slow. They will simply not come back. The brand has failed a test it did not know it was taking.

Most companies treat website performance as an engineering concern. They optimize images, they enable a CDN, they squeeze a few percentage points out of Lighthouse, and they consider the work done. The framing is that performance is a technical hygiene problem, not a brand problem.

This is wrong. Performance is, increasingly, the single most legible signal a visitor receives about your company. It is faster to read than copy. It is more universal than design. And it operates below the threshold of conscious assessment, which makes it harder to fake and easier to misjudge.

What visitors actually perceive

Imagine a visitor lands on your homepage. In the first second, they have made roughly three subconscious assessments: did the page render quickly, did it render correctly, and did it feel stable. These map almost exactly onto Google's Core Web Vitals: Largest Contentful Paint (LCP), First Input Delay or its successor Interaction to Next Paint (INP), and Cumulative Layout Shift (CLS).

But the visitor is not thinking Core Web Vitals. They are thinking, is this a company that has their stuff together. A slow page reads as carelessness. A jumpy page reads as amateurism. A page that takes three seconds to become interactive reads as a company that does not respect the visitor's time. None of these conclusions get articulated. They just get filed away, and when the visitor comes to choose between you and a competitor, they remember the feeling the site gave them without remembering why (web.dev: Core Web Vitals).

The brands that win this game in 2026 understand that performance is brand work. They invest in it the way they invest in typography or photography. They do not delegate it to the engineers as a technical concern.

The numbers that matter

There is a lot of metric salad in the performance world. For practical purposes, four numbers describe everything that matters for a marketing site or product surface.

Largest Contentful Paint (LCP) is how long it takes for the largest piece of content above the fold to render. Good is under 2.5 seconds. Premium feels under 1.5 seconds. The brands that feel fast hit under one second on a decent connection.

Interaction to Next Paint (INP) is how long it takes for the page to respond to a tap or click. Good is under 200 milliseconds. Below 100 is the difference between responsive and instant.

Cumulative Layout Shift (CLS) is how much the page jumps around as it loads. Good is under 0.1. Anything visible is reading as broken.

Time to First Byte (TTFB) is how long it takes the server to send the first piece of the page. Good is under 600 milliseconds. Edge-rendered or static pages hit under 100.

Most sites I audit fail at least two of these. The most common failures are LCP, because of unoptimized hero images or render-blocking scripts, and CLS, because of fonts loading late or ads injecting after page load. Both are fixable, and both are usually caused by decisions made by a brand or marketing team without performance considered.

The decisions that cost you performance

If you want to find what is slowing down your site, do not start with the JavaScript bundle. Start with the brand decisions.

The first usual suspect is the hero video. A four-megabyte autoplay video above the fold is a brand decision (the brand team wanted motion) with massive performance consequences (LCP is now four seconds on a slow connection). The right answer here is almost always use a high-quality image, or use a much smaller looping video clip with a poster frame, or both. The brand wins are usually invisible. The performance loss is real.

The second is web fonts loaded from third-party CDNs. Self-hosting your fonts as woff2 and preloading the critical weight gets you most of the way back. Using font-display: swap prevents invisible-text flashes. Most sites I look at are leaving free Lighthouse points on the table here.

The third is third-party scripts that nobody audits. Analytics, chat widgets, A/B test scripts, marketing pixels, each one adds bytes and runtime cost. Most companies install these and never remove them. By year three, the homepage has fifteen third-party scripts and a five-second time-to-interactive. The fix is brutal: audit them quarterly, and remove anything that isn't pulling its weight.

The fourth is image weight. Modern formats, AVIF and WebP, are roughly half the size of equivalent JPEGs at the same visual quality. Responsive srcset serves a smaller image to phones. Lazy-loading below-the-fold images defers their cost. Most sites do none of this and serve a four-thousand-pixel-wide JPEG to a phone.

Why this is brand work, not engineering work

A pure engineering team, given the goal make the site faster, will optimize what they control. They will compress images, code-split bundles, and add caching. They will get the site somewhat faster. They will not, however, push back on the brand team's decision to put a four-megabyte video above the fold, because that is not their decision to push back on.

This is the structural failure. Performance gains that matter come from decisions made earlier in the process, design, brand, marketing, not from optimization applied to a finished design. If the brand team commissions a homepage with eight custom font weights, six animated illustrations, and an autoplay video, the engineering team can only do so much. The damage was done in the brief.

The studios that get this right involve performance in the brief. They have a target, for example, LCP under 1.5 seconds on a 3G connection, and design within it. This is exactly analogous to print-design constraints in the era when print mattered. A poster designed for a magazine had a trim size, a paper weight, a maximum bleed. The constraint shaped the design. Performance is the modern equivalent constraint, and the studios that respect it produce work that is, paradoxically, more interesting than studios that ignore it. Constraint produces creativity. The opposite produces bloat.

Fast sites feel premium. Slow sites feel cheap. This has nothing to do with what is on the page and everything to do with how the page arrives.

What to ask for

If you are commissioning a website right now, two questions in your brief will shift the entire result.

First: what performance targets are you designing to? A serious answer is LCP under 1.5 seconds, INP under 100 milliseconds, CLS under 0.05, on a representative slow connection. A non-answer is we'll optimize at the end. The first means performance shaped the design. The second means it didn't.

Second: how will you measure performance after launch, and what happens if it regresses? A serious answer is we set up Real User Monitoring with alerts at our targets, and a performance regression is a bug that blocks deploys. A non-answer is we'll check Lighthouse occasionally.

These two questions take about ninety seconds to ask. The difference in the answer separates studios that treat performance as brand work from studios that treat it as an afterthought. After years of building for the web, I am fairly confident which group produces the work that lasts.

If you are about to ship a new site and you have not asked these questions, ask them. The visitor who closes the tab at second four does not write you an email about it. They just file the feeling and move on. The brand they remember is the one that arrived instantly. Be that one.