The Beautiful Website Google Won't Forgive: Core Web Vitals and the Problem That Starts in Figma (Not on the Server)

Tuesday morning, late September 2025. I'm sitting at one of the outdoor tables at the Gran Caffè Garibaldi, on the corner where Corso Garibaldi meets Piazza Bovio. Across the street, the façade of the Teatro Garibaldi dominates the square, overlooked by the historic Liceo Classico Nevio with its semicircular terrace and arched windows — one of those Santa Maria Capua Vetere buildings that seems to exist purely to remind you that some structures weather centuries, while others buckle at the first sign of rain. The late-September air still carries that stubborn warmth that clings to your shirt. The Corso drifts sleepily past the edge of the awning.

Berto is sitting across the table. Luigi introduced us — a long-standing client in the construction sector I've been working with for nearly a decade: "Umberto, I'm sending a friend your way, you're the right person for him." The kind of call that, in Campania, counts for more than any signed and notarised contract. Berto runs a well-established bespoke furniture company in the area — one of those entrepreneurs with work-worn hands and a deep-rooted wariness of anything that happens inside a screen, particularly since a dodgy consultant relieved him of a fair bit of money back in 2012 for an advertising campaign that never got off the ground. He's not agitated. Berto never shows agitation openly. But there's that fixed look in his eyes — the look of someone who's spotted a jammed cog and wants to know exactly which part needs replacing.

He places his phone on the table, sliding it towards me face down, then flips it over. "Umberto, look at this. There's a lad from Maddaloni who runs online cookery courses from his basement. If I search 'cookery course Caserta' he comes up first every time. Every single time. I had my site rebuilt three months ago. Paid £3,800 to a proper design studio. It's beautiful — clean, with high-resolution photos of the sofas that look like they've come straight out of a Milan design magazine. And yet if I search 'furniture Caserta' from my phone, I don't even show up on the third page of Google. Have I been done over again?"

I give it to him straight: it's not the copy, it's not the SEO strategy, and nobody's deliberately stitched you up. The problem is that your gorgeous website takes 5.8 seconds to display the main image on a smartphone, and the entire page jumps three times as the fonts try to load. Google has witnessed this digital ordeal. Google has measured the user experience. And Google has simply wiped you off its map.

The week before, I was in London — Clerkenwell — for a meeting with Bobby, a client I'd taken on six months earlier to manage the social media and digital communications for his boutique corporate events agency between Shoreditch and Southwark. Good work, numbers moving in the right direction: Bobby's one of those Brits who won't thank you until he sees the data actually shift, but once it does, he hands you the rest of the brief too. "Since you're handling the communication side already, might as well look at the website too." And there it was: immaculate opening animations, floating text, vector images assembling themselves as you scroll, an Awwwards mention in the month of launch. A visual triumph that hadn't generated a single quote request in ninety days. PageSpeed Insights: 28 out of 100. The contact form: as silent as a Sunday morning in Southwark.

This is where the great misunderstanding of contemporary digital communications plays out. Core Web Vitals aren't a dull checklist of technical parameters to dump on the developers at the last minute. A website's performance is decided long before the server ever gets involved — it's decided in the wireframe, in the choice of that specific hero image, in the decision to use four variants of a custom typeface, in the heavy animation a designer dropped into Figma simply because it "created atmosphere". If you design visual interfaces and you don't know what LCP, INP, and CLS actually measure, you're tailoring a haute couture outfit from fabric that dissolves in the first shower. You're handing your client a stunning shopfront that Google will tuck away down a dead end.

This piece isn't written for people who write code. It's for the people who design the visual experience.

The invisible contract between design and visibility

There's a silent chain of failure that repeats itself identically from Naples to London, regardless of time zone or budget. It always starts with an ambitious brief: the client wants to impress, wants a digital identity that stands out from the grey mass of competitors. The designer opens Figma and does what they do best: creates beauty. Smooth transitions, full-screen images with no compromise on resolution, graphic elements that intersect in spectacular ways. The file gets approved with enthusiasm. It then lands on the developer's desk, who sets about turning those visual dreams into HTML, CSS, and JavaScript. The site goes live. The client is happy. Everyone smiles — except one party: Google's crawler.

