Interest in adding more functionality to the package

[christian-bromann]

Hey,

I am wondering if there is interest to add more functionality to Tracium than just computing the main thread tasks. We would love to have more models that allow us to get specific information on rendering events (e.g. long tasks, force style, forced layout etc.). We have seen a lot of useful classes in the devtools-frontend code which we can't really embed into ours as it requires the DevTools environment.

We are happy to build our own utility package but I thought it would be worth to ask and work together than building something new.

Cheers!

[patrickhulce]

Thanks for the suggestion @christian-bromann! We're in the process of converting the source of this in Lighthouse to be consumable and then the extra insight Lighthouse has to offer can be much more easily supplied as well.

Would you mind sharing what information you're interested in specifically? Is it tagging that a particular task was forced from userland JS? Long task identification is just .duration > 50

[christian-bromann]

Would you mind sharing what information you're interested in specifically?

To give some context: we at Sauce Labs trace the browser whenever the user is navigating to a new page (either via WebDrivers navigate command or via a click on a button or link). With the network logs as well as the trace file we then generate all performance metrics (e.g. TTFB, speedIndex, performance score etc.). Right now we import some of the audit classes from Lighthouse directly into our internal driver. This works fine although it feels a bit hacky.

I wonder if it makes sense to have a general package like Tracium that takes a trace log as well as network logs or other devtools event logs and provide various information on performance, e.g. metrics, performance score, rendering issues etc.

We are working to provide the ability for users to test the performance not only for page loads but also for soft navigations within SPAs as well as arbitrary events like scrolling through pages like https://googlesamples.github.io/web-fundamentals/tools/chrome-devtools/rendering-tools/forcedsync.html and compute a jankiness score based on paint and layout information from the tracelog.

[patrickhulce]

Ah thanks for the context! Not to speak for @aslushnikov here, but I don't see tracium/tracehouse ever providing opinionated summary performance scores. Its role is the parsing/processing of trace data and allowing the consumer (like Lighthouse and internal tools like the one you're building) apply their own specific analysis.

There's a world in which I see a few well established metrics being provided (like we do for FCP currently), but unlikely to see heavy computation for speed index when there are already other dedicated packages for this sort of thing.

[christian-bromann]

Another thing we would like to do is to better navigate and understand the tracelog by working with their respective models from the devtools-frontend package. It is currently hard to consume this package as it requires a specific environment (e.g. SDK as global var) and some other things that only work in conjunction with the DevTools app itself. Our goal is to make performance on a web application testable and these models are necessary to e.g. define the duration of async events to determine longTasks, forced style updates etc. I think these type of models (e.g. TimelineModel, TracingModel and others) can be encapsulated from the codebase to work with arbitrary trace logs to make things like reflows discoverable. However I understand that Tracium might not be the right place for that.

I will close this issue. We will move forward and go to build a consumable package that imports these classes from devtools-frontend. What do you think of that idea? There are a lot of useful logic in this code that we would love to consume to make performance issues traceable.

I will report back once we have something that we can release. I hope we can find a way to get things extracted out to have a single source of truth. Cheers!

[patrickhulce]

Our goal is to make performance on a web application testable and these models are necessary to e.g. define the duration of async events to determine longTasks, forced style updates etc.

This is a totally different beast than what we were discussing earlier @christian-bromann perhaps there was a miscommunication this is all well within the scope of tracehouse/tracium.

Regarding the duration of async events, perhaps I'm misunderstanding but async events from the trace perspective are already handled by tracehouse and long task identification should truly be as easy as mainThreadTasks.filter(task => !task.parent && task.duration >= 50).

Regarding forced style updates, again, how do you wish to surface this information? Is it tagging that a particular task was forced from userland JS (for example with a boolean flag instead of trace event name)?

[christian-bromann]

how do you wish to surface this information? Is it tagging that a particular task was forced from userland JS (for example with a boolean flag instead of trace event name)?

Yes, something along these lines. We are currently experimenting with a couple of solutions. Our problem that we want to solve is to detect jankiness by looking at the tracelog that we capture during a scroll action on a web application. You are absolutely right that long tasks can be determined using Tracium already. However rendering issues like forced layout and forced styles are still hidden in the devtools codebase. It also seems useful to identify the event to specific track types and its thread type (e.g. CrRenderer).

Would you say that tracing / timeline models of the devtools application can be within the scope of tracehouse/tracium?

[patrickhulce]

Would you say that tracing / timeline models of the devtools application can be within the scope of tracehouse/tracium?

Partially, yes. I think it might be better to provide a set of utility functions for asking questions events/finding events than to annotate with boolean properties, but a isForcedStyleOrLayout helper function seems well within scope 👍

At this current stage we're pretty focused on main thread events though, everything returned by tracium occurred on the main thread so the track types identification you've referenced would definitely be out of scope for the time being.

[christian-bromann]

but a isForcedStyleOrLayout helper function seems well within scope 👍

I have an update on this: we moved a bunch of code from devtools-frontend into a new package called tracelib and rewrote all of it into TypeScript given that everything was already nicely typed in the comments (not sure which compiler made use of that though). The package offers you to get a bunch of data that would only be accessible from the devtools app, things like:

• getting the summary of main browser tasks (e.g. rendering, painting, etc.)
• get amount of warnings for forced synchronous layouts and style
• get fps numbers
• get changes for JS Heap, Documents, Nodes, Listeners and GPU Memory

We now can use this to automate performance tests for it. One of our ideas is to just scroll from the top to the bottom and allow users to assert on the average FPS rate as well as e.g. create a performance score based on the idle vs. computation time.

Is this something you are interested in as well?

[patrickhulce]

Neat library @christian-bromann, great job unraveling the devtools frontend code! :)

If you're referring to our interest level in a performance score based on the FPS scroll, I would say it's fairly low and we'd leave it up to consumers to do this sort of opinionated ranking.

If you're referring to our interest level in these other features on top of trace events like counters and warnings, it's definitely there, but there are likely other priorities in the immediate future that would put this on the back burner.

FWIW, all of those specific features you've listed should be relatively straightforward to implement on top of the tasks already provided by tracium (with some slight modifications for the 2 non-main-thread items) without redoing the entire timeline model if the maintenance burden becomes too high there in the future.