You run Lighthouse and it tells you your Speed Index is bad.

But the page looks like it loads fine. You see stuff on screen early. So why is Lighthouse acting like your site is a sloth?

Speed Index is a “how fast does this page visually fill in” metric. Not “when did the first pixel show up” (that’s FCP) and not “when did the main content show up” (That’s LCP). It’s the whole above-the-fold loading experience, averaged over time.

What Lighthouse Is Telling You

Lighthouse defines Speed Index like this:

Speed Index measures how quickly content is visually displayed during page load.

Under the hood, Lighthouse literally records a video of your page loading, compares frames to see how quickly the viewport becomes “visually complete,” and then computes a score from that visual progression. If you want the canonical explanation straight from Google, here’s the Lighthouse Speed Index audit docs.

That’s why it can feel weird. Speed Index is not watching your DOM or your network waterfall. It’s watching what a user would see.

Speed Index Thresholds

Lighthouse reports Speed Index in seconds, and it has different “good” ranges for mobile and desktop.

Why It Matters

Speed Index is trying to capture a thing your users actually care about: does the page feel like it’s showing up progressively, or does it sit blank and then pop in all at once?

It rewards pages that paint meaningful chunks quickly and steadily, and it punishes pages that “download the world first” before rendering much. (Hello, giant JS bundles and render-blocking CSS.)

Also, Speed Index is a lab metric. Lighthouse runs in a simulated environment, so treat it as a clue, not gospel. If you want to know what real humans are seeing, you need real user monitoring, not just hope-driven Lighthouse runs.

And yes, if you’re chasing “the page feels loaded,” you probably also care about Largest Contentful Paint and whether your layout is doing a chaotic little dance, aka Cumulative Layout Shift.

How to Fix It

If Speed Index is slow, the theme is almost always the same: the browser is stuck doing work before it can paint progressively.

Focus on the stuff that helps the page render earlier and more continuously:

• Kill render-blocking CSS. Inline the critical CSS for above-the-fold, and defer the rest so you can paint sooner.
• Stop shipping a dump truck of JavaScript up front. Code split, defer, and trim third-party scripts so the main thread can actually render.
• Prioritize above-the-fold images and text. If your hero is important, make it load like it’s important.
• Make fonts not sabotage first render. If text is invisible while fonts load, your page looks empty even if everything else is ready.
• Fix backend latency first. If your server is slow to respond, every visual metric is going to look bad.

Common Mistakes

• Optimizing only for LCP and ignoring everything else above the fold. Speed Index cares about the whole viewport filling in, not just the biggest element.
• Skeleton screens that never match the final layout. If your “loading UI” is visually busy and then swaps, Speed Index can still look bad because the final page takes forever to settle.
• A/B tests and tag managers injecting late changes. You think the page is “rendered,” but Lighthouse sees the viewport still changing frame after frame.
• Treating Speed Index like a Core Web Vital. It’s useful, but it’s not what Google puts on the scoreboard.

Keep Improving

Lighthouse is great at yelling at you in a controlled lab. Real users are where the money is.

Run Lighthouse to find obvious problems, then validate with real-user data:

Use Real User Monitoring to see what your visitors experience across devices, networks, and real pages, then keep an eye on the Core Web Vitals, especially LCP, CLS, and INP, because those are the metrics Google actually cares about. And if you want the easy button, Request Metrics gives you the real timeline from real sessions so you can stop guessing and start fixing.

You’re reading an old performance article, and it keeps talking about “First Meaningful Paint.” You search for how to improve it, but every tool gives you different advice. Some don’t mention it at all. What’s going on?

Here’s the short answer: First Meaningful Paint is dead. Google deprecated it in Lighthouse 6.0 back in 2020 and removed it completely in Lighthouse 13. If you’re still trying to optimize for FMP, you’re chasing a ghost.

What Lighthouse Used to Tell You

The old FMP audit message said:

First Meaningful Paint measures when the primary content of a page is visible.

FMP tried to answer a simple question: when does the page look “done enough” that users can start reading or interacting? It watched for the moment when the biggest visual change happened above the fold, assuming that’s when the “meaningful” content appeared.

In theory, this was brilliant. In practice, it was a mess.

Why Google Killed FMP

First Meaningful Paint had three fatal flaws that made it unreliable for real-world performance measurement.

1. Wildly Inconsistent Results

FMP was “bimodal,” meaning you’d run the same test twice and get completely different numbers. A page might score 1.2 seconds on one run and 2.8 seconds on the next. This inconsistency made it nearly impossible to know if your optimizations were actually working or if you just got lucky.

The metric was overly sensitive to tiny changes in page load order. Shift one CSS file around, and your FMP could jump by a full second. That’s not useful data, that’s noise.

2. Tied to Chrome’s Internals

FMP relied on specific rendering events inside Blink, Chrome’s rendering engine. These events were implementation details that other browsers couldn’t replicate. Firefox and Safari had no way to report FMP because the underlying mechanism simply didn’t exist outside of Chromium.

A metric that only works in one browser family can’t become a web standard. And Google wanted metrics that the entire web could use, not just Chrome users.

3. “Meaningful” Is Subjective

What counts as “meaningful” varies wildly between websites. For a news site, it’s the headline. For an e-commerce site, it’s the product image. For a dashboard, it might be a chart or data table. FMP’s algorithm tried to guess what mattered on your page, and it often guessed wrong.

The metric would sometimes identify a loading spinner or navigation bar as the “meaningful” content, completely missing the actual content users cared about.

What Replaced FMP

Google replaced First Meaningful Paint with Largest Contentful Paint (LCP), which became one of the three official Core Web Vitals.

LCP takes a simpler, more reliable approach: instead of guessing what’s “meaningful,” it measures when the largest visible element renders. This is usually your hero image, main headline, or featured content block.

Why LCP is better:

LCP isn’t perfect. Sometimes the “largest” element isn’t the most important one. But it’s consistent, measurable, and actually tells you something actionable about your page performance.

What You Should Do Now

If you’re still seeing FMP mentioned anywhere, here’s how to handle it:

Update Your Monitoring Tools

Any performance monitoring that still reports FMP is running outdated software. Modern tools like Request Metrics, PageSpeed Insights, and current Lighthouse versions all use LCP instead. If your tooling still shows FMP, it’s time to upgrade.

Ignore Old Articles

Performance articles from before 2020 will mention FMP prominently. The optimization advice in those articles is often still valid (faster servers, smaller images, fewer blocking resources), but the metric they’re targeting no longer exists. Focus on LCP instead.

Focus on the Right Metrics

1. First Contentful Paint (FCP): When the user sees anything render. This tells them their request was received.

2. Largest Contentful Paint (LCP): When the main content is visible. This is the replacement for FMP.

3. Time to First Byte (TTFB): How long until your server responds. This affects everything else.

These three metrics together give you a complete picture of loading performance. FCP shows the first response, LCP shows when content is ready, and TTFB tells you if your server is the bottleneck.

Check Your LCP Score

If you were worried about FMP, you should be checking LCP instead. Run your site through PageSpeed Insights or use Chrome DevTools Lighthouse panel to see your current LCP score.

Good LCP thresholds:

If your LCP is slow, check out our guide on Understanding Lighthouse: Largest Contentful Paint for specific fixes.

The Lesson Here

Web performance metrics evolve. What Google recommended five years ago might be deprecated today. FMP seemed like a great idea until real-world data showed it was too unreliable to be useful.

