• I have a problem with LSCache running on OpenLiteSpeed server, that my enqueued main theme JS file (and probably other JS assets as well) are randomly not loading on some cached pages, causing various problems (lazy loading not working on those pages (gray placeholders), scripts not running at all, etc.).

    I have confirmed this by doing a simple console.log() on document ready event, which gets triggered on (almost) every page, instead the broken ones that don’t have JS loaded correctly.

    Here’s my JS settings in Page Optimization:

    • JS minify: ON
    • JS combine: OFF
    • JS combine external and inline: ON (but this shouldn’t have any effect since combine is disabled)
    • JS defered: OFF

    CSS seems to be loading fine everywhere, because I’m not noticing any layout/design problems. I am loading my JS assets like this:

    wp_enqueue_script( 'app-js', get_stylesheet_directory_uri() . '/assets/js/app.js', array('jquery'), TEME_VERSION, true );

    I can also see something is wrong when checking the Source tab in browser DevTools: If the page is cached correctly, I can see way more JS assets loaded in /wp-content/litespeed/js/. On incorrectly cached pages there are fewer JS files bundled/loaded.

    I’ve sent the plugin report as well, here’s the number: GJCCHNNO

    What could be causing this and how to prevent it?

Viewing 9 replies - 1 through 9 (of 9 total)
  • Plugin Support qtwrk

    (@qtwrk)

    this is weird issue

    have you tried to compare the html source code on both cases ?

    Thread Starter Kristián Filo

    (@kristianfilo)

    @qtwrk I’ve stumbled upon the broken category page again and I’ve compared the HTML source.

    The broken page is literally incomplete, it is trimmed at a random position, in the middle of a <a> link (its text) and after that there’s nothing. The text of that <a> link doesn’t even contain any special characters or anything. It seems like the build process of that static HTML page crashed at some point for some reason.

    Anyway, the part where it crashes is within the Complianz cookie banner. I’ve tried adding ‘complianz.js’ to the JS excludes, but I think this is random (and other broken pages are probably rendered up until a different part of the code).

    Anyway, some optimized CSS/JS code is being loaded after this part of the code, so that is why it’s missing from these broken pages.

    Is there a way to detect if page was optimized/built correctly and if not, attempt to optimize/cache it again?

    Plugin Support qtwrk

    (@qtwrk)

    i feel like maybe

    1. the PHP process was crashed , or terminated prematurely for whatever reason
    2. something else interfered our plugin’s output buffer function , maybe other plug also use output buffer, and flushed our buffer as well

    does it always crash on the part related to Complianz ?

    meanwhile , did you see anything in php error log ?

    Thread Starter Kristián Filo

    (@kristianfilo)

    No, I’ve noticed it fails at random parts of the page (not only during Complianz banner rendering).

    I don’t see any relevant messages in error log, except for this one message from today:

    Cron reschedule event error for hook: litespeed_task_crawler, Error code: could_not_set, Error message: The cron event list could not be saved.., Data: {"schedule":"litespeed_crawl_filter","args":[],"interval":120}

    I don’t think output buffering conflict is the issue, it would probably be more frequent. The pages are OK in 99% of cases, I’m only noticing couple of broken pages per week.

    PHP termination seems reasonable, is there any way to prevent this? I mean – to only store the cache if the page was rendered and built completely? I have Crawler enabled with these settings:

    • 500 microseconds delay
    • 500 seconds run duration
    • 120 seconds interval between runs
    • 86400 seconds (24 hrs) crawl interval
    • 4 threads
    • 30 seconds timeout
    • 2 server load limit

    Some data from the last (active) crawler that might be helpful:

    • Last complete run time for all crawlers: 16014 seconds
    • Run time for previous crawler: 16014 seconds
    • Current server load: 1.15

    I am running a VPS with 32 PHP threads available (512 MB of RAM allocated for each). These are my PHP settings (which might be relevant):

    • max_execution_time: 600 s
    • max_input_time: 60 s
    • max_input_vars: 5000
    Plugin Support qtwrk

    (@qtwrk)

    wait , please disable HTML minify , I see a case before certain html content may crash the HTML minify library that could potentially leave a weird or incomplete content , maybe it’s related.

    Thread Starter Kristián Filo

    (@kristianfilo)

    I disabled it. I’ll keep an eye on it and will update the thread with either result. Could you please leave the thread opened until then? Thank you.

    Plugin Support qtwrk

    (@qtwrk)

    certainly

    Thread Starter Kristián Filo

    (@kristianfilo)

    Hi @qtwrk , I can confirm the issue still persists after disabling HTML minify.

    Plugin Support qtwrk

    (@qtwrk)

    well , be honest I am not sure what else to look at this point

    this is kind of long shot , but let’s give it a try

    please go to debug setting , enable debug log , log level to advance, log size to 300MB , now try to reproduce again , and hopefully we can catch the log on a broken request

Viewing 9 replies - 1 through 9 (of 9 total)
  • You must be logged in to reply to this topic.