Dynamic Caching & Content Synchronization Explained

‍

Key Takeaways

• Dynamic Content Merging: Speed Kit accelerates traditional websites by racing a cached, anonymous version of a page against the live, personalized version. It instantly displays the cached version and then seamlessly merges dynamic content, guaranteeing a faster experience without ever slowing down the original site.
• Automated Content Synchronization: The system uses three distinct, automatic triggers—deployment detection, periodic updates, and crowd-sourced change detection—to ensure content is always fresh across the backend, edge, and browser caches.
• Effortless & Guided Integration: The initial setup is a straightforward process typically taking less than two hours, involving three simple steps: integrating a JavaScript tag, uploading our service worker file, and IP whitelisting, all fully supported by Speed Kit's dedicated onboarding team.

Introduction

A core challenge for modern websites, especially in e-commerce, is that their HTML documents are typically considered uncacheable. Due to dynamic content like prices, stock levels, and personalized information like user carts, servers send cache-control headers that prevent caching by traditional systems. This forces the user's browser to wait for the origin server to generate a full page on every navigation, creating significant latency and a slow user experience.

Speed Kit's primary innovation is making this uncacheable HTML cacheable. Our system is designed to intentionally ignore these prohibitive headers and apply its own proprietary caching rules. By creating a fast, "neutral" version of the HTML, Speed Kit directly solves two critical performance bottlenecks:

• Server Time: We eliminate your server's processing time for generating a page, because the page is already built and waiting in our cache.
• Network Time: We drastically reduce network latency by serving the cached page from a global edge network, close to your users. With predictive preloading, this network time can often be eliminated entirely.

The combined effect is a dramatic optimization of the Time to First Byte (TTFB) and typically a major improvement to the Largest Contentful Paint (LCP) as well. To ensure no personal data is ever stored incorrectly, our backend fetches pages from your origin server in an anonymous, cookie-less context—effectively simulating a brand-new visitor.

This document provides a comprehensive overview of Speed Kit's caching architecture for Multi-Page Applications (MPAs). We will also detail the fully automatic mechanisms that keep content perfectly synchronized with your origin server.

Note: This document focuses on acceleration for traditional Multi-Page Applications (MPAs). For Single-Page-Applications (SPAs) and sites that do client-side rendering, Speed Kit offers a different set of powerful tools. To learn more, see our guides on Accelerating Single-Page Applications (SPAs) and Solving the Client-Side Rendering (CSR) Problem. Advanced techniques like Predictive Preloading can also be applied to further enhance performance.

Effortless, Expert-Guided Integration

Speed Kit's integration process is designed to be exceptionally fast and straightforward, typically requiring less than two hours of your technical team's time. We combine a few simple setup steps on your side with a comprehensive, white-glove service from our expert Product Integration team, ensuring a seamless and risk-free launch.

The process involves:

• A Simple Technical Setup: The process begins with a few basic steps, like adding a JavaScript tag to your site, which are outlined in a personalized guide.
• Custom Configuration by Our Team: Our experts build a configuration tailored specifically to your website's architecture and performance goals.
• Safe QA and Phased Rollout: You can safely test the integration on your live site using our browser extension. We then proceed with a controlled, phased rollout, starting with A/B testing to measure the impact before a full launch.

For a complete walkthrough of all steps, please refer to our comprehensive Installation Guide.

​​A Low-Risk, Independent Architecture

It is important to understand that Speed Kit adds a new architectural layer that operates independently of your existing infrastructure. Unlike a traditional CDN integration that can be complex to reverse, Speed Kit is designed for maximum flexibility and safety.

The entire service can be deactivated at any time with a single click in the Speed Kit dashboard. Within seconds, all traffic will route directly to your origin as it did before, making the integration exceptionally low-risk.

Transforming Dynamic Pages into Cacheable Assets

Before a dynamic page can be cached and accelerated, Speed Kit's backend first creates a fast, universally cacheable version of it. This foundational process transforms a personalized page into a generic, "anonymized HTML" document that is safe to serve to any user.

The goal is to remove or hide all user-specific content while preserving the page's structure and static elements. This allows for an instant initial render, which is later filled with live data by the client-side merge process.

The preparation process involves these automated steps:

1. Anonymous Crawl: Our backend first fetches the page from your origin server in an anonymous context (i.e., without any user cookies) to get a base version of the content. This ensures that we never see or cache private user data from your visitors.
2. Automated Analysis: The fetched HTML is then parsed and analyzed. Our system automatically identifies sections that typically contain personalized content by looking for generic markers and common structural patterns. This process does not require you to add any custom tags to your site.
3. Content Neutralization: Once personalized sections are identified, our "document handler" module neutralizes them. This involves several actions:
   
   • Comment & Script Removal: All HTML comments and inline scripts are stripped from the document to create the clean, anonymized HTML. This is critical because these scripts can be personalized or contain dynamic logic. After the client-side merge, the browser executes the original, personalized scripts that arrive with the live response from your origin server.
   • Hiding of Personalized Elements: Based on a custom configuration created by our Product Integration team during onboarding, other site-specific dynamic elements are hidden via injected stylesheets. It is also possible to configure custom placeholders or loading spinners for these areas instead of simply hiding them.
4. Caching the Anonymized HTML: The result of this process is a clean, "anonymized HTML" document. This is the version that is stored across all layers of our cache, ready to be delivered instantly to any user.

Managing Loading States with CSS

To prevent users from briefly seeing generic content on the static version of the page before it is replaced by personalized data, Speed Kit attaches status classes to the main <html> element. You can use these classes to control the visibility of the placeholder content with CSS.

• Before Replacement: The <html> element has the class speed-kit-dynamic-loading.
• After Replacement: This class is replaced with speed-kit-dynamic-loaded.

Example: Hiding the placeholder You can use the status class to hide generic content until it is replaced. The CSS rule will no longer match after the replacement, making the element visible again.

.speed-kit-dynamic-loading .my-shopping-cart {
  visibility: hidden;
}

Example: Adding a loading spinner You can also use these classes to create more advanced transitions, such as displaying a loading spinner within the placeholder.

@keyframes speed-kit-loading {
  0% {
    box-shadow: 8px 0 #C8C8CD, 20px 0 #DDDDE0, 32px 0 #EDEDEE;
  }
  33% {
    box-shadow: 8px 0 #EDEDEE, 20px 0 #C8C8CD, 32px 0 #DDDDE0;
  }
  66% {
    box-shadow: 8px 0 #DDDDE0, 20px 0 #EDEDEE, 32px 0 #C8C8CD;
  }
}
.speed-kit-dynamic-loading .my-shopping-cart::after {
  content: "";
  display: block;
  position: absolute;
  top: 50%;
  left: 50%;
  width: 8px;
  height: 8px;
  margin: -4px 0 0 -24px;
  border-radius: 50%;
  box-shadow: 8px 0 #C8C8CD, 20px 0 #DDDDE0, 32px 0 #EDEDEE;
  will-change: box-shadow;
  animation-name: speed-kit-loading;
  animation-duration: 1.5s;
  animation-iteration-count: infinite;
  animation-fill-mode: both;
  visibility: visible !important;
  z-index: 1000 !important;
}

‍

The Core Caching & Synchronization Architecture

To deliver content at maximum speed while ensuring it is always up-to-date, Speed Kit uses a multi-layered architecture. The components work together, with three pillars of change detection feeding into a central sync mechanism.

The Three Caches

Content is stored in three locations to maximize speed:

• Backend Cache (AWS): The central cache where anonymous HTML and assets are processed and stored.
• Edge Cache (Fastly): A globally distributed CDN that serves cached content from locations close to the user for minimal network latency.
• Service Worker Cache (Browser): A cache directly in the user's browser, enabling truly instant page loads for repeat visits and pre-cached pages.

The Principle of Revalidation

Instead of blindly deleting and re-downloading content, Speed Kit's philosophy is based on efficient, active revalidation.

When one of our detection methods signals a potential change, our backend immediately queries your origin server to verify it. This is done using standard HTTP conditional request headers like ETag and last-modified.

A cache update is only performed if this revalidation confirms that the content has actually changed. If your server responds with a 304 Not Modified, it means the content is still current. In this case, no data is transferred and no caches on our side are purged, which saves bandwidth and protects your origin from unnecessary load.

The Bloom Filter: Synchronizing the Browser Cache

The biggest challenge in keeping content fresh lies with the service worker cache in the user's browser. A server has no direct way to "push" an invalidation notice or force the browser to discard a cached file that has become stale on the origin. Our elegant solution to this problem is the Bloom filter, a space-efficient, probabilistic data structure that tests if a URL has recently changed.

Before any file is served from the browser cache, the service worker consults the Bloom filter. The service worker keeps its local copy of this filter fresh by updating it at regular intervals (every 5 minutes) and on page reloads. If a URL is present in the filter, the service worker knows it must revalidate that asset before serving it from the cache. The filter can also carry a domain-wide signal to indicate a deployment is in progress, instructing the browser to bypass the cache temporarily.