This is why Real User Monitoring matters more than chasing specific metric scores. The metrics will change. The goal stays the same: make your site feel fast for actual users.

LCP will probably get refined or replaced eventually too. The important thing is understanding why these metrics exist (to approximate user experience) rather than obsessing over the specific measurement. A site that loads quickly for real users will score well on whatever metric Google invents next.

Keep Improving

Stop chasing FMP. It’s gone, and it’s not coming back.

Instead, focus on the metrics that actually influence your search rankings and user experience today:

1. Set up monitoring with Request Metrics to track your Core Web Vitals (LCP, CLS, INP) for real users.

2. Run Lighthouse audits regularly to catch performance regressions before they affect users.

3. Check Search Console to see how Google rates your Core Web Vitals based on real Chrome user data.

The web moves fast. Your performance strategy should too.

Your hero image takes 5 seconds to show up. Your headline sits invisible while JavaScript churns away. Your users? They’ve already hit the back button. That’s the cost of a slow Largest Contentful Paint, and it’s killing your conversions and search rankings.

LCP is one of Google’s Core Web Vitals, which means it directly impacts how Google ranks your website. A slow LCP doesn’t just frustrate users, it actively hurts your SEO. Let’s figure out what Lighthouse is telling you and how to fix it.

What Lighthouse Is Telling You

When Lighthouse flags your Largest Contentful Paint, you’ll see something like this:

Largest Contentful Paint marks the time at which the largest text or image is painted.

LCP measures how long it takes for the biggest visible element on your page to render. This is usually your hero image, main headline, or featured video poster. The browser watches as elements paint to the screen and tracks whichever one takes up the most pixels in the viewport.

Lighthouse breaks LCP into four phases that add up to your total score:

1. Time to First Byte (TTFB): How long until your server responds
2. Load Delay: Time between TTFB and when the browser discovers the LCP resource
3. Load Duration: How long it takes to actually download the LCP element
4. Render Delay: Time between download completing and the element appearing on screen

Each phase is an opportunity to improve. If your TTFB is 2 seconds before anything else even starts, no amount of image optimization will save you.

Lighthouse Scoring Thresholds:

These thresholds matter because Google uses them for ranking decisions. LCP accounts for 25% of your overall Lighthouse Performance score.

Why It Matters

Back in the early web days, we measured page performance with a simple “load” event. When the browser finished downloading everything, the page was “done.” Simple.

But modern websites don’t work that way. JavaScript frameworks render content after the initial HTML loads. Images lazy-load as you scroll. Third-party widgets inject themselves whenever they feel like it. The “load” event became meaningless because pages could feel completely usable long before it fired, or painfully slow long after.

Google created LCP to answer a better question: when does the user think the page is ready? Research showed that users perceive a page as “loaded” when they can see the main content, which is almost always the largest visible element. That hero image. That headline. That product photo.

This metric directly correlates with user behavior:

• 53% of mobile users abandon sites that take over 3 seconds to load (Google research)
• A 1 second delay in page response can reduce conversions by 7% (Aberdeen Group)
• Google factors LCP into search rankings as part of the Page Experience update

For a deeper technical dive into how LCP is measured through browser APIs, check out our guide on Measuring Largest Contentful Paint.

How to Fix It

Improving LCP means attacking those four phases: server response, resource discovery, download time, and render delay. Here’s where to focus.

1. Speed Up Your Server Response (TTFB)

Your LCP can’t be faster than your Time to First Byte. If your server takes 2 seconds to respond, your LCP is at least 2 seconds.

# Check your TTFB in the Network panel
# Or use curl to measure server response time
curl -w "TTFB: %{time_starttransfer}s\n" -o /dev/null -s https://yoursite.com

Common fixes:

• Cache your HTML with tools like Varnish, Cloudflare, or your framework’s built-in caching
• Use a CDN to serve content from servers closer to your users
• Optimize database queries if your pages are dynamically generated
• Upgrade your hosting if you’re on shared hosting with limited resources

2. Make Sure the Browser Finds Your LCP Element Early

The browser can’t load what it doesn’t know about. If your LCP image is buried in JavaScript or loaded by a CSS background, the browser discovers it late.

For images, use a preload hint to tell the browser about important resources immediately:

<head>
  <!-- Tell the browser to start loading the hero image right away -->
  <link rel="preload" as="image" href="/images/hero.webp">
</head>

If your LCP element is text, make sure fonts are loading efficiently. Use font-display: swap so text renders immediately with a fallback font while custom fonts load:

@font-face {
  font-family: 'MyHeadlineFont';
  src: url('/fonts/headline.woff2') format('woff2');
  font-display: swap;
}

3. Shrink Your LCP Resource

Smaller files download faster. For images, this means:

• Use modern formats: WebP is typically 25-35% smaller than JPEG. AVIF is even smaller where supported.
• Serve the right size: Don’t send a 2000px image to a 400px container
• Compress appropriately: Quality 80-85 is usually indistinguishable from 100

<picture>
  <source srcset="/images/hero.avif" type="image/avif">
  <source srcset="/images/hero.webp" type="image/webp">
  <img src="/images/hero.jpg" alt="Hero image" width="1200" height="600">
</picture>

For text-based LCP elements, ensure your HTML and CSS are minified and compressed with gzip or brotli.

4. Remove Render-Blocking Resources

JavaScript and CSS in your <head> can block the browser from painting anything until they’re fully loaded and parsed.

<!-- BAD: This blocks rendering -->
<script src="/js/analytics.js"></script>

<!-- GOOD: This loads without blocking -->
<script src="/js/analytics.js" defer></script>

Critical CSS that’s needed for above-the-fold content should be inlined. Everything else can load asynchronously:

<head>
  <!-- Critical CSS inline -->
  <style>
    .hero { /* styles for LCP element */ }
  </style>

  <!-- Non-critical CSS loads async -->
  <link rel="preload" href="/css/full.css" as="style" onload="this.onload=null;this.rel='stylesheet'">
</head>

Common Mistakes

Lazy-loading the LCP image. Lazy loading is great for images below the fold. It’s terrible for your hero image. The browser waits for JavaScript to execute before even starting to load the image, adding hundreds of milliseconds to your LCP.

Using CSS background images for hero content. Background images aren’t discoverable until the CSS is parsed. Use an <img> tag with proper preloading instead.

Forgetting about mobile. Your LCP element might be different on mobile versus desktop. A desktop hero image might be below the fold on mobile, making your headline the LCP element instead. Test both.

Ignoring third-party scripts. That chat widget, analytics bundle, or A/B testing tool might be blocking your main content from rendering. Audit your third-party scripts and defer anything that isn’t essential for initial render.

Over-optimizing Lighthouse at the expense of real users. Remember, Lighthouse has limitations. A perfect Lighthouse score means nothing if your real users on slow networks still experience a 5-second LCP. Use Real User Monitoring to see what’s actually happening in production.

Keep Improving

Lighthouse gives you a snapshot, but your LCP changes based on network conditions, server load, and what content appears on each page. Here’s how to stay on top of it:

1. Set up Real User Monitoring to track LCP for actual visitors. Request Metrics shows you LCP broken down by page, device, and connection type.

2. Check your Core Web Vitals in Search Console. Google reports how your pages perform for real Chrome users through the Chrome User Experience Report.