The search engine doesn't get excited by a well-judged colour pairing or a silky transition on a thirty-inch monitor in Shoreditch. Google opens the site simulating an average user on a suboptimal mobile connection, with a mid-range device. It measures real response times, calculates the stress placed on the phone's processor, and if the numbers don't add up, it penalises the indexing — silently, definitively, with no right of appeal.

Data from the HTTP Archive Web Almanac 2025 shows that just 48% of pages on mobile devices and 56% on desktop successfully pass all three Core Web Vitals. More than half of all websites are running with the handbrake on, gifting a wide-open stretch of organic ranking to those businesses that have chosen to treat performance as a primary design consideration.

To understand just how deep this pattern runs, you only need to look across the Channel. A sector-by-sector analysis by British agency Warbox Creative found that fashion brands in the UK recorded the worst web performance scores across fourteen market segments examined — despite more than a third of British consumers making the majority of their clothing purchases online. These companies invest millions of pounds in extraordinary photographic productions and interface design crafted by the finest studios on City Road or in Hackney. And yet they end up with platforms that frustrate users at the first click, bleeding organic traffic share. Aesthetics pursued for their own sake, without any technical grounding, produces nothing but splendid digital wastelands.

Why the problem starts in Figma, not on the server

When a site fails speed tests, the instinctive reaction is to blame the hosting. The slow server. The poorly configured database. In the vast majority of real cases I monitor, that's the wrong diagnosis. The root of the problem runs back to the earliest stages of visual design.

If the designer specifies a hero section with a looping cinematic video and no lightweight alternative, they're loading between 5 and 10 megabytes of data onto the user's connection before they've had a chance to read a single line of text. If they add continuous micro-animations to every element that appears on screen, they're forcing the browser to constantly occupy the main thread — the processor's primary logical channel — recalculating graphic positions.

It always reminds me of the carpenter who had his workshop on the main street in Portici, just round the corner from the Pietrarsa museum. He built beautiful shelves — hand-inlaid, with spectacular lacquered finishes. A client commissioned him to build a bookcase for a legal practice. The craftsman made it without once asking how many ring binders and law volumes it would need to hold. The problem didn't emerge when the bookcase was fitted, smooth and perfect. It emerged three weeks later, when the client loaded the entire legal encyclopaedia onto it and the central uprights began to bow, splitting the hinges. Dismantling, reinforcing, and repairing cost twice as much as a structural calculation done at the outset would have. In web design, exactly the same thing happens.

LCP, INP, CLS: three acronyms that determine whether you exist on Google

I want to strip away the technical jargon and translate these parameters into concrete, human terms. Three pillars: how quickly things appear on screen, how promptly the site responds to user input, and the visual stability of graphic elements. I'll explain them the way I'd explain them to Berto over that coffee in Santa Maria Capua Vetere — without losing a scrap of the precision the algorithm demands.

LCP — Largest Contentful Paint: the dish that arrives late

LCP measures the time it takes for the main visible element above the fold — the portion of screen visible without scrolling — to render completely. In most modern layouts, this means the hero image, the main heading, or the background video.

The aesthetic choices that wreck LCP are predictable: hero images exported as native high-resolution JPEGs without compression (4–8 megabytes per file is not unheard of), third-party fonts loaded via @import in the main CSS — a method that blocks any text from displaying until the entire stylesheet has downloaded.

A real-world case documented on Google's official platform, web.dev, shows how the Vodafone Italia team managed to improve their portal's performance by reducing LCP by 31%. They didn't change the servers: they implemented Server Side Rendering for critical HTML, removed unnecessary JavaScript that was blocking the load, and optimised product image formats. The direct, measurable result: +8% on online store sales. Speed isn't a technical nicety. It's a business metric.

I'm always reminded of a restaurant in Naples back in 2024 — a gorgeous place, top of TripAdvisor, an established clientele. Site commissioned from professionals, full-screen food photography at 6 megapixels apiece, Playfair Display pulled in from Google Fonts without optimisation. Lighthouse: LCP at 7.2 seconds on a mobile connection, PageSpeed score 23 out of 100. For anyone searching where to eat in Naples without already knowing the restaurant's name, that place was simply invisible.

INP — Interaction to Next Paint: the waiter who doesn't respond

