Site Speed and Core Web Vitals: Building Fast Without Sacrificing Design
You do not have to choose between a fast site and a good-looking one. Most performance problems come not from ambitious design but from a handful of recurring implementation mistakes. This article covers them and their fixes.
A common assumption in performance discussions is that a fast site requires compromising on design. In practice this is not the case. In most of the slow sites we have reviewed, the problem was not ambitious design but a handful of recurring implementation mistakes — and those can be fixed without lowering visual quality.
This article looks first at what the metrics mean, then at which decisions damage performance, and finally at how to speed things up while keeping the design intact.
What the metrics tell you
Core Web Vitals consist of three metrics designed to describe the experience real users have, rather than laboratory conditions.
Largest contentful paint
Measures when the largest visible element — usually a hero image or main heading — appears. It is the closest proxy for the feeling that "the page has loaded". The target is under 2.5 seconds.
The main causes of poor scores: oversized hero images, late-loading fonts, render-blocking stylesheets and slow server responses.
Cumulative layout shift
Measures how much content moves while the page loads. Text jumping down as you begin reading, or a button shifting just as you tap it, indicates a poor score. The target is under 0.1.
Almost all layout shift comes from four sources: images without declared dimensions, fonts loading late, dynamically inserted ad or announcement slots, and notification bars pushing content down.
Interaction to next paint
Measures how long it takes for a visual response to appear after the user interacts. The target is under 200 milliseconds. JavaScript that occupies the main thread for long stretches is the primary enemy here.
Design decisions that hurt performance
Unoptimized images
The most common problem and the easiest to solve. A photo uploaded straight from a camera can be four to six megabytes; the same image converted to a modern format and generated at display size drops to 80–150 kilobytes with no visible loss of quality.
- Convert to WebP or AVIF
- Generate separate sizes for different screen widths and let the browser choose
- Lazy-load anything below the fold, but never the first-screen image
- Give every image explicit width and height attributes
Font loading strategy
Custom typefaces are part of a brand's visual identity and do not need to be given up. How they load, however, matters. Keeping text invisible until the font downloads lowers perceived speed and causes layout shift.
The fix is to show text immediately in a fallback font and swap when the custom font arrives. Matching the fallback's metrics to the real font removes almost all of the resulting shift. Using variable fonts also removes the need to download separate files for each weight.
Third-party scripts
Chat widgets, heatmaps, analytics, ad tags, embedded social content — each looks small alone but together they often form the heaviest part of the page. Worse, their performance is outside your control.
A workable rule: for every third-party script ask "what do I lose without this?" Load whatever survives after the page has rendered, or when the user interacts. Loading the chat widget when the user starts scrolling rather than in the first second noticeably improves perceived speed.
Animation and motion
Motion, when well designed, guides the user and makes an interface easier to read. The problem is not the presence of animation but how it is implemented.
Animations driven only by transform and opacity do not trigger layout recalculation and stay smooth. Animating width, height, position or shadow forces recalculation on every frame and causes stutter on lower-powered devices.
Animations should be disabled for users who prefer reduced motion. That is an accessibility requirement rather than a performance one — but it helps performance too.
Frameworks heavier than the job requires
Setting up a full application framework for a five-page brochure site means shipping tens of kilobytes of JavaScript that serve no purpose. Technology should match the real need; content-driven corporate sites are usually far faster with server-rendered pages and small, targeted scripts.
Getting faster while keeping the design
- Inline critical CSS: ship the styles needed for the first screen with the page and load the rest afterwards.
- Declare resources early: preload the hero image and primary font so the browser does not have to discover them.
- Enable server caching: caching the output of database-driven pages substantially cuts server response time.
- Use a content delivery network: serve static files from servers geographically close to the visitor.
- Remove unused code: strip theme and plugin styles and scripts the site never uses.
- Generate responsive images: prepare a size for each breakpoint.
- Defer scripts: delay all JavaScript not required to paint the page.
Do not optimize without measuring
The most common mistake in performance work is improving on assumption. Measure the current state first, identify the element causing the largest delay, and start there. On most sites the bulk of the total gain comes from the first two or three changes.
Alongside lab tests, watch real user data. A result taken on a fast machine over a good connection does not reflect the experience of a visitor on mobile data.
Performance is a design decision
Speed is not a checklist applied at the end of development; it is the sum of decisions made from the first draft. How many typefaces are used, whether the hero carries video or an image, how many third-party tools are connected — all of these are design decisions, and all of them determine performance.
If you would like us to assess your current site's performance, we can produce measurement results and a prioritised list showing how much each change would gain.
Frequently asked questions
What do Core Web Vitals actually measure?
Three things. Largest contentful paint shows how quickly the page feels loaded, cumulative layout shift shows how much content moves while loading, and interaction to next paint shows how fast the page responds to a tap or click. Together they describe the experience real users perceive.
Do animations and motion slow a site down?
Not when implemented correctly. The issue is not animation itself but which property is animated. Animations driven by transform and opacity run on the GPU and stay smooth; animating width, height or position forces layout recalculation and drops frames. Animations should also be disabled for users who prefer reduced motion.
How should I optimize images?
Three steps are enough: convert to a modern format, generate them at the size they will actually be displayed, and lazy-load anything off screen. Showing a 3000-pixel photo in a 600-pixel slot means the browser downloads and processes data for nothing. Giving every image width and height attributes also prevents layout shift.
When should performance work happen?
Starting at the design stage is by far the most effective. Improvements made after launch tend to stay superficial; there is a limit to what can be gained on a site built on a heavy theme with many third-party scripts. That said, image optimization, caching and script management usually make a visible difference even on existing sites.
Last updated: 9 Apr 2026
