Accessibility Statement Caching Explained

Overview

AllAccessible uses performance caching to deliver your accessibility statement quickly to visitors worldwide. This guide explains how caching works, why updates take up to an hour to propagate, and how to manage cache effectively.

Who This Is For

Technical users managing accessibility statements
Anyone needing immediate statement updates
Users troubleshooting statement display issues

What You'll Learn

How statement caching works
Why propagation takes up to 1 hour
How to force cache updates when needed
Troubleshooting cache-related issues

How Statement Caching Works

The Multi-Layer Cache System

AllAccessible uses three caching layers to optimize performance:

┌─────────────────────────────────────────────┐
│  Layer 1: Database (Instant)                │
│  Your edits save here immediately           │
└────────────────┬────────────────────────────┘
                 │
                 ↓
┌─────────────────────────────────────────────┐
│  Layer 2: Server Cache (1 hour TTL)         │
│  API responses cached for fast delivery     │
└────────────────┬────────────────────────────┘
                 │
                 ↓
┌─────────────────────────────────────────────┐
│  Layer 3: Browser Cache (24 hour TTL)       │
│  Visitor's local storage cache              │
└─────────────────────────────────────────────┘

Layer 1: Database Storage (Instant)

What Happens When You Save

Action: You click "Save Statement"

Immediate Effects:

Statement HTML saved to database
Timestamp updated (updated_at field)
Success message displayed
Changes visible in dashboard immediately

Database Fields Updated:

statement (text field with HTML content)
updated_at (current timestamp)
statement_version (incremented)

Time: Instant (< 1 second)

Layer 2: Server-Side Cache (1 Hour)

How Server Caching Works

Purpose: Fast API responses without database hits

Implementation:

// symfony/src/Controller/APIController.php line 484-485
$cacheKey = 'statement_lookup_' . md5($accountID . '_' . $pageUrl);
$statement = $cache->get($cacheKey, function() {
    // Fetch from database if cache miss
    return $subdomain->getStatement();
});

Cache Duration: 60 minutes (3600 seconds)

What This Means:

API returns cached version for up to 60 minutes
After save, old version served until cache expires
Cache key specific to each account + page combination

Cache Expiration Process

Timeline After Save:

0-5 minutes: Most servers still serving old cached version
5-30 minutes: Some servers expired, serving new version
30-60 minutes: Majority of servers serving new version
60+ minutes: All servers guaranteed to have new version

Why Variable?

Multiple servers worldwide
Cache expiration not perfectly synchronized
CDN nodes expire independently

Worst Case: 60 minutes until 100% propagation

Layer 3: Browser Cache (24 Hours)

Local Storage Caching

Purpose: Instant loading for repeat visitors

Implementation:

// widget-v2/src/components/modal/AccessibilityStatement.ts line 181-202
private getCachedStatement(): string | null {
  const cached = localStorage.getItem('accessibilityStatement');
  const cacheData = JSON.parse(cached);
  const cacheAge = Date.now() - cacheData.timestamp;
  const maxAge = 24 * 60 * 60 * 1000; // 24 hours  if (cacheAge < maxAge && cacheData.accountId === this.config.accountId) {
    return cacheData.content; // Return cached version
  }
}

Cache Duration: 24 hours

What This Means:

Repeat visitors see cached version for up to 24 hours
New visitors always fetch from server
Cache specific to each visitor's browser
Each browser session independent

How Browser Cache Affects Updates

Scenario: You update your statement at 2:00 PM

Visitor Timeline:

Visitor A (accessed at 1:00 PM): Sees old version until 1:00 PM next day
Visitor B (first visit at 3:30 PM): Sees new version (after server cache expires)
Visitor C (accessed at 10:00 AM): Sees old version until 10:00 AM next day

Key Point: Browser cache is per-visitor, not global!

Complete Propagation Timeline

Realistic Update Scenario

You save statement at 2:00 PM on Monday:

Time	Status
2:00 PM	Saved to database ✅
2:01 PM	Visible in your dashboard ✅
2:05-3:00 PM	Server cache updating ⏳
3:00 PM	Server cache fully updated ✅
3:00 PM-2:00 PM Tuesday	Browser caches expiring gradually ⏳
2:00 PM Tuesday	100% propagation complete ✅