In March 2024, Google permanently retired the old FID metric, replacing it with INP. Not a simple name change — a genuine revolution in how the algorithm evaluates interactivity. Where FID measured only the delay on the very first interaction, INP monitors the responsiveness of every click, tap, and keypress throughout the entire session. The official Chrome User Experience Report release notes lay out the difference starkly: 99.9% of sites comfortably passed FID on desktop, whilst only 77.3% of origins achieve a satisfactory INP score — a structural collapse that pushed millions of pages into the red zone overnight, having previously been fully compliant. According to the Web Almanac 2025, 43% of sites still fail to meet the 200-millisecond INP threshold, making it the most commonly failed Core Web Vitals metric across the web.

INP thresholds:

• Under 200ms: Good. The site responds instantly.
• 200–500ms: Needs improvement. The interface starts to feel sluggish.
• Over 500ms: Poor. The user taps repeatedly, convinced the button is broken.

The primary cause of a high INP almost always lies in how advanced visual effects are handled. When a designer incorporates scroll-driven animations managed through heavy JavaScript libraries, every millimetre of movement forces the browser to recalculate the geometry of the entire layout. Take the opening animation on Bobby's site in Clerkenwell: it was built on an 847-kilobyte JavaScript library. Every element on the homepage — heading, subheading, hero, even the menu — appeared with a sequential fade and a slight upward drift. Visually spot-on. Technically: 800 milliseconds of saturated main thread on every attempted interaction. Bobby found out well after launch.

Renault tackled this systematically across their vehicle configuration pages: by stripping back third-party scripts and optimising the loading of variable fonts, they recorded a 13% increase in test-drive enquiry conversion rates (source: web.dev). When the interface responds immediately, the user completes the action. When it hesitates, they leave.

CLS — Cumulative Layout Shift: the table that moves while you're eating

CLS measures the visual stability of a page during loading — the total sum of every sudden shift suffered by graphic elements whilst the user is already reading or interacting.

CLS thresholds:

• Under 0.1: Good. The page is rock solid.
• 0.1–0.25: Needs improvement. Some blocks shift when late-loading elements arrive.
• Over 0.25: Poor. The layout shifts continuously, causing unintended clicks.

The design choices that destroy CLS are as simple as they are common: images without width and height attributes declared in the code, fonts that load late and alter heading dimensions relative to the system fallback, cookie banners, pop-ups, and ad blocks that appear out of nowhere, shoving the text aside.

Here's what happens to anyone browsing on mobile: you're reading an article, you spot an interesting link, you move your thumb to tap it — and at that precise millisecond a banner loads at the top. Everything shifts three centimetres downward. Your finger lands on the ad instead of the link. That's CLS in its most infuriating form. Google tracks it through real browser data from Chrome and downgrades the site without mercy.

Swappie, the European market leader in refurbished smartphone sales, tackled this head-on across their mobile e-commerce: by restructuring product pages to prevent visual shifts, they achieved a 91% reduction in CLS and a 55% reduction in LCP. The direct revenue growth from mobile traffic: +42%. A stable layout is a layout that sells (source: web.dev). 

The 5 design mistakes that wreck performance

Here they are — the five mistakes I see time and again, from Naples to London. These aren't technological limitations in the code. They're design decisions made upstream, when the designer's digital pencil draws shapes without accounting for the physics of the browser.

1. The unoptimised hero image

The mistake isn't in pursuing visual quality. A professional photographer should deliver outstanding shots. But the designer needs to understand that the original export format cannot be the same file published online. A native 4-megabyte JPEG and a compressed 180-kilobyte WebP deliver exactly the same visual quality on a smartphone screen.

Google doesn't look at your site through the eyes of an art director: it reads the file size in kilobytes and the download time. The solution is to include in the creative brief a firm requirement for next-generation output formats, with a hard ceiling of 150–200 kilobytes for above-the-fold images.

2. The Google font loaded the wrong way

A few months back I was working on a project for a dental practice in Vomero, Naples. Their designer had specified Cormorant Garamond in three weight variants, loaded via @import in the main CSS. Lighthouse flagged a 1.8-second render block caused by that single request alone. The prospective patient searching for a dentist on their phone during a lunch break — probably on via Scarlatti, surrounded by the market crowds — was never going to wait nearly two seconds staring at a blank screen. Designers choose trending typefaces like Clash Grotesk or Inter without specifying a fallback or thinking through how they'll actually load.

