You probably don't want to take apart the web player, though you could try. It'd likely be easier to use spine-ts instead, which the web player is written on top of. You could see the WebGL demos, though they have a little scaffolding for the demos. See here for a pretty barebones implementation:
http://esotericsoftware.com/files/runtimes/spine-ts/webgl/example/test.html
You could still use what you find in the demos source code for ideas on what is possible with the API.
Keep in mind if your bottleneck is not what the player adds to spine-ts, then you may not see any improvement at all for your effort. As with all performance optimizations, ideally you correctly identify the bottlenecks first, then optimize what gives you the biggest improvement.
I doubt any other runtime (eg pixi.js) would be faster, as spine-ts for WebGL is doing only the minimal work necessary. Most game toolkits will have a lot of other stuff. That can be great if you need it, but not if you just want to display animations.
We have revised the spine-ts page. Please see the new examples section, specifically the new part about WebGL examples:
spine-runtimes/spine-ts at 3.8
The barebones.html
you'll find there is better than the test.html
I linked above.
Note my guess is still that using the player is fine and that the time is taken for downloading and browser processing.