Slow site

[Steve Pierce]

We've received many reports over the past few weeks that www.mediasanctuary.org is responding very slowly, at times not at all. We're not sure why this would be happening. Would it be possible to look into this for us?

[JaimeV]

Hi. Sorry for the delayed repsonse. I've looked into this and I don't see ny of the usual indications that the server where the site is hosted claudette has been under any stress. That doesn't mean your individual site has not been having trouble for some reason. I'm scanning the logs to see if anything is amiss. Can you tell us anything else about whether this is happening at particular times of the day? One thing we can do proactively is route the site through our nginx caching server which can really help speed up the site.

[update]

After scanning the logs I see one particular ip number has been hitting the site's login continously. It has been doing it just slow enough to not to trigger being blocked by our intrusion protection mechanism. Our nginx caching server also gives us a few more tools to limit this kind of behaviour. Would you like us to go forward with helping you make that change?

[Steve Pierce]

We'd much appreciate anything you can do!

[Steve Pierce]

BTW, I also asked Roger to take a look at the problem. This is what he found:

Ran all the WordPress updates. Let me if that helps at all. You-all have added a considerable number of complex plugins and that may have an effect on site performance. But looking at the error log and doing a bit more research the slowdown may be due to attacks on the site being warded off by WordPress. There are many instances of this error:

[Thu Nov 12 14:44:03.397611 2020] [access_compat:error] [pid 1471:tid 139663688709888] [client 204.197.178.82:50553] AH01797: client denied by server configuration: /home/members/nyma/sites/mediasanctuary.org/web/xmlrpc.php

I'll look into things more later today or tomorrow.

Roger

[JaimeV]

I've made the switch to route mediasanctuary.org through our caching server. Let us know if over the next few hours you begin to notice any difference and please ask your team to test different parts of the site, submission forms etc... to help ensure everything continues working as it should.

[JaimeV]

I also want to point out something a little more basic.

The two largest files that have to be downloaded to load the homepage are these:

​https://www.mediasanctuary.org/wp-content/uploads/2020/08/1.png

​https://www.mediasanctuary.org/wp-content/uploads/2020/10/2.png

Together these are almost 5MB of file download for a homepage load. That is a lot and is sure to slow down you home page no matter what we do. You should really consider replacing these two files with more compressed jpg versions. You will see a big difference.

[Steve Pierce]

OK--thank you!

[Steve Pierce]

Thanks for the tip on the homepage images. We've replaced them with much smaller files.

We've been checking various site elements and working on page updates. The site is still V E R Y slow today!

[https://id.mayfirst.org/mswp]

hi JaimeV

1) Routing mediasanctuary.org through the caching server hasn't improved performance. Is it possible to return things to previous configuration? I'm thinking that makes testing other possible solutions simpler? (Ie: does caching server delay effects of changes made?)

2) Did you add the xmlrpc.php related edit in the advanced 'Web Configuration' on Nov 15th? I just went there to add a similar entry and see it's already been attempted. (Not having an effect).

3) Fwiw, checking the error log today I see over 5000 entries since Nov 5 of that xmlrpc.php related error mentioned previously.

thanks! Roger

[JaimeV]

Replying to https://id.mayfirst.org/mswp:

hi JaimeV

1) Routing mediasanctuary.org through the caching server hasn't improved performance. Is it possible to return things to previous configuration? I'm thinking that makes testing other possible solutions simpler? (Ie: does caching server delay effects of changes made?)

I will say that unless it is actively affecting functionality, if the caching server isn't making things faster it can't be making things worse. Yes, routing through the caching server might delay seeing the results of some changes. I will switch the DNS to point back to the origin server now.

When I run your site home page through several free website performance analyzers they seem to point out that many layers of css and javascript files are the first thing blocking the immediate page load. One reason you could have so many spearate css and javascript requests is because several wordpress plugins and the theme are inserting their own. These sites also point to large images that might be better resized or compressed as the next thing that is slwoing down page load.

In general the site appears to load between 5-6 seconds. Here are just a few of the tools I tried with.

​https://gf.dev/website-audit ​https://tools.pingdom.com ​https://gtmetrix.com/

2) Did you add the xmlrpc.php related edit in the advanced 'Web Configuration' on Nov 15th? I just went there to add a similar entry and see it's already been attempted. (Not having an effect).

That change was already there and I think was added at an earlier date.

3) Fwiw, checking the error log today I see over 5000 entries since Nov 5 of that xmlrpc.php related error mentioned previously.

Every time access to that file is blocked it is logged as an error. That shouldn't have an impact on page load speed.

thanks! Roger

[https://id.mayfirst.org/mswp]

One reason you could have so many spearate css and javascript requests is because several wordpress plugins and the theme are inserting their own.

-- Yep, I've mentioned the possibility of plugin related issues and the team is working on reducing the number of plugins.

These sites also point to large images that might be better resized or compressed as the

next thing that is slwoing down page load.

-- The team has also been working on optimizing images.

r