The three numbers that matter
Google ranks sites partly on Core Web Vitals: three measurements of how your site feels to real visitors. Not how fast your server responds, not your Lighthouse score in isolation—how actual humans experience your pages on phones with flaky connections.
Your targets:
- LCP under 2.5 seconds: Largest Contentful Paint. The biggest image or text block should appear within 2.5 seconds of someone clicking your link. Not the whole page—just the main thing they came to see.
- INP under 200 milliseconds: Interaction to Next Paint. When someone taps a button, the screen should respond in under 200ms. Delays over 500ms feel broken.
- CLS under 0.1: Cumulative Layout Shift. Elements shouldn't jump around while the page loads. A CLS of 0.25 means you've shifted the viewport by a quarter of its height—infuriating on mobile.
These aren't suggestions. Google uses them for search ranking. Sites that fail all three see measurably worse visibility. Sites that pass all three get a ranking boost, especially on mobile queries.
Why these three metrics exist
Before Core Web Vitals, everyone optimized for Time to First Byte or DOMContentLoaded—server-centric metrics that didn't correlate with user experience. A page could score green on TTFB but feel sluggish because a 4MB hero image took nine seconds to render, or because a late-loading script locked the main thread.
LCP measures perceived load speed: when does the page look ready? INP measures responsiveness: does the site react when I touch it? CLS measures visual stability: does stuff stop moving so I can read or tap accurately?
Google chose these because they predict bounce rate. Pages with LCP over 4 seconds lose half their mobile visitors before the content appears. Pages with CLS over 0.25 generate accidental clicks on ads and navigation, making people angry. INP over 500ms makes sites feel laggy compared to native apps.
The 75th percentile rule
Google measures Core Web Vitals at the 75th percentile of real-world traffic. That means 75% of your visitors must experience LCP under 2.5s for your site to pass. If your median visitor sees 2.1s but your 75th percentile visitor sees 3.8s—maybe because they're on 3G or using a budget Android—you fail.
This percentile approach punishes sites that only test on fast office WiFi. Your iPhone 15 on gigabit fiber doesn't represent the person on a train in rural France with spotty 4G. Design for the 75th percentile, not the median.
How to measure your site in five minutes
Open Chrome. Visit PageSpeed Insights at pagespeed.web.dev. Paste your homepage URL. Click Analyze.
PageSpeed Insights runs two tests: a lab test (Lighthouse) on Google's servers, and a field test using 28 days of real Chrome user data. The field data matters more—it shows what actual visitors experienced. The lab data shows what's possible under perfect conditions.
Look at the Core Web Vitals assessment at the top. Green means pass, orange means needs improvement, red means fail. If you see "No data" for field metrics, you don't have enough Chrome users yet—rely on the lab test until you do.
Reading the diagnostics
Scroll past the scores to the diagnostics section. PageSpeed Insights lists opportunities (things to fix that directly improve metrics) and diagnostics (explanations of why you're slow). Opportunities show estimated time savings. Prioritize anything saving more than 0.5 seconds.
Common red flags: "Reduce unused JavaScript" (you're loading libraries you don't use), "Properly size images" (your 4000px photo is displaying at 400px), "Eliminate render-blocking resources" (CSS or JavaScript blocking the page from painting). These three account for most slow sites.
The five causes of slow sites
1. Gigantic unoptimized images
A 3.2MB JPEG hero image wrecks LCP. You photograph your product with a DSLR at 6000×4000 resolution, upload it directly, and display it at 1200×800. The browser downloads 15 times more data than needed.
Fix: resize images to their display dimensions before uploading. Convert to WebP (60% smaller than JPEG at the same quality). Use srcset for responsive images so mobile users don't download desktop-sized files. Marcus does this automatically—every image you upload gets resized to four breakpoints and converted to WebP.
2. Render-blocking CSS and JavaScript
Your page can't paint until it downloads and parses all CSS in the <head>. If you're loading a 200KB framework CSS file to style a landing page, LCP waits for that entire file even though you only use 8KB of those styles.
Fix: inline critical CSS (the styles needed for above-the-fold content) directly in the HTML. Load the rest asynchronously. Marcus automatically extracts and inlines critical CSS for every page, then lazy-loads the full stylesheet.
Same for JavaScript. A 400KB React bundle in the <head> blocks rendering. Move scripts to the bottom with defer or async attributes, or eliminate them if they're not essential for first paint.
3. Late-loading web fonts
You load a custom font from Google Fonts. The browser discovers it late (after parsing CSS), downloads it, then re-renders all text. This causes a flash of invisible text (FOIT) or a flash of unstyled text (FOUT), both wrecking CLS as text reflows when the font swaps in.
Fix: preload font files with <link rel="preload" as="font">. Use font-display: swap to show fallback fonts immediately instead of hiding text. Subset fonts to include only the glyphs you need (Latin instead of Latin+Cyrillic+Greek). Marcus preloads all fonts and uses swap by default.
4. Missing dimensions on images and embeds
You insert an image without width and height attributes. The browser allocates zero space, paints the page, then the image loads and pushes everything down. Instant CLS failure.
Fix: always specify width and height on <img> tags, even if you override them with CSS. Modern browsers use these to reserve space before the image downloads. Same for iframe embeds (YouTube videos, maps). Marcus enforces dimensions on all media elements.
5. Too many third-party scripts
Every analytics pixel, chatbot widget, and social media embed adds JavaScript that fights for main-thread time. Load ten third-party scripts and you're executing 2MB of someone else's code before your own site becomes interactive. This kills INP—the main thread is busy running ad trackers instead of responding to clicks.
Fix: audit what you've installed. Remove anything you don't check weekly. Load non-essential scripts with async or defer them until after page load. Replace heavy widgets (live chat, social feeds) with lighter alternatives or on-demand loading. Marcus limits third-party scripts to explicitly approved integrations and loads them after interaction.
Quick wins that work on any platform
You can improve Core Web Vitals without rebuilding your site. Start here:
- Enable compression: Turn on gzip or Brotli compression on your server. This makes text assets (HTML, CSS, JavaScript) 70% smaller in transit. Every host supports this—find the setting in your control panel.
- Set cache headers: Tell browsers to cache static assets (images, CSS, JavaScript) for at least 30 days. One-line server config change, massive reduction in repeat-visitor load time.
- Use a CDN: A content delivery network serves your assets from servers near your visitors instead of routing everyone through your single origin server. Cloudflare's free tier works for most small sites. Cuts LCP by 40% for international visitors.
- Lazy-load below-the-fold images: Add
loading="lazy"to images that don't appear in the first viewport. The browser won't download them until the user scrolls near. Saves bandwidth, improves LCP for above-the-fold content. - Reduce redirects: Every redirect adds a full round-trip to your load time. www to non-www, HTTP to HTTPS—these stack up. Minimize chains, use canonical URLs in your links.
These five changes require no coding and no visual redesign. On a typical WordPress or Shopify site, they improve LCP by 1-2 seconds.
Hosting performance matters more than you think
A site on shared hosting with 600ms server response time will never pass Core Web Vitals, no matter how optimized your images are. LCP starts counting when the user clicks the link—if the server takes 800ms to send the first byte of HTML, you've already burned a third of your 2.5-second budget.
Target server response time (TTFB) under 200ms. Anything over 500ms indicates a hosting problem: overloaded server, slow database queries, or too many plugins executing on every page load.
Marcus sites run on edge infrastructure with response times under 100ms globally. Your pages are pre-rendered and served from 200+ locations worldwide. No cold starts, no database queries blocking initial paint. This architectural choice—static generation with dynamic personalization at the edge—is why Marcus sites consistently score 95+ on PageSpeed Insights without optimization effort.
Mobile vs. desktop performance
Test on mobile separately. PageSpeed Insights shows separate scores for mobile and desktop—your desktop score might be green while mobile fails.
Mobile networks have higher latency (40-200ms per round trip vs. 10-30ms on broadband). Mobile processors are slower. Mobile screens make CLS more noticeable because users tap more precisely. A site optimized only for desktop WiFi testing will disappoint 60% of traffic.
PageSpeed Insights simulates a mid-tier mobile phone on a 4G connection with 400ms round-trip time and 1.6 Mbps throughput. If you pass mobile, you'll pass desktop. Don't assume the reverse.
When speed matters enough to obsess over
Not every site needs a perfect 100 Lighthouse score. An internal company intranet used by five people on office WiFi? LCP of 3 seconds is fine. A landing page for paid ads where you're spending €5000/month? Every 100ms of LCP improvement increases conversion by 1-2%.
E-commerce sites see direct revenue impact from Core Web Vitals. A study of large retail sites found that improving LCP from 4.2s to 2.1s increased completed checkouts by 8%. Reducing CLS from 0.3 to 0.05 reduced cart abandonment by 4%. These changes translate to six-figure revenue differences at scale.
Content sites see ranking and traffic impact. Google's algorithm weighs page experience more heavily for commercial queries ("buy protein powder") than informational queries ("what is protein"). If you monetize via ads or affiliate links, passing Core Web Vitals is table stakes for top-10 rankings.
Portfolio and branding sites benefit from perceived quality. A designer's portfolio that loads in 1.2 seconds signals competence. One that takes 5 seconds raises doubts. Speed is part of your first impression.
How Marcus handles performance by default
Marcus sites pass Core Web Vitals out of the box because the architecture prevents the common mistakes. Images auto-optimize to WebP at multiple sizes. CSS and JavaScript bundle and minify automatically. Pages pre-render to static HTML and serve from edge nodes. No database queries, no server-side processing on page load.
You can't accidentally upload a 5MB image—Marcus resizes and compresses on upload. You can't block rendering with third-party scripts—they load after interaction. You can't forget width and height on images—the builder enforces it.
This isn't magic. It's eliminating the thousand small choices where people unknowingly wreck performance. You focus on content and design; Marcus enforces performance constraints that keep Core Web Vitals in the green.
Typical Marcus sites: LCP 1.1-1.8s, INP 80-150ms, CLS 0.02-0.06. PageSpeed Insights scores 92-98 mobile, 98-100 desktop. No performance tuning required on your part. That's €29/month on the Builder plan, €290/month for Studio if you need custom domains and team collaboration.