How the duration is measured
This benchmark tries to measure the duration of some table operations in the browser. That means we want to compute the duration starting from the click event until all repainting has finished.
An alternative approach would be to measure just the javascript duration. We're not going this approach since we're interested in the complete client side duration (wall clock) and that includes the duration for rendering.
Let's take a look at the performance tab:
The selection shows what we want: The duration is the timespan from the start of the click to the end of the paint event.
Painting events are colored green. So we're looking for the end of the green bar.
Chrome automation tools like puppeteer, playwright and webdriver can log the same events that the performance tab uses for its display.
The click event is pretty easy to identify and the invariant is that there must be exactly one such event. We're interested in the start timestamp of that event.
Some frameworks will perform the javascript logic during the click event which is the simplest case shown above.
Other frameworks can delay javascript logic and execute them in a request animation frame callback or a timer event like shown here:
Can you spot the problem? There are two green bars. A small one after the click and the other after the timer. We're interested in the second green bar.
Due to some changes prior to chrome 117 there's now a commit event that marks the end of rendering:
Duration is measured as the difference between the start of the click event and the first commit event that follows the last fireAnimationFrame, timerFire, layout or functioncall event. If no commit event is found this way take the last commit event. Only events of the main browser process are processed.
There are a few unit tests for that logic implemented in computeDuration.test.ts. We'll go through them here. The selection displays the duration we're measuring.
cample causes a commit event on other processes. We're only processing events of the main browser process, i.e. the events outside the selection are ignored.
Better react has two commit events. A very small one near the blue line and a second after function call and layout. The second commit is used, since it's the commit after the layout.
Select causes no layout event for most frameworks. For arrowjs we want the commit after the function call (below the timer):
dojo issues two commit events. The first after a layout event, but then a fireAnimationFrame event causes a second commit, which we take as the end point:
If we zoom in we see both commits:
blazor-wasm has a timer callback that doesn't cause any rendering. We're using the commit event before that timer.
Some frameworks have hit tests and a commit following the hit test. We're ignoring this combination since we're using the first commit after a fireAnimationFrame, timerFire, layout or functioncall.
- Disussions for this WIKI page: https://github.com/krausest/js-framework-benchmark/discussions/1381
- Overiew RenderingNG: https://developer.chrome.com/articles/renderingng-architecture/#rendering-pipeline-structure
- Trace format: https://docs.google.com/document/d/1CvAClvFfyA5R-PhYUmn5OOQtYMH4h6I0nSsKchNAySU/preview?pli=1#heading=h.yr4qxyxotyw