The fix is straightforward: font-display: swap in the CSS, a system fallback font with similar proportions, and where possible self-hosting the font on your own server rather than loading it from Google Fonts — a choice that consistently delivers an LCP improvement of between 10% and 30%.

3. The opening animation that blocks everything else

I already mentioned this in Bobby's experience in Clerkenwell. It's worth unpacking the mechanism. A complex JavaScript animation that brings in headings, moves geometric blocks, and creates cross-fades on load monopolises the browser's main thread during the critical loading phase. Whilst the smartphone is busy running these graphical calculations, the interface goes completely deaf to any external input. The user taps. Nothing happens. They tap again. Still nothing. By the third attempt, they're already on another site.

The solution: complex animations in the first viewport reduced to an absolute minimum or removed entirely. Any dynamic effect is triggered only after the first scroll, leaving the opening section free to load and respond instantly.

4. Images without declared dimensions: the most underestimated cause of CLS

This is the invisible mistake. I was monitoring a site for an estate agency in Caserta that was loading property photographs without specifying width and height in the tags. During a Lighthouse test in "slow 4G" mode I counted seventeen consecutive layout shifts on the listings page. Seventeen times the content lurched downward whilst the user was trying to click on something. CLS: 0.81. Bright red. The mechanism is straightforward: the browser doesn't know how much space to reserve for an image until it downloads it. If nobody's told it in the code, it allocates zero pixels initially. When the image arrives, it suddenly expands the block, pushing everything else down.

The fix takes thirty seconds per image: explicitly declare width and height in the tag. It changes nothing about the creative vision. It stabilises everything.

5. The autoplay hero video with no strategy

I saw this mistake in its worst form on a boutique hotel website in the Southwark area of London, during a recce for a client who was weighing up a commercial partnership. The uncompressed 4K opening video weighed 14.2 megabytes. Loaded without a poster image, without lazy loading, at full resolution. The manager showed it to me with evident pride: "look at this intro." LCP: 9.3 seconds. The bar on the ground floor was getting more bookings by phone than enquiries online.

If video is genuinely tied to a real narrative purpose, the solution is lazy loading paired with a lightweight WebP poster image: the browser displays the static image immediately — satisfying the LCP — whilst the video loads in the background.

How to measure right now: free tools in 10 minutes

The toolkit I reach for every time I pick up a web project hasn't changed much in three years. Not because better tools don't exist — but because these are free, precise, and work in the right order. I run through them systematically before showing any work to a client. From an agency on City Road to Naples, from an office in Caserta to a laptop on a pub table in Southwark: three URLs I never forget.

Google PageSpeed Insights: the starting point

The quickest way in is pagespeed.web.dev. Enter the URL, wait thirty seconds, receive a score out of 100 — separate for mobile and desktop. The colour coding is instant:

• Green (90–100): Optimal. LCP under 2.5s, INP under 200ms, CLS under 0.1.
• Amber (50–89): Warning signal. Bottlenecks to address.
• Red (0–49): Active penalty. The site is losing positions every single day.

That morning at the Gran Caffè Garibaldi, with the façade of the Liceo Classico Nevio opposite and the coffee still warm on the table: we opened PageSpeed Insights on the laptop and entered the URL of Berto's £3,800 website. Bright red screen. LCP at 5.8 seconds, CLS at 0.47, INP at 450 milliseconds. Then we entered the competitor from Maddaloni: all green. LCP at 1.9 seconds, CLS at 0.04, INP at 180 milliseconds. WordPress with Elementor, images optimised with an automatic compression plugin at $29. No stylistic frills. First on Google.

Google Search Console: Page Experience and real-world data

Whilst PageSpeed Insights runs an instant snapshot test, the "Page Experience" report in Google Search Console collects and analyses real navigation data from the past twenty-eight days — the dashboard Google actually consults when deciding whether to reward or demote a site. If the report shows that a significant proportion of users are experiencing real slowdowns from their phones, Search Console lists exactly which URLs need fixing.

Lighthouse in Chrome DevTools: the in-depth analysis

