[^1]: Ignoring the Ubuntu font, which is 301kB on its own but can load slowly and separately, and is not needed for page functionality.
This is quite good! It's significantly smaller than even a single puzzle screenshot would be, in a lot of cases.
However, there are some issues, like:
three doesn't code split well, and is imported basically in its entirety for cubing/bluetooth just in case we need it for quaternion code when connecting to a Gan bluetooth cube.
Due to dynamic imports that enable some of the total transfer bytes savings, we sometimes have to make more round trips than otherwise. On connections with decent bandwidth and high latency, this can actually cause the page to load longer. This might be tricky to optimize, but it's definitely possible (e.g. find a way immediately fetch the Cube3D and three code on page load if we're "sure" that we'll be rendering a 3D cube, possibly based on URL parameters and server-side edge workes).
Inside our JS bundle, we currently bundle unoptimized CSS and data structures (e.g. JSON, SGS data) that could be compressed better. If the ecosystem evolves enough, we may be able to move the outside JS without too much penalty.
We use an inline WASM build, but we could try to get most bundlers to load it from an actual file, which might improve caching and instantiation.
Right now, we use
esbuildwith--bundle --splitting, which is quite good at enabling a page to load only the code that it needs. For example:<twisty-player>code if you just need scrambles, and vice-versa.This allows the following page to load using only 106kB transferred over the internet[^1]: https://alpha.twizzle.net/edit/?puzzle=clock&alg=UR1%2B+DR4-+DL4%2B+UL3-+U2%2B+R4%2B+D3-+L2-+ALL2-+y2+U1%2B+R5%2B+D4-+L2%2B+ALL3%2B+UR And puzzles with 3D visualization load in ≈266kB[^1].
[^1]: Ignoring the Ubuntu font, which is 301kB on its own but can load slowly and separately, and is not needed for page functionality.
This is quite good! It's significantly smaller than even a single puzzle screenshot would be, in a lot of cases.
However, there are some issues, like:
threedoesn't code split well, and is imported basically in its entirety forcubing/bluetoothjust in case we need it for quaternion code when connecting to a Gan bluetooth cube.Cube3Dandthreecode on page load if we're "sure" that we'll be rendering a 3D cube, possibly based on URL parameters and server-side edge workes).