--- Comment #5 from Faidon Liambotis <> ---
I don't think the cacheable bit will help much. The pageimages API parameter
will be for a more-or-less unique combination of articles OR'ed with each
other, as they resulted from the search query. I'm not sure of the distribution
of our search queries, but I'm guessing caching those combinations won't make a
huge difference (and it will be a waste of cache memory/disk).

It won't help client performance either, as clients will still do 17 extra
requests on every search for this feature. I think the design of this whole
feature honestly sounds a bit naive to me. We should really go a step backwards
and rethink the best way to do this with server- and client-side performance in

Assuming images on search results is something that is not hurtful from a
performance PoV and a requirement for where mobile is going, then we should
probably have one single search endpoint in the API which returns the JSON
result set enriched with image thumbnails URLs. There is no reason for this to
be in an extension or a separate request, AIUI.

The dozen requests to fetch a 1-2KB thumb eachs is still
going to kill client-side performance though. There's a tremendous overhead of
data for the request and round-trips that will delay the total page load time
from a viewer's perspective. It's also high-latency requests, as these 50px
images in most cases will need to be scaled on the fly. Unfortunately our
architecture makes it difficult to return this directly in the result set as
e.g. data URIs but if that'd work maybe we could find a way.

Let's think of other ways to improve this feature in general. I'd be happy to
discuss performance with you, as well as help in case some deeper
infrastructure change (Swift/Varnish) could help make this feature better for
everyone. I'm sure Ori could be of help here as well, with his client-side
performance expert hat on.

You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
Wikibugs-l mailing list

Reply via email to