Firefox Dev Edition, but same in regular Firefox
# spicedb
n
Firefox Dev Edition, but same in regular Firefox
105.0b7
for Firefox Dev Edition, Safari
Release 153 (Safari 16.0, WebKit 17615.1.4.1)
,
104.0.2
for regular Firefox,
Version 107.0.5288.0 (Official Build) canary (x86_64)
for Chrome
on macOS
12.5.1
with Intel Architecture
Neither Chrome
Version 106.0.5249.30 (Official Build) beta (x86_64)
, this time in incognito with the default values and no extensions active whatsoever
v
seems to work here with a freshly installed firefox 🤔
n
could it be a problem with that the wasm takes very long to load?
It's also weird that the file is served to slowy, as the traceroute is pretty short:
Copy code
$ traceroute play.authzed.com
traceroute to play.authzed.com (130.211.126.102), 64 hops max, 52 byte packets
 1  ekg10-router (10.10.8.1)  0.589 ms  0.259 ms  0.257 ms
 2  780wip2.fiber7.init7.net (81.6.46.1)  0.844 ms  0.844 ms  0.590 ms
 3  r2win9.core.init7.net (141.195.80.70)  1.315 ms  1.414 ms  1.612 ms
 4  r1win12.core.init7.net (5.180.135.51)  1.294 ms  1.406 ms  1.494 ms
 5  r1zrh6.core.init7.net (5.180.135.52)  1.618 ms  1.700 ms  1.708 ms
 6  r1glb1.core.init7.net (82.197.168.223)  1.772 ms  1.790 ms  1.765 ms
 7  pni-google.init7.net (77.109.135.214)  1.095 ms  1.993 ms  1.808 ms
 8  102.126.211.130.bc.googleusercontent.com (130.211.126.102)  160.456 ms  160.380 ms  160.040 ms
j
Could be blocked by an extension or security setting
n
Tested in my Chrome in incognito with no active extensions – to no avail
j
Hrmph
v
Could the analytics requests be blocking something?
n
Could still be related to that interconnect, since it loaded very quickly on my mobile via the mobile network. And there it also worked great.
Or – better said – that the delayed loading of the wasm is breaking something, i.e. the code is expecting a quick loading of the wasm file
v
yeah but once the wasm loads, it should all happen client side, so I don't see a reason why that'd go slow
unless the analytics requests are happening synchronously to the call to wasm, and since that goes slow, makes the whole thing go slow
j
even if it delay loads, it should be cached after the first load
so then it shouldn't matter
there is a timeout, but it shouldn't be less than a few 10s of sec
n
Maybe some quota limit on the Storage? – But that would only explain the 'slow' speed. And it would be applied to 'everyone'. So probably not.
@vroldanbet can you test in your fresh Firefox what happens when you limit the bandwith with the dev tools?
v
yeah, let me give that a go
goes fast with 3G simulation
n
alright. it's me then so far. I'll look for a different computer or network and try again.
thanks so far!
v
I also deactivated caching. it was way slower, but eventually suceeded
n
switched to the mobile network. now it works. not sure what happens on my regular network.
before, when I downloaded the wasm with wget, it broke up the connection multiple times and the average speed was 50kbps 😕 something weird going on here. all good on the mobile connection. Thanks for checking and sorry for holding you guys up 😕
j
we'll see if we can move the hosting for it to a CDN
v
np!