Skip to main content

Understanding Script Updates and Caching Delays

Introduction​

When we deploy updates to your ocm.js script, the changes may not appear immediately on your website. This document explains the various caching layers involved and what you can do to troubleshoot delays.

Important: While we purge our CDN cache immediately after every update, there are multiple other caching layers beyond our control that can cause delays ranging from a few minutes to several hours.

Caching Layers Overview​

Your script passes through several caching layers before reaching your visitors:

Google Buckets → Cloudflare CDN → Website Plugins → Browser Cache → User

Each layer can introduce delays. Let's examine them:

1. Browser Cache (Most Common Cause)​

What is it?​

Web browsers save copies of JavaScript files locally to speed up page loads. Even when we deploy updates, browsers may continue using their saved version.

How long does it cache?​

  • Our setting: We set Cache-Control: no-cache, max-age=0 to minimize caching
  • Reality: Different browsers use different caching heuristics, causing varying delays
    • Chrome: Typically 5-10 minutes for no-cache resources
    • Firefox: May cache up to 30 minutes depending on usage patterns
    • Safari: Can be more aggressive, sometimes 30-60 minutes
    • Mobile browsers: Often have different behavior than desktop versions

Important: Because browser vendors implement caching differently, the same update might appear immediately in one browser but take 30+ minutes in another for the same user.

What you can do:​

  • Hard Refresh: Press Ctrl+Shift+R (Windows/Linux) or Cmd+Shift+R (Mac)
  • Clear browser cache: Go to browser settings and clear cached files
  • Incognito/Private mode: Open your site in a private browsing window
  • Different browser: Test in a browser you haven't used recently

For your visitors:​

Most visitors will see updates within 5-30 minutes as their browser cache naturally expires.

2. Cloudflare CDN (Our Layer)​

What is it?​

We serve ocm.js through Cloudflare's global CDN network from cdn.orangeclickmedia.com.

Our purge process:​

Every time we deploy an update, we automatically purge Cloudflare's cache for:

  • Your main domain
  • Your www subdomain
  • All registered subdomains
  • Direct CDN URLs

Typical delay:​

  • Expected: 1-3 minutes globally
  • Worst case: Up to 5 minutes for distant edge servers

Cloudflare Issues (Rare but Possible):​

Occasionally, Cloudflare itself may experience technical issues that affect cache purging:

  • Purge API delays: Their purge API may be slow or temporarily unavailable
  • Edge server synchronization: Cache purges may not propagate to all edge servers simultaneously
  • Stale-while-revalidate: Even after purge, some edge servers may continue serving cached versions temporarily

The challenge: When Cloudflare has issues, they continue serving the old cached version of the script while their systems resolve the problem internally. This is by design (to keep websites online), but it means updates are delayed until Cloudflare's systems fully recover.

Resolution time: Depends entirely on Cloudflare's incident response - typically 15-30 minutes for minor issues, but can extend to 1-2 hours for major incidents.

Query Parameters and Caching:​

Important Note: If you add query parameters to the script URL for testing (e.g., //cdn.orangeclickmedia.com/tech/beta/youfly.com_v2/ocm.js?test=123), Cloudflare treats this as a separate cached resource.

This means:

  • ocm.js (no query) is cached separately from ocm.js?test=123
  • ocm.js?v=1 is cached separately from ocm.js?v=2
  • Using the same query parameter (e.g., ?test=123) will return the cached version until that specific URL is purged or expires

Best practice for testing:

  • Use a unique/random query parameter each time: ?t=1234567890 (timestamp)
  • Or use hard refresh instead of relying on query parameters
  • Remember: We only purge the base URL without query parameters during deployments

What you can do:​

Nothing needed on your end - we handle this automatically. However:

  • If you suspect a Cloudflare caching issue after 10+ minutes, contact us
  • We can check Cloudflare's status page (status.cloudflare.com) for known incidents
  • In rare cases, we may need to wait for Cloudflare to resolve infrastructure issues on their end
  • Avoid using fixed query parameters for testing - they create separate cached versions

3. Third-Party Caching Plugins​

What are they?​

Many websites use caching plugins to improve performance. These plugins create and serve cached versions of your HTML pages, including the script tags.

Common plugins:​

  • WordPress: WP Rocket, W3 Total Cache, WP Super Cache, LiteSpeed Cache, Autoptimize
  • Drupal: Internal Page Cache, Dynamic Page Cache, Boost
  • Joomla: JCH Optimize, JotCache
  • Generic: Varnish Cache, Redis Cache

How they affect updates:​

Even if the ocm.js file itself is updated, if your HTML page is cached, it might:

  • Reference an old version of the script
  • Bundle the old script inline
  • Prevent the browser from making a fresh request

What you can do:​

Contact your development team to:

  1. Clear your site's cache through the plugin settings
  2. Check if JavaScript files are being cached or minified separately
  3. Verify cache exclusions for third-party scripts
  4. Consider excluding cdn.orangeclickmedia.com from caching

Typical delay:​

Varies widely based on plugin settings - anywhere from 1 hour to 24 hours or even "never" if cache isn't cleared.

4. RocketLoader and Performance Optimizers​

What is it?​

RocketLoader (Cloudflare feature) and similar tools defer JavaScript loading to improve page speed. Some implementations can interfere with script updates.

Common tools:​

  • Cloudflare RocketLoader
  • Flying Scripts
  • WP Rocket JavaScript optimization
  • Autoptimize script defer
  • Async JavaScript plugin

How they affect updates:​

These tools may:

  • Cache analyzed versions of scripts
  • Bundle multiple scripts together
  • Delay execution in unexpected ways
  • Create dependency conflicts with new script versions

What you can do:​

Work with your developers to:

  1. Temporarily disable RocketLoader or similar features
  2. Clear optimization plugin caches
  3. Check if ocm.js should be excluded from optimization
  4. Verify the script is loading asynchronously as intended

Typical delay:​

Depends on how the tool caches - usually 30 minutes to 2 hours.

5. Reverse Proxy Cache (Server Level)​

What is it?​

Many hosting providers use reverse proxies (Varnish, Nginx cache) or CDNs to cache entire page responses at the server level.

Common setups:​

  • Hosting CDNs: Cloudflare (your site's own), Sucuri, StackPath
  • Server caching: Varnish, Nginx FastCGI Cache, Redis
  • Platform caching: Shopify, Wix, Squarespace built-in caching

How it affects updates:​

The entire HTML page (including script tags) might be cached, preventing the browser from even requesting the updated script.

What you can do:​

Contact your hosting provider or dev team to:

  1. Identify if a reverse proxy is in use
  2. Purge the proxy cache
  3. Check cache rules for HTML pages
  4. Verify proper cache headers are being sent

Typical delay:​

Can range from 1 hour to 24 hours depending on cache TTL settings.

6. DNS and Network Caching​

What is it?​

Less common but possible: ISP-level caching or DNS propagation delays can affect how the CDN URL resolves.

How it affects updates:​

  • Stale DNS records pointing to old CDN servers
  • ISP-level transparent proxies caching resources
  • Corporate network caches

What you can do:​

  • Flush DNS: ipconfig /flushdns (Windows) or sudo dscacheutil -flushcache (Mac)
  • Try a different network (mobile data vs. WiFi)
  • Use a VPN to test from a different network

Typical delay:​

Rare, but can be 5 minutes to 1 hour for DNS propagation.