Page MenuHomePhabricator

Performance: don't request watch status dynamically
Closed, ResolvedPublic

Description

On every page view we do GET /w/api.php?action=query&format=json&titles=Barack+Obama&prop=info&inprop=watched HTTP/1.1

It's absolutely unnecessary as pages aren't cached for logged-in users so we can output the watched status in the page HTML.


Version: unspecified
Severity: major

Details

Reference
bz44126

Event Timeline

bzimport raised the priority of this task from to Needs Triage.Nov 22 2014, 1:25 AM
bzimport set Reference to bz44126.

I don't see what this gives us apart from more code fragmentation. Is this really a performance hit to the server?

Remember we dynamically load pages on beta and when this happens we will need to do an ajax call anyway to get watchlist status. This would mean we would need to special case against the first page load to do something different. I worry this will lead to clumsy javascript code.

It's worth noting that currently we don't show the watchlist star to users with older phones that we don't serve javascript to. It might be worth rendering the star in the html and making it a simple form post so that these users can still watch pages. This might be a good motivation to doing things this way.

Also surely we should be getting to a state where we can cache logged in users page - we should be working towards that and I feel like this works against that direction... no?

Thoughts?

Also to clarify
"On every page view we do GET"
should actually read
"On every page view where a user is logged in we do a GET"

afeldman wrote:

An unnecessary roundtrip to api.php should be avoided if at all possible, its more expensive to invoke than it should be. Logged in users do not generate api.php?action=query&prop=info&inprop=watched on every page view, and I think MobileFrontend should strive not to add additional request overhead vs. the standard site. +1 to Max's approach here.

Note that ResourceLoader allows module responses to be embedded in the page HTML, for the purposes of improving the performance of logged-in page views. This is used, for example, to send user preferences. We're not currently working towards HTTP caching of logged-in page views.

Thanks Asher and Tim for the input. Using ResourceLoader in this way seems to be the way to go.