Where the speedup stops
spryte beats PixiJS 8 by 2.7 to 3.8x per sprite on desktops and iPhones, but its bulk paths finish level on iPhones. Its own benchmark says the GPU's fill rate is the limit there, so less CPU work can't help.
debuffjp/spryte
spryte is a 2D renderer for the web built on WebGL2. Its own benchmarks claim up to 3.7x over PixiJS 8, and they also say where that stops.
The docs/benchmarks.md page has a section called "How to read these". Across the devices measured in 2dbench, spryte's one call per sprite path leads on every one: 2.7 to 3.8x on desktops and iPhones, 1.6x on an Android phone. Then comes the catch, in the project's own words: "The bulk paths finish level on iPhones, where the GPU's fill rate is the limit."
That is a cause, not just a number. spryte's gains come from doing less work on the CPU: the sprite maths moved into the vertex shader in 0.7.2, and the bulk copy path sends each instance as a single vec2 position, 8 bytes against 52. On a phone GPU that is bound by how many pixels it can fill, cutting CPU work and upload size changes nothing, because the GPU was never waiting on the CPU.
The same page is careful elsewhere. Ratios are only compared within one run, the table is one desktop machine, and the numbers from different days are called not comparable. If you draw a huge number of sprites on mobile, the one call per sprite path is where the advantage is. For bulk particles on an iPhone, expect no difference.