Header elements delaying whole site

We'll definitely keep an eye out for any similar issues. Let us know if you find anything that may help :)

Thanks!

I certainly will. I imagine that for Generatepress, which takes a justifiable pride in speed and simplicity, this can be an awkward issue if it is inherent in something. I hope someone can identify it closer.

One further point. For me the issue started after an update of WP to 5.8. What I first noticed was <h2> headings that were blue instead of red, and left-justified, not centered in a coulmn. My colleague found the way to place the uploads/generatepress/style.min.css file (I don't know how), and the formatting reverted to normal but the timing problem arose (it may have been there, masked by our fixation on the formatting).

Now on our older site, if I go in Customiser/General and assign css to a file rather than inline, these formatting problems arise the same (so I have left it as inline). This site has not created a css file in uploads, I expect placing one there will fix this, but a manual placing surely can't be what was intended. I don't know if anyone else has had this problem?

Strange - we haven't received any reports of issues with the file. In fact, we're using it here on this site as well.

As a test, what happens if you click the Regenerate CSS file button in Customize > General when it's set as External File? Any change?

Precisely no, that's what's unexpected. Setting the customizer to css file did not create one, nor did pressing the regenerate button. The headings colour problem then showed. But if I manually create the folder in uploads and place the css file from the other site, then the problem is gone. For now I left it as inline.

(The .rs site is now set to redirect to the .com site, since the latter is working acceptably now and I don't want to cause confusion with 2 almost identical sites, so it's inaccessible online, but I can get it activated again if it serves a diagnostic purpose.)

It's possible that your server isn't allowing the CSS to properly write to the file in that folder. Can you confirm that the file exists and has CSS inside of it?

Ah, now I think you have hit on something serious. My host is a small local one run by our IT expert, who is security-crazy. This can be a good thing, but indeed it may be an issue. I have to investigate. Clearly, if the plugin doesn't have permission to create a folder, then this will go wrong when I set css to file. This would explain the formatting issue.

But it would appear to have no influence on the timing issue in which page-irrelevant headers slow up server response backend time. Surely other people have sites with many pages, and unique headers on each page? Do they experience this slowdown?

No, your report is the first one we've had when it comes to slowdowns like this. It's hard to know exactly what the cause is without a detailed performance report using something like New Relic.

If there's a lot of security, I'm willing to bet the file isn't being generated/written to. If that's the case, there really isn't any harm in just using the Inline option.

Guys, I think this is solved. Since I put the css back inline, the timing issue has disappeared.

It was the fact that the plugin did not have permission to create a folder that started it. It is allowed to write to a file, but not to create a folder. So when it was set to 'css to file', there was no file since there was no folder, and the result seems to have been that it spent a long time working this out every time a page was requested. Why it needed to somehow 'visit' every header element to do this is a mystery, but that is what it must have done, since for any one page, the latent response time was directly proportional to the number of active page header elements on the site.

Thanks again for your support in solving this!

Glad it's all working now - thanks for reporting back! :)

:)