Acceleration for Multi-Page Applications (MPAs)

For traditional websites and server-side rendered frameworks, Speed Kit uses a dynamic content merging process orchestrated by the service worker.

The Simultaneous Request Race

When a user navigates to a page, the Speed Kit Service Worker issues two parallel requests:

1. To the Speed Kit Cache: For the fast, anonymous version of the HTML.
2. To the Origin Server: For the fully personalized, live version of the HTML.

There are two possible outcomes to this race, both of which prioritize the user experience and site stability.

Outcome 1: Speed Kit Wins the Race (The Common Case)

In the vast majority of cases, the request to the Speed Kit cache resolves first. The process is as follows:

Tiered Cache Fetch Process

To serve a page, Speed Kit checks its cache layers sequentially, from fastest to slowest:

1. Prerendered Cache: If the page was predictively prerendered in the background, users experience an almost instant page load, with a Largest Contentful Paint (LCP) typically under 300 ms. This is the fastest possible outcome.
2. Service Worker Cache: For pages already in the browser—either from a previous visit or from predictive preloading—we first consult the Bloom filter to verify freshness. If the content is not marked as stale, it is served directly from the local service worker cache for a near-instant response.
3. Edge Cache: For a first-time visit, the request goes to the nearest global Edge node for fast delivery from our network.
4. Backend Cache: If the page is not found on the edge node, it is fetched from our central backend cache.
5. Origin Server (Discovery): If the page is not in any of our caches, we fetch it from your origin server. This final step is how new pages are discovered. The newly fetched page is then populated across our Edge nodes and stored in the user's Service Worker cache for subsequent visits. During this initial discovery, the origin server often wins the race, triggering the fail-safe described in Outcome 2.

Crucially, any page successfully served to the user is automatically stored in the local service worker cache. This ensures that the next time the user visits that page, it will be served directly from the browser for a near-instant response.

Seamless Merge

