Many users experiencing extremely slow load times (or no loading at all)

[Brave-Matt]

Description

It appears that we have a good number of users reporting that the browsers load times have slowed to a crawl, if sites load at all. There don't appear to be many common threads between reports other than that. There are several reports that I will continue to add to this issue as I dig them up. One user left a recording of the behavior (shown here: https://youtu.be/KW0dPinJKBo).

So far, we've seen that:

• A couple users seem to have better results after using switching to Shields v1 (via flag), but this does not resolve the issue for all users
• Un/reinstalling resolves the issue temporarily but after a while the issue returns
• Disabling FPP did not resolve the issue
• Disabling HWA did not resolve the issue
• Clearing cache for site(s) resolves the issue temporarily (for some users) but the issue persists after a while

Steps to Reproduce

No official steps to reproduce just yet — seems to simply "happen" without any direct action causing it.

Reproduces how often:

Frequently

Brave version (brave://version info)

v1.39.111

Version/Channel Information:

• Can you reproduce this issue with the current release? Y
• Can you reproduce this issue with the beta channel? Y
• Can you reproduce this issue with the nightly channel? Y

Other Additional Information:

• Does the issue resolve itself when disabling Brave Shields? N
• Does the issue resolve itself when disabling Brave Rewards? N
• Is the issue reproducible on the latest version of Chrome? N

Miscellaneous Information:

User threads:

• https://community.brave.com/t/infinity-load-in-random-pages-slow-loading-or-no-loading/398629

[rebron]

cc: @atuchin-m @goodov We still need to get investigate and get this into a reproducible state. @nullhook Some comments that maybe shields v2 related but still need the test case to see.

[d-j-a]

cc: @atuchin-m @goodov We still need to get investigate and get this into a reproducible state. @nullhook Some comments that maybe shields v2 related but still need the test case to see.

I have recorded a few minutes of screen activity that show the issue and how I was able to reproduce it. I am happy to test and/or provide any additional information as may be helpful.

https://youtu.be/Q0W0JCGY7z4

Thanks!

[Brave-Matt]

Potentially related issues: https://github.com/brave/brave-browser/issues/23187 https://www.reddit.com/r/brave_browser/comments/v01z1c/need_to_reload_a_page_for_it_to_actually_load/ https://www.reddit.com/r/brave_browser/comments/uytxb3/brave_not_loading_certain_pages_until_i_reclick/ https://www.reddit.com/r/brave_browser/comments/v4v8h9/is_anyone_elses_brave_suddenly_much_slower_or_is/

[agalli93]

Thought I would offer a website where I can ~more consistently replicate the problem.

Using explore mode on google flights, clicking a city destination, and then clicking a flight in the results column in the left seems to 30-50% of the time cause the problem.

I've recorded some footage if it could help.

Windows 10 21H2, Version 1.39.111 Chromium: 102.0.5005.61 (Official Build) (64-bit)

https://www.google.com/travel/explore?tfs=CBwQAxoaagwIAhIIL20vMGQ5anISCjIwMjItMDYtMjMaGhIKMjAyMi0wNi0yN3IMCAISCC9tLzBkOWpycAKCAQsI____________AUABSAGYAQGyAQQYASAB&tfu=GgIgAw

Reach out if I can be of assistance.

https://user-images.githubusercontent.com/3828034/172318270-be57128d-6efe-4f04-aee5-7c67b8af19b6.mp4

[atuchin-m]

https://github.com/brave/brave-browser/issues/23187

[atuchin-m]

Thanks you guys for the reporting. Does the problem reproduces on recent nightly builds? It seem to be fixed in https://github.com/brave/brave-browser/issues/22610. If not, could please collect more details (we don't have a stable reproduction of the bug yet):

1. Does it happen only on navigations from Google?
2. Does disabling De-Amp (on brave://flags) or/and Brave Shield globally resolve the issue?
3. Could you share brave://histograms & brave://net-export/ when the problem happens? (make sure that you select Strip private information)
4. Could you please also record & share performance traces?

[atuchin-m]

The DeAmp fix was already merged in 1.39.x 5 days ago and a new version is scheduled in the next few days.

[valynor]

1. Does it happen only on navigations from Google?

Definitely NO. I have the problem on a wide variety of webpages and I don't use Google search either.

[d-j-a]

Thanks you guys for the reporting. Does the problem reproduces on recent nightly builds? It seem to be fixed in #22610. If not, could please collect more details (we don't have a stable reproduction of the bug yet):

1. Does it happen only on navigations from Google?
2. Does disabling De-Amp (on brave://flags) or/and Brave Shield globally resolve the issue?
3. Could you share brave://histograms & brave://net-export/ when the problem happens? (make sure that you select Strip private information)
4. Could you please also record & share performance traces?

Still happening on a brand new install of nightly build with amp on and off. I'll try to grab the info requested when possible.

[labrnth]

I can replicate this issue consistently with one of our vendor's support site (they use Servicenow). To complicate matters, we use Proofpoint for our email security so all URLs in our email messages are rewritten so that when the user clicks the link in the message it analyzes the URL/website first and then redirects the user to the site if it's safe.

Every time I click on one of these links to this vendor's support website it hangs and never loads.

I'll try to collect some of the requested info.

[atuchin-m]

@d-j-a I believe that in most cases the problem is triggered by DeAmp, but not it yours. Could you please collect extra details in my recent post?

[agalli93]

Disabling DeAmp did nothing for me on the release build.

Since d-j-a said it still happens on the nightly I got some net-exports just on the release. I wasn't sure what exactly to provide of the histogram? I can look into performance traces more later.

Change the .txt to .json since github wasn't happy with me uploading json.

chrome-net-export-logOneMiddleFailandLastFail.txt chrome-net-export-log3rdAnd5thFail.txt

Edit: for the 3rd and 5th fail, I did a refresh and that caused the page to load.

[radPhil]

Just had this problem again in latest Nightly (Version 1.41.42 Chromium: 102.0.5005.78 (Offizieller Build) nightly (arm64))

Here are the requested files:

Histograms.txt trace_Wed_Jun_08_2022_11.40.46.json.gz chrome-net-export-log.json.txt

Edit: I can easily reproduce it now: Search for "Brave Community" in Google. Click on first result --> empty screen. Every time.

[atuchin-m]

@radPhil thanks for the details, looking into traces. Just one sanity check: Does disabling all the extensions solve the issue?

[radPhil]

No, disabling extensions doesn't solve it.

[atuchin-m]

Thanks you all guys for the extra info.

Well, the problem seems to be more complicated. The traces help to localize the problem. We've found a broken state inside blink HTMLDocumentParser, but we're still unsure how it happens. The problem seems to be racy and hard to reproduce..

1. Does disabling all this: DeAmp, debouncing, Speedreader, Shield globally help?
2. Does the problem happen on a fresh profile (pass --user-data-dir=<some-empty-directory> to command line to launch browser on a new profile)?
3. If for 2 the answer is yes, could you try this nightly revision v1.40.57 (chrome 101), v1.40.58 (chrome 102)?

If someone other can share the perf trace, it would also be extremely helpful.

[valynor]

The latest update to Version 1.39.120 Chromium: 102.0.5005.99 (Official Build) (arm64) has not fixed it for me. Here's a way to semi-reliably trigger the bug on my system: Go to http://explosm.net/comics/latest (yes, http!). This forwards you to the latest webcomic and the server also redirects you to the https version of the site (I have upgrade to https set to off in shields). Most of the time the tab doesn't load (eternal spinner, empty dark grey page). After doing a Shift+CMD+R it loads immediately. If you try again hours later it's back to not working until you do another Shift+CMD+R.

[rudolphos]

Version: Version 1.39.120 Chromium: 102.0.5005.99 (Official Build) (64-bit)

@valynor I tried opening that website and it doesn't load. I disabled brave-shields and it started working.

@atuchin-m Disabling de-amp didn't fix it.

EDIT: @rebron Yes.. But actually the problem still persists on other pages, even with shields disabled. Only that specific page started loading without an issue with shields disabled.

[rebron]

@rudolphos Do you have other extensions installed? I'm not able to reproduce what you're seeing with shields up (or down).

Brave	1.39.120 Chromium: 102.0.5005.99 (Official Build) (arm64)
Revision	870f7bcc58dfa811cc68c2186439721385e086d0-refs/branch-heads/5005@{#1125}
OS	macOS Version 12.3 (Build 21E230)
JavaScript	V8 10.2.154.7
User Agent	Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/102.0.5005.99 Safari/537.36

[labrnth]

@atuchin-m here is a link you'll be able to reliably test against. I don't mind sharing it as doesn't contain any sensitive data. I just tested now and the page just sits there loading indefinitely until you manually reload the page (in my case ⌘ + R).

https://urldefense.com/v3/__https://beyondtrustcorp.service-now.com/kb_view.do?sysparm_article=KB0015891__;!!NRZJKXZLOPM!bKTuJlniIb0A319pyqIa59mxqDV9hMw2AnEcouPfX9VlGKIOzxFawQzZIP3-btq9cYoMQ-uCQVnvH-5c-spcvSFaoVncDXo$

[agalli93]

@atuchin-m here is a link you'll be able to reliably test against. I don't mind sharing it as doesn't contain any sensitive data. I just tested now and the page just sits there loading indefinitely until you manually reload the page (in my case ⌘ + R).

https://urldefense.com/v3/__https://beyondtrustcorp.service-now.com/kb_view.do?sysparm_article=KB0015891__;!!NRZJKXZLOPM!bKTuJlniIb0A319pyqIa59mxqDV9hMw2AnEcouPfX9VlGKIOzxFawQzZIP3-btq9cYoMQ-uCQVnvH-5c-spcvSFaoVncDXo$

Clicking this link on the release build, shields up, de-amp off, loads perfectly fine for me. Even trying it 10x over.

[labrnth]

@atuchin-m here is a link you'll be able to reliably test against. I don't mind sharing it as doesn't contain any sensitive data. I just tested now and the page just sits there loading indefinitely until you manually reload the page (in my case ⌘ + R). https://urldefense.com/v3/__https://beyondtrustcorp.service-now.com/kb_view.do?sysparm_article=KB0015891__;!!NRZJKXZLOPM!bKTuJlniIb0A319pyqIa59mxqDV9hMw2AnEcouPfX9VlGKIOzxFawQzZIP3-btq9cYoMQ-uCQVnvH-5c-spcvSFaoVncDXo$

Clicking this link on the release build, shields up, de-amp off, loads perfectly fine for me. Even trying it 10x over.

Weird, so I just tested with a new profile and that link works just fine. However in my main work profile it doesn't. I've disabled all the extensions as well and it still doesn't work in my main profile until I reload the page. I'll try with de-amp off.

[atuchin-m]

@autonomic This difference can be caused by variations/settings/extension. Could you please:

1. Restart a browser on the fresh profile and check again;
2. Post brave://version/?show-variations-cmd from the main & fresh profile here?

[labrnth]

@atuchin-m So I just checked the output of the show-varations-cmd and ran a diff against both of them and the only difference is the "Profile Path". Everything else is the same (with the extensions disabled in my main profile).

With that said I was able to get that link to work in my main profile a couple of times (not sure why), but now its back to it's old tricks and not loading.

[atuchin-m]

Thanks @autonomic Could you and other please try to launch browser with --disable-features=EarlyBodyLoad?

[radPhil]

[...] try to launch browser with --disable-features=EarlyBodyLoad?

Did it. No problem for now. Will keep using it and report back.

[labrnth]

Thanks @autonomic Could you and other please try to launch browser with --disable-features=EarlyBodyLoad?

Same thing. When I first launch the browser with --disable-features=EarlyBodyLoad that URL loads a couple of times and then stops working. After that point it just wont load anymore unless I reload the page while it's stuck.

[labrnth]

@atuchin-m Hold-up, it's now working again and consistently but I haven't changed anything. I'm still running the browser instance with --disable-features=EarlyBodyLoad. Not sure why it was briefly not working but it appears to be working now. I'll have to keep running it like this for a while to see if I see any other sites with the same issue.

[atuchin-m]

@radPhil sounds great, because I've discovered the problem in your traces ;) So it should help.

Unfortunately, I'm not sure that all of you have the same problem.

@autonomic If it doesn't helps, please record the perf traces. Also check brave://crashes just in case.

[labrnth]

@atuchin-m I spoke to soon. I just tried another site that I've had issues with in the past that uses SAML for SSO authentication to Azure AD. When I click on the application to login it redirects to login.microsoftonline.com and then just hangs. I'll try to run a perf trace.

[labrnth]

@atuchin-m Here is my perf trace trace_Thu_Jun_09_2022_7.06.17_AM.json.gz .

[atuchin-m]

@autonomic Thanks, looking into it. One extra thing to distinguish long network delays/timeout from the case I've found: for the original problem pressing the reload button should preserve the url (because the navigation is committed)

[djprmf]

@atuchin-m Answering the questions from before and expanding in the #23187 1- This happens at random website, most of the times loading contents in the pages. Sometimes also in the first load of the page. 2- Disable De-Amp, SpeedReader, Shields, etc doesn't help 3- Create a new profile doesn't help 4- Using a clean instalation - tested in a real system and VM - doesn't solve the issue 5- Clear the cache, cookies, etc, doesn't solve 6- nightly revision doesn't solve. 7- I was thinking that it could be related with DNS, but clearing the brave DNS cache, and using difrerent configurations of DNS doesn't help. 8- EarlyBodyLoad appears to help, but may be placebo. The issue it still present.

I can replicate more consistently how @valynor stated before, loading the HTTP page, where the browser tries then redirect to the HTTPS version, staying in the infinite load.

Here are some traces from two different profiles: trace_test3.json.gz

trace_test2.json.gz

[atuchin-m]

@autonomic your case is different. I see 4 navigations, but for the last navigation no bytes were sent to renderer process. Could you please make sure that it isn't DeAmp/Speedreader/Shield/Extensions? Also it will be good to verify that other browsers work as expected.

[atuchin-m]

@djprmf many thanks for detailed explanations.

I've checked your traces and the feature should fix the problem for you. The problem is that HTMLDocumentParser got stuck and the feature affect exactly the place when it got suck. https://chromium-review.googlesource.com/c/chromium/src/+/3400186

What do you mean by The issue it still present?.

[labrnth]

@autonomic your case is different. I see 4 navigations, but for the last navigation no bytes were sent to renderer process. Could you please make sure that it isn't DeAmp/Speedreader/Shield/Extensions? Also it will be good to verify that other browsers work as expected.

I've disabled DeAmp/Speedreader/Shield/Extensions and still have the issue. I've tested in other browsers with the same site and it's working fine, but not in Brave.

[djprmf]

@atuchin-m This is the trace with --disable-features=EarlyBodyLoad trace_trace4.json.gz

i can still replicate the issue with it.

[atuchin-m]

@autonomic thanks for the info.

@djprmf Surpassingly, it looks like the feature has no effect, the same "stuck" situation on traces. Could you please sanity check that you see the disabled feature on brave://version?

[djprmf]

@atuchin-m I checked and it was there. But after more digging, i clear the cache and start tested again. Until now, i don't see the issue anymore. the pages appear to load fine now. 👍

I will test a little more using the browser for some time.

[djprmf]

@atuchin-m Ok, after a little more testing, the --disable-features=EarlyBodyLoad helps, but the issue can still be notice from time to time. There are some improvements, and most of the pages now load correctly. But at random the pages enter again in the "infinity load" state.

I left here a trace where that happend. I open the website 3 times, in different tabs. the first two times, it loaded fine. In the third one, it enter in a infinity load state.

The trace is a little big to upload here, but i left the download here: https://mega.nz/file/09EhkIBA#kU4oFYDoazchLu8R6U8IsS059t2PLrRqEQrNQv7bouM

I can confirm that the --disable-features=EarlyBodyLoad is active in the command line

[radPhil]

The problem just occurred again while I was logging into Salesforce Commerce Cloud. With EarlyBodyLoad disabled everything was fine... until now 🤷‍♂️

[atuchin-m]

@radPhil I've discovered in the traces that the DocumentLoader doesn't get a signal about complete loading body. It seems that EarlyBodyLoad doesn't solve this completely, but reduces the chance of a (possible) race in the network stack that trigger the problem. It's likely that the problem primary happens with a fast/local resources. That's why I can't simply reproduce it on my own.

1. During the problem have you ever seen some content (possible partition) of a hanged page?
2. In theory Speedreader/DeAmp has some code that can trigger such behavior, but disabling them doesn't help.. Could you please try to record traces without these features enabled (disable them by brave://flags as in the comment)?

[radPhil]

Yes it is so much better with EarlyBodyLoad disabled.

1. No, the page was always empty
2. Sure! Will try to reproduce the problem and record traces.

Edit: Never happened with local resources such as Synology Diskstation...

[labrnth]

@atuchin-m here is the most resent trace I have with DeAmp/Speedreader/Shield/Extensions disabled and trying to load a site that I can reliably reproduce this issue with.

trace_Fri_Jun_10_2022_8.31.34_AM.json.gz

[valynor]

Just tested on Version 1.39.122 Chromium: 102.0.5005.115 (Official Build) (arm64), infinity loading is still present.

Cleared cache and went to http://explosm.net/comics/latest (http!) and site forwarded me to https://explosm.net/comics/armed-teachers but with blank dark-grey page and eternal spinner/infinite loading. :-| As usual site loaded normally after a Force Reload (Shift+CMD+R).

[agalli93]

Is there any more data gathering that needs to be done at this point with certain parameters or builds?

[djprmf]

Is there any more data gathering that needs to be done at this point with certain parameters or builds?

Leave as many traces as possible with the issue present.

[atuchin-m]

~~Another traces with DeAmp/Speedreader/Shield/Extensions disabled can helps (from someone else than @autonomic , thanks). It likely we found a reproduction in company, so I will be much easily to debug.~~

UPD: No more traces, I've found the way how to reproduce the issues with a code modification.

[atuchin-m]

I believe that the root of the problem is a race in Chromium navigation subsystem with the disabled NavigationThreadingOptimizations feature. The feature is explicitly disabled in Brave because it previous had a major bug (currently, it's fixed it in Chrome).

We don't know all the details now, but something was broken in M102. In case of quickly processing a navigation in renderer (maybe onLoad handlers on the previous frame), CodeCacheHost is incorrectly reset which leave the frame in infinite waiting state.

So guys, could you try to launch browser with --enable-features=NavigationThreadingOptimizations? (without --disable-features=EarlyBodyLoad, we don't need it anymore).

It resolves the problem for us and we are planning to enable it in the near future.

[djprmf]

After the --enable-features=NavigationThreadingOptimizations, i notice that the browser crashed up on startup - may have been a "one time thing".

Right now, testing and appears fine loading the pages. After loading around 100 websites, none appear to have "pending loading". Will edit this out if appears some error.

As a note @atuchin-m , since this is a major issue for many users, i think is better to enable it "asap", not in the "near future". We have already being 2+ weeks with issues, and is causing major problems in the usage of the browser daily.