Conservative Estimate: 24 hours for all visitors to see updates
Realistic for Most: 1-2 hours for most new visitors

Force Cache Update (When Needed)

Method 1: Wait for Natural Expiration (Recommended)

Best For: Non-urgent updates

Process:

Save your changes
Wait 60 minutes
Verify on live site
Done!

Pros:

✅ No action needed
✅ Works automatically
✅ No risk of issues

Cons:

⏰ Takes up to 60 minutes

Method 2: Manual Cache Clear (Testing Only)

Best For: Verifying your changes immediately

Process:

Save your statement
Hard refresh browser:
- Windows: Ctrl+Shift+R
- Mac: Cmd+Shift+R
Or use incognito/private mode

Pros:

✅ Immediate verification for you
✅ Good for testing

Cons:

❌ Doesn't help other visitors
❌ They still see cached version

Method 3: Emergency Cache Purge (Urgent Only)

Best For: Critical errors requiring immediate fix

Process:

Save your corrected statement

Email [email protected]:

Subject: Urgent: Cache Purge RequestAccount ID: [Your Account ID]
Reason: [Critical error description]
Time Sensitivity: [Why immediate update needed]

Support manually purges server cache
Changes propagate within 5-10 minutes

When to Use:

❌ Typo fix (wait naturally)
❌ Minor wording update (wait naturally)
✅ Incorrect legal information
✅ Wrong contact details
✅ Settlement deadline
✅ Critical factual error

Support Response Time: Within 1 hour during business hours

Why We Use Caching

Performance Benefits

Without Caching:

Database query on every widget load
Slower response times (200-500ms)
Higher server costs
Risk of database overload

With Caching:

Instant responses (<50ms)
Reduced database load
Lower costs
Better user experience

Real-World Impact

Example: Site with 10,000 daily visitors

Without Cache:

10,000 database queries per day
10,000 × 300ms = 3,000 seconds of wait time
Cumulative: 50 minutes of visitor waiting

With Cache:

1 database query per hour
24 queries per day
Near-instant delivery
Cumulative: ~2 seconds of visitor waiting

That's 1,500x faster!

Troubleshooting Cache Issues

Issue: Updates Not Appearing After 1 Hour

Diagnostic Steps:

1. Verify Save Completed

Check dashboard for success message
Refresh dashboard, verify changes there
Check browser console for errors

2. Check Cache Status

Has it been a full 60 minutes?
Check server time vs. your local time (timezone!)

3. Test Fresh Browser Session

Open incognito/private window
Visit your site
Check widget statement

If Still Not Updated:

Email support with Account ID
Include timestamp of when you saved
Support can investigate cache status

Issue: Different Visitors See Different Versions

This is Normal!

Cause: Browser cache varies by visitor

Visitor A (visited 30 min ago): Old version (browser cache)
Visitor B (first visit now): New version (fresh fetch)
Visitor C (visited 2 hours ago): Old version (browser cache still valid)

Solution: Wait 24 hours for complete uniform propagation

Issue: Dashboard Shows Update But Widget Doesn't

Cause: Server cache lag

Timeline:

Dashboard reads directly from database (instant)
Widget uses API (cached up to 1 hour)

Solution:

This is expected behavior
Wait 60 minutes
Not a bug

Cache Strategy for Different Situations

Regular Maintenance Updates

Scenario: Quarterly statement review

Strategy:

Schedule updates during low-traffic times
Save all changes in one session
Use natural cache expiration
Verify next business day

Timeline: 24-hour propagation is fine

Time-Sensitive Updates

Scenario: Settlement deadline requires updated statement by 5 PM

Strategy:

Make updates by 3 PM (2-hour buffer)
Email support for emergency cache purge
Verify by 4 PM
Screenshot for documentation

Timeline: Need 1-2 hour guaranteed propagation

High-Traffic Update

Scenario: Major announcement or media coverage expected

Strategy:

Update statement 24-48 hours BEFORE announcement
Allows full cache propagation
Verify across all devices
No rush, no emergency purges needed

Timeline: Proactive 24-48 hour advance update

Cache Monitoring

How to Check Cache Status

Method 1: Browser Network Tools

Open browser DevTools (F12)
Go to Network tab
Refresh page
Find statement API request
Check response headers:
- Cache-Control: max-age=3600 (1 hour)
- Age: 1234 (how old cache is in seconds)

