Page MenuHomePhabricator

Loading links content only once on hover [Proposal]
Closed, DeclinedPublic

Description

I've noticed such feature on wikipedia: loading content from hovered link article. It makes ajax call every time hover happens. So, we may reduce requests number by caching results on client and that's all)
I can implement this one, if I get to know module name
It's just proposal, What do you think?

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptMay 30 2017, 6:51 PM
Progsmile renamed this task from Loading links content only once on hover. to Loading links content only once on hover [Proposal].May 30 2017, 6:57 PM
Aklapper edited projects, added Page-Previews; removed JavaScript.May 30 2017, 8:06 PM

Hi @Progsmile and welcome to Phabricator! The functionality is provided by the Page-Previews extension - see the extension homepage for more info and also general developer information.
Could you explain why you think that reducing the number of requests is more desirable than reducing the amount of downloaded (and never used, if I do not put my mouse pointer on most links in the text) cached data?

Jdlrobson assigned this task to phuedx.May 30 2017, 11:51 PM
Jdlrobson added a project: Readers-Web-Backlog.
Jdlrobson added subscribers: phuedx, Jdlrobson.

Hi @Progsmile thanks for taking the time to make this proposal.

This is actually intentional... you can read the background on T161284.
The requests to RESTBase are cached on the client via a header - but they will show up in your network console.

It may be useful to avoid them on mediawiki api.php calls however but we should check in with @phuedx before implementing that... let's see he says.

Jdlrobson triaged this task as Low priority.May 31 2017, 4:55 PM
phuedx added a comment.Jun 6 2017, 9:07 AM

Hey @Progsmile! Welcome! Thanks for creating this task.

Let me add a clarity to @Jdlrobson's comment above: Page Previews (PP) can request previews from either the MediaWiki API or from the RESTBase page summary endpoint, both of which are configured differently when it comes to client-side caching. Moreover, PP will request previews from the MediaWiki API by default. Which wiki(s) are you using PP on?

Now, the MediaWiki API can be told to return cache headers as part of the request: the smaxage and maxage query parameters can set the corresponding values in the Cache-Control header of the response. In the case of the PP API request, the response has the following header:

Cache-Control: s-maxage=300, max-age=300, public

The response can be cached by any shared cache – a well-behaved caching proxy, say – and a private cache – the user's browser – for 5 minutes. The latter is important here. My browser's DevTools will log every request that the browser makes but highlight whether or not the response was served from its cache, e.g.

The RESTBase page summary endpoint can only be configured to return cache headers. It was in T161284: Minimise incidental HTTP requests caused by Page Previews, for example. A typical response has the following headers:

Cache-Control: s-maxage=1209600, max-age=300
ETag: "18502569/bf523db2-4977-11e7-8793-a0298cce90fd"

The response could be cached by cached by any shared cache for 14 days and a private cache for 5 minutes. If the cached response is stale, then the agent should re-request the stored response using its ETag (it should "revalidate" the response). This is the recommended default behaviour of an HTTP client.

In either case, PP leverages the browser's cache rather than maintaining its own. We rely on Grade A browsers implementing HTTP caching correctly and their vendors making accessing them as efficient as possible in order to avoid incurring the incidental complexity of writing our own cache in JavaScript. I think this is reasonable.

In either case, PP leverages the browser's cache rather than maintaining its own. We rely on Grade A browsers implementing HTTP caching correctly and their vendors making accessing them as efficient as possible in order to avoid incurring the incidental complexity of writing our own cache in JavaScript. I think this is reasonable.

T167093: Document why Page Previews doesn't cache API responses covers documenting this architecture decision in the codebase.