BugWP logo BugWP
Back to Community
Home / Community / Plugin → Litespeed cache

Resolving Multi-Currency and Query String Caching Issues in LiteSpeed Cache

23 threads Sep 7, 2025 Plugin → Litespeed cache

Content

Why Caching and Dynamic Content Sometimes Clash

Many WordPress site owners using WooCommerce with multi-currency plugins or tracking marketing campaigns with query strings (like UTM parameters) encounter a frustrating problem: their LiteSpeed Cache doesn't seem to work as expected. Pages might not be cached on the first visit, currency selections reset when navigating, or the cache creates a separate copy for every tiny URL variation, bloating the cache and reducing its efficiency.

Based on common community reports, this happens because caching fundamentally relies on storing a static copy of a page to serve it quickly. Dynamic elements—like a user-selected currency, a geo-location, or a unique tracking parameter—by their nature, change the content. LiteSpeed Cache has sophisticated methods to handle this, but they require specific configuration.

Common Problems and Their Solutions

1. The Multi-Currency / Multi-Language Dilemma

The Problem: Your store supports multiple currencies or languages, but when a user switches from USD to EUR, the page doesn't update, or it always defaults back to the base currency on the next page load. The cache status often shows a 'miss' on the first visit.

Why It Happens: Caching plugins treat a single URL as one unique page. If your currency switcher only uses a query string (e.g., ?currency=EUR) or a session variable, LiteSpeed may see /product/abc/ and /product/abc/?currency=EUR as two different pages. If the switcher uses JavaScript without setting a persistent cookie, the cache has no way to know which version to serve.

The Solution: You must tell the cache how to differentiate between versions of the same URL.

  • Use the Vary Cookie Feature: This is the most common solution. If your currency plugin sets a cookie (e.g., wmc_current_currency), you can add it in LiteSpeed Cache -> Cache -> Advanced -> Vary Cookies. This instructs the server to store and serve a different cached page for each value of that cookie.
  • Check for ESI Support: For more complex scenarios, ESI (Edge Side Includes) can be enabled to dynamically inject uncachable fragments (like a shopping cart) into a cached page. Some users report success configuring custom vary rules for specific plugins like Aelia Currency Switcher in their .htaccess file.
  • Avoid PHP Sessions: As one thread highlights, if a plugin uses PHPSESSID to store currency, it creates a unique cache for every single visitor, rendering caching useless. The best practice is to use a currency plugin that relies on a single, simple cookie for identification.

2. The Query String Confusion

The Problem: Google Analytics and ads append parameters like utm_source, fbclid, or gclid to URLs. This creates countless variations of the same page, leading to a low cache hit ratio as the server tries to store a unique version of /about-us/, /about-us/?utm_source=facebook, /about-us/?gclid=abc123, etc.

Why It Happens: By default, a query string changes the URI, making it a unique resource for the cache.

The Solution: Use the 'Drop Query String' feature correctly.

  • Navigate to LiteSpeed Cache -> Cache -> Drop Query Strings.
  • Add the query parameters you want to ignore (e.g., utm_*, fbclid, gclid, _ga). The asterisk (*) acts as a wildcard for parameters like utm_source, utm_medium, etc.
  • Important Note: If you are on a hosting setup where LiteSpeed is acting as a reverse proxy (e.g., LiteSpeed ADC), this rule might also need to be configured at the server level, not just in the WordPress plugin.

3. The First Visit Cache Miss

The Problem: The first visitor to a page always experiences a slow 'miss,' and only subsequent visitors get the fast 'hit.' You want the first visitor to get a cached page too.

Why It Happens: This is standard caching behavior. A page is only stored in the cache after it is generated for the first time.

The Solution: Use the Crawler.

  • The LiteSpeed Crawler is designed to solve this exact problem. It acts as a robot that visits your site's pages to pre-build the cache before real users arrive.
  • You can configure it to simulate different cookies, which is essential for pre-caching pages in all available currencies and languages. This is often found under Crawler -> Cookie Simulation.

Key Takeaways for a Smooth Experience

  1. Identify Your Mechanism: Determine how your multi-currency or multi-language plugin works. Does it use a cookie, a query string, or a session? The solution depends on the answer.
  2. Cookie is King: For the best caching results, use a currency/language plugin that sets a simple, persistent cookie. This allows you to easily use the 'Vary Cookies' feature.
  3. Drop What You Don't Need: Aggressively use the 'Drop Query String' list for all tracking parameters to keep your cache efficient.
  4. Pre-Warm with Crawler: Don't let your visitors build your cache for you. Use the Crawler to pre-warm it for all important page variations.
  5. Check Your Environment: Some advanced settings, particularly those involving .htaccess rules, may require server-level support depending on your hosting setup.

By understanding how caching interacts with dynamic content, you can configure LiteSpeed Cache to work harmoniously with your WooCommerce store, delivering fast, accurate experiences to all your visitors, no matter where they are or what currency they use.

Related Support Threads Support