Is there a site that is particularly bad?

No, not really.  It seems that any site that uses a Google API takes forever to load, if it loads at all.

I too am having this issue. Any site loading an external Google resource either never loads or takes a few minutes. Stackoverflow is one I've noticed the issue on and once the page loads there there is a bar on the top indicating the site requires external javascript to function and that the scripts couldn't be loaded. The scripts are loading from Google domains.

I however don't get those same messages regarding external javascript.  The webpages simply do not completely load for me while waiting for the Google APIs.

I've seen this once or twice in the console of chrome. (messages like this)

jsapi:22 A Parser-blocking, cross site (i.e. different eTLD+1) script, https://www.google.com/uds/api/search/1.0/890e228675e68570fa203500d9572ad4/default+en.I.js, is invoked via document.write. The network request for this script MAY be blocked by the browser in this or a future page load due to poor network connectivity. If blocked in this page load, it will be confirmed in a subsequent console message.See https://www.chromestatus.com/feature/5718547946799104 for more details.
google.loader.f	@	jsapi:22

Is it only websites that use Google APIs that are slow, or are Google websites slow as well?

Try disabling QUIC and seeing if that helps. Copy the following URL to the location bar: chrome://flags/#enable-quic (clicking it will not work). Select "Disable" from the drop down menu and then restart the browser.

If this doesn't help I suggest changing it back to "Default" afterwards.

In order for Chrome developers to be able to debug the problem they will need more information. See https://dev.chromium.org/for-testers/providing-network-details for how to create a network log.

It only appears to be websites using Google APIs/Resources and not Google websites as well -- with the exception of the "gmail.com" domain. I have often just typed 'gm' into my browser url bar and "gmail.com" is autofilled and I submit; that is typically how I access my Gmail inbox from my desktop.

Lately that domain does not work. I do not get redirected - instead I have to go to mail.google.com manually to access my inbox. 
--
re: QUIC - I had found that suggestion a few days ago and tried it. There was no improvement. I set the flag back to Default settings.
--

I have attached two network logs.

"chrome-net-export-log_gmail-com_standard_profile.json" is me attempting to access gmail.com from my regularly used user profile in Chrome.

"chrome-net-export-log-stackoverflow-com_guest_profile.json" is me attempting to access stackoverflow.com from the "Guest" profile in Chrome. I  did this to hopefully rule out any extensions that could be causing the problem (though I have already tried disabling almost all extensions in various combinations to isolate the issue)

Please let me know if there is anything else you need to help move forward towards a resolution in this issue.

Deleted: chrome-net-export-log_gmail-com_standard_profile.json 1.3 MB

chrome-net-export-log_gmail-com_standard_profile.json 1.3 MB View Download

Deleted: chrome-net-export-log-stackoverflow-com_guest_profile.json 1.8 MB

chrome-net-export-log-stackoverflow-com_guest_profile.json 1.8 MB View Download

@ricea, the issues appear for me only on websites that use Google APIs.  I actually had QUIC disabled already but per your advice I changed the setting back to "default".

Below is the network log for approximately the past 3 hours.

Thanks for your help.

David

Deleted: chrome-net-export-log.json 30.4 MB

chrome-net-export-log.json 30.4 MB Download

Thank you for providing more feedback. Adding requester "ricea@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Network component is probably a better starting point for triaging this further.

@kenjibaheux@chromium.org

What are you suggesting? Is there something else we can provide? I noticed today a few times a site would load fine and others it continued the slow/non loading behavior while waiting for Google resources.

There was also at least three other occurrences of the issue in console linking to https://www.chromestatus.com/feature/5718547946799104

Here are a couple things to try that will help us to narrow down the problem:

1. If you completely close the browser, and start it with the --disable-quic flag, do you still have the problem?

2. If you open an incognito window and browse to the site, do you still have the problem?

Thanks!

Disabling the QUIC flag has not made a difference. 

Yes, using incognito experiences the same issue. 

Can you provide a net-internals log from when you connect to a site over incognito?

Sorry for the delay but here you go, svaldez.  This is the net log when I was using Chrome incognito.  I had to upload it to Dropbox since the file was apparently too large to upload here:  https://www.dropbox.com/s/j7u48z6lq0z3tql/chrome-net-export-log-incognito.json?dl=0

Thanks again.

David

Thank you for providing more feedback. Adding requester "svaldez@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Thanks for the log. Sending to this to the HTTP2 component because it looks like a bug there.

