Sitecore and Core Web Vitals. Changing the client cache

Introduction

In the modern digital landscape, website performance is not just a nice-to-have—it’s a business-critical factor. Google’s Core Web Vitals (CWV) have shifted the way developers, marketers, and architects think about web optimization. These metrics—Largest Contentful Paint (LCP), First Input Delay (FID), and Cumulative Layout Shift (CLS)—play a significant role not only in user experience but also in search engine ranking.

For organizations running Sitecore XP/XM, optimizing Core Web Vitals requires a combination of content delivery strategies, caching improvements, and configuration tuning. Among these, changing the client cache policies is often overlooked, but it can dramatically impact your CWV scores.

In this article, we will explore how Sitecore interacts with Core Web Vitals, why client-side caching is crucial, and provide a step-by-step guide to configuring cache headers in Sitecore to improve performance. Along the way, we’ll mix conceptual explanations with technical code snippets, ensuring both architects and developers can follow along.

Understanding Core Web Vitals in the Sitecore Context

What Are Core Web Vitals?

Core Web Vitals are a set of user-centric performance metrics introduced by Google. They measure how fast and stable a website feels for end users.

• Largest Contentful Paint (LCP): Measures how quickly the largest visible element (e.g., hero banner, image, or block of text) loads.
• First Input Delay (FID): Measures how responsive the site is to the first user interaction, such as clicking a button or link.
• Cumulative Layout Shift (CLS): Measures how stable the page layout is while loading, preventing “shifts” that frustrate users.

In 2024, Google started incorporating Interaction to Next Paint (INP) as a replacement for FID, making responsiveness even more important.

Why Core Web Vitals Matter for Sitecore Sites

Sitecore is a feature-rich DXP with dynamic rendering capabilities. But this flexibility can come at a cost if caching and delivery are not optimized. Out-of-the-box Sitecore projects often suffer from:

• Unoptimized media delivery: Images and videos not cached or compressed correctly.
• Heavy personalization: While powerful, dynamic personalization can bypass caches, slowing LCP.
• Suboptimal cache headers: Default IIS/Sitecore setups don’t always leverage client cache to its full potential.

These factors directly hurt CWV scores and therefore SEO rankings, bounce rates, and conversion rates.

Understanding Core Web Vitals in the Sitecore Context

What Are Core Web Vitals?

Core Web Vitals are a set of user-centric performance metrics introduced by Google. They measure how fast and stable a website feels for end users.

• Largest Contentful Paint (LCP): Measures how quickly the largest visible element (e.g., hero banner, image, or block of text) loads.
• First Input Delay (FID): Measures how responsive the site is to the first user interaction, such as clicking a button or link.
• Cumulative Layout Shift (CLS): Measures how stable the page layout is while loading, preventing “shifts” that frustrate users.

In 2024, Google started incorporating Interaction to Next Paint (INP) as a replacement for FID, making responsiveness even more important.

Why Core Web Vitals Matter for Sitecore Sites

Sitecore is a feature-rich DXP with dynamic rendering capabilities. But this flexibility can come at a cost if caching and delivery are not optimized. Out-of-the-box Sitecore projects often suffer from:

• Unoptimized media delivery: Images and videos not cached or compressed correctly.
• Heavy personalization: While powerful, dynamic personalization can bypass caches, slowing LCP.
• Suboptimal cache headers: Default IIS/Sitecore setups don’t always leverage client cache to its full potential.

These factors directly hurt CWV scores and therefore SEO rankings, bounce rates, and conversion rates.

How Client Cache Impacts Core Web Vitals

Cache and Largest Contentful Paint (LCP)

LCP often involves a hero image or banner. If that image isn’t cached properly, every page load requires a network round-trip. By enabling strong client cache headers (Cache-Control: public, max-age=31536000), we allow browsers to reuse cached assets, dramatically reducing LCP times.

Cache and First Input Delay (FID/INP)

While caching doesn’t directly affect responsiveness, reducing JavaScript download and parsing time helps free up the main thread faster, indirectly improving FID/INP.

Cache and Cumulative Layout Shift (CLS)

Caching CSS ensures that styles load instantly, preventing layout “jumps” caused by late-loaded fonts or stylesheets. This reduces CLS significantly.

Configuring Client Cache in Sitecore

