Missing stylesheets referenced in HTML – race condition?

Hi @schwipps

I thought you already regenerated Elementor’s CSS files as part of your deployment process.

What I have found is that not doing so is helping.

Mmh… To my understanding, this could mean that Elementor’s CSS is just not always generated in time after the deployment process. So that the pages sometime render without it. This coincides with what I observe when comparing a single page that’s broken, and the same after (succesfuly) clearing the page and reload it: the only difference is the Elementor CSS not being missing in the latter.

On the other hand, if the Elementor CSS is kept over the deployment process, then it’s already available for delivery when the page is called. So no issue.

What do you think?

@schwipps I think the same, it’s something like that.

Then I had an idea – what if I add the “–regenerate” switch to the command I am using:

wp elementor flush-css --regenerate

Which not only removes the old files, but creates the new ones immediately, before I flush the W3TC page cache. I really thought I’d cracked it, but then the issue persisted. So now I am just trying without the flush at all. The problem is that flushing Elementor’s CSS is often a way to cure other problems.

Sidenote in case it’s useful to you, Elementor has acknowledged that the placement of linked stylesheets in the HTML from initial page load to subsequent page load differs.

OK. Then, one thing that’d worth a try, would be to maintain Elementor’s CSS, which is obviously cleared along the object cache?

• This reply was modified 2 weeks ago by T4ng.

I have tested with the object cache completely disabled (and the object cache PHP file removed) and with it enabled and it doesn’t seem to make any difference to this issue.

Mmh, you’re right, we already checked that the issue occured with only the page cache enabled. So this might be cached somewhere else.

I know that Elementor’s “flush-css” command removes the stylesheets from wp-content/uploads/elementor/css and also clears some entries from the database but I have no idea why asking it to generate the files fresh and then clearing the W3TC cache still causes the issues but not flushing Elementor’s cache at all appears to work fine.

@schwipps @vmarko

One issue I can definitely reproduce is this: When Elementor’s CSS files are “regenerated” by default that means they are removed until a page comes along and requests them. Immediately after a “regeneration” if we clear the W3TC page cache and that cache is fresh enough, for the next 30 seconds W3TC serves us the “old” version of the HTML which now includes links to missing stylesheets.

Hi @jamieburchell,

What you’re explaining here makes sense: if after clearing the W3TC page cache, the old html version is still served for 30 seconds, then there’s a good chance this leads to problems.

@jamieburchell , have you tryed remonvend this 30 seconds availability instruction from the code, to see if it makes any difference at all?

@vmarko we haven’t heard from you for a while on this topic, while your input could be really useful.

• Can you please explain why the HTML remains available for 30 seconds after clearing?
• Do you think, based on our finding, there’s a chance this is what causes this issue?
• If so, is there an option/solution/idea of a workaround, to suspend it?
• Maybe there’s something here, that’s worth a chat with Elementor?

Thanks

@schwipps What I said about the old version of the HTML being served for 30 seconds is not quite correct. The old version of the HTML is served if it is no more than 30 seconds old. So, the old version of HTML could be served for you for 30 seconds if it is still quite fresh. Of course, when I was testing things by repeatedly clearing caches I was triggering this behaviour.

I’m not quite sure why W3TC does this. It was said that it was done to keep the website online. Perhaps it’s to allow enough time for a new HTML page to be generated while visitors can continue to get the older page. But, a new page would need to be generated and served if the old version was created more than 30 seconds ago anyway, so I’m not sure that reasoning stacks up?

Ok, understood.

Still, while being pertinent, this trick obviously seems to be an issue here, since serving that page when the newer one is too long to generate… get it in the cache, and served until next generation. Which might take a while.

It will definitely cause an issue for us because the stylesheets referenced in that old HTML are no longer available. However, I don’t think that’s the only issue here. I did try removing the code responsible for serving the old HTML and while it “fixed” the problem for that 30 second window I still encountered the broken page issues outside of that window. I will try again if I get some time.

Hello @jamieburchell @schwipps

Sorry for the late reply. Notifications for topics updates sometimes do not come through.
Is it possible if someone can share the entire Performance>Page Cache settings page?
We have tried and tried to replicate this however, no avail. It’s just something that may be related to some other things besides these two options

Possible some small tweak is needed so I would like to see the settings you have in Page Cache

Thanks!

Hi @vmarko,

Here is my page cache config page screenshot.

Can you please clarify why these 30 seconds?

Thank you

• This reply was modified 1 week ago by T4ng. Reason: Adjust screenshot link

Hi @vmarko

Here’s mine

Are you regenerating Elementor’s CSS before you clear the W3TC caches? That’s what appears to be causing the issues.