3. Test after every deploy. Lighthouse scores can regress when you add new features. Include performance testing in your CI/CD pipeline.

4. Identify your actual LCP element. It might not be what you expect. Use Chrome DevTools Performance panel to see exactly which element triggers LCP on each page.

LCP is the single most impactful Core Web Vital for perceived performance. When users see your main content quickly, they trust that your site works. When they don’t, they leave. It’s that simple.

You ran Lighthouse and got flagged for a slow First Contentful Paint. The score is orange (or worse, red), and the help text says something about “the time at which the first text or image is painted.”

But what does that actually mean for your users? And why should you care?

What Lighthouse Is Telling You

First Contentful Paint (FCP) measures the time from when a user starts navigating to your page until the browser renders the first piece of actual content. That content could be text, an image, an SVG, or even a non-white canvas element.

Lighthouse is checking: “How long did users stare at a blank screen before seeing something?”

Google considers FCP scores under 1.8 seconds good. Anything between 1.8 and 3.0 seconds needs improvement. Over 3.0 seconds is poor, and your users are probably already reaching for the back button.

Good:         0 - 1.8 seconds
Needs Work:   1.8 - 3.0 seconds
Poor:         > 3.0 seconds

Why It Matters

FCP is about trust. When users click a link or type your URL, they need confirmation that something is happening. A blank screen feels broken. A fast FCP tells users: “I got your request, content is coming.”

This matters for three reasons:

User perception. Studies show users perceive sites as “fast” when they see content within 1-2 seconds, even if the page isn’t fully loaded yet. FCP is that first reassurance.

Bounce rates. Every extra second of blank screen increases the chance users will bail. They don’t know if your server is slow, their connection dropped, or your site is just dead.

SEO rankings. Google includes FCP in its Core Web Vitals assessment. Poor FCP scores can hurt your search rankings, especially on mobile where Google prioritizes page experience signals.

The good news? Everything you do to improve FCP also helps your Largest Contentful Paint (LCP) score. Two birds, one optimization.

How to Fix It

FCP includes all the time spent waiting for your server to respond, downloading HTML and CSS, and processing render-blocking resources. To speed it up, you need to attack each of these.

Speed up your server. Your server needs to respond fast. If you’re running WordPress, use a caching plugin. If you’re making database calls for every request, cache those results. The goal is to get bytes flowing back to the browser as quickly as possible.

Reduce render-blocking resources. The browser can’t paint anything until it has downloaded and parsed your CSS. Inline your critical CSS, defer non-essential stylesheets, and eliminate any synchronous JavaScript in the <head> that isn’t absolutely necessary.

Use compression. Enable gzip or brotli compression on your server. Smaller files download faster. This is table stakes in 2025.

Leverage a CDN. Serve your content from servers physically closer to your users. A CDN can shave hundreds of milliseconds off FCP by reducing network round-trip time.

Optimize your fonts. Web fonts are sneaky FCP killers. Use font-display: swap so text renders immediately with a fallback font while your custom font loads. Better yet, use fewer fonts.

For a complete breakdown of optimization tactics, check out our FCP Cheat Sheet.

Common Mistakes

Ignoring Time to First Byte (TTFB). FCP can’t be faster than your server response time. If your TTFB is 2 seconds, your FCP will be at least 2 seconds. Fix the server first.

Loading too much CSS. Every kilobyte of CSS delays FCP. That 500KB framework you imported for a few utility classes? It’s costing you. Audit your CSS and remove what you don’t need.

Chaining CSS imports. Using @import statements inside CSS files creates a waterfall of requests. The browser can’t start downloading the imported stylesheet until it finishes downloading the first one. Avoid @import and link stylesheets directly in your HTML.

Forgetting about mobile. Lighthouse simulates slower connections and devices. Your FCP might be great on your developer machine and terrible for real users on 3G. Test with throttling enabled.

Focusing only on Lighthouse. Here’s the thing: Lighthouse runs a synthetic test with simulated conditions. Your real users might have completely different experiences. A good Lighthouse score doesn’t guarantee good real-world performance. Learn more about Lighthouse’s limitations.

Keep Improving

FCP is one piece of the performance puzzle. Once you’ve optimized it, you’ll want to look at LCP (when the main content loads), CLS (how much the page jumps around), and INP (how responsive it is to interaction).

For a deeper dive into what FCP measures and how to track it with code, read our guide on Using First Contentful Paint.

The best way to know if your optimizations actually help real users is to set up Real User Monitoring. Lighthouse tells you what might be slow. RUM tells you what is slow for your actual audience.

You ran Lighthouse and got a passing audit for “Has a <meta name="viewport"> tag with width or initial-scale.” Great. But do you know what happens when it’s missing?

Your users wait an extra 300 milliseconds on every single tap. On mobile, that’s an eternity.

What Lighthouse Is Telling You

Lighthouse checks if your page has a viewport meta tag in the <head>. Specifically, it looks for something like this:

<meta name="viewport" content="width=device-width, initial-scale=1">

If it’s missing (or malformed), Lighthouse flags it.

Why It Matters

Back in the early smartphone days, mobile browsers had a problem. Websites were designed for desktop screens, and phones had tiny screens. So browsers pretended to be desktop-sized and let users pinch-zoom around.

To figure out if a page was “mobile-friendly,” browsers would wait 300ms after a tap to see if it was actually a double-tap (for zooming). This made every interaction feel sluggish.

The viewport meta tag tells the browser: “Hey, I’m mobile-ready. No need to wait.” That 300ms delay disappears.

Beyond the tap delay, the viewport tag also:

• Ensures your CSS media queries work correctly
• Prevents weird zoom behavior on form inputs
• Helps your page render at the right size on first load

Google considers mobile-friendliness a ranking factor. No viewport tag means your page looks broken on mobile, and that’s bad for SEO.

How to Fix It

Add this line inside your <head> tag:

<meta name="viewport" content="width=device-width, initial-scale=1">

That’s it. If you’re using a modern framework or CMS, this is probably already there. But check anyway. I’ve seen plenty of sites where someone accidentally deleted it during a template refactor.

If you need to prevent users from zooming (like for a kiosk or game), you can add user-scalable=no, but think twice before doing that. Accessibility advocates will rightfully yell at you.

Common Mistakes

Forgetting to include it at all. Especially common when building from scratch or migrating templates.

Putting it in the <body> instead of the <head>. The browser needs to see it before rendering starts.

Using width=1024 or some fixed value. This defeats the purpose. Use device-width so it adapts to whatever screen the user has.

Keep Improving

The viewport meta tag is one of those “table stakes” items. If you’re missing it, fix it now. But there’s a lot more to mobile performance than this one tag.

Check out our guide on fixing First Contentful Paint for more ways to speed up your site, or set up Real User Monitoring to see how your mobile users are actually experiencing your site.

Most web servers treat URLs as case-insensitive. A request to /About-Us lands on the same page as /about-us or /ABOUT-US. So when Request Metrics captures your traffic, we normalize all URLs to lowercase to prevent these duplicates from cluttering your reports.

But not every system works that way.

Some web frameworks (looking at you, Node and Python) treat URL casing as meaningful. /User/Profile and /user/profile might be completely different routes. If you’re running one of these systems, our normalization was actually hiding important data from you.

We just shipped a fix: Preserve Casing.

You’ll find it in your Website Settings under URL Format. Check the box, and we’ll keep your URLs exactly as they came in.

