Looking back: improvements to edit save time

The WMF's financial year and its annual plan are coming to an end, and one of the Performance team's goals this past year was to reduce the amount of time it takes to save an edit on a wiki.

This set of metrics, which we call Save Timing, is publicly tracked on Grafana. It's recorded for all Wikimedia wikis. It's a critical performance pain point for editors, as edits on large wiki pages can sometimes take seconds to save.

We distinguish the amount of time the backend takes to process the edit, from the amount of time the end-user actually experiences to save the edit (collected client-side). We'll focus on the latter, as this is what people really experience. Backend traffic can come from bots, jobs, etc. where long execution times atypical of human edits affect the metrics.

Let's look at the evolution of frontend save timing since the beginning of the financial year, on July 1st 2016.

The 99th percentile, which represents the slowest editors experience dropped significantly:

Capture d'écran 2017-06-08 11.13.49.png (573×1 px, 57 KB)

Going from 22.4 to 16.82 seconds (weekly average), a 25% improvement.

So did the median:

Capture d'écran 2017-06-08 11.13.38.png (576×1 px, 62 KB)

Going from 953 to 813 milliseconds (weekly average), a 15% improvement.

@aaron deserves most of the credit for this tremendous performance improvement that editors experience every day. Performance is a never-ending goal and we hope to achieve even better save timing in the future thanks to our continued work in this area.

Written by Gilles on Jun 12 2017, 9:32 AM.
Engineering Manager, WMF
Krinkle, Peter, aaron
"Like" token, awarded by mmodell.

Event Timeline