You should check with your IT helpdesk about why they are blocking certain sites or slowing traffic down. Your using their internet so they choose how it functions as well. Also this is a forum user help not a support ticket request line.

Hi Mark. Corporate firewalls aren't new. And blocking all internet traffic except for specific sites isn't that unusual either. I realise this is a community forum and not a commercial support site but I was hoping that someone else might have come across this problem and worked out what functionality in Firefox v132 and v133 might be causing the issue.

You can use the Timing section of the Network Monitor (Ctrl+Shift+E) to see where the wait times are for specific requests. Generally speaking, you will need to reload the site after opening the Network Monitor, and you might want to bypass the cache (Ctrl+Shift+R) to rule out a cache access bottleneck as an issue.

Ref. https://firefox-source-docs.mozilla.org/devtools-user/network_monitor/index.html

Recent threads on r/Firefox on Reddit are associating a lot of mid-session slowdowns with use of YouTube, and particularly higher-than-full-HD video (like 1440p). Users can try terminating YouTube processes (using the built-in Task Manager about:processes, at Shift+Esc) and if they experience immediate relief, it could be the same (as yet unsolved) issue.

What operating system are you on?

Would it be possible for you to use the profiler to see what is happening?

https://profiler.firefox.com/

I had been using the Network Monitor to try to narrow down what might be occurring but the first Get request for each website I've been trying is where the delay seems to occur. The screenshot I have uploaded shows a blocked time of 18.91 seconds to respond to a request for https://www.microsoft.com It is representative of what I am seeing when I try to get to some other websites we use. If I uninstall Firefox v133 and reinstall v131 and retry I get responses from the same websites in times ranging from 0.3 seconds to 2.0 seconds but nothing like the 18-20 I am getting consistently on v132 and v133.

In this case Firefox is installed on Windows Server 2019 (i.e. Windows 10 equivalent). The environment doesn't currently allow access to the profiler website but I will see if I can get the firewall temporarily changed to allow it to test that out.

You can also use mozregression to find affecting commit.

Yeah, I second what TyDraniu said, but that might be hard behind the firewall. We really need to figure out what caused it.

Hi Steve,

Could you also try to capture a http log? https://firefox-source-docs.mozilla.org/networking/http/logging.html#using-about-logging

In about:logging, please select "logging to file" and send the log to necko@mozilla.com.

Thanks.

I've not used mozregression before but I gave it a go. I got mozilla.org and mozilla.com temporarily added to the firewall to allow my test machine access to retrieve the nightly builds and ran the bisection. The attached screenshot shows build 920dd9bc was returned at the end of the process.

When running mozregression I marked a build a good if the website loaded in less than a second and bad when it showed the 18.xx second duration for Blocked, etc, as per my earlier screenshot.

Does this help? Is there anything else I can/should do at this point?

That points to

https://hg.mozilla.org/mozilla-central/rev/920dd9bc5aeb2e00cf951878e7dead42f1ef9c30

which probably isn't it.

Was there something in the bottom window?

I've rerun the same bisection again and got the same result. Screenshot of the full mozregression window attached.

To try to confirm that mozregression was getting accurate results I also tried manually downloading the Firefox Nightly builds from https://ftp.mozilla.org/pub/firefox/nightly/2024/09/ for the 16th and 17th.

When I accessed the test site from the build stored at 2024-09-16-21-52-24-mozilla-central/firefox-132.0a1.en-US.win64.installer.exe I got the desired result (sub 1-second reponse)

I repeated the same test using the build stored at 2024-09-17-09-28-38-mozilla-central/firefox-132.0a1.en-US.win64.installer.exe and got a 18.96 second blocked time

I'm not 100% sure how to tell what was included in each of those two builds but it points to the same timeframe as mozregression.

Try to switch security.tls.enable_kyber to false in about:config (+restart).

Thank you all for your assistance on this perplexing problem. I'm not sure how the security.tls.enable_kyber setting is working but disabling it has resolved the issue without me having to get the firewall changed to allow any:any Thanks again

Are you by chance using any of the devices at the bottom of this post:

https://tldr.fail/

Hi Mike I'm accessing the websites from a Windows Server 2019 instance which in this case is running within an AWS virtual machine and none of the devices listed on the tldr.fail site align with that. I don't have any direct knowledge of what sort of infrastructure the destination sites are hosted on so I can't rule it out completely but it seems unlikely to be the culprit.

Out of interest I also tried experimenting on a brand new Windows Server 2022 instance (i.e. Win11 equivalent). I was getting the same 18-20 second blocked timings within Firefox until I switched the kyber setting at which point they went back to a more normal sub-1-second response.

This means that the two solutions I have found to work so far are: 1. set security.tls.enable_kyber to false 2. allow the browser to access to all websites on our network firewall Option 2 is not really an option for me so I will be implementing Option 1

I don't understand why having security.tls.enable_kyber set to True would lead to Firefox accessing an external website for some reason that, when it can't reach it, would cause a roughly 18 second delay. But that is what seems to be occurring.