Page MenuHomePhabricator

VisualEditor: Compress POST data in the client
Closed, ResolvedPublic

Description

Until Parsoid removes metadata, large articles are going to consist of several megabytes of data (en:Barack_Obama = 3.4MiB). As browsers doesn't provide any mechanism for compressing post data, this is takes about 20s to upload on a typical 1Mbps up ADSL line.

Using a JS implementation of deflate, we could achieve 80-90% compression in a few hundred ms on a decent machine: http://jsperf.com/js-deflate

A couple of considerations with performing such a complex calculation in pure JS:

  • Really bad JS engines or slow devices (old browsers, IE, mobile) may offer to little to overall speed benefit. We may want to detect these cases by user agent or performance profiling.
  • The compression function will be synchronous and lock browser interaction. On slower machines this may give the appearance of crashing, or with memory leaks may actually crash. If this proves to be a significant problem we could look into encoding in chunks of 100k at a time so we could at least provide progress, and maybe improve memory usage (at the cost of overall compression).

See Also:

Details

Reference
bz66914

Event Timeline

bzimport raised the priority of this task from to High.Nov 22 2014, 3:28 AM
bzimport set Reference to bz66914.

Supporting section editing (bug 48429), and submitting only modified section to the server, might be a better way to increase performance.

Change 141678 had a related patch set uploaded by Esanders:
Compress HTML data with deflate before POSTing

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

There are a number of things we can do to avoid this heavy payload:

  • Section editing
  • Separating Parsoid metadata
  • Sending differential linmod data using a server-side converter

None of these are ready or close to being ready yet, and 20s to save a page is fairly significant problem in the present that compression can mitigate.

  • Bug 59659 has been marked as a duplicate of this bug. ***

(In reply to Ed Sanders from comment #0)

  • The compression function will be synchronous and lock browser interaction.

You could look at doing it asynchronously in the background, with a Web Worker (i.e. thread) (https://developer.mozilla.org/en-US/docs/Web/API/Worker), in supported browsers (IE 10+, and Firefox/Chrome/Safari/Opera going back pretty far).

Change 141678 merged by jenkins-bot:
Compress HTML data with deflate before POSTing

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

Krinkle updated the task description. (Show Details)