One thing to note: this only affects new traffic. Changing the setting won’t retroactively update your historical data, so you won’t see old URLs suddenly split apart. Going forward though, your case-sensitive routes will be tracked separately.

If your framework treats casing as meaningful, flip the switch in your settings and let us know how it works for you.

Google Lighthouse helps you identify page performance issues and generates an overall performance “score” to make you feel good (or bad) about your site’s speed. This score can be useful, but has serious limitations.

Lighthouse is an automated tool for assessing web page quality. It generates metrics for performance, SEO, accessibility and more. Google has been promoting it as THE way to measure website quality. We’ll focus on the performance part of Lighthouse and the ways Lighthouse scores fail to tell the whole story. Try it on your site with Lighthouse in Chrome Dev Tools.

Here’s the shocking reality: Google’s own research found that 50% of websites with perfect Lighthouse scores still fail Core Web Vitals when measured with real user data. If half the sites celebrating perfect scores are actually slow for real users, maybe we need to rethink how we measure performance.

Lighthouse Is Synthetic

Lighthouse attempts to simulate the 85th percentile user experience. To do this it slows the page load by throttling network and CPU speeds. By default, this throttling is done even when using “Desktop” mode.

On my computer, the Request Metrics login takes .4 seconds to load in Chrome. Lighthouse on the same computer takes more than double that time. Lighthouse does not represent MY page experience. Does it represent the 85th percentile user’s experience? No one can tell—we must trust that Lighthouse has simulated the “common user” appropriately.

Lighthouse tries to simulate an “85th percentile user”—but their simulation is usually wrong. Your users aren’t Google’s generic average. A developer-focused B2B tool has completely different users than a consumer social app. Lighthouse can’t know the difference, so it makes assumptions that are often completely wrong for your specific audience.

Lighthouse Does Not Understand Your Web Page

Lighthouse does not know the purpose of your page. It does not know how important the page is or how it will be used. Because it does not know these things, Lighthouse must make assumptions about what constitutes “good” or “bad” performance. This can lead to scores that are not representative of a real user’s experience.

An example is Google’s own product, Gmail. Gmail is a remarkably snappy single page application (SPA). Google has spent huge amounts of time and effort to make it seamless, quick and responsive. However, Gmail takes a fair amount of time to load initially.

Lighthouse does not know any of this. Testing the Gmail inbox results in a terrible Lighthouse score even though the actual user experience is very good:

What Lighthouse Misses: Real-World Variables

Synthetic testing like Lighthouse can’t simulate the complexity of real user experiences:

• Network conditions beyond simple throttling: Packet loss, latency spikes, and network congestion that affect real users
• Device thermal throttling: How phones slow down during extended usage sessions
• Background apps competing for resources: Real users don’t browse in isolation
• Browser extensions affecting performance: Ad blockers, password managers, and other extensions that change how pages load
• User behavior patterns: Scrolling, multitasking, and multiple tabs that synthetic testing can’t replicate
• Geographic network infrastructure differences: Real network conditions vary dramatically by location
• Third-party vendor performance and outages: Services that work fine in testing but fail for real users

Lighthouse Is Not Performance Monitoring

A Lighthouse performance audit can’t tell you everything. Lighthouse is a synthetic test and must guess what your website’s average user looks like. It can’t tell you which pages are slow for your real production users or what kind of experience they’re having. It can’t tell you which pages are the most important or most trafficked by your users.

Desktop to mobile ratio varies wildly by use case. Lighthouse can’t tell you whether to focus on desktop or mobile performance. There’s not much use optimizing for mobile on a desktop-heavy app and vice-versa for mobile-focused sites.

Most critically, Lighthouse can’t tell you which performance problems actually cost you money. Maybe your homepage loads slowly but users stick around anyway. But maybe your checkout process is fast in testing but slow for real users with actual payment data. Lighthouse would never catch this difference.

Ultimately, we don’t care what score Lighthouse gives us—we care how things are going for our production users.

The Real Solution: Combine Lighthouse with Real User Monitoring

Lighthouse has value as a development tool. Use it to catch obvious performance problems before you ship code. But don’t mistake a good Lighthouse score for good real-world performance.

To understand how your site actually performs, you need Real User Monitoring that captures data from actual user sessions. RUM shows you which performance problems affect real users and which ones actually impact your business.

The complete performance strategy:

1. Use Lighthouse during development to prevent shipping obvious problems
2. Use Real User Monitoring in production to see what actually needs fixing
3. Investigate with Lighthouse when RUM identifies specific issues
4. Validate fixes with RUM to ensure improvements help real users

For a detailed comparison of synthetic vs real user approaches, read our guide on Synthetic Testing and Real User Monitoring.

For a deep dive into why Real User Monitoring reveals performance problems that synthetic testing misses, check out Why You Need Real User Monitoring to Really Understand Your Web Performance.

Conclusion

The best way to know which pages are slow is to monitor your actual users’ performance. It’s easy to do this with a website performance monitoring service like Request Metrics. Request Metrics monitors the page performance of your live production users in real time. It tells you which pages are slow for actual users.

Once you know a page is slow from real user data, Lighthouse becomes a great tool for investigating and understanding why that page has performance issues.

Great Lighthouse scores, but your site is still slow. Sound familiar?

You’ve run PageSpeed Insights, Request Metrics, and every other synthetic test you can find. Your scores look great. But your analytics shows users bouncing, conversions dropping, and complaints about “slow pages.” What’s going on?

The answer is simple: synthetic testing only tells you how your site performs in a test, not how it performs for real users in the real world. And the gap between lab performance and real-world performance is huge.

Here’s the shocking truth: Google’s own research found that nearly 50% of websites with perfect Lighthouse scores still fail Core Web Vitals when measured with real user data. Half! That means half of the developers celebrating their perfect scores are still delivering poor performance to their users.

To understand how your website really performs—you need Real User Monitoring (RUM).

What Real User Monitoring Actually Tells You (That Lighthouse Can’t)

Real User Monitoring does exactly what the name suggests: it monitors real users as they interact with your website. Instead of simulating user conditions in a test environment, RUM collects performance data from actual user sessions as they happen.

When a real person visits your site on their actual device, using their actual network connection, RUM captures their experience. Did the page load quickly? Did they experience lag when clicking buttons? How long did it take for the page to become interactive? RUM answers these questions with data from real usage, not simulated conditions.

The key difference is test conditions versus real-world chaos. Synthetic testing runs in perfect, controlled environments. Real User Monitoring captures the messy, unpredictable reality of how people actually use your website.

How Real User Monitoring Works

RUM works by adding a small piece of JavaScript to your website that runs alongside your normal page content. This JavaScript agent uses built-in browser APIs to collect performance data as users interact with your site.

When someone visits your page, the RUM script automatically measures things like:

• How long it took for the page to load
• When the page became interactive
• How long animations and interactions took to complete
• Any errors or slowdowns that occurred

The browser itself provides most of this data through APIs like the Navigation Timing API and Performance Observer. The RUM script simply collects these measurements and sends them to a reporting service where you can analyze the data.

This approach gives you performance data that reflects real network conditions, real devices, real user behavior patterns, and real-world usage scenarios—something synthetic testing simply cannot provide.

For a detailed technical comparison between synthetic and real user approaches, check out our guide on Synthetic Testing and Real User Monitoring.

