That’s not the cache that I am talking about. I meant the browser cache.
You have an immense amount of JavaScript and CSS files being loaded in your page.
Any plugin telling a browser to disable the browser cache or CDN for any reason will cause your site to clog down. Especially if CDNs are disabled as well.
Still, look - https://www.youtube.com/watch?v=7RQiRyJV6uA
No other plugin has any effect.
The site is hosted on the Google Cloud subnet in Western Europe.
What you’re saying sounds horribly unprofessional. Just because your Internet is slow doesn’t mean there isn’t a problem. This is a very strange argument, to the fact that your plugin slows down wordpress for a few seconds at all.
No need to blame my site. The problem is the same with a completely clean wordpress and the default theme.
Again, the admin panel slows down too, do you clean the cache there too? Why? What are you bolkiing there?
No need to blame my site.
Anything can happen with websites and software. The problem cannot be solved without following clues and providing pointers.
The problem is the same with a completely clean wordpress and the default theme.
Try to provide a screencast with such a fresh WP install and this particular plugin only. With a default WP theme instead of the current one that you are using.
If you can provide ftp access to that stack like I asked in email, we can do some tests tomorrow. For now, have a nice day.
It saddens me greatly the way you look for the cause everywhere but yourselves.
I should have started with an example of a clean wordpress installation to avoid all this.
Here’s a completely clean, freshly installed wordpress, just with your plugin, and it’s the same, everything slows down by 3-6 seconds or more. None of your explanations explain why even the admin panel is slowing down. And the cache has nothing to do with it at all, and my site with a bunch of scripts has nothing to do with it either. And I can be sure it shouldn’t be like that at all.
Here’s an even better demonstration of how your plugin on pure wordpress increases initial server response time by 3 seconds - Patreon screencast slows down blank wordpress - Lighthouse - YouTube
It saddens me greatly the way you look for the cause everywhere but yourselves.
Since this is not reproducable in a standard & cheap cPanel hosting stack, the natural route is to examine the stack and the website. This is standard debug procedure.
There is a visible change in initial page response time in your stack while using the plugin, however without knowing the details of your stack or doing tests at your staging site there is nothing that can be said for sure.
Is the plugin currently inactive at your live site?
Here is a screencast testing the plugin with a fresh WP install on a standard cPanel hosting account: (mute the audio before you start the video).
As visible, there is no delay in response times like in your example.
Yeah, that’s just impossible to use.
Did you connect the plugin to patreon, or did you just activate it?
The problems start exactly when the plugin is connected to patreon.
Or give me access to this site, I’ll take a look myself.
Here’s another example server first response delay +2 seconds with plugin - Patreon screencast slows down blank wordpress - Lighthouse #2 - YouTube, it’s on the test cloud https://www.boldgrid.com/ you can experience it for free.
Stacks on which the same problem is repeated:
wordpress.com business rate
Check it out for yourself.
I think this is a sufficient sample to understand that this is not a narrow or isolated problem.
The below benchmark is from your live site.
It does not at all appear unusable.
Did you connect the plugin to patreon, or did you just activate it?
Yes, its connected to Patreon.
Here’s another example server first response delay +2 seconds with plugin - Patreon screencast slows down blank wordpress - Lighthouse #2 - YouTube
Your non-plugin time to first byte is already 0.82 seconds. The plugin adds ~1 seconds to it, and this is the problem then? Which I am not experiencing?
I think this is a sufficient sample to understand that this is not a narrow or isolated problem.
Unfortunately its not. Something is happening with your stack and your setup, for sure. However it is not something that is server-choking with high loads as you have described earlier. Nor it is something that is consistent, since you yourself said that ‘It is better today than yesterday’ at one point.
Neither other WordPress.com business users are reporting this.
Because you can’t provide access to a staging site for your stack or the exact copy of your stack to run specific tests, there is nothing more that can be done with the amount of information you provided. Yes, there seems to be something happening at your stack while using the plugin. Criticizing the developers or blaming anyone won’t help solve the situation. Providing access to a copy of your stack, would.
Since that is not happening, there is nothing more that can be done on this side. I will just process your refund. Sorry that it didn’t work out for you.
Note that if you are using any kind of NFS setup, you may need to use opcache to avoid the limitations of NFS. Especially if you are on a Kubernetes environment.
In any case, good luck.
Because the plugin is disabled!
I gave you everything you asked for! How can you claim that I didn’t give you access to the staging site?
The erratic and varying results that came out of your site point to there potentially being a conflict with your stack, yes. I understand that you would be unable to use the plugin with your stack since at this state you can’t be sure that it will work in an acceptable manner all the time and therefore you are frustrated.
However the WP admin and database access that you provided are not enough by themselves to troubleshoot such an issue. You would need to provide either FTP access, or access to your deployment pipeline if your stack does not provide such direct file access.
Alternatively, trying more common stacks may help - Apache with event MPM and PHP-FPM with opcache can provide you up over 100 requests/sec with 300 ms TTFB with a few vcpu even on an entry level VM. Moreover, Apache naturally supports advanced .htaccess file functionality without any tweaks or translations, which is needed by this plugin and many other plugins.
For anyone who may experience such rare and elusive initial page load issues: The plugin occasionally contacts Patreon api during page load to ensure that various details about your campaign are correct. If your web host or site is not able to contact Patreon easily and it occasionally has connectivity issues (or timeouts), this can cause such page load times. In such cases, contact your host, or if you can do it yourself, check whether connections from your site to Patreon api are not impeded.
Unfortunately, it seems to not be occasional, but on every page load, even if it’s 200 OK, slowing down website by about 0.5 seconds just from this API call each page load. I also have a problem very similar to this topic, having 401 unauthorized on my production website, while it’s 200 OK on my development website. I will probably make a separate thread on this.
Which exact api call?
Separate threads would be good.
