Core Web Vitals: How to Get a 95+ Lighthouse Score

A Lighthouse score of 95+ isn't just a vanity metric — it directly correlates with better search rankings, lower bounce rates, and higher conversion rates. Google has confirmed that Core Web Vitals are a ranking factor, and real-world data consistently shows that faster sites convert better. For every 100ms reduction in load time, conversion rates can improve by up to 8%.

This guide breaks down exactly how to achieve and maintain a 95+ Lighthouse score across all four categories: Performance, Accessibility, Best Practices, and SEO. It covers the specific techniques we use for every website we build at DMC Kreatif — sites serving European business audiences in France, the UK, Belgium, the Netherlands, and Germany.

Understanding the Lighthouse Score

Lighthouse evaluates your site on four dimensions, each scored 0–100:

• Performance (weight: ~60% of overall): How fast your page loads and becomes interactive. Measured via Core Web Vitals: LCP, INP, and CLS
• Accessibility: Whether all users, including those with disabilities, can use your site effectively. WCAG 2.1 AA compliance is the standard
• Best Practices: Security headers, modern APIs, HTTPS, and coding standards that protect users
• SEO: Whether search engines can properly crawl, understand, and rank your content

The Performance score is the hardest to optimize and has the most impact on user experience and rankings. It is also the score where most sites fail — a typical business WordPress site scores 40–65, while a well-built React site consistently scores 92–100.

Why European Businesses Should Care About Lighthouse Scores

Before diving into technical optimizations, it's worth understanding why these scores matter specifically for European market businesses.

European internet users have some of the highest expectations for digital experiences globally. Research from Deloitte shows that 70% of European consumers say website experience influences their purchasing decisions. In France, the UK, and Germany — three of our primary markets — mobile internet usage has surpassed desktop, meaning your Lighthouse mobile score is what most of your visitors experience.

Additionally, Google's search algorithm updates in 2023 and 2024 gave increasing weight to Core Web Vitals as ranking signals. For businesses competing for local or industry-specific search terms across European markets, a 30-point Lighthouse performance improvement can meaningfully shift your position in search results — and the difference between page 1 and page 2 is not marginal. Pages on position 1 get approximately 10x more clicks than pages on position 2.

Largest Contentful Paint (LCP) — Target: Under 2.0 Seconds

LCP measures when the largest visible element finishes loading. It's typically your hero image, a large text block, or a video poster frame. Here's how to optimize it:

Identify Your LCP Element

First, identify your LCP element using Chrome DevTools (Performance tab > Timings > LCP). Common LCP elements and their optimal handling:

• Hero image: Convert to WebP or AVIF format (30–50% smaller than JPEG), serve the correct size using srcset, and preload it with <link rel="preload" as="image" href="hero.webp">. Set fetchpriority="high" and loading="eager" on the image element
• Large text heading: Ensure your web font loads quickly. Use font-display: swap, preload the font file, and self-host fonts to eliminate Google Fonts DNS lookup latency
• Video poster frame: Use a static JPEG poster image and lazy-load the video player itself — never autoplay a video as your LCP element

Reduce Server Response Time (TTFB)

Your Time to First Byte should be under 200ms. Achieve this by:

• Using a CDN with European edge locations: Vercel serves content from edge nodes in Frankfurt, Amsterdam, Paris, and London — reducing latency for your European audience to 20–50ms instead of 150–300ms from a US server
• Implementing static generation (SSG): Pre-build pages at deploy time so the server serves static HTML — no database queries or server-side processing per request. This is the single biggest TTFB improvement for most business sites
• Enabling Brotli compression: Brotli reduces transfer sizes by 15–25% compared to gzip. Both Vercel and Netlify enable it automatically
• HTTP/2 or HTTP/3: Enable multiplexing to load multiple resources in parallel. All modern CDN platforms support this by default

Eliminate Render-Blocking Resources

• Critical CSS: Inline the CSS needed for above-the-fold content (typically under 14KB), defer the rest with a link preload trick
• Async/defer scripts: Add defer to non-critical scripts, async for independent scripts like analytics
• Remove unused CSS: Tailwind CSS's built-in tree-shaking eliminates unused styles automatically — production CSS is typically 8–15KB. For other frameworks, use PurgeCSS
• Code splitting: Load only the JavaScript needed for the current route. React with React.lazy() and Vite's automatic chunk splitting make this the default behavior

LCP Optimization Checklist