Once the personalized HTML response arrives from your origin server moments later, Speed Kit intelligently swaps the <body> of the already-rendered page with the <body> from the origin. This allows personalized content (like a user's shopping cart) to become visible, merging the speed of a static cache with the dynamism of a live site.

JavaScript Execution

To prevent scripts from breaking due to these DOM changes, Speed Kit delays JS execution until the merge is complete. This ensures all scripts from the origin—whether static or dynamic—run correctly on the final, personalized DOM.

Outcome 2: The Origin Server Wins the Race (The Fail-Safe)

In the rare event that your origin server responds faster than the Speed Kit cache, the system prioritizes showing content immediately:

• Direct Render: The service worker simply forwards the response from your origin server directly to the browser.
• No Merge: No merging or content swapping occurs. The user sees the original version of your site, exactly as they would without Speed Kit.

This fail-safe mechanism guarantees that Speed Kit will never slow down your website. In the worst-case scenario, your site remains exactly as fast as it was before.

Automated Content Synchronization: The Three Pillars of Freshness

Speed Kit uses three distinct, automated methods to discover when your content has changed. Each method triggers our universal cache synchronization process.

Method 1: Deployment Detection

This is the most important mechanism for keeping the cache in sync with your codebase. Speed Kit detects deployments by monitoring asset hashes, checking version numbers in meta tags, or via API triggers from your CI/CD pipeline.

When a large-scale deployment is detected, a safety protocol is initiated: a "deployment in progress" flag is added to the Bloom filter. This flag instructs all browsers to enter a temporary "passthrough" mode (15 minutes by default). The purpose of this mode is to provide a safe time window for your origin servers to complete the deployment across your entire infrastructure. This ensures that when we begin revalidating our caches, we are pulling from a stable and fully updated source.

Method 2: Periodic Updates

This scheduled, time-based mechanism is ideal for predictable, site-wide content updates, like a daily price refresh. By systematically revalidating pages, it ensures consistency more effectively than relying on individual user visits. Default, configurable frequencies include:

• HTML Pages: Daily
• High-Priority Landing Pages: As frequently as every 10 minutes
• Assets (CSS, JS): Every 10 minutes
• Images: Every 7 days

Method 3: Crowd-Sourced Change Detection

During the page merge process, a script in the user's browser strategically compares key "above the fold" content elements between the anonymous HTML from the Speed Kit cache and the live HTML from your origin server. These crucial elements, like the product name or price, are defined during the initial setup.

If a discrepancy is found, the browser informs our backend via a RUM beacon. The backend revalidates the page and refreshes all of our caches within a few seconds. This crowd-smart solution guarantees that only one user sees the outdated content. Even for that user, the stale version is only visible for a very short moment before the correct, up-to-date content from your origin server is shown.

The Cache Synchronization Process: Our Response to a Change

Once a change has been detected by any of the methods above, our backend orchestrates a unified, three-step process to ensure all caches are updated correctly and efficiently.

Step 1: Updating the Bloom Filter (For the Browser Cache)

This step details the smart, time-based logic our backend uses to populate the Bloom filter. The following backend process determines which URLs are added to the filter and for how long:

• Estimated TTL: For every asset the Speed Kit backend caches, it calculates an Estimated Time-to-Live (TTL) based on how frequently that asset has changed in the past.
• Bloom Filter Entry Lifecycle: If a change is detected before an asset's estimated TTL has expired, its URL is added to the Bloom filter for the remainder of that original TTL. This acts as a "recall notice" for the browser. For example: if an asset has an estimated TTL of 4 days and a change is detected after only 2 days, the URL is added to the Bloom filter for this remaining 2-day period. The URL is automatically removed from the filter once this period ends because, at that point, the browser would need to revalidate the asset anyway.

Step 2: Purging the Edge Cache

Simultaneously, the backend sends a purge command to our CDN. This instantly removes the stale version of the asset from all globally distributed edge nodes.

Step 3: Pre-warming the Edge Cache

To ensure performance does not degrade after a purge, our system immediately begins repopulating the edge cache with the new content. This is a crucial step for maintaining low latency to end users.

• Proactive Pre-warming: Our standard process is to intelligently pre-warm the cache using RUM data. This identifies and prioritizes your most important pages, fetching them onto the most relevant geographic edge nodes before users even request them.
• User-Driven Revalidation (Post-Deployment): In the specific case where a deployment was detected and we are rebuilding the cache, we supplement proactive pre-warming with user-driven revalidation. As we rebuild, the pages with the most traffic are naturally requested by users first. Each of these initial requests triggers an immediate, "ad-hoc" revalidation for that specific page, ensuring your most popular pages are refreshed with the highest priority.

This combination ensures that your most important, highest-traffic pages are the very first to be refreshed and available in the edge cache, maximizing performance where it matters most.

Manual Controls and Visibility: The Dashboard & API

While our system is fully automatic, we provide powerful tools for manual control when you need it.

The Speed Kit Dashboard

The dashboard provides a user-friendly interface for visibility and direct control over your cache. You can:

• View Cached Assets: See a complete list of all assets in the Speed Kit cache, with powerful filters.
• Trigger Content Updates: Manually trigger an update job to revalidate and refresh specific assets.
• Purge Assets: Remove an asset from the cache entirely.
• Manage Whitelist & Blacklist: Control which resources are included in or excluded from Speed Kit's acceleration.‍
• Configure Periodic Updates: View and edit the schedules for all recurring update jobs.

Speed Kit Dashboard Documentation: https://www.speedkit.com/docs/web-dashboard 

The Refresh API

For programmatic control, all manual jobs can be triggered via our Refresh API, which is authenticated using API tokens. Every job returns a unique ID that can be used to monitor its progress.

For detailed endpoint descriptions, request/response schemas, and code examples, please see our API Documentation.

Advanced Topics: Scalability & Origin Protection

Scalability & Cache Management

Speed Kit is designed for scale and handles customers with over 500,000 product pages without issue.

• Cache Eviction Policy: To keep our caches focused and efficient, pages are automatically removed when they are no longer needed. When the calculated Time-to-Live (TTL) for an HTML page expires, we apply a default grace period of 10 days. If the page is not requested by any user during this 10-day grace period, the file is permanently deleted from our edge and backend caches. This ensures that stale content that receives no traffic is cleared efficiently.
• URL Parameter Handling for Cache Efficiency: To maximize the cache-hit ratio, Speed Kit can be configured to handle URL parameters flexibly. Many URLs can point to the same content but differ only by parameters used for tracking, analytics, or sessions (e.g., ?utm_source=google, ?session_id=xyz). By ignoring a predefined list of these parameters via the Speed Kit configuration, our system can treat multiple URL variations as a single cacheable item. This configuration is fine-tuned for your specific site during the onboarding process and is a key strategy for maintaining a highly efficient cache.

Origin Server Protection

Speed Kit is designed to be a good neighbor, with multiple safeguards to protect your infrastructure from being overwhelmed. We understand that whitelisting our servers relaxes your existing bot or rate-limiting rules. Therefore, we have implemented a multi-layered security strategy to mitigate any potential risks.

Our entire backend infrastructure runs on AWS, where we strictly adhere to all security best practices, such as the AWS Well-Architected Framework. For content delivery, we rely on the robust and secure Fastly CDN.

To protect your origin server, we have implemented the following safeguards:

1. Fastly Next-Gen WAF at the Edge

We utilize Fastly's Next-Gen Web Application Firewall (WAF) directly at the CDN level. This filters malicious requests before they can reach our servers or yours by using:

• Up-to-date Open Web Application Security Project (OWASP) Top 10 rule sets
• Known bot signatures
• Geo- and IP-based blocklists

2. Strict & Dynamic Rate-Limiting

Our system operates with multiple layers of rate-limiting to ensure predictable traffic and prevent overload:

• Hard Limits: We enforce strict, configurable limits on the number of requests per second our system can send to your origin.
• Customer-Specific Thresholds: Even if our primary limits were bypassed, we enforce an absolute traffic ceiling for each customer as a final backstop.
• Dynamic Throttling: As an additional safety layer, we continuously monitor the response time from your origin server. If we detect that answer times are rising, our system automatically throttles its request rate, ensuring we "back off" if your server is under stress.

3. Secure Request Handling

We ensure that only safe, valid requests are forwarded to your origin:.

• GET Requests Only: Our service will only ever forward GET requests to your origin. Other HTTP methods like POST, PUT, or DELETE are never passed through, eliminating them as a potential attack vector.
• Header Sanitization: We do not forward HTTP headers from the end-user's client. Instead, our system uses its own strictly defined set of headers for all requests to your origin, which prevents attacks carried in malicious HTTP headers.

4. Data Privacy by Design

Protecting your users' data is a fundamental principle of our architecture. To create a cached version of a page, our backend system fetches the content in a completely anonymous context.

• No Cookies: Our crawlers operate from a neutral, third-party domain and do not receive or use any cookies from your users.
• Anonymous Fetch: The crawl to create the cached page is performed without any user context, effectively acting as a new, unknown visitor. This is a fundamental privacy measure that ensures our backend systems do not receive any personally identifiable information (PII) or user-specific session data from your origin server.
• Client-Side Personalization: All personalization and merging of user-specific content happens entirely within the user's own browser, separate from our caching systems.

Broad Compatibility & Proven Value

Speed Kit is platform-agnostic, working with all major e-commerce platforms and even with custom e-commerce solutions. We provide dedicated solutions for modern architectures, including client-side rendered (CSR) pages and Single-Page Applications (SPAs). Our architecture is also designed to handle personalized content and A/B testing tools. With our customers, we have demonstrated that Speed Kit can achieve a significant performance uplift on all e-commerce platforms to provide a strong return on investment.

Addressing SEO: How Speed Kit Interacts with the Google Crawler

By dramatically improving page load times, Speed Kit provides a significant, positive impact on key SEO ranking factors. Site speed and the resulting user experience are critical components of Google's ranking algorithm, particularly through Core Web Vitals (CWV). Speed Kit is engineered to deliver major improvements to metrics like Time to First Byte (TTFB) and overall page load time, which can directly translate to higher search engine rankings. Learn more about these benefits in our Speed Kit Business Impact Guide.

Technical SEO and Crawler Compatibility

While the performance benefits are clear, it is also crucial to understand that Speed Kit is designed to be fully compatible with search engine crawlers, posing no risk to your SEO foundation. The Googlebot always indexes the live, canonical version of your site directly from your origin server, not the cached version from Speed Kit.

This is because Google's Web Rendering Service (WRS), the system used to crawl and render pages, does not support Service Workers.

• No Service Worker Execution: The Googlebot does not install or execute Service Workers. We have confirmed this through Google Search Console, which shows that the crawler rejects the Service Worker registration script. Therefore, it cannot be intercepted by Speed Kit's client-side logic.
• Stateless Crawling: The WRS crawls in a stateless manner, meaning it does not retain cookies, session storage, or local storage between page loads. It effectively acts as a brand-new visitor on every request.
• Verified Behavior: Analysis of our request logs across all customers consistently shows no traffic from the Google crawler to the Speed Kit infrastructure. The crawler exclusively interacts with the origin server.

This behavior guarantees that search engines see the exact same content your origin server produces, eliminating any risk of cloaking—the practice of showing different content to users and search engines. Because Speed Kit guarantees that the user always sees the correct, up-to-date content from your origin at the end of the interaction, the final page is consistent for both users and crawlers, ensuring your SEO integrity remains intact.