In all of the netlogs on this bug, I see a few HTTP2_SESSIONs with a gap of several minutes (or until logging stops) between RECV_GOAWAY with error_code COMPRESSION_ERROR and SESSION_CLOSE. I'm assuming that's not expected behavior. Search for type:URL_REQUEST sort:duration to find them. Here's an example, from event 10613 in the log in comment 9:

t= 325051 [st=    25]    HTTP2_SESSION_RECV_GOAWAY
                         --> active_streams = 2
                         --> debug_data = "[0 bytes were stripped]"
                         --> error_code = "9 (COMPRESSION_ERROR)"
                         --> last_accepted_stream_id = 3
                         --> unclaimed_streams = 0
t=1118199 [st=793173]    HTTP2_SESSION_CLOSE
                         --> description = "Error 101 reading from socket."
                         --> net_error = -101 (ERR_CONNECTION_RESET)

Hi all.  Any ideas about what's going on or how to fix this?  I'm still having the same problem.  

And I'm not sure if it's related but I also seem to have a cookies/caching issue, as in every time I visit a site then close the page, I have to sign in again when I return, even if I haven't signed out and I return within a few minutes.  I've adjusted my Chrome settings but that hasn't seemed to have helped.

Thanks again.

David

Sorry for the delay.  I'll look into this tomorrow.

Great, thank you.

I too am looking forward to an update. Thank you.

Hey folks able to reproduce this issue, could you help me by recording a network log including raw bytes?  I will then be able to see what actual bytes Chrome is sending to the server that triggers the COMPRESSION_ERROR.

Remember that this mode of logging saves all kinds of sensitive information like cookies, so I recommend that you open a blank incognito window, then close every other Chrome window (including windows with other profiles), then go to chrome://net-export, select "Include raw bytes (will include cookies and credentials)", then open gmail.com or stackoverflow.com in a new tab.  Do not enter any passwords or other sensitive information.  You only need to record until you first see that loading does not finish.

I hope this is not too much to ask.  Thanks for your help.

If you'd rather not share such a log publicly for fear of accidentally leaking sensitive information, please send them to me at bnc@chromium.org.

The two logs from comment #8 both contain an HTTP/2 connection, one to gmail.com the other to ajax.googleapis.com, with a single request sent, and then a GOAWAY frame received from the server after 20 ms or so.  The GOAWAY frame contains error code COMPRESSION_ERROR, and has last_accepted_stream_id = 1.

The log from comment #9 has 15 connections to Google services with GOAWAY frame received with this error code within 20 to 50 ms.  Some connections have one request only, some have as many as 6, and the GOAWAY that the server sends always has a last_accepted_stream_id field that acknowledges having seen all of them.

There are two bugs here:

1. COMPRESSION_ERROR.  Getting the raw bytes will help me debug that.  This really should not happen.  It could be a client or a server error.

2. The server sending such GOAWAY frames.  Since last_accepted_stream_id is the highest stream_id of the requests, the server actually states that it might go on with processing those requests.  Chrome is not in the wrong waiting for them (though it could time out, or could try them in parallel on another connection if the requests are considered idempotent).  If the server does not intend to serve the requests, it really should close the connection.  I'll bring this up with the appropriate developers.

For the record, I cannot reproduce this error.  I tried:
59.0.3071.86 (both Stable and Beta currently on my installation)
60.0.3112.20 Dev

Once I finish up some things I am working on I will do as you ask.

I have ran the net-export with all bytes included while attempting to access three domains; gmail.com, gotowebinar.com and another domain related to a project I am working on at work but find I often experience the non-stop loading of "fonts.gstatic.com" resource on. This third domain is not top secret by any means but as it is related to ongoing development I would prefer to not publish it here.

There are four log files in total. Two are from gmail.com and the other is from the other domain. 
* The first gmail log file I interrupted early because I needed to do something briefly for work. 
* The second log was running for quite some time and found that after 20 or so minutes (I was in a meeting and not at full attention on my browser) that the gmail.com login page finally loaded. I continued to let that run for another 10 or so minutes (I think) and had to stop so I could get back to doing some work.
* The third is an example of when I am not actually prevented from accessing a website but the resource never stops loading.
* The fourth is a recent example I have been experiencing (and several of my colleagues have reported) is when attempting to add a "GoToWebinar" calendar entry to their calendar via a link from "GoToWebinar" (one of their standard "add to Google Calendar" links that they generate) -- I've had instances where the link hangs on loading "ajax.googleapis.com" and I can't add the item to my calendar. Other times it works just fine. I only ran this for a few minutes as I had to get back to work but I am hoping it includes the relevant information you need.