• Hero image is WebP or AVIF, correctly sized for each breakpoint
• Hero image has fetchpriority="high" and loading="eager"
• Hero image is preloaded in document head
• Fonts are self-hosted and preloaded
• No render-blocking scripts in document head
• TTFB under 200ms (test from a European location)
• Static generation or ISR used instead of server-side rendering per request

Cumulative Layout Shift (CLS) — Target: Under 0.05

CLS measures visual stability — how much the page layout shifts while loading. Nothing frustrates users more than clicking a button that moves just as they tap it. For European e-commerce sites in particular, unexpected layout shifts can cause accidental purchases, wrong option selections, or failed form submissions.

Image and Media Dimensions

The single biggest CLS fix: always set explicit width and height on images and videos. This allows the browser to reserve the correct space before the media loads.

• Use the width and height HTML attributes — the browser calculates aspect ratio automatically and reserves the right amount of space
• Alternatively, use CSS aspect-ratio property on image containers
• For responsive images, the aspect ratio is maintained regardless of the rendered size — no reserved space issue
• Set explicit dimensions on iframes (Google Maps embeds, YouTube videos, Calendly widgets) using the aspect-ratio approach

Font Loading Strategy

Web fonts are a major CLS culprit. When a custom font loads and replaces the fallback font, text reflows and shifts the layout — sometimes dramatically. Fix this with a multi-pronged approach:

• Use font-display: swap to show fallback font immediately, then swap to custom font when loaded
• Preload critical fonts: <link rel="preload" as="font" type="font/woff2" href="font.woff2" crossorigin> tells the browser to fetch the font at the highest priority
• Use font metric overrides: CSS properties like size-adjust, ascent-override, and descent-override match the fallback font's visual metrics to your web font, minimizing reflow when the font swaps
• Self-host fonts: Eliminates the DNS lookup and connection to Google Fonts servers (saves 100–300ms), and gives you full control over caching headers
• Limit font weights: Load only the weights you actually use. Loading Regular, Medium, SemiBold, Bold, and ExtraBold when you only use Regular and Bold doubles your font payload unnecessarily

Dynamic Content

• Never insert content above existing content after the page has loaded — cookie banners, notification bars, and chat widgets that pop in from the top cause significant CLS
• Reserve space for ads, embeds, and iframes using min-height or aspect-ratio before they load
• Use CSS contain property on components that change size to limit the impact of their changes on surrounding layout
• Animate with transform/opacity only — properties that trigger layout (width, height, top, left, margin) cause layout recalculation and can increase CLS
• Position cookie banners at the bottom of the viewport — they still comply with GDPR requirements but cause zero CLS because they don't push existing content

Interaction to Next Paint (INP) — Target: Under 150ms

INP replaced First Input Delay (FID) in March 2024 and measures the responsiveness of all interactions during a visit, not just the first one. It tracks the worst-case delay between any user interaction and the visual response. For sites with complex UI — filtering, sorting, multi-step forms, interactive calculators — INP is often the hardest Core Web Vital to optimize.

Reduce JavaScript Execution Time

• Break long tasks: Any JavaScript task that takes longer than 50ms blocks the main thread and delays interaction responses. Break long synchronous operations into smaller chunks using requestIdleCallback, setTimeout(fn, 0), or the Scheduler API
• Use React concurrent features: useTransition marks state updates as non-urgent so React can interrupt them for more important updates. useDeferredValue defers expensive re-renders until the browser is idle
• Virtualize long lists: Rendering 500 DOM elements is expensive. Use windowing libraries (react-virtual, react-window) for lists longer than 50 items — render only what's visible in the viewport
• Debounce and throttle expensive operations: Search inputs should debounce API calls (300–500ms delay). Scroll and resize handlers should throttle (execute at most every 100ms)
• Move heavy computation off the main thread: Web Workers run JavaScript in a background thread, leaving the main thread free for user interactions. Suitable for data processing, PDF generation, and image manipulation

Minimize Third-Party Impact

Third-party scripts are the biggest INP killers for typical business sites. A chat widget, social sharing buttons, and marketing analytics can collectively block the main thread for 500ms+ during page load:

• Audit all third-party scripts: Use Chrome DevTools Coverage tab to identify unused code, and the Performance tab to see which third-party scripts cause long tasks
• Lazy-load non-essential widgets: Chat widgets, social feeds, and video embeds should load on user interaction (click to open chat) or after first user interaction with the page
• Use facade patterns: Show a static image of a YouTube video; load the actual player only when clicked. This is one of the highest-impact INP improvements for marketing sites
• Self-host analytics: Reduces DNS lookups and gives you more control over loading timing. Plausible Analytics is a GDPR-compliant, privacy-focused alternative to Google Analytics that loads faster and requires no cookie consent banner
• Defer Google Tag Manager: GTM loaded during page initialization can block the main thread significantly. Load it after the first user interaction if possible

