I have set community.openstreetmap.org assets (Javascript, CSS etc) to now load via a Content Distribution Network (CDN) in an attempt to improve the site loading speed for Global Users.
Feedback appreciated. Site load any faster for you? Any issues?
From Poland - it seems to be loading slower, but maybe it is some sort of illusion.
Definitely slower. Previously I never encountered spinners when switching between threads.
But I have no idea why this would be caused by general assets being delivered from CDN, these should not be loaded on thread switching.
But still, there is a chance that it is an unrelated disruption or illusion.
site load freezed every time a few minutes before
After a restart of firefox (107) loading is now ok.
Had no problem with site load speed before anyway, feel no difference.
remark:
Effect of CDN greatly depends on region and provider.
Local provider may need some minutes to establish an effective route to new location (CDN).
I get actually 30-40 ms via 11-12 hops to community.openstreetmap.org
and 11 ms via 5-6 hops to community-cdn.openstreetmap.org (fastly.net).
All requests to community-cdn seem to be using HTTP/1.1, while community.openstreetmap.org uses HTTP/2.
This seems to depend on the browser. Firefox 106 (on Ubuntu 22.04) won’t use h3 for some reason and falls back to HTTP/1.1, while Chrome uses h3.
On tile.openstreetmap.org, which is also served by Fastly, Firefox manages to use HTTP/2.
I am using Firefox 107.0
CDN headers send have HTTP/1.1
HTTP/2 is of course more efficient than HTTP/1, but if the connection is fast enough, you won’t see a great difference
Depends on what you mean by fast enough: throughput, latency, or even both?
I think HTTP/2 should be noticeable faster, with all the small assets on this site.
Effective loading time of a page is a combination of both.
If that time is below 1 s, it does not matter for me.
Looking at the stats, a considerable amount of requests is via IPv4. That can make a difference, too.
In the meantime @Firefishy probably tweaked the settings on Fastly, as I’m getting HTTP/2 with Firefox now. Time for some retesting…
Hard page reload (ctrl-shift-R) looks quite good now. You’ll notice that all avatar images are almost instantly visible.
My Firefox 107.0 on Arch Linux is using HTTP/3 over IPv6 for community-cdn.openstreetmap.org.
Local provider may need some minutes to establish an effective route to new location (CDN).
That’s not how BGP works…
Me too, and I am seeing the same for host=community.openstreetmap.org as well (FF 107.0)
With chromium I get H2 for community.openstreetmap.org and H3 for the cdn.
EBGP is a little bit more complicated. It takes not only technical issues in account but also cost. Performance depends on your provider.
But we shouldn’t get stuck in technical details as tweaking seems to improve response.
I first only looked short on it with wireshark, but now I checked it again also with web console and see, that for this thread a mix of HTTP/3 (PNG and JPEG images loaded via internal FF/LibreWolf(also 107, with all extensions disabled, as I have many of them in my FF)-JavaScript) and HTTP/2 (direct loaded JavaScript files and stylesheets) is used.
Not counting healthchecks, most of the traffic on the CDN is using HTTP/2 or HTTP/3, and cache hit ratio is in the 80-90% range.
Right now, loading any page on this site takes about 4-5 seconds. I don’t think that it’s a network issue (that’s in a browser with all assets cached by now, on a fast network connection); it seems to be just the time taken to display everything using javascript on the fly, on a relatively low-spec PC.
I see similar effects (maybe a 3-second delay) on mobile Firefox on a recent mid-range Android phone too.
Worse than before?