User more info - Cache results and render optimization

I’m not even sure if there is an issue. I’ve been perusing Meta for a couple of months now and clicked on avatars… three times? Maybe fivish. Tops.

Even if someone had a keen interest in everybody else’s biography, there’s no reason to click the same user’s avatar ten times in a row. In fact, caching the data means that our hypothetical stalker would miss out on any new badges the watched user gets unless they clear the app-level cache by way of refreshing the entire page.

I am all for optimising but I think there are plenty other spots that need to be optimised first.


@elberet I guess there are not many interesting faces/people here, if you are not checking each and every avatar.
the base use case that you can look at is if you check a person, you closed the info box quickly and then wanted to see it again. just for this it is worth having short term caching, it does not make sense to make an identical ajax call in 2-3 seconds difference.

The user info box is a possible future optimization an it is just an example of the missing cache capability.
I did bring up the point that it may not be possible to cache ajax request on meta ( possibly at all?) I am not sure how much caching is needed on ajax requests. but the user box is an example.

I couldn’t check my code on discourse without secure HTTP(s) to confirm if it is SSL that prevent caching on ajax requests. or may be another header in the response.

Do you know of a Discourse instance that allow http requests without redirect to https?, So I can test and satisfy my curiosity?

Which ones do you consider we should take a look first? regarding optimization.

I’m new to discourse community and I would like to start contributing, so if you point me in the right direction I might be able to help here and there :slight_smile:

Best wishes,


1 Like

It’s precipitous that this got bumped. I’ve noticed that user cards take a LONG time to pop up, over a second for me, so I have been thinking about this lately. I feel like the user card should come up faster (maybe with placeholders?) and dynamically query the info it needs @sam.


I vaguely recall @eviltrout? maybe had the placeholder solution in initial versions, but it was a bit jarring.

I had a quick look and your user.json takes about 220ms, wack on a a roundtrips and yeah this can take a second (at least from some geos)

Agree it would be nice to do something better here, it is purely a UX change. I wonder how @awesomerobot feels here? We could certainly kick off a 400ms subtle animation (grabbing data at the start) and then finalizing the card once the animation is over?

@venarius really loves this kind of stuff, maybe do a mockup here?

I would recommend picking something a tiny bit smaller here as a first contribution, this is quite tricky to wire up. Have you had a look at:


Yeah just some kind of slightly better responsiveness here, where we defer the card work a bit and show an animation, even, would be a marked improvement. It doesn’t need to be perfect just “better than what we have now” … currently user cards are really clunky and slow to appear for me, and I have a very fast connection and I’m also close to many of the servers :confused:

Just clicking on your user card, it’s almost a full second before anything happens on my screen at all … really closer to two seconds :confounded:


Also as an idea I have would be maybe to implement something like here? It starts the ajax call as soon as the user hovers the avatar and shows intention to click on it.

There is a test at Test your click speed - InstantClick that shows that you can easily save about 400ms of loading time with this. Even on mobile.


Hmmm we would need to be ultra careful with that, intent is something that is hard to ultra reliably determine, people could be just moving the mouse pointer around.

This would have to start off as an experimental thing.


Some more ideas which are probably on the more easier side to implement:

  • Show a loading circle on top of the avatar after the user clicked on it as an indication for “something is about to happen”

  • Instantly show the modal and show a loading circle until the content is loaded in


This would be better from my perspective. Even if the user card “bounces” and resizes a bit. Because certainly at minimum we know the avatar and username on click, right?


Agreed. I think showing the avatar/username and a spinner while everything else loads is the simplest way to go. The biggest causes for jitter would be the background images and bio… with some layout adjustments the background image loading jitter can probably be avoided… everything else is relatively consistent.


The first version of the user cards I implemented was definitely instantaneous and based on the information we already had in memory with more loading happening afterwards. I imagine it changed at some point either accidentally or because people find the quick change in formatting to be jarring.


Just opened a PR with a first mockup for this :slight_smile:


Does this look OK @sam?

I find the spinner here somewhat jarring:

We should have username/name/title and low res image on the page, not following why we can not start with that?


Because as far as I see here, the user modal gets only called with the username of the user. data-user-card={{username}}. That’s why it only knows the username.

Is there a way for me to get the other information without having to do another request to the backend?

I am not sure what the perfect solution here is or even if we will all be perfectly happy with the partial card -> full card transition.

I think we can use the Store to look up a user in the cache which is free from the component? @eviltrout ?


The store would work in many cases, but there is still lots of code that does not use the store. Some is historical, some is HTML that is pre-baked.

I don’t recall if the topic view uses it (I think it does), which might be 90% of the time the user wants to pop up a card. It’s worth trying out.


I figured out how to get the avatar from the Cache and also worked on another animation. Maybe that one suits more :slight_smile:

This is now like these Facebook “wireframes” you can see on their app ( also animated like them )