A Slow Website Is a Design Failure. Not an Engineering One.
A product manager files a bug: "Homepage load time is 6 seconds on mobile." It goes into the engineering backlog. An engineer picks it up, audits the network waterfall, discovers the hero image is 4.2MB, the custom font is loading six weights with zero subsetting, and there's an autoplay video above the fold.
The engineer optimizes the images, lazy-loads the fonts, removes the autoplay. Load time drops to 2.1 seconds. The PM closes the ticket and thanks the engineering team for "fixing the performance issue."
Except: none of the decisions that caused the issue were engineering decisions. The 4.2MB hero image was specified in a Figma mockup. The six font weights were a brand requirement from a design document. The autoplay video was a product decision made at a design review. An engineer implemented them accurately. Accurately is not the same as correctly.
What Core Web Vitals Are Actually Measuring
Google's Core Web Vitals — the three metrics that became a ranking signal in 2021 and are still the primary framework for measuring real-user web performance — measure three things: how fast the largest visible element loads (LCP, Largest Contentful Paint), how responsive the page is to user interaction (INP, Interaction to Next Paint), and how much the layout shifts during load (CLS, Cumulative Layout Shift).
The 2025 Web Almanac, which analyzes HTTP Archive data across millions of websites, found that approximately 32% of sites pass all three Core Web Vitals on mobile. That means 68% of websites are failing the performance standard that search engines use to evaluate user experience quality.
These are not engineering failures in the main. They are design failures that engineering inherited.
LCP Is Almost Always a Design Decision
Largest Contentful Paint measures when the biggest element visible in the viewport has fully loaded. On more than 60% of sites, that element is a hero image or a video. On every one of those sites, a designer chose to put a large visual element in the most prominent position on the page.
The 4.2MB hero image isn't a compression failure — it's an original-resolution photograph exported from a design tool and handed to a developer who implemented it as specified. A designer who understood LCP would have sized the image appropriately, would have specified srcset for responsive delivery, would have flagged that a full-bleed video autoplay in the hero creates an unacceptable LCP hit. A designer who treated performance as an engineering problem handed over a file and moved on.
Vercel's website loads in under 1.5 seconds on mobile. That's not an engineering accident. Their design system has explicit constraints on hero section weight and explicit guidance on image optimization that originates in the design process. The engineer implementing a Vercel-spec component can't produce a slow page without actively working against the spec.
INP Connects Directly to Component Design Choices
Interaction to Next Paint replaced First Input Delay as a Core Web Vital in March 2024 because FID was gameable — you could pass FID by ensuring the first tap was fast while letting every subsequent interaction be slow. INP measures the full distribution of interaction latency across a page visit.
The most common INP killers are third-party scripts and complex DOM structures that force the browser to do expensive layout recalculations on every interaction. Both of these originate in design decisions:
Third-party scripts — ad platforms, analytics, chat widgets, social embeds — are product decisions that get treated as givens by engineering. A designer who advocates for their exclusion, or who specifies a facades approach where a lightweight placeholder loads instead of the full script until interaction, is making a performance decision. Most don't, because the performance consequences are someone else's column.
Complex DOM structures come from design systems that specify deeply nested component architectures without any performance budget attached. A card component that nests 7 divs for a purely aesthetic separation of concerns multiplied across 60 items in a feed is a slow feed. The engineer who built it built what the design specified.
CLS Is a Layout Specification Problem
Cumulative Layout Shift measures visual instability — the jarring experience of content jumping around as the page loads. The most common cause is images and video without declared dimensions, fonts that load after text has already been rendered in a fallback font, and dynamic content (ads, banners, notifications) that inserts itself into the DOM without reserving space.
These are specification problems. A design spec that includes explicit image dimensions, that uses size-adjusted font metrics to reduce flash of unstyled text, that reserves fixed space for ad slots — that spec produces low CLS. A design spec that treats layout as static and leaves rendering behavior to "the frontend team" produces CLS at scale.
The Organizational Misalignment
The reason this misalignment persists is that performance feedback reaches engineers, not designers. Bug reports, load time dashboards, Core Web Vitals scores — these land in engineering workflows. The designer who specified the 4.2MB hero never learns that it caused a 6-second load time. The design review for the next project starts from the same unconstrained baseline.
In agencies and larger product orgs, designers often don't have access to production performance data. They work in Figma, which renders at desktop resolution with local fonts, and nothing about that environment surfaces the consequences of their decisions on real devices over real networks. The feedback loop that would teach them doesn't reach them.
The fix isn't to make designers into performance engineers. It's to integrate performance into the design process at the point where consequential decisions are made.
What a Performance-First Design Process Looks Like
Performance budgets in the design brief: Before design begins, establish maximum acceptable LCP, target INP for interactive components, and allowed weight for page assets. These function identically to spacing constraints or color palette rules. They're not engineering requirements — they're design constraints.
Core Web Vitals as design criteria in critique: In design review, LCP analysis should be as routine as reviewing accessibility or visual hierarchy. "Where is the LCP element? How heavy is it? What loads before it?" These are design questions that don't require engineering expertise to ask.
Type and font specifications with performance notes: Specifying a typeface should include subsetting guidance and weight limits. The Monotype 2024 font loading performance study found that loading four or more font weights adds an average of 0.8 seconds to LCP on mobile networks. That's a design consequence worth knowing before specifying brand fonts.
Performance-aware asset libraries in design systems: Design tokens and component libraries can include performance guidance: maximum hero image weight, lazy-loading defaults for images below the fold, preferred patterns for embedding third-party content. Linear's design system, for example, is documented with explicit guidance on rendering behavior — not just visual properties.
Access to production data for designers: Dashboard access to Core Web Vitals for the products you design creates the feedback loop that makes learning possible. A designer who can see that their hero section redesign correlated with a 1.2-second LCP improvement understands performance in terms of their decisions, not in terms of engineering abstractions.
Google's own research shows that a 100ms reduction in page load time correlates with an 8% lift in conversion rate. That's a design impact, paid for by design decisions. The measurement exists. The accountability is pointed the wrong way.
Related: Progressive Disclosure Is Gone. Engagement Metrics Killed It. covers the broader pattern of how product teams optimize for the wrong metrics until the user experience collapses.
Photo by Sanket Mishra via Pexels