Page MenuHomePhabricator

Performance review of new foundation website design
Closed, ResolvedPublic

Description

The foundation's website has had a big update this summer. Let's check if its performance is ok...

Event Timeline

Did a quick check and there where a couple of accessibility issues that I think should be fixed first, making it harder for screenreader etc. But I'm not sure what kind of setup we have today, if we do any automatically tests for that?

Gilles triaged this task as Medium priority.
Gilles moved this task from Inbox, needs triage to Doing (old) on the Performance-Team board.

Just FYI before I went to sleep yesterday I added the main page to my personal test (following the same standard that we will have when we move our testing, so its just a one-liner to add a new URL):

https://dashboard.sitespeed.io/d/000000044/page-timing-metrics?orgId=1&var-base=sitespeed_io&var-path=desktop&var-group=wikimediafoundation_org&var-page=_&var-browser=chrome&var-connectivity=cable&var-function=median

I'll keep it running for a week or two so we have some metrics.

Besides Piwik, there is a big chunk of CSS and jQuery being blocking, but I'm going to guess this is a general Wordpress problem, not specific to the foundation website's install.

A wordpress plugin inserts a script that's not deferred, at the bottom of the DOM, with the code of the "Flickity" JS library. I think this could probably be a deferred script, given the nature of what this does (flickable carousels). I'm going to guess that the fact that the script isn't deferred is the fault of whatever Wordpress plugin is injecting that script. That being said, it seems like that plugin is used for the language selector, and I fail to see how it's useful. It makes the whole selector draggable like this and adds the underline style:

Sans titre.gif (100×640 px, 217 KB)

The whole thing is 19kb of compressed JS:

$ curl --compressed -so /dev/null https://wikimediafoundation.org/_static/??-eJyVzc0OgjAQBOAXElYUiRfjs0i7yNb+kM6K6duLCQePcJzMfBn6TJVJUTkq6ciBQRglJ3oArCArUBq8mJdoqYLE2uFAWxDmZ8sz59InW+pdUpe7Moj3+5jJMin+jUTj33ZZO/wih57t2t/Drbl0bXM+nq6d+wKaoWHM -w '%{size_download}'
19738

IMHO the use of that JS library seems overkill and the likely intended effect (underlined bars) should be achievable with pure CSS.

That's all I can find. The website has a really good score on Pagespeed Insights for lab data. Field data is comparable to the www.wikipedia.org portal.

Assigning to you Peter for analysis of the data you're recording over time.

TTFB

First Visual Change looks ok, we had some higher metrics that correlates to higher TTFB:

Screen Shot 2019-10-15 at 6.47.00 PM.png (1×1 px, 168 KB)

I couldn't see anything like that for the other tests on that machine so I think this could be a real thing. Could it be that we hit a couple of times where the page was re-generated? Looking at the result we have a x-cache miss where we have the high ttfb.

Adding a filmstrip of how the page is visually rendered, so we have it for the future. I wonder what information is the most important on the page, is it the text with the yellow background, then our first paint is the most important.

Screen Shot 2019-10-15 at 7.48.30 PM.png (802×2 px, 408 KB)

Images

Images needs some love, we ship a lot of extra bytes that isn't needed. We have photos that are served as pngs instead of JPG. Checkout https://wikimediafoundation.org/wp-content/uploads/2018/07/Screen-Shot-2018-07-30-at-1.24.58-PM-e1533254033550.png?w=400&h=300&crop=1 that is 241 kb. Just changing that to JPG (with quality 10, max) gives us 107 kb. And then compressing that image using imageoptim, gets us down to 25 kb. You can have plugins in Wordpress that fixes this but since its not so many pages, I would manually fix it and compress the images using imageoptim.

Start with:
https://wikimediafoundation.org/
https://wikimediafoundation.org/news/
and then take the rest. The start page is important since its the first users visits and the news page is the heaviest one where we can gain a lot by just fixing the images (one image is > 800kb).

Nits

One response header has references to Wordpress, can we remove it?:

<https://wikimediafoundation.org/wp-json/> rel="https://api.w.org/" <https://wp.me/PawWr3-a> rel=shortlink

There's a prefetch in the HTML against Wordpress, that shouldn't be needed since we serve it from another domain:

<link rel='dns-prefetch' href='//v0.wordpress.com'/>

We have two moderate accessibility violations (using axe):

<div class="language-dropdown" role="navigation">

is missing a title or aria label.

Most pages have problems with headings. Either it misses a h1 or we have them in orders where we miss out on headers, like we have a h3 and h5 but no h4.

I think the accessibility issues at least should be fixed for https://wikimediafoundation.org/accessibility-statement/ :)

You should file all these individual issues as separate tasks under wikimediafoundation.org