Unpredictable js caching issue

  • Resolved frenchomatic

    (@frenchomatic)


    3 weeks, 4 days ago

    I have an unpredictable caching issue which is hard to track down.

    I have a sticky menu header with a white background which shows when I scroll the page. When the page first loads the menu background is transparent.This is the correct behaviour. It never fails when in development mode on cloudflare or when logged in. What seems to happen is some time later, perhaps hours or even days, the page (not logged in and cached) no longer shows the transparent menu background but instead it behaves like it has already scrolled down to give a white background. I can roll up or down but still the white background remains fixed. The javascript which inserts a transparent menu is not firing.

    WordPress 7.1.2 WP Bakery 9.0.1 Super page cache 5.3.5

Viewing 5 replies - 1 through 5 (of 5 total)
  • Plugin Support rodicaelena

    (@rodicaelena)

    3 weeks, 3 days ago

    Hi there,

    Thanks for reaching out! To help us investigate and pinpoint what’s causing the issue with your sticky header, could you please provide a few additional details?
    1. What JS optimization options (such as JS Minification, Delay JS, or Defer JS) do you currently have enabled in Super Page Cache or other caching/optimization plugins?
    2. Does the issue persist if you temporarily exclude your theme’s sticky header JS script from optimization/caching?
    3. If possible, could you share the URL of the affected page along with any JavaScript errors shown in your browser console when the issue occurs?

    Once we have these details, we can guide you on the right configuration or investigate further!

    Thread Starter frenchomatic

    (@frenchomatic)

    3 weeks, 3 days ago

    Hi I am using auto-optimize but it has been doing it for some time (so a few super cache versions now but I ignored it and just cleared the cache manually – the site wasn’t doing much). The problem started before automatise was installed – it does it even if I deactivate autoptimze.

    Don’t know about deactivating the sticky header – I will try it and report back. I suspect it wont because the menu background is now transparent all the time.

    No javascript or php errors.

    Thread Starter frenchomatic

    (@frenchomatic)

    3 weeks, 3 days ago

    ok I can confirm it is caching the wrong header even when the sticky menu is turned off.

    This css selector on line 327 should be getting displayed from this

    @media only screen and (min-width: 1018px){
    #header.transparent_header:not(.scrolled) { background: rgba(0, 0, 0, 0); }#header.transparent_header:not(.scrolled) { -webkit-box-shadow: none;-moz-box-shadow: none;box-shadow: none; }

    instead it is showing on line 1256 of the css file

    #header{
    position: fixed;
    display: block;
    margin: 0 auto;
    top: 0px;
    left: 0px;
    right: 0px;
    background: #fff;
    box-shadow: 0 0 0 1px rgba(0, 0, 0, 0.05);
    -moz-box-shadow: 0 0 0 1px rgba(0, 0, 0, 0.05);
    -webkit-box-shadow: 0 0 0 1px rgba(0, 0, 0, 0.05);
    z-index: 499;
    -webkit-transition: top 0.1s ease-out, background-color 0.6s ease;
    -moz-transition: top 0.1s ease-out, background-color 0.6s ease;
    -ms-transition: top 0.1s ease-out, background-color 0.6s ease;
    -o-transition: top 0.1s ease-out, background-color 0.6s ease;
    transition: top 0.1s ease-out, background-color 0.6s ease;header
    }

    I will deactivate autoptimze and test just in case I am wrong but it would be strange that it never does it when logged in so caching isn’t present. If you have a support email I can share the site and details with you. .

    • This reply was modified 3 weeks, 3 days ago by frenchomatic.
    Thread Starter frenchomatic

    (@frenchomatic)

    3 weeks, 2 days ago

    Solved : caching was not the root cause but wp_mobile() on safari which was playing tricks. It is not a reliable method for themes to detect mobile views. Better to use it in combination with javascript to set the css class based upon viewport. I guess an incorrect mobile menu (the solid background css rule) was getting cached at mobile and displayed in desktop.

    • This reply was modified 3 weeks, 2 days ago by frenchomatic.
    malexandric

    (@malexandric)

    3 weeks, 2 days ago

    Hi @frenchomatic,

    Thanks for following up and for sharing the root cause, that is very useful for other readers.

    Your conclusion matches how the cache works. Super Page Cache stores one copy of the HTML per URL, and Cloudflare’s edge does the same per data centre. The cache does not look at the visitor’s device or browser. If the theme decides the header markup or CSS on the server with wp_is_mobile(), the first visitor after a purge determines which version gets stored, and everyone else at that data centre receives it until the next purge. That is why it looked random and why logged in or Development Mode views were always right, since those bypass the cache.

    Any server side device check has this effect with full page caching, so the safest approach is the one you took: output the same HTML for everyone and let CSS media queries or a small script apply the mobile styling in the browser.

    Glad it is sorted. If anything else comes up, let us know.

Viewing 5 replies - 1 through 5 (of 5 total)

You must be logged in to reply to this topic.