Performance and Core Web Vitals

A one-second delay in page load reduces conversions by 7% — performance is not a technical nice-to-have, it is a conversion lever.

Why This Matters

💻 Dev: You own the performance budget. Every unoptimized image, render-blocking script, and layout shift is a conversion leak that only you can fix. Core Web Vitals are also a Google ranking factor — poor performance means less organic traffic.
📋 PM: Performance directly impacts your conversion rate, bounce rate, and ad spend efficiency. A slow page burns paid traffic budget. You need to set performance targets and hold the team accountable.
🎨 Designer: That hero video, custom font stack, and parallax animation all have a performance cost. Understanding the budget helps you make design choices that look great AND load fast.

The Concept (Simple)

Imagine visiting a restaurant.

LCP (Largest Contentful Paint) is how long it takes to get seated and see a menu. If you stand at the door for two minutes waiting, you might leave. On a landing page, LCP measures how quickly the main content appears. Target: under 2.5 seconds.

INP (Interaction to Next Paint) is how responsive the waiter is. You ask for water and they acknowledge you instantly versus staring blankly for five seconds. INP measures how fast the page responds when a visitor clicks a button or fills out a form. Target: under 200 milliseconds.

CLS (Cumulative Layout Shift) is the waiter bumping your table while you eat. You reach for your glass and it has moved. On a page, CLS happens when elements jump around as the page loads — a button shifts down just as you try to click it. Target: under 0.1.

If any of these experiences are bad, the visitor leaves before dessert — before they convert.

How It Works (Detailed)

The Three Core Web Vitals

╔══════════════════════════════════════════════════════════════════╗
║                      CORE WEB VITALS                            ║
╠════════════════════╦═════════════════╦═══════════════════════════╣
║        LCP         ║      INP        ║          CLS              ║
║  Largest Content.  ║  Interaction to ║   Cumulative Layout       ║
║  Paint             ║  Next Paint     ║   Shift                   ║
╠════════════════════╬═════════════════╬═══════════════════════════╣
║  Good:   < 2.5s    ║  Good:  < 200ms ║  Good:   < 0.1            ║
║  Needs:  2.5–4.0s  ║  Needs: 200–500 ║  Needs:  0.1–0.25         ║
║  Poor:   > 4.0s    ║  Poor:  > 500ms ║  Poor:   > 0.25           ║
╠════════════════════╬═════════════════╬═══════════════════════════╣
║  "Can I see the    ║  "Does it       ║  "Does stuff stop         ║
║   content?"        ║   respond?"     ║   jumping around?"        ║
╚════════════════════╩═════════════════╩═══════════════════════════╝

Page Load Waterfall

This is what happens when a visitor loads your landing page:

Time ──────────────────────────────────────────────────────▶

│  DNS Lookup     │
│  ████           │
│                 │
│  TCP Connect    │
│     ████        │
│                 │
│  TLS Handshake  │
│        ████     │
│                 │
│  HTML Download  │
│           ███   │
│                 │
│  Parse HTML ─────────────────────────────────────────│
│              ██                                      │
│                 │                                    │
│  CSS Download   │  ◀── Render-blocking!              │
│              ██████                                  │
│                 │                                    │
│  JS Download    │  ◀── Can be deferred               │
│              ████████████                            │
│                 │                                    │
│  Font Download  │  ◀── Can cause CLS                 │
│                ████████                              │
│                 │                                    │
│  Hero Image     │  ◀── Usually the LCP element       │
│                ██████████████                        │
│                 │           │                        │
│                 │           ▼                        │
│                 │      ┌─────────┐                   │
│                 │      │   LCP   │                   │
│                 │      │  EVENT  │                   │
│                 │      └─────────┘                   │
│                 │                                    │
│  JS Execute     │  ◀── Affects INP                   │
│                    ████████████████████              │
│                                                      │
└──────────────────────────────────────────────────────┘

LCP: Making Content Appear Fast

The LCP element is usually your hero image, hero heading, or background video. Common causes of poor LCP:

Problem	Fix
Large unoptimized hero image	Use WebP/AVIF, serve correct size via srcset
Render-blocking CSS	Inline critical CSS, defer the rest
Render-blocking JavaScript	Use defer or async attributes
Slow server response (TTFB)	Use CDN, edge caching, static generation
Web fonts blocking render	Use font-display: swap, preload key fonts
Too many redirects	Eliminate redirect chains