Real User Monitoring vs Synthetic Monitoring: What You’re Missing

We’ve written extensively about the limitations of Lighthouse, but it’s worth highlighting the key blind spots that affect every synthetic testing tool.

Lighthouse tries to simulate an “85th percentile user”—but their simulation is usually wrong. Your users aren’t Google’s generic average. A developer-focused B2B tool has completely different users than a consumer social app. Lighthouse can’t know the difference, so it makes assumptions that are often completely wrong for your specific audience.

Consider Google’s own Gmail, which scores terribly on Lighthouse despite being one of the snappiest web applications ever built. Lighthouse doesn’t understand that Gmail’s initial load time is irrelevant because users keep it open all day and interact with a fast, responsive interface. The performance that matters happens after the initial load—something synthetic testing completely misses.

Real-world variables that synthetic tests can’t simulate:

• Network conditions beyond simple throttling (packet loss, latency spikes, congestion)
• Device thermal throttling during extended usage sessions
• Background apps competing for resources
• Browser extensions affecting performance
• User behavior patterns (scrolling, multitasking, multiple tabs)
• Geographic network infrastructure differences
• Time-of-day performance variations
• Third-party vendor performance and outages affecting your site

Speed Matters

Get your free speed check to see your website performance for real users.

Free speed test

Free speed check

Check how fast your website is for the real users that visit.

Check website

Why Chrome User Experience Report (CrUX) is Just “RUM Lite”

The Chrome User Experience Report provides real user data, which sounds great—but it’s like the lite beer of Real User Monitoring. Sure, it’s better than nothing if you have a lot of it, but it lacks the substance you need to make real decisions.

CrUX does show data from your specific website, but only for your busiest pages and only as total aggregate performance. It’s like getting a report that says “your restaurant had mixed reviews this month” without knowing which dishes, which servers, or which times of day caused problems. You know something might be off, but you can’t do anything about it.

The 28-day reporting delay means you could have performance problems for weeks before CrUX shows them. In web time, that’s an eternity. Your users could be suffering through slow experiences while you’re celebrating last month’s good CrUX scores.

CrUX data is public, which makes it excellent for benchmarking against competitors. You can see how your site’s Core Web Vitals compare to others in your industry. But that same public nature means it’s not detailed enough for making optimization decisions about your specific site. You know there might be a problem, but not where, when, or why.

CrUX gives you the 30,000-foot view. Real User Monitoring gives you the ground-level intelligence you need to actually improve your site.

Now let’s look at the specific problems that only Real User Monitoring can catch.

Real User Monitoring Benefits: Problems Only RUM Can Catch

Here are the performance issues that synthetic testing will never reveal, but Real User Monitoring catches immediately:

Dynamic Content Performance Issues

Your website probably shows different content to different users. Personalized experiences, user-generated content, different product catalogs, A/B test variations—none of this complexity appears in synthetic testing.

RUM reveals how these dynamic elements affect real performance. Maybe your personalization engine is fast for new users but slows down for power users with complex histories. Maybe your A/B test is tanking performance for the variant group. Synthetic testing would never catch these issues because it can’t simulate your actual user diversity.

The Long Tail of Performance Problems

Every website has edge cases and unusual scenarios that affect real users but would never appear in synthetic testing:

• That specific Android phone model that struggles with your animations
• Users in geographic regions with different network infrastructure
• Performance degradation during high-traffic periods
• Third-party service failures affecting real users
• Progressive performance degradation over long user sessions

These “long tail” issues might affect a small percentage of users, but they often affect your most valuable users—the ones who engage deeply with your site.

Business-Critical Performance Scenarios

RUM shows you which performance problems actually hurt your bottom line:

Are slow pages costing you sales? RUM can tell you exactly which performance issues make users bounce before buying. Maybe your product pages load fine in testing but struggle with real product catalogs and user reviews.

Is mobile really slower than desktop? You might assume mobile users are more patient, but RUM shows you the reality. Maybe your mobile checkout flow is actually faster because it’s simpler, or maybe it’s a disaster because of third-party payment widgets.

What happens during your Black Friday traffic spike? Synthetic testing can’t simulate real load on your servers, payment processors, and CDN. RUM captures what actually happens when thousands of people try to buy your stuff at once.

How do your fancy search filters perform with real data? Testing with a clean database is one thing. RUM shows you how search and filtering work when users have thousands of products, complex queries, and messy real-world data.

Real User Performance Monitoring Tools in Action: What You Actually Get

When you install RUM, you get immediate access to performance intelligence that transforms how you think about your website:

What You Actually See When You Install RUM

When you install RUM, you immediately start seeing things that will surprise you. Maybe your mobile users aren’t actually slower—they’re just using your site differently. Maybe that page you thought was fast is actually driving people away because it’s slow on the devices your users actually have.

You’ll see which performance problems cost you real money. That checkout page that loads fine in testing? RUM might show you it’s actually slow for users with older phones, and those users abandon their carts. That’s actionable data you can’t get anywhere else.

RUM Keeps Watching So You Don’t Have To

Unlike running Lighthouse once a week, RUM never stops monitoring. It’s like having someone constantly watching your site and tapping you on the shoulder when things go wrong.

You get alerts that actually matter. Not “your LCP went from 2.1 to 2.3 seconds,” but “your checkout page just got slow and people are bailing.” RUM can tell you when a code deploy made things worse, when a third-party service is dragging you down, or when traffic spikes are overwhelming your servers.

You see patterns over time. Maybe your site gets slower every Tuesday (server maintenance?). Maybe performance tanks during lunch hours when your team deploys. Maybe that new feature you shipped last month has been slowly degrading performance. RUM catches this stuff.

What You See When RUM Finds Problems

When Request Metrics RUM spots a problem, it doesn’t just say “something’s slow.” It tells you what’s slow, for whom, and when.

You see the user’s whole story. Maybe users bounce on your pricing page, but only after they’ve struggled through a slow product search. That’s a different problem than users bouncing immediately. RUM connects the dots between performance and user behavior.

You get real device and browser data. Not “simulated iPhone,” but “actual iPhone 12 on Verizon in Chicago.” You can see if your performance problems are specific to certain devices, browsers, or network conditions that your real users actually have.

You spot the weird edge cases. Like that one page that’s only slow for users who came from Google Ads, or the form that gets laggy after people have been on your site for more than 10 minutes. Synthetic testing would never catch this stuff.

Why You Need Both (But RUM Reveals What Actually Matters)

Don’t misunderstand—synthetic testing still has value. The complete performance strategy uses both approaches strategically.

Synthetic Testing: Good for Development and Investigation

As we covered in our Lighthouse limitations article, synthetic testing excels at:

• Catching obvious issues before release in a controlled environment
• Investigating specific problems once you know they exist (RUM tells you there’s a problem, Lighthouse helps you understand why)
• Consistent testing environment for A/B testing code changes during development

Think of synthetic testing as your development safety net. It prevents you from shipping obviously broken performance, but it can’t tell you how your site actually performs for real users.

RUM: Essential for Understanding Production Reality

Real User Monitoring is where you discover what actually needs fixing in production:

• Actual user experience measurement across all your user segments and conditions
• Business impact quantification showing which performance issues cost money and which don’t
• Real-world performance validation under the conditions that actually matter
• Continuous monitoring and alerting for production issues affecting real users

The Complete Performance Strategy

The most effective approach combines both tools strategically:

1. Use synthetic tests during development to prevent shipping obvious performance problems
2. Use RUM to discover what actually needs fixing in production with real users
3. Cross-reference findings: when RUM shows a problem, investigate with synthetic testing to understand the root cause
4. Validate fixes with RUM to ensure your improvements actually help real users

For a deeper technical comparison of when to use each approach, read our detailed guide on Synthetic Testing and Real User Monitoring.

How to Do Real User Monitoring: Beyond the Demo

If you’ve watched RUM demos but weren’t sure why you’d bother installing it, here’s what you can expect when you actually implement Real User Monitoring:

What to Expect When You Install RUM

First 24 hours: RUM establishes your performance baseline. You’ll start seeing data about how your site actually performs for real users, often revealing surprises. Maybe your mobile performance is worse than you thought, or maybe a specific page that seemed fast in testing is actually slow for real users.

First week: Patterns emerge. You’ll see which pages consistently have performance issues, which user segments struggle the most, and which times of day or days of the week show performance degradation. This is when RUM starts answering questions you didn’t even know you had.

First month: You can analyze trends and identify optimization opportunities based on real user impact. You’ll have enough data to prioritize performance improvements based on actual business impact rather than synthetic scores.

Ongoing: RUM becomes your continuous performance intelligence system, alerting you to problems as they happen and helping you measure the real-world impact of every change you make.

Implementation Best Practices

Key metrics to monitor from day one:

• Core Web Vitals (LCP, INP, CLS) from real users
• Page load times across different user segments
• Error rates and their correlation with performance issues
• Business metrics like conversion rates and bounce rates tied to performance data

Focus on trends, not arbitrary thresholds. Instead of getting alerts every time a metric crosses some magic number, track whether your performance is improving or getting worse over time. A gradual decline in performance is often more important than a single spike, and trending data helps you spot problems before they become disasters.

Avoiding common setup mistakes: Don’t try to track everything at once. Start with the metrics that matter most to your business, then expand your monitoring as you get comfortable with the data.

Best Real User Monitoring Tools: What to Look For

Not all RUM tools are created equal. When evaluating Real User Monitoring solutions, look for:

Essential RUM Features

Real-time data collection and alerting: You need to know about performance problems as they happen, not days or weeks later.

Core Web Vitals tracking: Your RUM tool should track the metrics that Google uses for ranking and that correlate with user experience.

User segment analysis: The ability to slice performance data by device type, geography, user behavior, and other dimensions that matter to your business.

Integration with synthetic testing: When RUM spots a performance problem, you can use synthetic testing tools to get actionable tips on how to make it faster.

Request Metrics Advantages

Setup that doesn’t suck. Most RUM tools make you configure a million settings and wait days for useful data. Request Metrics gives you insights within minutes of adding the script to your site.

Data you can actually use. Many RUM tools dump spreadsheets of metrics on you. Request Metrics focuses on showing you what’s broken and what to fix first, not overwhelming you with numbers.

Alerts that matter. Get notified when performance issues actually affect your users and your business, not every time a metric fluctuates by 50 milliseconds.

Connects to what you care about. See how performance impacts your conversions, not just abstract scores that don’t relate to your business goals.

Your Next Step

Ready to see how your website actually performs for real users? Install Request Metrics Real User Monitoring and start getting insights about your actual user experience within minutes.

In your first week with RUM, you’ll likely discover performance issues you never knew existed and optimization opportunities that can directly impact your business metrics. More importantly, you’ll finally have the data you need to make performance improvements that actually matter to your users.

Stop guessing about your website’s performance. Start measuring what really matters with Real User Monitoring.

Great Lighthouse scores, but users still complain your site is slow? Here’s the shocking truth: Google’s research found that 50% of websites with perfect Lighthouse scores still fail Core Web Vitals when measured with real user data. Half!

Synthetic Testing and Real User Monitoring are the most important tools in your performance toolbox. But they do different things and are useful at different times. Many developers only master one of these tools and miss critical performance problems—like trying to hammer in a screw.

Let’s look at these tools, what they measure, and when to use them.

Synthetic Testing

Synthetic Testing measures the performance of a website under controlled conditions. Examples include Lighthouse audits from Chrome DevTools, PageSpeed Insights, or Request Metrics Lab tests. The test simulates location, latency, bandwidth, browser, and device to approximate a visitor’s experience.

For synthetic tests to be accurate and valuable, you need to know things about your likely visitors: where they are, what network they’re on, and what device they’re using. Then the test must accurately simulate these characteristics. Both are difficult.

The internet is big and diverse, and developers don’t always know enough about our users. We make guesses, but because we often run on fast networks with new laptops, we overestimate our users’ capabilities. It’s fast on my machine.

Plus, you likely have more than one type of user. Some visit from work laptops. Others try to login on phones from trains, or tablets with flaky coffee shop wi-fi. Each user has a different performance perspective and would need different test simulations.

Lighthouse tries to simulate an “85th percentile user”—but their simulation is usually wrong. Your users aren’t Google’s generic average. A developer-focused B2B tool has completely different users than a consumer social app. Lighthouse can’t know the difference, so it makes assumptions that are often wrong for your specific audience.

The biggest benefit is that you can run a synthetic test right now, regardless of whether you have users. The results will probably show your biggest performance problems.

The test will be flawed, and that’s okay—it gives you an idea of performance. Synthetic testing never tells you how fast your website really is—only how fast it might be under ideal conditions.

For more on synthetic testing limitations, see our detailed guide on The Limitations of Lighthouse.

Real User Monitoring

Real User Monitoring is just that: real. RUM records actual performance from users who visited your website. RUM doesn’t guess or simulate—it records the actual performance they experienced.

RUM works by adding JavaScript to your website that runs alongside your page content. This script uses built-in browser APIs to collect performance data as users interact with your site—page load times, interaction delays, animation performance, and errors.

When someone visits your page, the RUM script measures their real experience and sends that data to a reporting service. This gives you performance data that reflects real network conditions, real devices, and real user behavior patterns.

Real User Monitoring is more accurate than synthetic testing, but there’s also more noise and delay.

RUM data includes all users, even that person browsing your website from Mongolia on questionable internet. You’ll need statistics to understand what it means—medians, percentiles, and distributions. Used correctly, RUM tells you how your fastest users, typical users, and worst users experience your website.

The biggest limitation is delay. RUM can’t tell you how fast your site will be until users visit it. You have to release changes and measure impact to see if your site sped up—or not. Synthetic testing can guess at performance early, helping find obvious problems, but to prove your site is fast, you need RUM.

Why Chrome User Experience Report (CrUX) Isn’t Enough

The Chrome User Experience Report provides real user data, which sounds great—but it’s like the lite beer of Real User Monitoring. Sure, it’s better than nothing if you have a lot of it, but it lacks the substance you need to make real decisions.

CrUX does show data from your specific website, but only for your busiest pages and only as total aggregate performance. It’s like getting a report that says “your restaurant had mixed reviews this month” without knowing which dishes, which servers, or which times of day caused problems. You know something might be off, but you can’t do anything about it.

The 28-day reporting delay means you could have performance problems for weeks before CrUX shows them. In web time, that’s an eternity.

CrUX data is public, making it excellent for benchmarking against competitors. But that same public nature means it’s not detailed enough for optimization decisions about your specific site.

CrUX gives you the 30,000-foot view. Real User Monitoring gives you the ground-level intelligence you need to improve your site.

