User more info - Cache results and render optimization

(lid) #1

When a user click on author avatar on a side of post, A small inline box will expand with additional user information.
most of the information in this box is pulled dynamically from the server (ajax).

###what is the issue?

  1. every time the user click on the avatar a request will be issued to the server. you clicked on the same avatar and toggled it on 10 times.

the server will get 10 ajax requests to


There are two losers here

  1. user: the user will have a slower responses due to the content not being cached.
  2. The server no cache mean the server will get more requests.

###Possible solutions:

  1. Add Browser cache support
    I tested the following code in console, and for the life of it I don’t understand why chrome/firefox does not cache the request
dataType: 'json',
//ifModified : true,
headers: {
      'Cache-Control': 'max-age=60' 

2 . Cache results in the app logic.


It will probably be ideal to have a proper caching on the browser level, with a reasonable expiry.
But having the app cache this type of requests temporarily is also a feasible solution.

####Another possible optimization:
The info of that box is rendered in div#poster-expansion The div is being reused on the page for different users info.
When you close the box it is just hidden with css.
We can save some dom manipulation, by checking when you open the box if the request is for the same user just show the box. do not reload or re render the box with the json data.

####Update - Why does the Ajax request doe not cache ( ssl ) :
In the test ajax request (see code above), I could not trigger the browser to cache the request.
There is no obvious header in the server response to should prevent the browser from caching.
I suspect that it is possible that the request is not cached due to the combination of an ajax request over SSL.
I couldn’t find anything to back that up yet.

(Jens Maier) #2

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.

(Sam Saffron) #3

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

(lid) #4

@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?