Cache Settings

Advanced storage configuration capabilities enable greater flexibility and precision in managing how data is cached and updated within browser environments.

These enhanced options allow developers to fine-tune storage behavior by specifying which mechanisms to use (such as localStorage(default), sessionStorage, or IndexedDB), as well as defining custom rules for cache invalidation and refresh intervals. This level of granularity not only improves application performance by reducing unnecessary data fetches but also ensures more predictable and efficient control over data persistence and cache lifetimes, leading to a more responsive and consistent user experience.

Key Features:

1. Custom ttl (Time To Live) Option
   • The ttl setting allows to specify how long the settings should remain valid in the storage. If not specified, the default TTL is set to 2 hours. This helps in controlling the frequency with which settings are refreshed from the server.
     Note - The TTL value is specified in milliseconds.
   • This is especially useful when you want to limit the frequency of network requests and instead rely on cached settings for performance.
2. alwaysUseCachedSettingsOption
   • When enabled, the SDK will always use cached settings, regardless of the TTL value. This means the settings stored in the browser will be used even if they have expired based on the TTL.
   • By default, this option is disabled. If disabled, the SDK will check the TTL and refresh settings as per the specified interval.
3. Background Refresh
   • When valid cached settings are returned and the TTL has not expired, the SDK will use the cached settings immediately. While doing so, it will asynchronously refresh the settings in the background. This helps in ensuring the settings are up to date without introducing delays in loading or performance bottlenecks.

Benefits

• Improved Performance: By customizing the TTL and cache usage, you can optimize how often settings are fetched from the server, reducing unnecessary network requests and improving load times.
• Better Control: You can fine-tune how settings are stored and refreshed, ensuring that your application behaves exactly as needed depending on the environment and the use case.
• Flexible Caching: It allows for a balance between always using fresh settings and reducing the reliance on server fetches, giving you more control over your caching strategy.
• Non-Blocking Updates: The background refresh feature ensures that the user experiences no delay in getting the settings, while the SDK silently keeps them updated in the background.

Configuration Parameters

Usage

const vwoClient = await init({
  accountId: '123456',
  sdkKey: '32-alpha-numeric-sdk-key',
  clientStorage: {
    // Custom key used to store SDK data, default is 'vwo_fme_data'
    key: 'vwo_data',
    
    // Use cached settings regardless of TTL, defaults to false
    alwaysUseCachedSettings: true,
    
    // Custom TTL value in milliseconds (1 hour), defaults to 2 hours
    ttl: 3600000
  },
});

Flow

The diagram outlines how the VWO FME JavaScript SDK manages settings using configurable caching options:

flowchart TD
    A[Initialization] --> B[Set Options: TTL, alwaysUseCachedSettings]
    B --> C{alwaysUseCachedSettings == true?}

    %% If alwaysUseCachedSettings is true
    C -->|Yes| D[Use Cached Settings]
    D --> E[Fetch Fresh Settings in Background]
    E --> F[Update Cache with New TTL]
    
    %% If alwaysUseCachedSettings is false
    C -->|No| G{Is TTL Valid?}

    G -->|Yes| D[Use Cached Settings]
    
    G -->|No| K[Fetch Fresh Settings Immediately]
    K --> L[Store in Cache with New TTL]
    L --> M[Use New Settings]

    classDef init fill:#bbf,stroke:#333,stroke-width:1px,color:#000;
    class B init;

1. Initialization – The SDK is initialized with options like:
   1. Custom TTL: Defines how long cached settings are valid.
   2. alwaysUseCachedSettings: Forces the SDK to always use cached data.
   3. Background Refresh: Allows settings to be refreshed asynchronously.
2. TTL Logic – Checks if cached data is still valid:
   1. If valid: Use cached data and refresh in the background.
   2. If expired: Fetch fresh data and update the cache.
3. alwaysUseCachedSettings Logic – Bypasses TTL:
   1. If enabled: Always use cached data.
   2. If not: Fallback to TTL logic.
4. Background Refresh – Ensures the app uses available cached data immediately while updating it in the background for freshness.