Signal vs Noise: The Real Difference

Synthetic testing and Real User Monitoring is about signal vs noise. Synthetic tests don’t have much noise—each Lighthouse test is a valid measurement for those conditions. Run the test again with the same conditions and you’ll get similar results.

But as Google’s research showed, there’s not much signal in those synthetic results either. That Lighthouse report isn’t how any user experiences your page (unless they’re browsing from your laptop on your network).

Real User Monitoring is the opposite. Each bit of RUM data shows how your website really performed for a visitor. But those visitors can be wildly different. Some have awesome experiences. Others think they’re still on dial-up.

The trick is: which users do you care about? If you’re building a site for corporate users in the United States, performance for mobile users in remote areas might not matter. RUM tools like Request Metrics help you filter noise and aggregate data for a clearer picture of your target users.

When Only RUM Will Do: Real-World Scenarios

Here are performance problems that synthetic testing will never catch:

Black Friday traffic spikes: Synthetic testing can’t simulate real load on your servers, payment processors, and CDN. RUM captures what happens when thousands of people try to buy your stuff simultaneously.

Dynamic content complexity: Your personalization engine might be fast for new users but slow for power users with complex histories. Maybe your A/B test variant tanks performance. Synthetic testing would never catch these issues.

Geographic infrastructure differences: Users in different regions experience vastly different network conditions. RUM shows which markets have performance problems you’d never see in controlled testing.

Third-party service reality: That chat widget, analytics script, or payment processor might work fine in testing but cause real user delays during outages or peak usage.

Device-specific issues: RUM reveals problems like “our site is slow on iPhone 12 specifically” or “users with older Android phones can’t complete checkout.”

The Complete Performance Strategy

Both synthetic testing and Real User Monitoring are valuable for developers building fast websites. Use them strategically:

Use synthetic testing to test changes before release. It catches obvious mistakes and gives you consistent testing conditions during development. Think of it as your safety net.

Use Real User Monitoring tools like Request Metrics to see if changes really sped things up. You don’t know how fast your website is until your visitors tell you.

The winning approach:

1. Develop with synthetic testing to prevent shipping obvious problems
2. Deploy and measure with RUM to see real-world impact
3. Investigate with synthetic testing when RUM spots problems
4. Validate fixes with RUM to ensure improvements help real users

For a deeper dive into why RUM is essential for understanding your site’s true performance, read our comprehensive guide: Why You Need Real User Monitoring to Really Understand Your Web Performance.

The Bottom Line

Stop guessing about your website’s performance. Synthetic testing gives you development confidence. Real User Monitoring gives you production truth.

Ready to see how your website actually performs for real users? Start monitoring with Request Metrics and discover what synthetic testing has been missing.

The fastest website is the website that is already loaded, and that’s exactly what HTTP caching delivers. HTTP caching is a powerful technique that lets web browsers reuse previously loaded resources like pages, images, JavaScript, and CSS without downloading them again. Understanding HTTP caching headers is essential for web performance optimization, but misconfiguration can cause big performance problems.

In this guide, we’ll explore what HTTP caching is, which headers control HTTP caching, and how to cache static resources effectively—without requiring you to read hundreds of pages of the HTTP Caching Spec.

What is HTTP Caching?

HTTP caching is a technique that temporarily stores copies of web resources to reduce server load, bandwidth usage, and latency. When implemented correctly, caching creates a win-win scenario:

• For users: Faster page loads and reduced data consumption
• For servers: Decreased load and bandwidth costs
• For businesses: Improved user experience and conversion rates

The caching process works through a series of HTTP headers that tell browsers and other intermediaries (like CDNs) whether to store a resource, how long to store it, and when to validate it’s still fresh. Let’s explore how these headers work together to optimize your web performance. 🚀

Speed Matters

Get your free speed check to see your website performance for real users.

Free speed test

Free speed check

Check how fast your website is for the real users that visit.

Check website

Which Headers Control HTTP Caching

HTTP caching is managed through a set of specialized response headers. Understanding these headers is crucial for implementing effective caching strategies:

Primary Caching Headers

1. Cache-Control: The most powerful and flexible caching header
2. Expires: An older but still supported way to specify cache duration
3. ETag: Enables efficient validation of cached resources
4. Last-Modified: Another validation mechanism based on modification time
5. Vary: Controls how cached responses are matched to requests

Let’s examine each of these headers in detail and see how they work together.

How to Use the Browser Cache

The browser calculates “Cache Freshness” using headers in the HTTP response. Cache freshness is how long a cached asset is valid since it was downloaded. Freshness is calculated depending on which headers are returned.

The Cache-Control Header

The Cache-Control header has a number of directives to control caching behavior, but the most common is max-age. Max-age specifies how many seconds after download the cached resource is valid. Here’s an example:

# Cache this response for 10 minutes (600 seconds).
Cache-Control: max-age=600

Additional important Cache-Control directives include:

• public: Response can be cached by any cache (browsers, CDNs, etc.)
• private: Response can only be cached by the user’s browser
• no-cache: Cache but revalidate before using
• no-store: Don’t cache at all
• must-revalidate: Verify resource is still valid when it becomes stale
• immutable: Resource will never change while cached (prevents revalidation)

The Expires Header

The Expires header contains a date and time at which the cached resource should be marked stale, but only if you didn’t already use the max-age Cache-Control option. Expires is used to determine freshness if the response also contains a Date header for when the response was sent. Freshness is simply subtracting Date from the Expires time.

# This response can be cached for 1 hour (Expires - Date == freshness).
Expires: Tue, 09 Nov 2024 21:09:28 GMT
Date: Tue, 09 Nov 2024 20:09:28 GMT

Pro tip: While Expires is still supported, Cache-Control: max-age is generally preferred as it’s more precise and not dependent on clock synchronization.

The Browser’s Automatic Caching

Even if you don’t use the Cache-Control or Expires header, most web browsers will cache resources automatically and guess how long they will remain fresh. This guessing is referred to as “heuristic freshness”. Usually, the guess is based on the Last-Modified header included automatically by most web servers. But each browser implements this differently, so it’s dangerous to rely on it for your caching.

Some browsers assume a resource is “fresh” for 10% of the time since the resource was last modified.

# Freshness = 2 hours  (20 hours since last modified)
# (Date - Last-Modified) * 10% == freshness
Last-Modified: Tue, 09 Nov 2021 02:00:00 GMT
Date: Tue, 09 Nov 2021 22:00:00 GMT

Warning: Relying on heuristic freshness can lead to unpredictable caching behavior across different browsers and devices. Always set explicit caching directives for predictable performance.

Handling Expired Resources

What happens when a resource “expires”? This is referred to as a “stale resource”, and the browser must re-validate the resource from the server. In some cases, the browser can validate the resource without downloading it again. Otherwise, the browser re-downloads the entire resource and caches the new version.

There are a couple ways this validation can happen, depending on which HTTP Validation Headers are sent with your resources.

Validating With the ETag Header

The ETag header allows the browser to tell the server what version it currently has. The header contains a string which uniquely identifies the content, usually a checksum of the file.

When a resource with an ETag expires, the browser will send a validation request with a If-None-Match header containing the ETag value it already has. If the resource is unchanged, the server replies with an empty 304 (Not Modified) HTTP response. Otherwise, the server sends the resource like normal when the content has changed.

