I'm using 53.0.2785.116 on Ubuntu and it seems relatively fast. The resources you call out are 52 and 80ms respectively.

I think a network log is likely needed:

https://dev.chromium.org/for-testers/providing-network-details

WOW I collected a trace of this and it is very interesting. I see a huge task in the renderer upon receipt of the main resource, before the previous document is detached.

Let me try to drill down into tracing categories to see why...

Attached is the network log.
I saw another email said something did show for them.
Cheers!
(See attached file: net-internals-log.json)
Carl Roberts (Contractor)
Front-End Developer and QA, Digital Analytics and Tag Management
Email: crober@us.ibm.com
512-973-1039



From:	dtapu… via monorail <monorail+v2.2182922724@chromium.org>
To:	Carl Roberts/Austin/Contr/IBM@IBMUS
Date:	09/27/2016 01:51 PM
Subject:	 Issue 650708  in chromium: IBM.com pages loading very slow, 20
            plus seconds load times

Attached is the trace I recorded. WebURLLoaderImpl::Context::OnReceivedData gets descheduled for ~5 seconds, and it's unclear what is going on.

The last thing it does is detach the previous document.

Scheduling experts, I added scheduling debugging to the trace, would you please take a look?

Deleted: trace_ibm_canada.json.gz 8.7 MB

trace_ibm_canada.json.gz 8.7 MB Download

Looks like WebURLLoaderImpl::Context::OnReceivedData is calling some function that blocks or perhaps calls a long synchronous IPC. The trace doesn't seem to have enough events to show what it is, so perhaps you could add some more trace events there to narrow this down (assuming you can reproduce the bug)?

Removing network label.  Doesn't sound network related to me, give previous comments.  If that changes, feel free to add back.

Good morning Google team,

Do we have any update on this?

Thanks,
Carl

Carl Roberts (Contractor)
Front-End Developer and QA, Digital Analytics and Tag Management
Email: crober@us.ibm.com
512-973-1039



From:	mme… via monorail <monorail+v2.3079273537@chromium.org>
To:	Carl Roberts/Austin/Contr/IBM@IBMUS
Date:	09/28/2016 12:24 PM
Subject:	 Issue 650708  in chromium: IBM.com pages loading very slow, 20
            plus seconds load times

I'll try getting a trace with all possible labels.

Traces proved to be not that helpful and hard to reproduce. I attached a debugger to the renderer and got a stack trace during the hang. Could a V8 expert look at this possible deadlock?

