How does google calculate waiting time and receiving time in chrome network panel?
There are 4 timing categories in google chrome network panel
1.) Blocking
2.) Sending
3.) Waiting
4.) Receiving
I would like to know what all factors are included while calculating these options.
From this link
High "Receiving Time" for HTTP Responses below 500 bytes in Chrome Devtools
an explanation is there for receiving, but I would like to know about all the options in a bit more detail. Can anyone please help me out here ?
It appears that the timing functions may be platform related.
I have an internal web site and the access times reported for the same transactions appear vastly different. For example, my Windows 7 (latest Chrome) shows total response times as 200ms (almost 190ms of receiving) while my Ubuntu laptop shows a total of 4ms on the Chrome Network tab.
I also put timers on my server side first, just to make sure that it was not a delay in my node.js server (running on a different ubuntu box - not the one that has the Chrome client).
Related
Chrome Timing View
The image above show chrome spends most of the time queuing up the request. I am trying to figure out why that is happening to minimize it.
According to chrome developer documents:
A request being queued indicates that:
The request was postponed by the rendering engine because it's
considered lower priority than critical resources (such as
scripts/styles). This often happens with images.
The request was put on hold to wait for an unavailable TCP socket that's about to free up.
The request was put on hold because the browser only allows six TCP connections per origin on HTTP 1.
Time spent making disk cache
entries (typically very quick.)
Number 3 seems to be the most likely problem according to chrome developer documents but I know that only one request is going out at a time so that can't be it. I don't think it is number 1 either because the performance monitor doesn't show a lag from rendering. Maybe it is either 2 or 4 but I don't know how to test that.
Chrome Performance Monitor
I've included a picture of the performance monitor that shows these long tasks where something is happening in the system. These are also a mystery to me and seem related.
Any help is greatly appreciated!
Edit: It seems you can disable the disk cache when you open dev tools and that didn't seem to fix the problem.
I have this 1 Mb file for testing purposes (though the issue applies to any file hosted at lptoronto.com): https://lptoronto.com/sandbox/test.png
It always loads instantly in Internet Explorer (both via http and https).
In Google Chrome (currently Version 63.0.3239.132 (Official Build) (64-bit) on Windows 10) the situation is as follows.
When fetched via http, this file loads instantly without an issue.
When fetched via https, the same file takes about 40 (!) seconds to load (with very rare and irregular exceptions, when it also loads fast via https on occasion).
Chrome network monitor shows that all that 40 seconds the image is being slowly but steadily downloaded at low speed, i.e. there is nothing like waiting for server response etc.
Here's the screencast showing IE and Chrome side-by-side loading the same image:
https://www.youtube.com/watch?v=M4cUuhG1YuM
From time to time the issue disappears for a few minutes or an hour, but then re-appears again, without me doing anything on my side.
Same behavior is observed on at least one other computer - the one of my colleague (different ISP, different location).
Needless to say that I'm testing in a clean environment - cache cleared, extensions, firewall, antivirus disabled, connection verified and measured etc.
No Chrome issue whatsoever with any other website, be it http or https.
Hosting provider is yet unable to troubleshoot on their end, but they're still trying to help (it takes some time). They tried disabling mod_deflate, re-installing SSL, disabling caching rules, but to no avail.
The same issue was once observed about 2 months ago. That time I asked the hosting provider to disable SSL completely just to be able to work on my website content. When they re-enabled SSL in less than a day, the issue has gone; but now it re-appeared again, and there is no clue as to what is going on.
The bottomline:
issue appears only in Chrome, only with certain site, only with https
changing only the browser solves the issue
changing only the protocol (https to http) solves the issue
I honestly tried to google out anything similar, but failed to.
I would appreciate if you try the link above in the incognito Chrome window and report the load/refresh time, and of course any ideas are more than welcome.
This is a screenshot of Chrome's network timing and I'm trying to figure out the "stalled" time of ~250ms. Google's docs say the stalled status is for time spent either waiting for a socket (possibly due to max 6 rule) or time spent negotiating a proxy. However, in my case, this is the only active request (so it's not a max 6 issue), and there is no other network activity on the computer or even the network. I'm also not using any form of proxy or VPN.
I eventually figured out that this "stalled" time disappears if I change from https to plain http, so at first, I figured this was SSL setup time. But if that were the case, why isn't it showing up in the "SSL" section of the timing?
What's causing this "stalled" time taking 30% of the load time?
Edit
I had my buddy on the opposite coast hit the same page and it's worse for him, which suggests that it could be server-proximity related?
HTTPS
HTTP
I am trying to record with Chrome in LoadRunner for the first time (having to record a mobile app through an emulator that only works in Chrome), but when recording with Web (HTTP/HTML) protocol in Chrome I only get empty actions, no events are recorded (tried with several "standard" web pages).
LoadRunner opens Chrome fine, I click a few links and then stop recording, but script actions remain empty. Using HTML-style recoring.
Setup:
Windows 7 64 bit SP1
Loadrunner VuGen v11.52
Chrome v27.0
I have colleagues that manage to record fine with similar (if not exact same) setup. Has anyone faced the same issue?
You must close all Chrome windows before starting recording and use only the window that VuGen opens to record. Also make sure no chrome processes running before recording.
Why not record the actual device with vugen instead of an emulator?
Keep in mind you are trying to use a 32 bit application to record a 64 bit application. I would even go so far as to recommend that you look at using the proxy model recording as an HTTP proxy for the "old recording engine."
I have a weird problem with websockets and chrome (22.0.1229.79m) (I haven't coded authentication for other browsers yet so I cant test them). It seems like if I reload chrome 3 times, there will be a huge delay in connecting to my websocket server. The server is not delaying the connection, I tested this by connecting to it with another PC while chrome was delaying and it connected perfectly.
Is there anyway to fix this? This is a problem when I am switching servers receiving data. It will halt, and delay. This is really bad for user experience. I would assume this is strictly related to the chrome browser not closing the socket...
I have also seen this delay when creating multiple WebSocket connections from the same browser tab in Chrome within a short period of time. I believe this is to address a potential security issue with WebSockets which would allow a browser to be hijacked to do port scanning inside a network. By limiting the number of WebSocket connections that can happen within a given amount of time, you greatly limit the utility of a browser as a remote port scanner. In addition, the amount of information that is returned by onclose and onerror is intentionally limited for the same reasons.