audit: JavaScript boot-up time is high ⏱

[addyosmani]

Description: JavaScript boot-up time is high (> 4s)
Failure text: JavaScript boot-up time was 12s. This is too high.
Help text: Consider reducing the time spent parsing, compiling and executing JS. You may find delivering smaller JS payloads helps with this.

Overall: Highlight issues with parse/compile/execution time and point to the Performance panel for digging into this deeper.

Related issues: #2535
Could be a proper version of/redux of: #1695

[wardpeet]

I have a few questions about this one before I can start.

What do we want to show here?
Do we want to measure parse time, execution time, ... per script or do we rather want a global
view that takes everything in consideration? Or perhaps both? (@see #1695)

What do we consider boot-up time?
Is this TTI? FCP? onLoad (XD)?
Or when all critical resources are done executing?

Including this data inside the report might be a bit tricky as it's hard to display this kind of data
in a optimal way. In my opinion how @addyosmani was displaying it in #1695 might be a bit too much if we want to show it per script.

For an overall view per script a pie chart might be useful but you probably lose the raw numbers of the measurements.

Perhaps start with a table showing time per category for each script

[benschwarz]

Showing overall parse and compile is important for showing the difference in a CPU limited device vs one that isn't, so if we could have 'overall timings' as well as 'per script', that'd be best.

I'd say the 'boot up time' is all the scripting involved until TTI.

[addyosmani]

At the last team sync, we discussed coming up with a group of "how to serve JS better" audits that could show for each script:

• Bootup for parse/compile/execution time
• Network download time cost
• Wasted bytes from code coverage
• Opportunities for JS minification

@paulirish Was there anything else we wanted to include in there?

[addyosmani]

@brendankenny @patrickhulce I had some time to kill during BlinkOn so threw together a mock for JS opportunities we could bikeshed on.

Colors:

• Pink row = this specific script was too costly (took too long to download or spent too long being parsed, compiled and executed)
• Code coverage (similar to DevTools) green = used, red = unused

I tried to integrate a similar breakdown to the page execution PR in #1695 if you want to understand boot-up time in more depth. These aren't shown by default but are visible as an expandable.

[brendankenny]

probably lots of iterating that can be done, but I really like this. Would have loved exactly this doing a perf audit today

[wardpeet]

I really like the mockup. Perhaps just go with this to start with? We could improve later on?
So boottime is time until time to interactive?

[benschwarz]

👍 Looking great!

We could probably roll up the bootup time into a small split bar graph in order to remove the need for a <details> dropdown:

@addyosmani Nit: Here, it's listed as "bootup time", but elsewhere you've referred to it as "startup". Are you leaning towards one or the other? Could we call it Parse & Compile? or Script time? I feel like we're losing something in "boot up time".

[patrickhulce]

I like it :)

I'm similarly a little confused by what exactly "boot up time" represents. One thing that might be lost by breaking everything down by file is total time spent, but we might be able to break from our traditional table-only details and get creative about surfacing that too.

[benschwarz]

In Calibre, I'd probably have an overall timing (on the pulse page), then show the break down on a per script level a bit deeper into the report. Perhaps an overall summary would be useful too?

[addyosmani]

I'm similarly a little confused by what exactly "boot up time" represents.

This may be a nomenclature issue. Does "start-up" time make more sense? My mock originally had "Parse/Compile/Execution Time" but that felt like a pretty large label to try squeezing in. "Script time" or "Time in JavaScript" could also work.

Perhaps an overall summary would be useful too?

Perhaps something like this, @benschwarz?

@wardpeet Per the last team sync, it sounds like we're okay with focusing on the JS breakdown audits here for the short-term as both #931 and #3106 will require more complex critical-path analysis in order for us to move forward with them. Does that sound good to you?

[vinamratasingal-zz]

Thanks for putting together this mock Addy! Some quick feedback (from a lens of someone slightly more new to performance):

• Should we add a learn more link to help developers understand how they can "reduce the amount of work being done by items in pink"
• My understanding is that the JS time === boot up time. Should we use the same language to keep it consistent? (I like Time Spent Evaluating Javascript or something to that equivalent)
• Another question: how will the developer know what items refer to the pink vs green? Does that refer to specific lines of JS within vendor.js? Is there a legend somewhere explaining what the green vs pink mean?
• "How to serve Javascript better" sounds awkward. Can we say something like "Reduce time evaluating Javascript" or something (something that directly indicates the action the developer should be taking).

[addyosmani]

Should we add a learn more link to help developers understand how they can "reduce the amount of work being done by items in pink"

I think this is a solid idea. I'll check if we have a good existing article we can point to, otherwise we might need to put together a page in the Lighthouse doc that points to a few different resources.

My understanding is that the JS time === boot up time. Should we use the same language to keep it consistent? (I like Time Spent Evaluating Javascript or something to that equivalent)

Yeah. I think we'll need to iterate and agree on the best label to use there. I wouldn't be surprised if folks were confused with "boot-up" or "start-up" time but opting for a clear label sounds reasonable.

how will the developer know what items refer to the pink vs green? Does that refer to specific lines of JS within vendor.js? Is there a legend somewhere explaining what the green vs pink mean?

Good question. I don't believe the current Lighthouse report uses a color legend for the other colors there (e.g we assume folks know red = bad). Perhaps to stay consistent we should either highlight rows as red or introduce a color legend as you suggested.

