> Using the zip method saves you some of that headache/overhead with the tradeoff of having to package your images into a zip and unzip them on the client side.
I wrote an NPM module recently using this exact technique, https://github.com/deathcap/artpacks (for use in the browser with browserify). Had a bunch of small textures, originally I was requesting each individually in their own HTTP request, but zipping them up and extracting in the browser led to a fairly significant improvement in latency.
Packing all of the small textures into one big image and slicing it up at runtime was also an option I considered. In fact, since I'm using these textures with WebGL they actually are packed into one large texture atlas before uploading to the GPU, then indexed at runtime using UV coordinates. So one could stitch together all the textures beforehand, distributing a prebuilt texture atlas as a single file over HTTP — this may slightly improve performance, but it has another disadvantage.
Flexibility. For my purposes, it makes more sense to build up the atlas dynamically at runtime, since you might not know exactly what textures are needed and when (due to the nature of my application). Also, I wanted to support "cascading" textures, where multiple packs are loaded each providing possibly a subset of all textures, and the first pack with a matching texture takes priority. With unzipping at runtime in the browser, this technique was very easy to implement (without the latency cost of individual texture file requests).
And for compatibility with img src, and other HTML file references, I just convert the unzipped file to an HTML5 Blob then request its 'blob:' URI. 'data:' URIs would also work, but blobs are widely supported by modern browsers (unlike 'filesystem:' URLs, for the Web Filesystem API supported by Chrome) and don't need to encode the full file contents in the URL. The complete process, including unzipping, matching, blobbing, all happens fairly fast, have not ran into any noticeable performance issues.
(Note: technically I'm not using Stuart Knightley's JSZip, but Kris Kowal's zip module https://www.npmjs.org/package/zip - I can't recall why as they are both available on NPM, but its the same idea).
I wrote an NPM module recently using this exact technique, https://github.com/deathcap/artpacks (for use in the browser with browserify). Had a bunch of small textures, originally I was requesting each individually in their own HTTP request, but zipping them up and extracting in the browser led to a fairly significant improvement in latency.
Packing all of the small textures into one big image and slicing it up at runtime was also an option I considered. In fact, since I'm using these textures with WebGL they actually are packed into one large texture atlas before uploading to the GPU, then indexed at runtime using UV coordinates. So one could stitch together all the textures beforehand, distributing a prebuilt texture atlas as a single file over HTTP — this may slightly improve performance, but it has another disadvantage.
Flexibility. For my purposes, it makes more sense to build up the atlas dynamically at runtime, since you might not know exactly what textures are needed and when (due to the nature of my application). Also, I wanted to support "cascading" textures, where multiple packs are loaded each providing possibly a subset of all textures, and the first pack with a matching texture takes priority. With unzipping at runtime in the browser, this technique was very easy to implement (without the latency cost of individual texture file requests).
And for compatibility with img src, and other HTML file references, I just convert the unzipped file to an HTML5 Blob then request its 'blob:' URI. 'data:' URIs would also work, but blobs are widely supported by modern browsers (unlike 'filesystem:' URLs, for the Web Filesystem API supported by Chrome) and don't need to encode the full file contents in the URL. The complete process, including unzipping, matching, blobbing, all happens fairly fast, have not ran into any noticeable performance issues.
(Note: technically I'm not using Stuart Knightley's JSZip, but Kris Kowal's zip module https://www.npmjs.org/package/zip - I can't recall why as they are both available on NPM, but its the same idea).