Page MenuHomePhabricator

Calculate parsing speed for JavaScript on mobile
Closed, ResolvedPublic

Description

Last week there was a really interesting talk by Marja Hölttä at JSCOnfEu 2017: Parsing JavaScript - better lazy than eager

We should check how much time is spent parsing for Wikipedia on mobile! First let us go through a couple of extra interesting slides.

Wikipedia against the world

Marja had this slide comparing how much time is spent parsing on top site, and we can see that Wikipedia spend more time in parsing JS than maps.google.co.jp. Not sure though if that is really our mobile version or desktop. We should do our own benchmarking (we don't do that at all today). It would be really interesting to benchmark both mobile and desktop against other sites.

Screen Shot 2017-05-08 at 9.56.16 AM.png (914×1 px, 255 KB)

Parsing speed

The amount of JavasScript that is shipped is interesting because the browser needs to spend time parsing. And remember, it is not the compressed size that matters, it is the uncompressed size.

Screen Shot 2017-05-08 at 9.57.20 AM.png (920×1 px, 106 KB)

Here we can compare how much JavaScript we ship vs single page web apps (however we don't need the JS to render in most cases).

Summary

Marja had a summary how to make things faster: "Ship less code".

Screen Shot 2017-05-08 at 9.58.55 AM.png (912×1 px, 126 KB)

Size on desktop

I've tested Obama on desktop and the amount of Javascript uncompressed is 1mb.

Screen Shot 2017-05-08 at 10.02.22 AM.png (376×558 px, 47 KB)

You can also try this in latest Chrome (59 and later) and get the amount of unused Javascript in devtools BUT it is broken and don't get all JavaScript we use, so please use WebPageTest or other tools to get the correct amount.

Size on mobile

I've also tested Obama on mobile and the amount of Javascript uncompressed is 0.6 mb that would then be 0.6 seconds just to parse it. More JavaScript shipped than the single page webapps.

Screen Shot 2017-05-08 at 10.12.04 AM.png (380×550 px, 46 KB)

Let us discuss this in our meeting in the performance team on Wednesday and see what can be our next steps.

Event Timeline

Qse24h closed this task as a duplicate of T164723: New git repository: <repo name>.
Qse24h closed this task as a duplicate of T164723: New git repository: <repo name>.
Qse24h closed this task as a duplicate of T164723: New git repository: <repo name>.
Qse24h closed this task as a duplicate of T164723: New git repository: <repo name>.
Qse24h closed this task as a duplicate of T164723: New git repository: <repo name>.
Qse24h closed this task as a duplicate of T164723: New git repository: <repo name>.
Qse24h closed this task as a duplicate of T164723: New git repository: <repo name>.
Qse24h closed this task as a duplicate of T164723: New git repository: <repo name>.

I've asked Marja if she had more info on what URL that was tested in our case, she's not really sure but it could be Barack Obama page:
https://twitter.com/marjakh/status/861997882924249088
https://twitter.com/marjakh/status/861998033290104832

Reminds me that when we do benchmarking we need to do it open and reproducible for others.

so .. the numbers here are not representable for our mobile web, we should check if there's a way to collect these metrics ourselves.

Krinkle triaged this task as Medium priority.May 26 2017, 2:14 PM

Let us see how we can implement this for Marvin.

Once we can test on mobile phones, we should implement this.

Check on whether Chrome publishes a breakdown of which V8 events count as parsing. If not, reach out to the V8 team.

We will automatically have this when we have the mobile device lab.

Peter claimed this task.

Woho we do that now.