INP: Making Interactions Responsive

INP replaced FID (First Input Delay) as a Core Web Vital. It measures the worst interaction responsiveness across the entire page visit. Common fixes:

Break up long JavaScript tasks into smaller chunks using requestIdleCallback or setTimeout
Avoid layout thrashing — batch DOM reads and writes
Debounce scroll and resize handlers to reduce event frequency
Use CSS for animations instead of JavaScript — CSS animations run on the compositor thread
Lazy-load non-critical JavaScript with dynamic imports

CLS: Stopping the Page from Jumping

  WHAT CAUSES LAYOUT SHIFT:

  ┌──────────────────────┐       ┌──────────────────────┐
  │   [  Hero Image  ]   │       │   ████████████████   │
  │   (no dimensions)    │       │   (with dimensions)  │
  │                      │       │                      │
  │   Loading...         │       │                      │
  │                      │  ──▶  │                      │
  │   ▼ Content shifts   │       │   Content stays put  │
  │     down when image  │       │                      │
  │     loads            │       │   [  CTA Button  ]   │
  │                      │       │                      │
  │   [  CTA Button  ]   │       │                      │
  └──────────────────────┘       └──────────────────────┘
       ✗ BAD CLS                      ✓ GOOD CLS

Key fixes for CLS:

Always set explicit width and height on images (or use aspect-ratio in CSS)
Reserve space for ads, embeds, and dynamic content
Use font-display: optional or font-display: swap with size-adjusted fallback fonts
Avoid inserting content above existing content after page load
Use CSS contain to isolate layout changes

Optimization Techniques Summary

╔══════════════════════════════════════════════════════════════════╗
║                   OPTIMIZATION CHECKLIST                        ║
╠════════════════════════════╦═════════════════════════════════════╣
║  IMAGES                    ║  FONTS                             ║
║  ☐ Convert to WebP/AVIF   ║  ☐ font-display: swap              ║
║  ☐ Use srcset for sizes   ║  ☐ Preload critical fonts          ║
║  ☐ Lazy load below fold   ║  ☐ Subset to needed characters     ║
║  ☐ Set width and height   ║  ☐ Limit to 2 font families        ║
║  ☐ Use CDN for delivery   ║  ☐ Use size-adjust for fallbacks   ║
╠════════════════════════════╬═════════════════════════════════════╣
║  SCRIPTS                   ║  CSS                               ║
║  ☐ defer non-critical JS   ║  ☐ Inline critical CSS             ║
║  ☐ Code-split by route    ║  ☐ Defer non-critical CSS           ║
║  ☐ Remove unused code     ║  ☐ Purge unused styles              ║
║  ☐ Compress with gzip/br  ║  ☐ Use CSS containment             ║
║  ☐ Use dynamic imports    ║  ☐ Minimize reflows                 ║
╠════════════════════════════╬═════════════════════════════════════╣
║  INFRASTRUCTURE            ║  MONITORING                        ║
║  ☐ CDN for static assets  ║  ☐ Lighthouse CI in pipeline        ║
║  ☐ Edge caching / SSG     ║  ☐ Real User Monitoring (RUM)       ║
║  ☐ HTTP/2 or HTTP/3       ║  ☐ Web Vitals JS library            ║
║  ☐ Brotli compression     ║  ☐ Performance budget alerts        ║
║  ☐ Preconnect to origins  ║  ☐ CrUX dashboard review            ║
╚════════════════════════════╩═════════════════════════════════════╝

Performance Budget

Set a budget and enforce it. Here is a starting point for a high-converting landing page:

Resource Type	Budget	Why
Total page weight	< 500 KB	Fast on 3G connections
HTML	< 30 KB	Minimal markup, semantic structure
CSS	< 50 KB	Purge unused, inline critical
JavaScript	< 100 KB	Defer everything non-essential
Images	< 300 KB	Optimize formats, lazy load
Fonts	< 50 KB	Subset, limit families
Third-party scripts	< 50 KB	Audit every tag, load async
LCP	< 2.5s	Core Web Vital target
INP	< 200ms	Core Web Vital target
CLS	< 0.1	Core Web Vital target

Lighthouse Scoring Breakdown

Lighthouse weighs these metrics to produce a performance score from 0 to 100:

