Gravatar redirect chains cause too much load time
-
Gravatar redirect chains are a significant drag on directory homes page loads. Is there any way to make that more efficient?
-
what redirect chain is that?
only thing i see in
function bp_core_fetch_avatar( $args = '' ) {
which might slow down the process is checking for
if ( file_exists( $avatar_folder_dir ) ) {
if you have disabled avatar uploads for members.
Do you simply mean the call to retrieve the object? It’s becoming an increasing issue with many sites , where you see pages stall while attempting to render due to waiting on third party servers, it’s not simply gravatar that you see this with. We had a discussion on the subject on another forum that was suffering and the conclusion was that attempting to ensure that these scripts and calls loaded as late as possible was best so that at least the page content could load.
attempting to ensure that these scripts and calls loaded as late as possible was best so that at least the page content could load
How would you do that? That is my problem; half the page hangs while the browser goes back and forth to gravatar.com.
well the images from gravatar are displayed in the img src – not by third party scrips which wait until the dom content has loaded.
Does the system not have to go off and check with gravatar whether an image exists against an email and then grab it for the user. I don’t now that gravater is especially an issue but I’m not sure that all scripts wait until the dom is fully constructed do they?
Last time I looked at how Gravatar works, it was like this: A URL is built with a parameter tacked on. The parameter is a ‘hash’ of the user’s email address. That URL is embedded into an <img src…> tag.
When someone’s browser tries to render the image Gravatar is contacted. Gravatar then checks to see if the email address has an avatar (stored at Gravatar) associated with it. If it does it returns that avatar and if not it returns a default image instead.
So in either case a browser waits on Gravatar to dump out an image file.
Considering the relationship between BP, WP, Gravatar and Automattic, this topic is not going to get the answer you’re looking for.
If you don’t like Gravatar, then disable it and use local avatars only.
That said, make sure your local avatars are then being served from a fast CDN. If not, you likely won’t see any better load times than Gravatar.
Not sure if the OP actually expressed a dislike for Gravatar especially , but the overall issue is an interesting one. Over the last few years with the rise of offsite script calls and general offsite info being called into pages there are noticeable times when page loading stalls. It’s not a BuddyPress issue per se.
@hnla: The Gravatar implementation is rather good considering what it’s trying to do. The unfortunate place where it breaks down is when you have a lot of users who haven’t registered with Gravatar and the default Mystery Man image is sent back numerous times with different URLs.
The biggest change I’d like to see in handling of Gravatars is for WP (or BP or whatever) to intelligently check if a user has a Gravatar. If the user doesn’t have one then save that info in their profile and server either a local default or user the Gravatar Mystery Man default that is generated the the unknown@gravatar.com address. This would result in a consistent URL that can be better cached by browsers for users who do not have a Gravatar.
To handle when users actually register a Gravatar, just check Gravatar every X times their avatar image is needed and if one is found, use it (and update their profile info in the DB to reflect this).
On a “normal” WP site where anyone can toss in their email address, this isn’t as useful but on a BP site where your users are registering, this makes a lot of sense (to me).
That sounds like a good approach, worth suggesting to the powers that be?
Have to admit I haven’t noticed any great issue with Gravatar but have had pages stalling at times due to waiting on… and there’s the rub it becomes increasingly difficult – to a degree – to debug just how a page is loading and where bottlenecks occur.
The Gravatar caching idea can be implemented via a plugin as far as I can see. I don’t think there is anything specifically required in the BP core that isn’t already available to use. Maybe I’ll take a stab at it.
As for debugging load times, you need to use tools like YSlow, Google Page Speed, or the built in page load timers in Firebug (Net) or Safari Developer Tools. These can help you visualize what is taking longer to load. There’s lots of information out there on how to improve page load times (in general, not specific for BP) but much of it requires moving away from some of the features we all like/want (like avatars, child themes, javascript/AJAX, etc.).
The other alternative is to pay big bucks for ultra high performance hosting with built in CDN, etc.
I use and am familiar with all those tools, and always test own site development work especially where scripting is concerned but also spend a fair bit of time correcting or helping with others site layouts and sometimes the plethora of scripts running is simply overwhelming
As for debugging load times, you need to use tools like YSlow, Google Page Speed, or the built in page load timers in Firebug (Net) or Safari Developer Tools.
I’ve used a few of these. That’s how I found out. Already made lots of improvements, but the gravatar issue is one thing I have no control over. Don’t want to ditch gravatar either though.
Considering the relationship between BP, WP, Gravatar and Automattic, this topic is not going to get the answer you’re looking for.
All the more reason for Automattic to fix this. They can start with your suggestions.
- The topic ‘Gravatar redirect chains cause too much load time’ is closed to new replies.