Repository navigation
Make compressed site friendly for hosted static sites. #293
Description
Activity
This is (to my knowledge) not feasible:
If the server doesn't send theContent-Encoding: gzipheader, then the browser doesn't do the decompressing natively. Which would mean that the web-app needs to manually decompress the tiles through JavaScript. Which (i tried, and) is incredible slow.Reacted by Yi CaoI am not sure what i tried before, and if i tired it with pako .. i can put this somewhere in the TODO, but testing this will be very low prio. And will probably not happen in the near future (unless someone else PRs it)
I totally understand this. I’ve found an alt btw. Thanks for all the support.
I feel this would be extremely nice to have. For example, S3 or B2 storage fronted with a CDN provider such as CloudFront, CDN77, or Bunny.net.
But that also begs the other request, push direct to an external storage and don't maintain a local copy.
Reacted by StephanWith the Compression Streams API (which has baseline/widely available support according to MDN), it should be possible to use the browser's native gzip decompression. If support for browsers older than 2023 is desired, then I hear wasm gzip libraries are faster than any pure JS implementation.
In any case, I would find this feature very useful, and I might be interested in implementing it. I'm not too familiar with the BlueMap project structure, but I assume the implementation steps would be:
- In TileLoader.js Detect if the server only sends compressed PRBMs (somehow?)
- Instead of the Three.js FileLoader, fetch the
*.prbm.gzourselves and decompress - Parse the decompressed data with PRBMLoader() as normal
Are there any other caveats to be aware of? Other non-PRBM files that need decompressing elsewhere?
@fechan
The Compression Streams API is the way this should be implemented, yes 👍.
However, the current plan is to first do a complete rewrite of the webapp which is already in-progress. After that, issues like this one would be adressed.If you still want to implement this into the old webapp (as i can make no guarantees on how long the rewrite will still take me), here are my thoughts:
- In TileLoader.js Detect if the server only sends compressed PRBMs (somehow?)
Instead of a detection i would prefer a simple setting in the webapps
settings.json:)- Instead of the Three.js FileLoader, fetch the *.prbm.gz ourselves and decompress
- Parse the decompressed data with PRBMLoader() as normal
Sounds good
Are there any other caveats to be aware of? Other non-PRBM files that need decompressing elsewhere?
The
maps/<map-id>/textures.jsonis stored compressed (textures.json.gz) as well in the latest versions. Other then that, i don't think there are any more caveats :)Reacted by Yi Cao- moved this from Distant Ideas / To be discussed to Ready for next release in TODO / Idea board
on Aug 6, 2026
Is your feature request related to a problem? Please describe.
One of the benefits of static sites is it can be served through static site hosting providers. However when it comes to gzip compressed sites the wiki redirects the
.jsonto.json.gzwith aContent-Encoding:gziphttp header. However not every (little) hosting providers have this kind of functionality.Describe the solution you'd like
Instead of the full server side method, the client can have an idea about whether the site is compressed and fetch the gzips automatically.