Metric	Weight
First Contentful Paint (FCP)	10%
Speed Index	10%
Largest Contentful Paint	25%
Total Blocking Time	30%
Cumulative Layout Shift	25%

A score of 90+ is considered good. For landing pages, aim for 95+ on mobile.

In Practice

Shopify: Optimizing for Mobile in Emerging Markets

Shopify recognized that many of their merchants' customers browse on low-end Android devices over 3G connections. Their landing page optimization work focused on:

Aggressive image optimization — serving AVIF to supporting browsers, WebP as fallback, with srcset delivering appropriately-sized images for each device
Eliminating render-blocking resources — inlining critical CSS and deferring all JavaScript
Edge-side rendering — using their CDN to serve pre-rendered pages from locations close to visitors
Reducing third-party impact — auditing every analytics and tracking script, removing those that did not justify their performance cost

The result: a 40% improvement in LCP on mobile devices, which correlated with a measurable increase in merchant sign-up conversion rates.

Notion: LCP Through Image Optimization

Notion's landing pages feature rich illustrations and screenshots. Their team tackled LCP by:

Preloading the hero image using <link rel="preload" as="image">
Serving illustrations as optimized SVGs instead of PNGs where possible
Using blur-up placeholder techniques for screenshots — a tiny base64-encoded placeholder appears instantly, replaced by the full image once loaded
Implementing responsive images with srcset so mobile visitors download smaller files

The lesson: Your LCP element is almost always an image. Identify it (Chrome DevTools highlights it), then apply every optimization: right format, right size, preloaded, and served from a CDN.

Key Takeaways

Core Web Vitals (LCP, INP, CLS) directly affect both conversions and Google search rankings
LCP is your most impactful metric — optimize your hero image and eliminate render-blocking resources
CLS is the easiest to fix — set dimensions on images and reserve space for dynamic content
INP matters most for pages with interactive elements like forms, calculators, or configurators
Set a performance budget (under 500 KB total page weight) and enforce it in your CI pipeline
Test on real devices over throttled connections, not just your fast laptop on WiFi
Use Lighthouse CI to catch regressions before they reach production

Action Items

┌──────────┬──────────────────────────────────────────────────────┐
│ 💻 Dev   │ ☐ Run Lighthouse on your current landing page and   │
│          │   record baseline scores for all Core Web Vitals    │
│          │ ☐ Identify your LCP element and optimize it —       │
│          │   right format, preloaded, served from CDN          │
│          │ ☐ Add the web-vitals JS library to capture Real     │
│          │   User Monitoring data in production                │
│          │ ☐ Set up Lighthouse CI in your deployment pipeline  │
│          │   to block merges that exceed your performance      │
│          │   budget                                            │
├──────────┼──────────────────────────────────────────────────────┤
│ 📋 PM    │ ☐ Define performance targets: LCP < 2.5s,          │
│          │   INP < 200ms, CLS < 0.1 as acceptance criteria     │
│          │ ☐ Review your Google Search Console Core Web Vitals │
│          │   report for current field data                     │
│          │ ☐ Audit third-party scripts — does each one justify │
│          │   its performance cost with measurable value?       │
│          │ ☐ Add performance review to your landing page       │
│          │   launch checklist                                  │
├──────────┼──────────────────────────────────────────────────────┤
│ 🎨 Design│ ☐ Understand the performance cost of your design    │
│          │   choices — hero videos, custom fonts, animations   │
│          │ ☐ Design with a 500 KB page weight budget in mind   │
│          │   — ask "is this asset worth its bytes?"            │
│          │ ☐ Provide fallback designs for slow connections —   │
│          │   what does the page look like before images load?  │
│          │ ☐ Limit font families to two and provide specific   │
│          │   weights needed (do not load the entire family)    │
└──────────┴──────────────────────────────────────────────────────┘

Next: Chapter 15: SEO and Structured Data

Performance and Core Web Vitals ​

Why This Matters ​

The Concept (Simple) ​

How It Works (Detailed) ​

The Three Core Web Vitals ​

Page Load Waterfall ​

LCP: Making Content Appear Fast ​

INP: Making Interactions Responsive ​

CLS: Stopping the Page from Jumping ​

Optimization Techniques Summary ​

Performance Budget ​

Lighthouse Scoring Breakdown ​

In Practice ​

Shopify: Optimizing for Mobile in Emerging Markets ​

Notion: LCP Through Image Optimization ​

Key Takeaways ​

Action Items ​