Free and Open Source Speed Test. No Flash, No Java, No Websocket, No Bullshit.

Source Code

    • VerPoilu@sopuli.xyz
      link
      fedilink
      arrow-up
      13
      ·
      edit-2
      2 days ago

      The actual load test is from Netflix’s servers and Netflix’s domains. Open up the network tab in your browser debugging tool when running a speed test on fast.com and you’ll see.

      Netflix created fast.com to prove that some ISPs were throttling Netflix and hold them accountable towards their customers.

    • ForgotAboutDre@lemmy.world
      link
      fedilink
      arrow-up
      10
      arrow-down
      2
      ·
      2 days ago

      ISPs don’t see domains. Unless they control your DNS. I assume fast.com uses the same servers as Netflix and would have the same IP address, which would only be resolved to fast.com or Netflix inside Netflix’s servers. I think this is a fair assumption, as that’s the biggest benefit to Netflix. They want to prove your ISP is the problem not Netflix.

      • Rade0nfighter@lemmy.world
        link
        fedilink
        arrow-up
        9
        arrow-down
        1
        ·
        2 days ago

        Most ISPs provide their own router which will (by default) use their own DNS servers. They will use this to enforce site bans amongst other things.

        Anecdotal of course but years back I noticed my service got really slow sometimes, but speedtest.net reported decent speeds. After running the test my service would be fine… for a bit… until I ran another speed test which “fixed it” immediately again for a while.

        It got so bad that I’d be running a speed test every 45 mins or so, which would literally make Netflix etc work instantly.

        So tried just doing an nslookup on the domain out of curiosity, and wouldn’t you know it that worked too!

      • Passerby6497@lemmy.world
        link
        fedilink
        English
        arrow-up
        4
        ·
        edit-2
        1 day ago

        Your ISP can see the packets they pass, and your https headers still have the SNI field unencrypted unless you’re on a VPN or the operator has ESNI (old) or ECH (new) configured, but I don’t think these are super prevalent just yet. Having the SNI available means they can still traffic shape your packets if they have the hardware in place.