If Age is close to 3600: Cache about to expire

Method 2: Testing Across Browsers

Different browsers = different caches:

Test in Chrome (your main browser)
Test in Firefox (independent cache)
Test in Safari (independent cache)

If Firefox shows update but Chrome doesn't → Chrome's browser cache

Method 3: Incognito Mode

Always fetches fresh version:

Open incognito/private window
Visit your site
Check statement

If incognito shows update → Server cache updated
If incognito shows old → Server cache not expired yet

Best Practices

1. Plan Ahead for Important Updates

Don't wait until the last minute:

Legal deadlines: Update 48 hours early
Public announcements: Update 24 hours early
Regular reviews: Flexible timing okay

2. Batch Your Edits

Make all related changes in one session:

Reduces cache churn
More efficient workflow
Less confusion about what's live

3. Document Update Times

Keep a log:

2025-10-01 2:30 PM: Updated contact email
- Expected propagation: 3:30 PM
- Verified at: 3:45 PM ✅

4. Test Multiple Ways

After updates:

Different browsers
Incognito mode
Mobile devices
Different network connections

Common Questions

Q: Why not just disable caching for statements?
A: Caching provides 1,500x faster loading. The performance benefit far outweighs the 1-hour delay.

Q: Can I pay for faster cache updates?
A: No, but support provides emergency purges for critical issues.

Q: Why 24 hours for browser cache?
A: Balances freshness with performance. Statements don't change daily, so 24-hour cache is appropriate.

Q: What if I need same-day updates guaranteed?
A: Email [email protected] for emergency cache purge capability. Explain your use case.

Q: Do competitor platforms have instant updates?
A: Most use similar caching (15 minutes - 2 hours). Instant updates sacrifice performance.

Technical Details (For Developers)

Cache Key Format

$cacheKey = 'statement_lookup_' . md5($accountID . '_' . $pageUrl);

Components:

Prefix: statement_lookup_
Hash: MD5 of account ID + page URL
Example: statement_lookup_a1b2c3d4e5f6...

Why Hashed: Unique key per site, prevents collisions

Cache Invalidation

Automatic:

Expires after 60 minutes (TTL)
No manual invalidation needed normally

Manual (Support Only):

// Clear specific statement cache
$cache->delete($cacheKey);// Clear all statement caches (nuclear option)
$cache->clear('statement_lookup_*');

API Response Headers

Cache-Control: public, max-age=3600
Age: 245
X-Cache-Status: HIT

Meaning:

max-age=3600: Cache valid for 1 hour
Age: 245: Cache is 245 seconds old
X-Cache-Status: HIT: Served from cache (not database)

Creating and Publishing Your Accessibility Statement - Writing and publishing your statement
Editing Your Statement - Making changes
Updating Your Statement - Maintenance guide

Last Updated: October 2025
Server Cache TTL: 60 minutes
Browser Cache TTL: 24 hours
Emergency Purge: Available through support

Accessibility Statement Caching Explained

Accessibility Statement Caching Explained

Overview

Who This Is For

What You'll Learn

How Statement Caching Works

The Multi-Layer Cache System

Layer 1: Database Storage (Instant)

What Happens When You Save

Layer 2: Server-Side Cache (1 Hour)

How Server Caching Works

Cache Expiration Process

Layer 3: Browser Cache (24 Hours)

Local Storage Caching

How Browser Cache Affects Updates

Complete Propagation Timeline

Realistic Update Scenario

Force Cache Update (When Needed)

Method 1: Wait for Natural Expiration (Recommended)

Method 2: Manual Cache Clear (Testing Only)

Method 3: Emergency Cache Purge (Urgent Only)

Why We Use Caching

Performance Benefits

Real-World Impact

Troubleshooting Cache Issues

Issue: Updates Not Appearing After 1 Hour

Issue: Different Visitors See Different Versions

Issue: Dashboard Shows Update But Widget Doesn't

Cache Strategy for Different Situations

Regular Maintenance Updates

Time-Sensitive Updates

High-Traffic Update

Cache Monitoring

How to Check Cache Status

Best Practices

1. Plan Ahead for Important Updates

2. Batch Your Edits

3. Document Update Times

4. Test Multiple Ways

Common Questions

Technical Details (For Developers)

Cache Key Format

Cache Invalidation

API Response Headers

Related Articles