For those who want to check the work before going live: F12 → Lighthouse → "Analyse page load". Not just the numerical CWV scores — a detailed list of actionable suggestions, prioritised by impact. The exact list of images to compress, which scripts are blocking the main thread, how many kilobytes of unused CSS can be stripped out. Free, already installed in the browser.

The case studies: those who got it right, and those who paid the price

Those who optimised and saw the numbers shift

The most rigorously documented case is that of Rakuten 24, the e-commerce arm of the Japanese tech giant. As analysed in detail on web.dev — Google's official technical resource — the team launched a pilot project optimising a high-traffic promotional landing page, then ran an A/B test over one month: 50% of traffic on the optimised version, 50% on the original. Result: +33.13% in purchase conversion rate, +53.37% in revenue per visitor. Not an agency selling SEO services: Google's own house, empirical data, scientific method.

Add to this the results already cited: Vodafone Italia +8% on sales after a 31% improvement in LCP. Swappie +42% in mobile revenue after a 91% reduction in CLS. When the digital architecture stops getting in the way of the user's every step, the barrier to purchase collapses.

Those who ignored the problem — and why it's a design issue, not a development one

British fashion brands averaging 55 out of 100 on PageSpeed don't have a hosting or server problem. They have a creative process problem: nobody in the entire decision-making chain ever raised the question of performance before launch.

Bobby worked that out after six months stuck at a score of 28. When we analysed the site together — I opened Lighthouse in front of him at a meeting I'd called specifically for that purpose — the blame for the disaster didn't lie with the server configuration. It came down to three purely graphic decisions made upstream by the designer in Hackney: an uncompressed cover image at 9.4 megabytes, a custom font loaded in a way that completely blocked text rendering, and a JavaScript scroll animation that saturated the main thread for 800 milliseconds on every interaction. Three stylistic choices. Three Google penalties. Zero quote requests for ninety days.

Designer vs developer: who's to blame?

The honest answer is: both, and neither definitively. The designer cannot ignore the structural weight of their visual choices — that much is certain. But the developer cannot optimise after the fact what has been poorly designed without a disproportionate cost in time and resource. The real problem isn't the competence of the individuals involved: it's that the word "performance" is never mentioned during the initial brief. It's not in the document. It's not on the checklist. It's not in the conversation between client, designer, and developer before the first wireframe is drawn.

The solution isn't technical. It's procedural.

The permanent building site: what happens when you apply the rules to your own site

By way of direct comparison: the Insight ADV website — nearly 600 articles in two languages, a glossary of over 900 terms, also in two languages, a full portfolio, variable fonts, animated sliders, structured SEO optimisations — records a total homepage load time of around 651 milliseconds as measured by the Navigation Timing API. On more complex pages it rises to around 2 seconds, still comfortably below Google's critical threshold. That's not a lucky accident: it's the result of every choice described in this article applied systematically — all images in WebP, minified HTML and CSS, lazy loading, preloading of critical resources, Cloudflare configured to absorb traffic spikes.

And yet even this site has an open wound I haven't closed yet.

The agency's FAQ section runs to over 150 questions with answers, all marked up with JSON-LD structured data for Google's rich results — the correct implementation, the one every SEO guide recommends. At a certain point, performance monitoring flagged that this specific section was generating a volume of requests that was significantly degrading response times across the entire site. The decision was clear-cut: remove the structured data from that section, accept the SEO compromise in favour of speed. It's not the ideal solution. It's the real one — the kind you make when you're dealing with a complex site, a well-established content architecture, and a resource load you can't lighten without losing either visual identity or editorial coverage.

That wound is still there. We're working on it. It's a permanent building site, not a project with a final handover date.

The performance budget isn't a formula you apply once and shelve. It's an ongoing negotiation — between speed and content richness, between SEO optimisation and load stability, between the experience you want to deliver and the physical constraints of the browser that has to render it. Anyone who tells you their site is "optimised" in the sense of "finished optimising" either doesn't have a complex site, or isn't measuring enough.

The performance budget: designing within limits, as architecture has always done

Web design has physical constraints. Ignoring them doesn't make them disappear — it turns them into your client's problem, and a dent in your professional reputation. Designing for the web must stop treating itself as a blank artistic canvas with no limits, and start borrowing its rules from established disciplines like architecture: an engineer's first question isn't about the decorative details, it's about the maximum load the floor slab can bear.