# In original resource response headers:
ETag: "123abc987654"

# Browser sends in the validation request headers:
If-None-Match: "123abc987654"

Validating With the Last-Modified Header

When an ETag is unavailable, web servers may send a Last-Modified header, with the last modified date of the source file. Similar to ETags, the browser can send that date in a validation request with the If-Modified-Since header to tell the server which version it has.

The server returns an empty 304 (Not Modified) response if the content has not changed since the date specified.

# In original resource response headers:
Last-Modified: Tue, 09 Nov 2021 20:00:00 GMT

# Browser sends in the validation request headers:
If-Modified-Since: Tue, 09 Nov 2021 20:00:00 GMT

No Validation

If the original resource had neither ETag nor Last-Modified headers, then the browser simply requests the entire resource and uses the result.

How to Cache Static Resources Effectively

Static resources like images, CSS, JavaScript, and fonts are perfect candidates for aggressive caching. Here’s how to implement optimal caching for different types of static assets:

Images and Media Files

Images often make up the largest portion of a webpage’s size. Caching them properly can dramatically improve load times:

# Cache images for a year
Cache-Control: public, max-age=31536000, immutable

The immutable directive tells browsers that this content will never change at this URL, which prevents unnecessary revalidation requests.

CSS and JavaScript Files

For CSS and JavaScript, use versioned filenames and aggressive caching:

# Cache for a year, CDN-friendly
Cache-Control: public, max-age=31536000, immutable

Fonts

Web fonts should be cached aggressively as they rarely change:

# Cache fonts for a year
Cache-Control: public, max-age=31536000, immutable

HTML Documents

For HTML documents, a more conservative approach is typically best:

# Cache HTML briefly or validate frequently
Cache-Control: public, max-age=300, must-revalidate

Busting the Browser’s Cache

When something changes, such as a new image, refreshed session, or an updated release of your code, you’ll want to invalidate (or bust!) the browser cache so that your users get the new stuff. If you’ve aggressively set caching headers, this can be challenging, but there are a couple ways to solve it.

1. Changing the URL to the Resource

The most common cache busting strategy is just to change the name of your resources when they change. This could be something like including a hash, version, or date in the filename when you build your site.

scripts.e7686eaf.min.js

Implementation tip: Most modern build tools (Webpack, Rollup, Parcel) can automatically add content hashes to filenames during the build process.

2. Adding a Query Parameter

If you can’t change the name of your resources, you can add a querystring parameter with a changeable key, like a version or date. When you change your site, or a resource, updating the querystring to a new value will invalidate all browser caches.

/my/images.png?v=2024119

If you have a look at the source of our page here, you’ll see what we use this strategy, adding a date representation of the build time to all our scripts and styles.

3. Using the Vary Header

The Vary header can be returned in resource responses and tells the browser when a resource should be cached as a unique variation of the resource. It does this by specifying one or more headers to use as a unique key.

The browser will never be able to use its cached responses if the header values change on every request. Vary is often omitted entirely, and should be used carefully when needed.

# Good: A common value that should not impact caching
# Caches gzip vs non-gzip responses separately
Vary: Accept-Encoding

# Bad: Probably not what you want.
# Any change to X-App-Version will invalidate your cache!
Vary: X-App-Version

Common HTTP Caching Mistakes to Avoid

Even experienced developers can make mistakes with HTTP caching. Here are some pitfalls to watch out for:

1. Over-Caching Dynamic Content

Setting long cache times on content that changes frequently can lead to stale content being shown to users.

2. Under-Caching Static Content

Not caching static resources aggressively enough means browsers download the same files repeatedly, wasting bandwidth and slowing down the experience.

3. Forgetting Cache-Busting Mechanisms

Without proper cache-busting, users may never see your updated resources after deployment.

4. Misunderstanding no-cache vs no-store

Remember: no-cache means “revalidate before using” while no-store means “don’t cache at all.”

5. Ignoring the Vary Header

Without proper Vary headers, cached responses might be incorrectly served for different request contexts.

Testing Your HTTP Cache Configuration

Verifying that your caching strategy works as intended is crucial. Here are some tools and techniques to help:

1. Browser Developer Tools

Chrome, Firefox, and other modern browsers include Developer Tools that show how resources are being cached:

1. Open DevTools (F12 or Ctrl+Shift+I)
2. Navigate to the Network tab
3. Look for the “Size” column - you’ll see “(from disk cache)” or “(from memory cache)” for cached resources

2. Online HTTP Header Checkers

Check how your caching is configured right now! We made a neat tool that checks your HTTP cache settings.

3. Command Line Testing

You can use curl to inspect headers directly:

curl -I https://example.com/style.css

HTTP Caching Recipes

Different resources are cached differently. Here’s how to accomplish a few common caching scenarios.

1. Never Cache Anything!

Some resources are dynamic or time sensitive and should never be cached. This will force the browser to re-download resources each and every time the user loads the page. Force the browser to always makes a request:

Cache-Control: no-store

2. Cache, But Always Revalidate

Some resources are cacheable, but change often enough that they should be re-validated before use. We can accomplish this with the confusingly named no-cache directive. The browser will request an updated version of the resource, but will accept a 304 (Not Modified) response to save download bandwidth.

Cache-Control: no-cache

# no-cache is equivalent to:
Cache-Control: max-age=0, must-revalidate

3. Cache For A Day

Some resources change, but do so slowly. Setting a “just right” max-age on these allows them to be cached but updated in a timely manner when changed. Don’t depend on max-age alone if it’s critical that the browser immediately uses a new version, use a Cache-Buster!

Cache-Control: max-age=86400

4. Cache “Forever”

You probably don’t want to do this unless you are using a cache-busting strategy. There isn’t actually a “forever” cache directive, but you can get close enough by specifying a very large max-age.

# Cache this resource for a year
Cache-Control: max-age=31536000

Frequently Asked Questions About HTTP Caching

How long should I cache my resources?

The optimal cache duration depends on how frequently your content changes. Static assets like images, CSS, and JavaScript that are versioned can be cached for a year or more. Dynamic content might be cached for minutes or hours.

Does HTTPS affect HTTP caching?

HTTPS doesn’t prevent caching, but some directives like public and private become more important when using encrypted connections.

How can I force an update when content changes?

The most reliable approach is to change the URL of the resource, either by changing the filename or adding a version parameter to the URL.

What’s the difference between browser cache and CDN cache?

Browser caching occurs on the user’s device, while CDN caching happens on distributed servers. Both are controlled by HTTP headers, but they may interpret those headers differently.

Can I cache API responses?

Yes, but carefully. Short cache times or validation-based caching is usually best for API responses unless they’re truly static.

Conclusion: Mastering HTTP Caching for Optimal Performance

Proper HTTP caching is one of the most powerful tools in your web performance toolkit. By understanding HTTP caching headers and implementing appropriate caching strategies for different resource types, you can dramatically improve your website’s performance metrics:

• Reduced page load times
• Lower bandwidth usage
• Decreased server load
• Improved Core Web Vitals scores
• Better user experience and conversion rates

Remember, the right caching strategy depends on your specific content needs - there’s no one-size-fits-all solution. The key is finding the right balance between freshness and performance.

Ready to see how your caching strategy affects your real-world performance? Request Metrics provides detailed monitoring of your website’s performance, including cache hit rates and load times across different user segments. Start your free trial today and discover how effective caching can transform your website experience.