Note: this is really easy to reproduce at TOT (#421748) by just hard reloading the ibm page. Bumping priority to P1.

#1  0x00007f6efaee334d in v8::base::ConditionVariable::Wait(v8::base::Mutex*) () from /usr/local/google/home/csharrison/chromium/src/out/gnrelease/./libv8.so
#2  0x00007f6efa7b0d4b in v8::internal::OptimizingCompileDispatcher::Flush() () from /usr/local/google/home/csharrison/chromium/src/out/gnrelease/./libv8.so
#3  0x00007f6efaa6a317 in v8::internal::Heap::NotifyContextDisposed(bool) () from /usr/local/google/home/csharrison/chromium/src/out/gnrelease/./libv8.so
#4  0x00007f6ef09db16b in blink::V8GCForContextDispose::notifyContextDisposed(bool) () from /usr/local/google/home/csharrison/chromium/src/out/gnrelease/./libblink_core.so
#5  0x00007f6ef09f38ab in blink::WindowProxy::disposeContext(blink::WindowProxy::GlobalDetachmentBehavior) () from /usr/local/google/home/csharrison/chromium/src/out/gnrelease/./libblink_core.so
#6  0x00007f6ef09f65b3 in blink::WindowProxyManager::clearForClose() () from /usr/local/google/home/csharrison/chromium/src/out/gnrelease/./libblink_core.so
#7  0x00007f6ef09a196f in blink::ScriptController::clearForClose() () from /usr/local/google/home/csharrison/chromium/src/out/gnrelease/./libblink_core.so
#8  0x00007f6ef0efa571 in blink::LocalFrame::detach(blink::FrameDetachType) () from /usr/local/google/home/csharrison/chromium/src/out/gnrelease/./libblink_core.so
#9  0x00007f6ef0c24f1c in blink::ChildFrameDisconnector::disconnectCollectedFrameOwners() () from /usr/local/google/home/csharrison/chromium/src/out/gnrelease/./libblink_core.so
#10 0x00007f6ef0efa9b8 in blink::LocalFrame::detachChildren() () from /usr/local/google/home/csharrison/chromium/src/out/gnrelease/./libblink_core.so
#11 0x00007f6ef0efa4c8 in blink::LocalFrame::detach(blink::FrameDetachType) () from /usr/local/google/home/csharrison/chromium/src/out/gnrelease/./libblink_core.so
#12 0x00007f6ef0c24f1c in blink::ChildFrameDisconnector::disconnectCollectedFrameOwners() () from /usr/local/google/home/csharrison/chromium/src/out/gnrelease/./libblink_core.so
#13 0x00007f6ef0efa9b8 in blink::LocalFrame::detachChildren() () from /usr/local/google/home/csharrison/chromium/src/out/gnrelease/./libblink_core.so
#14 0x00007f6ef1346521 in blink::FrameLoader::prepareForCommit() () from /usr/local/google/home/csharrison/chromium/src/out/gnrelease/./libblink_core.so
#15 0x00007f6ef13468d9 in blink::FrameLoader::commitProvisionalLoad() () from /usr/local/google/home/csharrison/chromium/src/out/gnrelease/./libblink_core.so
#16 0x00007f6ef132f490 in blink::DocumentLoader::processData(char const*, unsigned long) () from /usr/local/google/home/csharrison/chromium/src/out/gnrelease/./libblink_core.so
#17 0x00007f6ef132f391 in blink::DocumentLoader::dataReceived(blink::Resource*, char const*, unsigned long) () from /usr/local/google/home/csharrison/chromium/src/out/gnrelease/./libblink_core.so
#18 0x00007f6ef0e84b92 in blink::RawResource::appendData(char const*, unsigned long) () from /usr/local/google/home/csharrison/chromium/src/out/gnrelease/./libblink_core.so
#19 0x00007f6ef0ea0e59 in blink::ResourceLoader::didReceiveData(blink::WebURLLoader*, char const*, int, int, int) ()
   from /usr/local/google/home/csharrison/chromium/src/out/gnrelease/./libblink_core.so
#20 0x00007f6efc35ae7c in content::WebURLLoaderImpl::Context::OnReceivedData(std::unique_ptr<content::RequestPeer::ReceivedData, std::default_delete<content::RequestPeer::ReceivedData> >) ()
   from /usr/local/google/home/csharrison/chromium/src/out/gnrelease/./libcontent.so
#21 0x00007f6efc35b73b in content::WebURLLoaderImpl::RequestPeerImpl::OnReceivedData(std::unique_ptr<content::RequestPeer::ReceivedData, std::default_delete<content::RequestPeer::ReceivedData> >)
    () from /usr/local/google/home/csharrison/chromium/src/out/gnrelease/./libcontent.so
#22 0x00007f6efc33710d in content::ResourceDispatcher::OnReceivedData(int, int, int, int, int) () from /usr/local/google/home/csharrison/chromium/src/out/gnrelease/./libcontent.so
#23 0x00007f6efc33900d in bool IPC::MessageT<ResourceMsg_DataReceived_Meta, std::tuple<int, int, int, int, int>, void>::Dispatch<content::ResourceDispatcher, content::ResourceDispatcher, void, void (content::ResourceDispatcher::*)(int, int, int, int, int)>(IPC::Message const*, content::ResourceDispatcher*, content::ResourceDispatcher*, void*, void (content::ResourceDispatcher::*)(int, int, int, int, int)) () from /usr/local/google/home/csharrison/chromium/src/out/gnrelease/./libcontent.so
#24 0x00007f6efc335ba5 in content::ResourceDispatcher::DispatchMessage(IPC::Message const&) () from /usr/local/google/home/csharrison/chromium/src/out/gnrelease/./libcontent.so
#25 0x00007f6efc3352a8 in content::ResourceDispatcher::OnMessageReceived(IPC::Message const&) () from /usr/local/google/home/csharrison/chromium/src/out/gnrelease/./libcontent.so

Another quick note: at TOT we never get out of this state. In M53 stable we do after some N seconds. This makes tracing on TOT very unhelpful.

Hi,

I was referred to this issue from another issue I had opened for problems with the IBM sites -  Issue 643833 . This is the update I did on that issue in response:

Hi Again,

I just tried both pages referred to in  issue 650708  from my WFH setup using Version 55.0.2876.1 canary SyzyASan on Win Pro 64 BIT SP1 + all fixes. I did NOT see any issues.Initial load & re-load no noticeable difference.

However I did a test using my corporate laptop (RDP connection from home) with older Canary (Version 55.0.2867.0 canary (64-bit) ) on a Win 7 Enterprise Edition SP1 + mostly up-to-date. The first load was what I would call "normal" for the laptop behind the corporate FW. The re-load was NOTICEABLY slower!

I suggest re-examining that issue using today's update. So far the IBM sites have worked great for me on Canary following today's update. I have moved back to Canary from Beta for these sites.

NOTE: Due to a Corporate GPO restriction the Google update is "blocked" on the Corporate assets. Since there is no "standalone" installer for Beta or Chrome I have a "hack" I use to update them on the Corporate Win Systems I use (a laptop + a VDI). Time permitting I try to update Canary once or twice a week and Beta once a week.

Response copied from  Issue 643833  .

Ross

Just as an FYI... csharrison@ see  issue 643833  that was a different issue logged against some excessive memory usage on the IBM portal sites.

I have updated my Chrome to the latest version, restarted my machine,
cleared cache and reloaded the sites. I still get long delays and the
pop-up for page hanging is coming up almost every time.

Carl

Carl Roberts (Contractor)
Front-End Developer and QA, Digital Analytics and Tag Management
Email: crober@us.ibm.com
512-973-1039



From:	demented… via monorail <monorail+v2.3521692426@chromium.org>
To:	Carl Roberts/Austin/Contr/IBM@IBMUS
Date:	09/30/2016 01:10 PM
Subject:	 Issue 650708  in chromium: IBM.com pages loading very slow, 20
            plus seconds load times

This looks like a duplicate of https://bugs.chromium.org/p/chromium/issues/detail?id=643833. I have added a comment there.

Please bisect this.

I'm not sure who created  issue 643833 .  As long as this issue, 650708 gets
updated I'm okay with it being labeled duplicate.  Is there any update on
the issue itself?

thanks,

Carl Roberts (Contractor)
Front-End Developer and QA, Digital Analytics and Tag Management
Email: crober@us.ibm.com
512-973-1039



From:	habl… via monorail <monorail+v2.1985917227@chromium.org>
To:	Carl Roberts/Austin/Contr/IBM@IBMUS
Date:	10/04/2016 05:28 AM
Subject:	 Issue 650708  in chromium: IBM.com pages loading very slow, 20
            plus seconds load times

Tested on windows 10 RAM 8GB  , Chrome 53.0.2875.143 Stable and followed below steps:
1. Opened "http://www.ibm.com/ca-en/" and "http://www.ibm.com/developerworks/opensource/library/x-android/"
2. In developer tools, cleared cache and reloaded the page hitting F5 
3. Took 8secs of time to load the page and did not observe any page hanging pop-ups. 

Please check the attached screenshots and let us know if we are following the correct procedure, else kindly help us with the same.

Thanks.!

Deleted: 650708_1.PNG 396 KB

	650708_1.PNG 396 KB View Download

Deleted: 650708_2.PNG 3.3 MB

	650708_2.PNG 3.3 MB View Download

The hang happens on any type of reload, devtools is not necessary. Even hard reload is not necessary to repro.

This bug manifests itself on my machine by causing a reload to take anywhere from 4-15s before the spinner stops turning counter clockwise and starts turning clockwise (and the page starts getting data). When the bug is not triggered a reload is practically instantaneous.

Note: It takes 3-4 reloads to reproduce this on M53 on macOs. Let me know if you need more info.

This issue is getting more attention here at IBM.  Do we have any ETA on
resolution?

Thank you,

Carl

Carl Roberts (Contractor)
Front-End Developer and QA, Digital Analytics and Tag Management
Email: crober@us.ibm.com
512-973-1039



From:	habl… via monorail <monorail+v2.1985917227@chromium.org>
To:	Carl Roberts/Austin/Contr/IBM@IBMUS
Date:	10/04/2016 05:28 AM
Subject:	 Issue 650708  in chromium: IBM.com pages loading very slow, 20
            plus seconds load times

hdodda were you planning on running a bisect for this? Otherwise I can probably find time today.

Re #17 ... doesn't this mean that this is related to the network layer? I cannot reproduce this though on Chrome 53 (Linux) or Chrome 55.0.2880.0 (Mac). Maybe this is related to a firewall that is running on the computer?

All #17 means is that the navigation did not commit in the renderer (I'm pretty sure the spinner is tied to commit). This happens right after the long pause in the renderer (RenderFrameImpl::didCommitProvisionalLoad).

Let me try reproing again.

This issue has been verified on the IBM network and outside our network.
We had an engineer from Tealium run some tests to verify if Tealium was at
all involved in the delay.  Running the pages from their side, they found
with Tealium turned off, the pages still had long delays.

thanks,
Carl
Carl Roberts (Contractor)
Front-End Developer and QA, Digital Analytics and Tag Management
Email: crober@us.ibm.com
512-973-1039



From:	habl… via monorail <monorail+v2.1985917227@chromium.org>
To:	Carl Roberts/Austin/Contr/IBM@IBMUS
Date:	10/06/2016 08:41 AM
Subject:	 Issue 650708  in chromium: IBM.com pages loading very slow, 20
            plus seconds load times

I bisected down to the range 391467 - 391471 on Linux
https://chromium.googlesource.com/chromium/src/+log/2f6536a4dfb76686ff7f29dcb35f1e02ad209f4d..f05e48e455137801346e2c58d71ef266054e83ac

This is Chrome 52 though, which contradicts the original posting. It's also possible that this is a race condition that only triggers in certain revisions, and just happens to also trigger in M53 stable.

Thanks csharrison.

That V8 range looks innocent regarding the mentioned symptoms. Added Jarin to confirm.

We have been working on this issue from our side also.  We found that if we
refactored 700+ rules for Tealium tag manager that we can get the 20 second
hang to stop happening.  So, we have fixed the problem from our side.  You
may want to revisit the URL's provided and verify that you don't see any
issues.  If it all looks clean, you can close the issue.

Thanks.
Carl

Carl Roberts (Contractor)
Front-End Developer and QA, Digital Analytics and Tag Management
Email: crober@us.ibm.com
512-973-1039



From:	habl… via monorail <monorail+v2.1985917227@chromium.org>
To:	Carl Roberts/Austin/Contr/IBM@IBMUS
Date:	10/10/2016 06:39 AM
Subject:	 Issue 650708  in chromium: IBM.com pages loading very slow, 20
            plus seconds load times

Based on comment #26 , tested the URL's provided in comment #0 and issue is not reproduced. Average page load time is observed to be 8 Seconds , please confirm if it could be the feasible time to reload the page. So that we can close the issue.

Thank You !

That concurs with my findings after refactoring our code.  We can consider
this issue closed.

Carl

Carl Roberts (Contractor)
Front-End Developer and QA, Digital Analytics and Tag Management
Email: crober@us.ibm.com
512-973-1039



From:	hdo… via monorail <monorail+v2.1193794847@chromium.org>
To:	Carl Roberts/Austin/Contr/IBM@IBMUS
Date:	10/13/2016 01:11 AM
Subject:	 Issue 650708  in chromium: IBM.com pages loading very slow, 20
            plus seconds load times