Page MenuHomePhabricator

Calculate parsing speed for JavaScript on mobile
Open, MediumPublic

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.

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.


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".

Size on desktop

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

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.

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

Related Objects

Event Timeline

Peter created this task.May 8 2017, 8:25 AM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptMay 8 2017, 8:25 AM
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>.
Aklapper reopened this task as Open.May 9 2017, 10:20 AM
Peter added a comment.May 10 2017, 7:08 AM

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.

Peter added a comment.May 17 2017, 2:02 PM

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
Jdlrobson moved this task from Needs triage to Triaged on the Mobile board.Jul 19 2017, 1:19 AM
Peter added a comment.Sep 12 2017, 2:46 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.