Well, I meant just fixed base cost in milliseconds. In other words, how long it takes to just output something extremely simple, say, a flat shaded triangle without external libraries. Not to measure resource loading and other initialization.
Of course initialization and possible shader language, SPIR or whatever compilation will take time on top of that.
Many current WebGL apps require a lot of large data, textures, meshes and libraries. Obviously loading those will take time.
Flash had an scheduled loading scheme, so the timeline specified when an asset would be sent as you played a Flash animation. Macromedia had authoring tools which would try to slot the assets in the timeline so they'd be available when needed, while staying under a bandwidth limit.
You could, in theory, do that with WebGL. Google is all fired up about "preloading" lately. This is an authoring tool problem, and if WebGL games get serious, there will probably be author-side tools for this.
Of course initialization and possible shader language, SPIR or whatever compilation will take time on top of that.
Many current WebGL apps require a lot of large data, textures, meshes and libraries. Obviously loading those will take time.