My suggestion

Too many small PNGs will add a lot of network overhead (because of the size of the HTTP requests, but also the PNG header, and, probably even more importantly, the inability to compress efficently). On the other hand, one very large PNG has the drawbacks that it takes some time to load, and needs to stay permanently in memory (40 megabytes for 10,000 tiles) in a continuous chunk of memory.

I recommend the middle ground: several reasonably sized PNGs, for instance 1024 tiles of size 32×32. Maybe grouped by theme (for instance, a PNG with forest tiles, one with mountain tiles, another with city tiles -- I don't know the theme of your game, but you get the idea).

Note about cache efficiency

Because of memory access efficiency, you should never make your spritesheets too wide. Blitting tiles from a 128×8192 image will always be faster than blitting from a 8192×128 image.

Imagine you want to blit the first tile in a 8192×128 image. For the sake of simplicity, assume 1 pixel is 1 byte. The first two lines of pixels are laid out this way (cells contain their byte number in memory):

┌────┬────┬───┬────┬──────────┬─────┐
│  0 │  1 │...│ 31 │   ....   │ 8191│
├────┼────┼───┼────┼──────────┼─────┤
│8192│8193│...│8223│   ....   │16383│
└────┴────┴───┴────┴──────────┴─────┘

So in order to blit the first line of the first title, the browser engine will retrieve bytes 0 to 31. To blit the second line, it will retrieve bytes 8192 to 8223, and so on until the 32nd line where bytes 253952 to 253983 are retrieved.

The total number of processed bytes will be 32×32. However, the total byte range is more than 253984 bytes. On a modern CPU, this means 32 or 33 cache stalls. In contrast, if the image was 128×8192, the memory range would be only 4000 bytes, which means no more than two cache stalls.

Because today's CPUs are very fast, cache stalls are very expensive and hang computations. So using a 128×8192 image instead of a 8192×128 image is potentially 8 times as fast, in theory at least. In practice this will depend how the blitting is implemented: it is possible that the underlying engine itself splits images into tiles to reduce the problem.

This isn't easy to explain correctly and I didn't expect to elaborate much. I hope it makes sense!

My suggestion

Too many small PNGs will add a lot of network overhead (because of the size of the HTTP requests, but also the PNG header, and, probably even more importantly, the inability to compress efficently). On the other hand, one very large PNG has the drawbacks that it takes some time to load, and needs to stay permanently in memory (40 megabytes for 10,000 tiles) in a continuous chunk of memory.

I recommend the middle ground: several reasonably sized PNGs, for instance 1024 tiles of size 32×32. Maybe grouped by theme (for instance, a PNG with forest tiles, one with mountain tiles, another with city tiles -- I don't know the theme of your game, but you get the idea).

Note about cache efficiency

Because of memory access efficiency, you should never make your spritesheets too wide. Blitting tiles from a 128×8192 image will always be faster than blitting from a 8192×128 image.

Imagine you want to blit the first tile in a 8192×128 image. For the sake of simplicity, assume 1 pixel is 1 byte. The first two lines of pixels are laid out this way (cells contain their byte number in memory):

┌────┬────┬───┬────┬──────────┬─────┐
│  0 │  1 │...│ 31 │   ....   │ 8191│ 1st line of pixels: bytes 0 to 8191
├────┼────┼───┼────┼──────────┼─────┤
│8192│8193│...│8223│   ....   │16383│ 2nd line of pixels: bytes 8192 to 16383
├────┼────┼───┼────┼──────────┼─────┤
│ .. │ .. │...│ .. │   ....   │ ... │

So in order to blit the first line of the first title, the browser engine will retrieve bytes 0 to 31. To blit the second line, it will retrieve bytes 8192 to 8223, and so on until the 32nd line where bytes 253952 to 253983 are retrieved.

The total number of processed bytes will be 32×32. However, the total memory range is more than 253984 bytes. On a modern CPU, this means 32 or 33 cache stalls. In contrast, if the image was 128×8192, the memory range would be only 4000 bytes, which means no more than two cache stalls.

Because today's CPUs are very fast, cache stalls are very expensive and hang computations. So using a 128×8192 image instead of a 8192×128 image is potentially 8 times as fast, in theory at least. In practice this will depend how the blitting is implemented: it is possible that the underlying engine itself splits images into tiles to reduce the problem.

This isn't easy to explain correctly and I didn't expect to elaborate much. I hope it makes sense!

Too many small PNGs will add a lot of network overhead (because of the size of the HTTP requests, but also the PNG header, and, probably even more importantly, the inability to compress efficently). On the other hand, one very large PNG has the drawbacks that it takes some time to load, and needs to stay permanently in memory (40 megabytes for 10,000 tiles) in a continuous chunk of memory.

I recommend the middle ground: several reasonably sized PNGs, for instance 1024 tiles of size 32×32. Maybe grouped by theme (for instance, a PNG with forest tiles, one with mountain tiles, another with city tiles -- I don't know the theme of your game, but you get the idea).

Note also that because of memory access efficiency, you should never make your spritesheets too wide. Blitting tiles from a 128×8192 image will always be faster than blitting from a 8192×128 image.

My suggestion

Too many small PNGs will add a lot of network overhead (because of the size of the HTTP requests, but also the PNG header, and, probably even more importantly, the inability to compress efficently). On the other hand, one very large PNG has the drawbacks that it takes some time to load, and needs to stay permanently in memory (40 megabytes for 10,000 tiles) in a continuous chunk of memory.

I recommend the middle ground: several reasonably sized PNGs, for instance 1024 tiles of size 32×32. Maybe grouped by theme (for instance, a PNG with forest tiles, one with mountain tiles, another with city tiles -- I don't know the theme of your game, but you get the idea).

Note about cache efficiency

Because of memory access efficiency, you should never make your spritesheets too wide. Blitting tiles from a 128×8192 image will always be faster than blitting from a 8192×128 image.

Imagine you want to blit the first tile in a 8192×128 image. For the sake of simplicity, assume 1 pixel is 1 byte. The first two lines of pixels are laid out this way (cells contain their byte number in memory):

┌────┬────┬───┬────┬──────────┬─────┐
│  0 │  1 │...│ 31 │   ....   │ 8191│
├────┼────┼───┼────┼──────────┼─────┤
│8192│8193│...│8223│   ....   │16383│
└────┴────┴───┴────┴──────────┴─────┘

So in order to blit the first line of the first title, the browser engine will retrieve bytes 0 to 31. To blit the second line, it will retrieve bytes 8192 to 8223, and so on until the 32nd line where bytes 253952 to 253983 are retrieved.

The total number of processed bytes will be 32×32. However, the total byte range is more than 253984 bytes. On a modern CPU, this means 32 or 33 cache stalls. In contrast, if the image was 128×8192, the memory range would be only 4000 bytes, which means no more than two cache stalls.

Because today's CPUs are very fast, cache stalls are very expensive and hang computations. So using a 128×8192 image instead of a 8192×128 image is potentially 8 times as fast, in theory at least. In practice this will depend how the blitting is implemented: it is possible that the underlying engine itself splits images into tiles to reduce the problem.

This isn't easy to explain correctly and I didn't expect to elaborate much. I hope it makes sense!