Image Optimization — The Biggest Performance Win

Images typically account for 50–70% of a page's total weight. Optimizing them is the highest-impact, lowest-complexity change you can make to improve performance:

Format Selection by Use Case

• AVIF: Best compression (50% smaller than JPEG at equivalent quality), growing browser support (Chrome, Firefox, Safari 16+). Use as the primary format with JPEG fallback
• WebP: Excellent compression (30% smaller than JPEG), universal browser support since 2022. Safe default if AVIF isn't available
• JPEG: Fallback for older browsers; use progressive JPEG encoding for perceived performance improvement
• SVG: For logos, icons, and illustrations — infinitely scalable, tiny file size, can be animated with CSS. Always prefer SVG for non-photographic graphics
• PNG: Only when you need pixel-perfect transparency and SVG isn't suitable — PNG files are significantly larger than WebP for equivalent quality

Responsive Images Implementation

Serving a 1920px-wide hero image to a 375px-wide mobile phone wastes 80% of the data and slows LCP unnecessarily. Implement responsive images properly:

• Generate multiple sizes: 400w, 800w, 1200w, 1600w, 2000w
• Use srcset and sizes attributes to let the browser choose the optimal size
• Use the <picture> element to serve AVIF to browsers that support it, WebP to those that don't, JPEG as the final fallback
• Lazy-load all images below the fold with loading="lazy" — browser-native lazy loading works well and requires no JavaScript
• Eagerly load the LCP image with loading="eager" and fetchpriority="high"

Build-Time Image Optimization

Manual image optimization is error-prone and time-consuming. Automate it:

• Vite: Use vite-plugin-imagemin or @svelte-kit/adapter-static's built-in image handling for automatic optimization at build time
• Next.js: The built-in next/image component handles format conversion, responsive sizes, and lazy loading automatically
• Cloudinary or Imgix: CDN-based image optimization services that serve the optimal format and size based on the requesting browser — useful for CMS-managed images

JavaScript Bundle Optimization

Keep your initial JavaScript bundle under 150KB gzipped. Here's how:

• Route-based code splitting: Each page loads only its own JavaScript. With React and Vite, this is automatic with React.lazy() — pages not in the initial bundle reduce Time to Interactive significantly
• Tree shaking: Import only what you need. Instead of import _ from 'lodash' (70KB), use import { debounce } from 'lodash-es' or a purpose-built utility that ships only the function you need
• Analyze your bundle: Use rollup-plugin-visualizer to generate an interactive treemap of your bundle. Most teams are surprised by what ends up in their bundle — multiple date libraries, polyfills for browsers you don't support, and accidental inclusion of server-side code
• Replace heavy libraries with lightweight alternatives: date-fns (12KB) instead of moment.js (67KB), Lucide React (tree-shakeable) instead of FontAwesome (entire icon set), native fetch instead of axios (13KB)
• Dynamic imports for heavy features: Load chart libraries, WYSIWYG editors, PDF generators, and map components only when the user actually needs them — not on initial page load

CSS Optimization

