-
Certain pages will stop loading at a certain point and sit idle for anywhere from 3s to a full minute. The time is often suspiciously close to a multiple of 10s.
-
This is largely a problem because a bunch of JS that actually makes the damn page work doesn't fire until after the delay.
-
While idle, Firefox is responsive, but the throbber (swirly loading animation on the tab) is active, and the "status bar" says "Waiting for" the name of some CDN. Sometimes it says "Read" or "Reading data from". I suspect this might be a red herring, and Firefox is just showing the last relevant network message for some reason.
-
It looks like something is delaying script execution, which delays
DOMContentLoaded, which delays a bunch of stuff from running. In the case of GitHub, some profiling revealed that the only script on the page doesn't actually run (sometimes!) until 20 seconds have passed. The script downloads almost instantly, but it doesn't actually execute. -
The Network tab in Firefox's dev tools does not attribute the long delay to any kind of network problem. It claims that the CDN request finishes almost instantly.
-
So far I've only seen this happen on Twitter, GitHub, Dropbox, and YouTube.
This problem is intermittent, so it's hard to tell for sure if I've fixed it or just gotten lucky. It seems to get worse the longer I have my browser open, and a force-refresh makes it much more likely.
I do have a lot of tabs? I don't know how that would directly relate.
It can't be the network, because I can't reproduce in Chromium, and I haven't witnessed any similar problem with any other program or on any other computer in our house.
It can't be the browser, because I can't reproduce in a clean profile.
It can't be addons, because I disabled all of them and still had the problem.
It can't be the cache, because force-refreshing is how I've been reproducing in the first place.
It seems unlikely to be a fundamental problem with the pages themselves, since it happens on several sites, and apparently just for me.
As previously mentioned, the Network panel in the Firefox dev tools claims that all of these requests finish in under 100ms, even though the status 'bar' would seem to disagree.
I've been hammering on this page, and the results are:
- Requests to
avatars#.githubusercontent.comare sent out, and complete successfully. - ABSOLUTELY NOTHING HAPPENS FOR TWENTY SECONDS. During this time, Firefox says "Waiting for avatars#.githubusercontent.com..."
- A request to
collector.githubapp.comsends and completes successfully. - Then same for
www.google-analytics.com,live.github.com, andapi.github.com. - Finally, the page becomes usable, by which I mean the
...expando buttons on commit messages respond to clicks.
Running the Firefox profiler during a "broken" page load reveals nothing. There's a lot of incremental GC, but the page itself seems to be doing nothing whatsoever. Then inline scripts execute, seemingly for no particular reason, and that allows DOM ready to fire.
I don't know what I'm doing here, but here's a rough timeline from a request I captured, as organized into TCP conversations by Wireshark. (The times don't start at 0 because I had to alt-tab and hit refresh, of course. I trimmed everything from before the first request I made to the main github.com IP.)
| Port A | Address B | Port B | Bytes | Rel Start | Duration |
|---|---|---|---|---|---|
| 48152 | 192.30.252.128 | 443 | 27340 | 0.583454737 | 10.375929519 |
| 48154 | 192.30.252.128 | 443 | 16379 | 0.584616081 | 6.1118591030 |
| 47060 | 199.27.79.133 | 443 | 44721 | 1.165613135 | 20.131691976 |
| 47062 | 199.27.79.133 | 443 | 85084 | 1.168825549 | 20.191475131 |
| 47064 | 199.27.79.133 | 443 | 76664 | 1.173414933 | 20.146767788 |
| 47066 | 199.27.79.133 | 443 | 143186 | 1.176510361 | 20.208427464 |
| 47068 | 199.27.79.133 | 443 | 1768 | 1.188077705 | 5.4528093880 |
| 47070 | 199.27.79.133 | 443 | 1768 | 1.188125779 | 5.4527716260 |
| 47072 | 199.27.79.133 | 443 | 7852 | 1.204606029 | 20.147728577 |
| 47074 | 199.27.79.133 | 443 | 13142 | 1.217547203 | 20.108879500 |
| 47076 | 199.27.79.133 | 443 | 11790 | 1.227242183 | 20.154673147 |
| 47078 | 199.27.79.133 | 443 | 4556 | 1.230630696 | 20.095215418 |
The 20s durations are a little misleading; that's just when I stopped the packet capture, because the page had finished loading.
192.30.252.128 is github.com; 199.27.79.133 is their CDN, including assets-cdn and avatars#.
I don't understand the second connection to 192.30.252.128. The first one transfers roughly the size of the page, and the Network panel doesn't show anything else being downloaded from that IP.
Looking at the actual packets, what happens is:
- 1.33s: CDN data appears to finish downloading. Nothing else happens until...
- 1.97s: DNS lookups for all the CDN IPs again (?). Again, nothing more until...
- 5.60s: I send several TLS alerts to the CDN, and receive alerts back.
- 6.60s: I send a few more alerts, and receive some back.
- 6.70s: I go back and forth with the main github IP a few times, receiving a single packet and sending back a RST. This all happens on the second connection.
- 10.89s: I receive a single TLS alert from the main github IP, on the first connection. A few ACKs go back and forth, and then that connection closes.
- 11.26s – 11.35s: I send a bunch of TCP keep-alives to the CDN. Nothing more happens until:
- 21.30s: I send a bunch of TCP keep-alives to the CDN, again.
- 23.65s: DNS lookup for
collector.githubapp.com, and the page loading resumes.
I stress that there was no network activity whatsoever with GitHub addresses in those large gaps.
Does this only occur on TLS/SSL webpages? If it resets with a clean profile, could it be a SSL-related browser setting that's broken for some reason?