Core Web Vitals

Core Web Vitals are three metrics Google uses to measure real-world frontend performance. They run in the browser of every visitor and feed back to both Google Search Console and Google's ranking signals. A storefront that fails Core Web Vitals loses search visibility and shopper trust. ## The three metrics Largest Contentful Paint (LCP). How long until the biggest visible thing on the page finishes loading. The hero image, the product image, the main headline. Google's green threshold is 2.5 seconds or faster. Anything slower starts to feel sluggish. Interaction to Next Paint (INP). How fast the page responds to user input. Click a button, the page should react within 200 milliseconds. Slower than that, shoppers think the click failed and tap again, doubling the action. Cumulative Layout Shift (CLS). How much the page jumps around as it loads. Image arrives late and pushes the buy button down right as the shopper taps. CLS measures the total visual instability. Below 0.1 is green. ## Why they matter Core Web Vitals are not vanity metrics. The same scores drive Google's ranking algorithm, the same scores correlate with conversion in published Google studies, and the same scores appear in any honest performance audit. A storefront stuck in the red is leaking revenue at the top of the funnel and losing search visibility at the same time. ## The common causes of failure Most performance problems in ecommerce come from the same handful of causes. Unoptimised hero images. Render-blocking JavaScript. Late-loading webfonts that swap and shift the layout. Third-party tags injecting late and pushing main content down. Server-side rendering done badly so the browser has to wait for hydration before showing anything. ## How Frntkey targets green by default Frntkey targets the green threshold on all three Core Web Vitals out of the box. The structural choices that make that possible: Server-side rendering on Nuxt. The browser receives a fully rendered HTML page on first request. LCP runs against real content, not a loading skeleton. Automatic image optimisation. Storyblok images served via the Storyblok CDN with width, format, and quality applied per device. The hero image on a mobile shopper does not load the desktop-resolution file. Lazy loading below the fold. Anything that is not in the initial viewport defers loading until it scrolls into view. The browser spends its initial budget on the first screen. Structured tag loading via GTM. Marketing tags fire after the page is interactive, not during initial render. Cookiebot consent runs before tags fire. Vercel CDN with cache invalidation. Edge nodes serve static assets close to the shopper. Cache invalidates only on Storyblok content publish, not on every request. The result is not a guarantee. Core Web Vitals depend on the device, the network, and the specific page content as much as on the underlying frontend. A merchant who uploads a 12MB hero image will still see degraded LCP, no matter how well the frontend renders. The structural baseline matters. The operational discipline matters too.