• Utility-first CSS with Tailwind: Tailwind CSS generates only the classes you actually use in your source code. A typical production Tailwind stylesheet is 8–15KB gzipped, compared to 50–200KB for Bootstrap or Material UI
• Remove unused CSS: If not using Tailwind, audit CSS coverage in Chrome DevTools (Coverage tab while loading the page) and run PurgeCSS to eliminate unused selectors
• Minimize CSS specificity: Flat, low-specificity selectors (Tailwind's utility classes are all single-class) apply faster and cause fewer cascade conflicts than deeply nested or ID-based selectors
• Use CSS containment: contain: layout style paint tells the browser that a component's layout and paint changes don't affect anything outside it — this enables significant rendering optimizations
• Critical CSS inlining: Extract the CSS needed for above-the-fold content (typically 3–8KB) and inline it in the HTML head. The rest loads asynchronously without blocking render

Caching Strategy

Proper caching means returning visitors load your site almost instantly — and CDN caching means first-time visitors in Europe get content served from nearby edge nodes:

• Static assets (JS, CSS, images): Cache for 1 year (max-age=31536000, immutable) with content-hash filenames. When the file changes, the hash changes, busting the cache automatically without coordination
• HTML: Short cache (60 seconds to 5 minutes) or stale-while-revalidate — serve cached HTML immediately while fetching a fresh version in the background
• API responses: Cache where appropriate based on data freshness requirements. Use ETags for conditional requests — the server returns 304 Not Modified if content hasn't changed
• Service Worker: For progressive web apps, implement offline-first caching strategies so the site works on poor mobile connections — common in rural European areas

Accessibility Score — Target: 95+

Accessibility isn't just a Lighthouse metric — it's a legal requirement in many European jurisdictions under the European Accessibility Act (EAA), which came into force in June 2025. Non-compliant websites face legal risk. The good news: accessible sites also perform better on SEO because many accessibility best practices align with search engine requirements.

• Color contrast: 4.5:1 ratio for normal text, 3:1 for large text (WCAG AA). Use contrast checkers during design, not after. The dark backgrounds common in premium European business sites often fail contrast tests with gray text
• Alt text: Every content image needs descriptive alt text that conveys the meaning of the image. Decorative images should use alt="" to be ignored by screen readers
• Keyboard navigation: All interactive elements must be reachable and operable via keyboard — Tab to navigate, Enter/Space to activate, Escape to close modals
• ARIA labels: Use semantic HTML first (buttons, links, headings, lists). Add ARIA only when HTML semantics are insufficient. Common correct uses: aria-label on icon-only buttons, aria-expanded on accordions, role="alert" on form error messages
• Focus indicators: Visible, high-contrast focus outlines on all interactive elements. The default browser outline is often removed with outline: none for aesthetic reasons — always provide a custom focus style instead of removing it entirely
• Form labels: Every input must have an associated label (via for/id pairing or aria-label). Placeholder text is not a substitute for a label
• Heading hierarchy: Logical H1 > H2 > H3 order with no skipped levels. The page should have exactly one H1. This helps both screen readers and search engines understand content structure
• Skip navigation link: A hidden link that becomes visible on focus, allowing keyboard users to skip directly to main content without tabbing through the entire navigation

Best Practices and SEO Scores

The Best Practices and SEO scores are generally easier to achieve once Performance and Accessibility are handled. Key items for each:

Best Practices

• HTTPS on all pages (mandatory in 2026 — no exceptions)
• Security headers: Content-Security-Policy, X-Frame-Options, X-Content-Type-Options
• No console errors in production
• No deprecated APIs or browser features
• Image display ratios match actual dimensions (no stretched or squashed images)
• JavaScript libraries with known vulnerabilities updated promptly

SEO Score

• Unique, descriptive title tags (50–60 characters) on every page
• Meta descriptions (150–160 characters) with natural keyword inclusion
• Descriptive, keyword-rich alt text on images
• Crawlable links (real anchor tags, not JavaScript onclick handlers)
• Valid robots.txt that doesn't accidentally block important pages
• Hreflang tags correctly implemented for multilingual European sites
• Structured data (JSON-LD) validated and error-free

Measuring and Monitoring Lighthouse Scores

A 95+ score today doesn't guarantee 95+ next month. Third-party scripts get added, images get uploaded without optimization, and new features get built without performance testing. Set up continuous monitoring:

1. Lighthouse CI: Run Lighthouse on every deployment using GitHub Actions or a CI/CD pipeline. Configure it to fail the build if any score drops below 90. This prevents regressions from reaching production
2. Core Web Vitals in Search Console: Monitor real user data (field data) from Chrome users visiting your site. This is the data Google actually uses for rankings — it differs from lab data because it reflects real devices, real networks, and real user behavior patterns
3. Performance budgets: Set limits on bundle size (150KB initial JavaScript), image weight per page (500KB total), and number of third-party requests (5 maximum). Include these budgets in your development guidelines
4. Monthly manual audits: Run PageSpeed Insights from a European IP address monthly. Verify both mobile and desktop scores. Document the results and investigate any drops above 3 points
5. Real User Monitoring (RUM): Tools like Vercel Analytics or Plausible capture Core Web Vitals from actual user sessions. This reveals performance on real devices and connection speeds that lab tests miss — particularly important for mobile users in rural France, Germany, or Eastern Europe

At DMC Kreatif, every site we build targets 95+ Lighthouse scores across all categories — and we monitor them continuously with automated CI checks on every deployment. If you want a website that's fast by design, not by afterthought, let's talk about your project. We'll show you exactly what's achievable with modern web technology built specifically for European business audiences.