What a performance budget actually looks like in practice

A performance budget is a technical and creative agreement signed off by all parties — client, designer, developer — before the first wireframe is drawn. A concrete working example:

• Target LCP ≤ 2.5s → above-the-fold images: max 120KB in WebP or AVIF.
• Target CLS ≤ 0.1 → all image tags with width and height declared; every font with a similarly proportioned system fallback.
• Target INP ≤ 200ms → no JavaScript animation libraries for elements in the first viewport.

Why it's not a creative straitjacket

The typical designer's reaction to a performance budget is visceral refusal — experienced as an attack on expressive freedom. It's a misunderstanding. Mandating WebP format doesn't say "your image mustn't look brilliant". It says: save it using a modern compression algorithm rather than one from the nineties. Requiring declared dimensions on images doesn't alter the visual layout by a single pixel: it simply defines the technical delivery parameters. Exactly as the dimensional constraints of a cardboard packaging box don't limit the talent of the graphic designer working on its exterior — they simply define the industrial production boundaries.

A proper Neapolitan Sunday ragù doesn't tolerate shortcuts. It needs to blip gently on the hob over a low flame for exactly the right amount of time: not a minute less, not an hour more. The designer who respects a performance budget isn't surrendering their project's visual ambitions — they're simply choosing to cook their creative idea over the right heat of contemporary technology.

Practical tools every designer should have in their workflow

For images

Squoosh.app — built directly by Google's labs. Drag any image into the browser and compare the original quality against the WebP or AVIF-compressed version in real time, seeing the actual saving in kilobytes before you export. Free, no installation required. For bulk compression: TinyPNG and TinyJPG cover the high-volume cases. The rule to keep in mind: no above-the-fold image over 200KB. Ideal target: 80–120KB.

For fonts

Fontsource (fontsource.org) — an open-source platform for downloading and self-hosting Google Fonts directly on your own server. It eliminates the HTTP request to an external domain on load, with a documented LCP improvement of between 10% and 30%. If you're keeping the Google Fonts link, adding the &display=swap parameter to the font URL is non-negotiable: the browser then displays a provisional system font whilst downloading, eliminating invisible text.

For measuring and monitoring

• PageSpeed Insights (pagespeed.web.dev): instant analysis for any public URL.
• web.dev/measure: full CWV audit with prioritised recommendations.
• Lighthouse in Chrome (F12): testing in a local environment before launch.

My workflow: Squoosh to optimise images during production, Lighthouse before handing the final mockup to the developer, PageSpeed Insights as the final validation check before raising the invoice.

Conclusion: the site is ready when Google says so, not when you do

Here's my position, clear and unmovable: I now require a green-zone PageSpeed Insights report as a binding document and an integral part of the final deliverable on every web project I oversee. It's not technical purism. It's basic professional respect for the client's budget.

A visually stunning website that nobody finds on Google isn't a digital work of art. It's the equivalent of a lavishly dressed shopfront, put together with premium materials and lit to perfection, positioned at the end of a dark, deserted alley. You might have designed it with every ounce of talent you possess, you might have sweated over every micro-interaction — but if nobody walks past it, all that work will never generate a single client or a penny of turnover.

Next time you're about to deliver a web project, before you raise the final invoice: open pagespeed.web.dev, enter the URL, wait thirty seconds. If the mobile score is below 70, the job's not done.

Two months after that morning at the Gran Caffè Garibaldi in Piazza Bovio, my phone buzzed. It was a message from Berto. No accompanying text — just a screenshot from his smartphone: the first page of Google for "furniture Caserta", with his company at the top of the organic results. Three structural interventions after that conversation: a complete overhaul of all images to WebP, self-hosted fonts, and declared dimensions on every graphic block. The site hadn't changed by a single pixel visually — the same sofas, the same photographs. But LCP had dropped from 5.8 to 2.1 seconds, CLS from 0.47 to 0.08, and Google's panel had turned green. The search engine had found him, measured him, and rewarded him.

Bobby, meanwhile, has stopped treating the whole thing as a problem to sort out with the Hackney studio. He's passed it to me. We're working on the optimisation together — the first working session with the developer is already booked for next week. At least now he knows exactly which pixel needs changing, and why.

📦 Summary box: the 3 values to know off by heart