"How to serve Javascript better" sounds awkward. Can we say something like "Reduce time evaluating Javascript" or something (something that directly indicates the action the developer should be taking).

"Reduce JavaScript fetch & evaluation time"
"Reduce cost of downloading & evaluating JavaScript"
"Reduce time spent fetching & processing JavaScript"
"Reduce time processing JavaScript"

Sure there are some other variants we can brainstorm too.

[vinamratasingal-zz]

Thanks for the quick feedback!

Re: 4, I really like "Reduce time spent fetching & processing JavaScript" OR "Reduce time processing JavaScript." Open to hearing what others think though! :)

For next steps, perhaps we can wait for folks to chime in by Friday, and put together a new version of the mock then? Addy- lmk if you need help (not sure if you're using Sketch to put this together) and I'll be happy to help you make changes as well.

[patrickhulce]

I really like the information this is surfacing here. One quick note based on our goals for what counts as an "Opportunity." What do you guys think about having this per-script breakdown and summary as mocked in "Diagnostics" and surfacing the minification separately as an additional opportunity (since code coverage as an opportunity is already done)?

[paulirish]

We see there are two separate components here. Both are inevitably diagnostics to the user:

• Global execution breakdown by category.
• Per script bootup costs - this includes parse, compile and EvaluateScript. All FunctionCall/Timers afterwards are not included in the per-script breakdown.

Let's do them separately. Let's start with the global execution breakdown. patrick, brendankenny, and me agree on all this ^.

@wardpeet sg?

[vinamratasingal-zz]

Addy- do we have any updates on the UX? Want to make sure the UX is ready for Ward so he's not blocked on this :)

[brendankenny]

I think all ideas are already in this thread :) We're probably going to have go with a bare-bones first implementation (hidden from the report if it's too rough at first :) For

Global execution breakdown by category.

we could probably just start with a table in Diagnostics.

[addyosmani]

Global execution breakdown by category.
Per script bootup costs - this includes parse, compile and EvaluateScript. All FunctionCall/Timers afterwards are not included in the per-script breakdown

Initially focusing on the global execution breakdowns sgtm.

Are we aiming to follow this up with the per-script bootup costs shortly after? Keen for us to give developers an answer to the (more actionable) "which scripts should I be looking at reducing time spent in?", but knowing you're spending too long in JS is still p valuable.

I really like the information this is surfacing here. One quick note based on our goals for what counts as an "Opportunity." What do you guys think about having this per-script breakdown and summary as mocked in "Diagnostics" and surfacing the minification separately as an additional opportunity (since code coverage as an opportunity is already done)?

Surfacing minification as a separate opportunity sg. I do think (at some point) it might be worth exploring how we can better group categories of JS optimization opportunities better but that can be an exercise for the future :)

[wardpeet]

1. Global execution breakdown by category.
   parse, compile & gc for the whole trace.

2. Create a table of the whole trace that contains (parse, compile & gc) of each script.

Can we combine these 2 in one audit or wouldn't that be possible due the limitations of the report?

I'll start on 1

[wardpeet]

should I move to lines like perf-metric? Description isn't correct with global execution either.

[addyosmani]

Do we want to only include script related categories in the timing here (compile, eval, GC etc but not image decodes, parsing styles, html)? Original intent was raising awareness of the time spent in JS. Would understand if we wanted this to be slightly broader.

…

On Oct 6, 2017 2:23 PM, "Ward Peeters" ***@***.***> wrote: [image: image] <https://user-images.githubusercontent.com/1120926/31299119-4b992cf4-aaed-11e7-8578-42b941243724.png> should I move to lines like perf-metric? Description isn't correct with global execution either. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#3105 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAGxaQ9_XMtSVhZqzRmonzYObGrZuZJjks5sppppgaJpZM4PAqWJ> .

[paulirish]

@wardpeet looks good.

Do we want to only include script related categories in the timing

I'd prefer to make sure this includes everything. But in order to help clarify script costs.. I see two solutions here:

1. Add a TaskCategory column that would help clarify Script vs Paint, etc.
2. Add a color chip next to the titles.. All yellow/orange would be quick to notice.

Obviously a more involved visualization would help make this data explorable, but this can wait.

In this table format I'm also thinking it might be useful to add another column indicating whats typical or flagging particular outliers. ("This is 500% more than the average pageload!") Do we have this data? no. :) But is it an interesting idea @addyosmani ?

[addyosmani]

I like the idea of the Task Category column and see that Ward has started implementing it over in #3520. Looking sharp. I do think that we could use some color in there to visually differentiate the different categories but agree that can be done in a follow-up PR.

In this table format I'm also thinking it might be useful to add another column indicating whats typical or flagging particular outliers.

How important is it that we have this data for each of the categories? With HTTP Archive we do have median and 99th percentile information available on parse/eval times. I think we could extract this for some of the other categories too but we'd have to check. cc @rviscomi as an fyi that this came up.

On is this useful/an interesting idea: I think there's value in gut-checking where you're at relative to the industry for some of these timings.

I do think we might need to noodle on the design for it. If you think about parse times, the global median for any given page could be 4s. If our table highlighted that you had 5 x scripts, each of which were spending 3s in parse, we'd technically be telling you you're doing fine vs. looking at this in the aggregate (15s). Maybe highlighting this for the entire table would be useful?

[wardpeet]

when getting all timings of scripts do we also want to show the main document parse time?

[stave15]

In https://www.fileour.com/ site will be a problem. But it's only like the mobile version.