js: slow to load due to no network parallelism

[eddy-geek]

When using pmtiles.js, network performance is a big bottleneck.

This is visible in the leaflet raster demo but mitigated by a very fast backend (read from a small pmtiles file), so response-time is ~15ms per tile.
Still you can see in the chrome dev tools that each fetch request is "stalled" (queued) until the previous one is answered.

My setup responds in ~150ms per tile, so time from scrolling to display is several seconds.

How can this be optimised?

• Reducing number of requests using Multipart Ranges does not seem possible without adding complexity to the leaflet integration.
• ... but according to chrome we're supposed to have up to 6 concurrent TCP connections per origin?

[bdon]

What HTTP server are you using to serve the PMTiles archive? This should only be dependent on your backend concurrency, and shouldn't have to do with pmtiles.js beyond needing to fetch directories.

[eddy-geek]

I am using scaleway object storage. But again the issue is the same with your sample with your DigitalOcean backend.

Here are screenshots:

The fact that the DevTools highlight it as stalling (grey strip above) and not just slow response (TTFB, green) points to a frontend bottleneck IMO.

[bdon]

The sample uses GitHub pages which uses GitHub's CDN (Fastly)

I can't reproduce this in Chrome Devtools, here's what my requests look like (multiple in parallel)

[bdon]

Can you turn on the "Protocol" column to verify that your browser is making requests using HTTP/2 instead of HTTP/1.1?

screenshot of "h2":

[bdon]

I'm doing some testing with Scaleway and it's pretty likely it doesn't support HTTP/2 out of the box, but this is a limitation of the backend and most S3-like APIs - the same latency should appear if you expanded tiles into directories in a bucket like /Z/X/Y.png.

[eddy-geek]

Indeed I found the same thing.
But I do also have an issue with my chrome setup, which somehow prevents parallel request. Switching to firefox is much faster both with your HTTP/2 demo and my HTTP/1 project (where I get at least the 6x parallelism).
Thanks for the quick answer!

[bdon]

Note: I should improve the docs somewhere indicating which static storage providers implement HTTP/2, as I think the parallel request issue will affect a lot of use cases. Thanks for giving PMTiles a spin!

[eddy-geek]

Good idea.
For the record, I just tried Backblaze B2, and it does not seem to accept http2 if I trust curl --http2.
I guess I'll try DigitalOcean next. Do you know of any other?

[eddy-geek]

Another perf gotcha: no caching of range requests in firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=1615698

[bdon]

@eddy-geek interesting, thanks for the link! I'll investigate with Firefox more and see if there's any progress to be made there.

[bdon]

I've done some research and updated the storage provider docs: https://protomaps.com/docs/pmtiles/storage-providers

As far as I can tell, Google Cloud Storage is the only major provider that supports HTTP/2 out of the box for static, single-region content. The core reason the others don't is probably to differentiate their more expensive CDN, multi-region products (CloudFront, etc) from the basic storage service.