Page MenuHomePhabricator

Preload the next page's image on proofreading view
Open, Needs TriagePublicFeature

Description

The Polish Wikisource preloads the next page's image while one is proofreading one page, which speeds up the load time significantly especially if you have lower bandwidth. It's implemented with a local gadget (not enabled by default for now).
https://wikisource.org/wiki/MediaWiki:Gadget-preload-prp-page-image.js

You could call it over-eager loading or prefetching. Otherwise, if indeed the thumbnail generation is the biggest part of the waiting time, especially for larger PDF/DjVu files and in some periods of the day when the imagescalers might be busier, it could be enough to request/generate the thumbnail server-side without loading it on the client, so it's ready on the cache.

Wikisource users at https://wikimania.wikimedia.org/wiki/2019:Transcription/Wrap-up and https://wikisource.org/wiki/Wikisource:Best_Practices have agreed this would be a feature worth implementing by default.

Details

Related Gerrit Patches:
mediawiki/extensions/ProofreadPage : masterAdds a rel=prefetch for the next Page: page

Event Timeline

Nemo_bis created this task.Aug 18 2019, 1:28 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptAug 18 2019, 1:28 PM
Nemo_bis updated the task description. (Show Details)Aug 18 2019, 1:34 PM

For context, the "slowness" (75th percentile of processing wallclock time) varies quite wildly for ghostscript and djvu https://grafana.wikimedia.org/d/0fj55kRZz/thumbor?orgId=1&panelId=11&fullscreen&from=now-7d&to=now : 2-3 s average and 10-15 s max is rather underwhelming.

Candalua added a subscriber: Candalua.
Ankry added a subscriber: Tpt.Nov 11 2019, 9:57 AM
Xover added a subscriber: Xover.Nov 11 2019, 10:19 AM

Incidentally, the correct place to solve this is in ProofreadPage because it has knowledge of what the next page in the sequence is. However, I suspect it would need facilities from core to do this intelligently: standard prefetching requires injecting a <link rel="prefetch" href="…" /> in the page, preferably before the browser sees it. ProofreadPage could of course "cheat" the way this gadget does (good version 1.0 / proof of concept / minimum viable product goal?), but that'd be kinda complicated, inelegant, overly specific, and prone to breaking over time.

On the upside, combining this with async (AJAX) save and preview could potentially give literal orders of magnitude improvement in perceived performance in the critical workflow for Wikisource!

Tpt added a comment.Nov 12 2019, 3:05 PM

This is a great idea! Adding this prefetch should be indeed fairly easy on the ProofreadPage side.

Change 550568 had a related patch set uploaded (by Tpt; owner: Tpt):
[mediawiki/extensions/ProofreadPage@master] Adds a rel=prefetch for the next Page: page

https://gerrit.wikimedia.org/r/550568

Tpt changed the subtype of this task from "Task" to "Feature Request".Nov 14 2019, 9:19 PM