Ok, for instance, there is calculations of light at early runtime:
- You have a material that is about to load [at initialize] a complex set of submaterials (f.i. large dimensioned normal map + other asset textures). This is one material of many.
- This is then handled (at least precalculated … I guess) by the PC-renderer but with a complex set of light sources, multiple cameras with each their layers, effects, individual settings etc.
- Another layer of lighting is then put into the mix; Lightmapping plus a heavy cubemap environment. Times passes (microseconds … milliseconds), and then/only now the first frame/update is executed.
It might sound straight forward, but if it is too heavy to execute smoothly, I/developers might run into trouble.
I can use the Profiler to see some of it, but it seem too confusing (with 6-8 yellow lines of progress in realtime) to get a real overview in regards to optimizing 1-to-3 above. I cannot console.log those parts of the startup as they lay too early (the console/network helps some though [SOLVED] Trouble accessing children in a glTF-imported file (load externally)).
Yes, the whole page of https://developer.playcanvas.com/en/user-manual/scripting/anatomy/ is quite helpful (including the lines about ‘initialize’), but a better PlayCanvas-team elaborated ‘console output’ -clustertext in regards exact “what-does-what-and-when” within early calculations like 1-3 above can detail the processes (this option can be a button for optional use within the Profiler -> a text that can be copied/saved for the calm and analytic developer).
In my case I am seriously considering a JS-GPU performance splash-redirectingpage before the PC-preloader page, as so many platform-GPUs performs differently (tried a PC-project on a 6 year old Smart-tv … did not go well (mostly due to non-tick of preloads I presume, but could not find the GPU-perf. or timeout specs on the platform anyway)).
“Pipeline overview illustrations” would still be very helpful regardless 
… such as this (had similar illustrations at my uni/BA):
http://15462.courses.cs.cmu.edu/fall2015/lecture/pipeline/slide_046
PS: I hope that your team will pursue ‘a higher end’ in these regards of more/better info-pages … I had, for instance, a good experience with using the guidelines within [SOLVED] Physics mimic lighter than air gas particle, but afterwards I could not debug the physics part of the profiler properly -> should I lower update rate at physics/XYZ-translation script to render ‘my particles’ more smoothly? [please dont answer this now -> cluster-output text and/or pipeline illustrations would help]
// on before hand thanks …