Patreon Plugin Slowing TTFB (Dramatically)

Hi y’all. I’ve been trying to get to the bottom of an abysmal TTFB (averaging around 4s, but sometimes upwards of 7s) on my site (Wordpress + WooCommerce + Storefront + Patreon Connect for members).

I knew I was fighting uphill, but I spent a lot of time optimizing things with my host and DNS, all to no avail. Then I deactivated the Patreon Plugin and my TTFB immediately dropped down to about 550ms (still not great, but not horrendous).

Has anyone else encountered this? If so, do you have any suggestions for how to fix it?

This is a deal-breaker for an e-commerce site, pushing my load time to be starting at 4+ seconds. But I don’t want to give up on Patreon being my platform for membership.

Looking at the sourcecode to the plugin we can see a function called updatePatreonUser which determines if the user is logged in, and if they are logged in it proceeds to “query Patreon API to get users patreon details”. That function is registered through the wp_head action hook, meaning on every single page load (from a user who is logged in to your wordpress site via Patreon) a request will be made to the Patreon API – which is causing the slowness.

The good news is that this is only impacting visitors to your website who have logged in with Patreon, it does not impact non-Patreon visitors. The sort-of good news is that there’s a sort-of “fix”.

Looking at line 70 of patreon_wordpress.php we can see the following code has been commented out:

// Below is a code that caches user object for 60 seconds. This can be commented out depending on the response from Infrastructure team about contacting api to check for user on every page load
/*
$cache_key = 'patreon_user_'.$user->ID;
$user = get_transient( $cache_key );
if ( false === $user ) {
	$user = $api_client->fetch_user();
	set_transient( $cache_key, $user, 60);
}
*/

You could, in theory, uncomment this code and increase the cache time (e.g: 3600 would be an hour) which would reduce the frequency of the requests to Patreon. The caveat there is that if a user updates their patronage they’re going to have to wait until the cache expires for it to be reflected on your site, but that might be a reasonable trade off to greatly reduce page load times.

For example, if you wanted to cache for 1 hour, you’d replace lines 70 through 78 with this:

// Below is a code that caches user object for 60 seconds. This can be commented out depending on the response from Infrastructure team about contacting api to check for user on every page load
$cache_key = 'patreon_user_'.$user->ID;
$user = get_transient( $cache_key );
if ( false === $user ) {
	$user = $api_client->fetch_user();
	set_transient( $cache_key, $user, 3600);
}

Note: I have no involvement with the wordpress plugin, I have no idea if this caching code actually works, but I’m assuming since it is included in the published plugin that it is functional. @codebard is the author of the plugin and may be able to provide further guidance.

1 Like

Yes, we are aware of this issue and it is already in the to-do list for 1.2.0 which is around the corner in 1-2~ weeks tops. (beta at forum sooner)

The solution you provided is a good solution in the meantime.

Thanks for weighing in, @sam! For the site in question, it’s not only happening for people who are logged in, but for any visitor. Is this included in the known issue you’re talking about, @codebard?

Nope, it should only affect people who are logged in users and a known Patron.

Anonymous users and non-patron users shouldnt get affected.

This was addressed in the upcoming 1.2.0. Now the checks will happen once a day when the user logs in. (Ie, update it if last update date was older than a day when the next time a user visits).

In later versions this is going to be handled via webhooks and wont involve page loads.