Site logo

Archived topic

Header elements delaying whole site

39 replies · Started by John David on July 30, 2021

Viewing posts 16–30 of 40

Hmmm... nope :)
Would it be possible to get temporary admin access to the site so i can take a look ?
You can share URL / Login in the Private Information field.

Oh dear. You mean you could not access these things on Googledrive?

I'd love to give you admin access. It's just that our host is a small local company run by a very determined security freak - his method is to allow access only to specified IP addresses. If you can give me the IP address you will use, I can get him to write that into the exceptions, then you will have full access.

If you can't do that, I'll talk to him about it, and see if there is another way.

OK, the other way is if I give you access via Teamviewer. That way you can see as I do the files on the host server, and the WP admin access.

We'd just need to agree a time, then I can send you Teamviewer access code. What time zone are you in?

Would that work?

Ok sorry about that - i fixed the issue my end with getting the Google drive images.
So everything in the header element is static content....
Which is fine if it were for one or two pages or posts.

Are the majority of the header elements for your single posts ? If so can you enable one and share a link so i can see what that is outputting ?

I enabled headers on 3 pages:
https://halifax-translation.com/translation-rates/
https://halifax-translation.com/technical-translation/
https://halifax-translation.com/computer-assisted-translation/

Yes, all static content. Each header element is for a page (I have not got round to that for blog posts). The idea is that the header image gives a powerful idea of what the page is about.

When you say "fine if it were for one or two pages or posts", remember that it WAS fine for all pages each with its own header, until this suddenly happened.

Thanks for your patience!

Its hard to explain why the issue 'just' started to occur. But my thinking is that the large number of Elements and their conditions could definitely be an issue with the server having to process that many conditional requests.

Having many static header elements probably not an issue, but when you get into 100's and consider there is also WPML conditions to run and those Hook Elements it could be a case that one more element tipped the scales.

For your Pages - do you have a Featured Image assigned to them? And is the Text over the Image the Post Title ?

There is a featured image assigned each page, which is blocked in the header specification. Perhaps I should remove the featured image? Is there any advantage to having it? I just did it without thinking.

The text over the image has an <h1> on each page (on some, e.g. the home page, there are also <h2>s. The Title in the post list is sometimes different - is there any advantage in having the title the same as the <h1> heading?

I added the keywords hooks on the advice of a SEO guy, but I'm not sure they have any value. I can remove them.

I guess the tipping point theory may be right, but then... The first server response time is directly proportional to the number of headers. When I had cut out half of them, the time was halved. 3/4 - 3/4 etc. Clearly, every active header is somehow in play before the server responds to the first request for a page. This makes quite a different execution to what it was before, when every page loaded as if the others (and other headers) did not exist (and I assume that is how it ought to work).

Now, I thought I would try once more to replace all the operating files: WP 5.8 (which should be stable by now I hope), Generatepress theme (latest is 3.04, I had 3.02 before), and latest generatepress plugin. Then I could try activating headers one by one. Surely, if I can see then that adding headers makes response time for a specific page slower after, say, 20 headers, then the same something must be wrong. Do you think that can be a good trial to make?

The direction i was going was this:

1. Create a Header Element.
2. In the Page Hero Text field add this code <h1>{{post_title}}</h1>
3. Set the Background Image to Featured Image.
4. Set the Padding to the same settings you have in your existing header elements for Pages.
5. Set the Display Rules to Pages > All Pages.

That single Header Element will then dynamically display the Featured Image and Post Title of the Current Page.
That one header element can replace 100+ header elements.

Ah, now that sounds like a great trick, very economical. Then I can set as featured image the same image I had as a header image before. This sounds like a good thing to do in any case. Thanks.

Now, that may avoid the problem, by calling only one header. However, if there is something wrong that is making this strange "call-them-all" effect, it will still be there, won't it? Still applying to any other hooks or header elements I may want to place. I'm wondering if there is a way to check further by what I was suggesting before I implement this great get-around for the hero images.

If I replace WP, theme and plugin, what is left? Only the database?

I can't actually understand what is causing the issue, as a few elements should not have any noticeable effect on performance.

You may want to install the Query Monitor plugin, which will give you some diagnostics on what 'functions' are creating those queries, it could be some other process interfering with it.

No, it's a very strange thing that's happening. Thanks for the idea, I'll give this plugin a try. I have a few things to work on now, I'll let you know as soon as anything becomes clearer.

Thanks a million for your help!

You're welcome - let us know how you get on.

This is driving me crazy.
Query Monitor looks like a good tool, but I'm not clued up enough to use it properly.

May I ask:

On our .com site, there is a folder in the uploads folder called uploads/generatepress. It contains one file, style.min.css, of 10.4kB. Should that be here?

If I remove this folder, I get the same problems with formatting (wrong, unstable colours) that spontaneously happened at the start of the problem.

On our .RS site (older than the problem), there is no generatepress folder in the uploads folder. The file style.min.css (26.8kB) is in the generatepress 2.4.2 theme root folder.

On COM site, generatepress theme 3.04 root folder has no style.min.css file.

(Both sites have style.min.css files in the themes/generatepress/assets/css folders)

Question: What css files should be where?

If I copy the complete Gpress theme from the functioning .RS site to the .COM site and activate, I still get the formatting problem unless I also have uploads/generatepress/style.min.css, even though there is now style.min.css in the 2.4.2 theme root folder.

I think the slow download problems began when my colleague (gone on holiday) did something to this uploads/generatepress/style.min.css file. It solved the formatting problems. (But perhaps I am wrong and the timing problems arose at the same time as the formatting problems, and we did not notice at first.)

The .RS site loads in minimal time, even with 147 published elements: reducing this number does not make it any faster, so it seems to be working properly, like the .COM site did before.

Hi there,

The stylesheet in the uploads/generatepress folder is your dynamic CSS built using the options in the Customizer.

It's not required as long as you set the Dynamic CSS Print Method to Inline Embedding in "Customize > General".

Does anything stand out in Query Monitor? Any errors? Slow queries?

This is interesting, good to know.
I refreshed that file, and the problem seems considerably reduced. With all the headers active (but none of the hooks), the initial backend duration is now down to 1.2 seconds. It is still dependent on the number of headers for other pages, but much less so. This means the site can function, which is fantastic (I had already resigned myself to rebuilding the site on the older one, which seems not to have this problem).

This lets me concentrate on other opening time reductions, like the rather elegant approach David suggested. The conundrum of headers for uncalled pages affecting the load time of the called one remains, but it's now manageable.

Thanks a million for your support and suggestions. If ever you have any idea about why an uncalled header should cause delay, I'd love to hear about it. I'll try and research it further myself, but I don't think I have the expertise to get very far.

This archived topic is closed to new replies.