@wOxxOm pointed me to the source code (much thanks!).
I did a cursory review of the code and here is my summary of the Chrome DevTools performance categories.
Loading: this category includes the following events.
- ParseHTML
- ParseAuthorStyleSheet
- FrameStartedLoading
- ResourceWillSendRequest
- ResourceSendRequest
- ResourceReceiveResponse
- ResourceFinish
- ResourceReceivedData
Note that the network "in-flight" times don't appear to be included in this category. This category includes timings for setting up the network calls, but the time for the network call themselves aren't captured in the category. You can verify this by running a test in which you record both the network times on the Network tab and the performance times on the Performance tab. As an example, when downloading a page from a local server the Performance tab load time is 37 ms; the Network tab shows that 26 requests were made, of which 10 requests were satisfied by the cache, but the remaining requests took 624 ms. The 37 ms shown on the Performance tab appears to be the setup of the calls whereas the 624 ms on the Network tab appears to be the actual in-flight request/response times.
Scripting: this category includes the following events.
- EventDispatch
- TimerInstall
- TimerRemove
- TimerFire
- XHRReadyStateChange
- XHRLoad
- CompileScript
- EvaluateScript
- CompileModule
- EvaluateModule
- StreamingCompileScriptParsing;
- WasmStreamFromResponseCallback
- WasmCompiledModule
- WasmCachedModule
- WasmModuleCacheHit
- WasmModuleCacheInvalid
- MarkLoad
- MarkDOMContent
- TimeStamp
- ConsoleTime
- UserTiming
- RunMicrotasks
- FunctionCall
- GCEvent
- MajorGC
- MinorGC
- JSFrame
- RequestAnimationFrame
- CancelAnimationFrame
- FireAnimationFrame
- RequestIdleCallback
- CancelIdleCallback
- FireIdleCallback
- WebSocketCreate
- WebSocketSendHandshakeRequest
- WebSocketReceiveHandshakeResponse
- WebSocketDestroy
- EmbedderCallback
- LatencyInfo
- GCCollectGarbage
- CryptoDoEncrypt
- CryptoDoEncryptReply
- CryptoDoDecrypt
- CryptoDoDecryptReply
- CryptoDoDigest
- CryptoDoDigestReply
- CryptoDoSign
- CryptoDoSignReply
- CryptoDoVerify
- CryptoDoVerifyReply
The events in this category are what I think you would expect - script compilation, function calls, garbage collection, etc.
Rendering: this category includes the following events.
- Animation
- RequestMainThreadFrame
- BeginFrame
- BeginMainThreadFrame
- DrawFrame
- HitTest
- ScheduleStyleRecalculation
- RecalculateStyles
- UpdateLayoutTree
- InvalidateLayout
- Layout
- UpdateLayerTree
- ScrollLayer
- MarkFCP
- MarkFMP
- MarkLCPCandidate
I previously had a hard time understanding the difference between "rendering" and "painting" and this SO post helped explain the difference. In short, the rendering category relates to the in-memory computation of the layout of the page.
Painting: this category includes the following events.
- PaintSetup
- PaintImage
- UpdateLayer
- Paint
- RasterTask
- CompositeLayers
- MarkFirstPaint
- DecodeImage
- ResizeImage
The events in the Painting category pertain to actually painting the pixels on the screen.
System: this category includes the following events.
- StreamingCompileScript
- Task
- Program
Idle: this category includes the following events.
- StreamingCompileScriptWaiting
One thing that isn't clear to me is the category in which background script compilation events are tracked. This Chrome feature is mentioned here and further clarified on this Akamai page. Both the Scripting and the System category have events that seem to allude to this feature.
It's worth mentioning that Chrome appears to have a few other event categories that it tracks, but aren't visible in the DevTools. Those categories are:
gpu - this category includes the following events.
async - this category includes the following events.
experience - this category includes the following events.