Note: with the gotowebinar log i accidentally closed my incognito window before I clicked the "stop logging" button. I hope that doesn't negatively impact your use of the log.

Thank you very much for providing me with the log files.

The first file contains one example on a connection to gmail.com.  The second one has two instances of the bug, one to gmail.com, the other to www.gstatic.com.  The third file has one example, to fonts.gstatic.com.  The fourth has two instances, ajax.googleapis.com and safebrowsing-cache.google.com.

I'll get to extracting the raw HTTP/2 data right away.

Re comment #28: It seems like you are using AVG antivirus which intercepts the HTTP/2 traffic.  Do you experience the same problem if you temporarily disable AVG?

The four log files contain headers in plaintext and also the encoded raw bytes for five independent requests that caused the server to send a GOAWAY frame with COMPRESSION_ERROR (the HEADERS frames in the two gmail.com ones are byte-to-byte identical, though the rest of the connection is not).  I fed the headers into Chrome's HPACK encoder and the output matches the raw bytes from the log, which is not surprising, given that they were generated with the exact same encoder on the user's machine.  I also fed the raw bytes into the HPACK decoder and got back the exact same headers.  Google servers happen to use the same decoder implementation.  This indicates that it is unlikely that there is an actual compression error here.

What I'm suspecting is that there is a bug in AVG's HPACK decoder and it is in fact AVG that generates the COMPRESSION_ERROR and closes the connection.

I will test disabling AVG and report back.
Thank you

Hmm, you might be onto something.  I disabled AVG, opened a few pages in Chrome and they seemed to load ok.  Although I do have a couple of pages still waiting for "s0.2mdn.net...".

Well, I might have spoken too soon.  I opened the same pages in Chrome and one page is still waiting for googletagservices and the other for the ajax api.

Thanks for checking.  If it still does not work, could you then please record network logs, including raw bytes, with AVG disabled, and send them to me?  Thanks.

After having disabled AVG I have not experienced the issue on my end in two days. I will continue to monitor and update the case if I run into the issue again. I plan on contacting AVG about this as well.

Thank you for your feedback.  I'll close this issue now.

I've been wondering myself - and more so now after having reached out to AVG - why this only occurs in Chrome and not in other browsers.

Response from AVG: 
"This is an issue that I personally ran into a lot but is more of a google chrome issue more so than an AVG issue. As you probably know using heuristic analysis has its major ups and downs but ultimately is the best way to keep you save against unknown threats. However if I temporary disable it in the Web Shield then it sometimes resolves the issue in Chrome but please keep in mind that you would be sacrificing security for performance. So I just use IE to compensate on the websites that I am experiencing the issues with instead of crippling the security for my computer to accommodate a few websites that I am having performance issues with using only chrome." 
The individual also went on to explain some more about heuristic analysis but I didn't find the entire response to be relevant to this post.

Obviously the answer shouldn't be to disable ones antivirus application or certain features of it to have a normal web browsing experience. Due to both personal preference and the fact that I am the administrator of our G Suite subscribing organization - I don't want to deal with the headaches of switching to another browser (or another anti-virus) to work around the issue.

I'm wondering if there is something that could be done by the Chrome team to avoid this issue?

As you see from the analysis above, Chrome is sending a request with valid compression, which, if intact, Google's servers can decompress.  However, an error with COMPRESSION_ERROR is returned.  This is caused by AVG in one of the following two ways: either AVG has a bug in its decompression algorithm and responds with a COMPRESSION_ERROR to the request, or it decompresses and then incorrectly re-compresses the request, sends it to the server, which cannot decompress it, and thus responds with COMPRESSION_ERROR.

Given that this error is reproducible and seems to be very specific, I am surprised at AVG's reluctance to debug and fix it, or if they believe that this is a bug in either Chrome in the server, then to send futher details to the corresponding team.

Thank you for bringing this issue up with AVG.  Would you please be so kind as to give me the contact information of the person you were corresponding with so that we can reach out to them directly?  Thank you.

All I have is the name of the person that responded. I have responded to the case asking for specific contact information with the goal of connecting you with someone there.

Thank you for going the extra mile. Once I receive a response is it alright if I email the contact information to you? I don't want to post anyone's information on a public space.

Yes, please feel free to e-mail me at bnc@chromium.org.  Thank you for your extra effort!

 Issue 735055  has been merged into this issue.

For the record, the bug turned out to be in the server, not in AVG.  It is in the process of being fixed in the server code, so this issue should be completely resolved soon.