The reading team are currently focusing energy on speeding up the site
for all our users (
https://phabricator.wikimedia.org/T98986 is the
tracking bug where this work can be followed)
Off the back of
https://phabricator.wikimedia.org/T105361 I had a
quick chat with Ori to document how the performance team is currently
identifying problems with MediaWiki's code. I'm sharing here, so
anyone who is interested in helping us improve the time our users can
load our content can analyse our data, raise tasks, and submit
patches.
I'm hoping this will be useful for anyone who wants to get involved in
an effort to make our site faster for our users (this is not desktop
specific). If you have anything useful to add please do, after some
discussion or nods I'd love to share some best practices on
mediawiki.org
Tool 1) Use
http://webpagetest.org (no credentials necessary)
* Use
https://en.wikipedia.org/wiki/Facebook as an example wiki page
* Choose a region of the world and browser
* Select first view only since this is what we are currently
interested in (repeat view is when they load again - and it should be
quicker as it is from cache).
* Capture video can be turned off - I personally find the screenshots
more useful
To shout out some of the advanced settings, the more
interesting/useful features include:
*Chrome > capture dev tools timeline
* Setting speed 3G or 2G
* Script can be used to conditionally turn on things which are not yet
available to everyone e.g. VisualEditor
You can do a lot of this in your Chrome browser locally, but different
browsers may have different behaviours and are in a fixed location so
this does not get captured in this tool. The visual screenshots also
make it easier to see where things get blocked. With the timeline from
advanced tools you can match up white screens with blocking
scripts/styles
Tool 2) Add
http://performance.wikimedia.org to your browser
bookmarks. Navigation timing section is probably the most interesting
right now. It points to
https://grafana.wikimedia.org (no credentials
needed) which is powered by
http://graphite.wikimedia.org (Access
graphite with your wikitech credentials). This data is sourced from
our users, so is a good representation of how we are doing.
If a graph is missing you can create a new one from data in graphite
by clicking "add row" or editing an existing graph.
Clicking edit on
https://grafana.wikimedia.org/#/dashboard/db/navigation-timing?panelId=12&a…
you'll be able to understand where the data comes from on graphite
e.g. metrics/frontend/navtiming/totalPageLoadTime
Note for graphs median data is less sensitive to edge cases so best to
use this as a more realistic indicator.
Folders in graphite, are populated by scripts that live in:
https://github.com/wikimedia/operations-puppet/tree/production/modules/webp…
To create a graph, simply go to an existing workboard, save it under a
different name (this clones it) - don't worry you can't mess up and
delete existing workboards.
Tool 3) Speedcurve requires you to setup an account but it gives you
an opiniated view about things you care about and is nicely presented
so could be a good source of inspiration for your own grafana
dashboard.
To oversimplify what it does: each day it will access a page, store
result, allow you to see historic data.
Note the performance team has plans to setup infrastructure to automate this.
Tool 4) is one we are not using -
http://sitespeed.io. We might want
to use it for performance regressions test.
In the grand scheme of things it would be great to get to a place
where Jenkins complains if you cause a regression in firstPaint time
but we are a long way from that but let's work in that direction :-)
Let's live up to the Hawaiian word after which we are named!
Apologies if this is oversimplified, please take this as an
opportunity to share how you/your team/your company test page
performance. I see this mailing list as a good place to share these
sort of things!