The first thing you need to do is create a config file or use an existing one to patch the following settings in the sitecore configuration:

<setting name="disableBrowserCaching" value ="false" patch:attribute="value"  />

<setting name="Speak.HttpCaching.ETagEnabled" value ="true" patch:attribute="value"  />

If you are not using SXA in your website and you have the website definition in your in a config file you should add an extra property to it to enable the browser cache.

<sites>
  <site name="YOURWEBSITENAME"
        inherits="website"
        hostName="$(env:CM_HOST)|$(env:CD_HOST)|cd|cm"
        rootPath="/sitecore/content/Website"
        startItem="/Home"
        dictionaryDomain="{B741B17B-67B2-4DD8-A216-D092813871F0}"
        patch:before="site[@name='website']"
        language="en"
        disableBrowserCaching="false"/>
</sites>

Now, using the same config file you need to overwrite a pipeline to set the headers and make the client cache public.

You can use the following code as example to overwrite the rendering processor:

public class CustomBrowserCaching : GetPageRenderingProcessor
{
    public override void Process(GetPageRenderingArgs args)
    {
        Assert.ArgumentNotNull((object)args, nameof(args));
        Profiler.StartOperation("Update browser caching headers.");
        HttpContext context = HttpContext.Current;
        Item currentItem = PageContext.CurrentOrNull.Item;
        if (context == null) return;

        SetCacheHeaders(currentItem, context);
        if (currentItem != null)
            SetUpdateHeaders(currentItem, context);
        Profiler.EndOperation();
    }

    private static void SetUpdateHeaders(Item currentItem, HttpContext context)
    {
        DateTime date = currentItem.Statistics.Updated;
        if (date > DateTime.UtcNow)
        {
            date = DateTime.UtcNow;
        }
        context.Response.Cache.SetLastModified(date);
    }

    private static void SetCacheHeaders(Item item, HttpContext context)
    {
        if (Context.Site == null)
            return;

        context.Response.Cache.SetCacheability(HttpCacheability.Public);

        var cacheMaxAgeSetting = Settings.GetSetting("Website.CacheMaxAge");
        
        if (TimeSpan.TryParse(cacheMaxAgeSetting, out TimeSpan cacheMaxAge))
        {
            cacheMaxAge = TimeSpan.FromHours(1);
        }

        context.Response.Cache.SetMaxAge(cacheMaxAge);
        context.Response.Cache.SetExpires(DateTime.Now.AddDays(7));
        var date = item.Statistics.Updated;
        if (date > DateTime.Now)
        {
            date = DateTime.Now;
        }
        context.Response.Cache.SetLastModified(date);
        context.Response.Cache.SetETag(item.Statistics.Revision);
    }
}

Ok, you got your custom processor done, now let’s make it work adding it in the config file previously created or used.

if you see in the code I added this extra setting to manage the cache max age in the config file

<setting name="Website.CacheMaxAge" value ="01:00:00" />

Below you will the how to add the overwrite to the Sitecore processor with our custom one.

<pipelines>
  <mvc.getPageRendering>
    <processor patch:after="*[@type='Sitecore.Mvc.Pipelines.Response.GetPageRendering.GetLayoutRendering, Sitecore.Mvc']" type="YourProjectName.Pipelines.CustomBrowserCaching, Website.Project">
    </processor>
  </mvc.getPageRendering>
</pipelines>

Finally deploy your changes and see how it works

Testing and Validating Improvements

Once cache headers are applied, test with:

• Chrome DevTools → Network tab
• WebPageTest.org
• Lighthouse / PageSpeed Insights

Look for:

• Cache-Control headers on images, JS, CSS.
• Reduced LCP in reports.
• Consistent CLS scores (stylesheets cached).

Conclusion

Optimizing Core Web Vitals in a Sitecore implementation is not just about frontend tweaks. Client cache configuration plays a central role in ensuring fast, responsive, and stable user experiences.

By tuning IIS, Sitecore Media Handler, and custom pipelines, you can drastically reduce LCP, improve CLS, and indirectly benefit INP. Combined with modern CDN strategies, these changes elevate both technical SEO and customer satisfaction.

When Core Web Vitals become a KPI for your organization, Sitecore projects that embrace client caching best practices will stand out in performance, visibility, and business results.