I am running performance tests on a webpage and I noticed the network tab of Chrome DevTools has a summary bar at the bottom with number of requests, bytes transferred and finish time. I would like to console.log (or even better log to a file) these values at the end of each test.
I do see a chrome.loadTimes() which has the timing info. Is there something similar to retrieve number of requests and bytes transferred?
Check out the Resource Timing API. It can give you a whole bunch of info on every resource that a page requests. And it's got good cross-browser support, so you can use it to collect some Real User Metrics on your page's load performance in the wild.
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 see the following anomaly in Resource Timings panel:
Content Download time (from Network time) is unexpectedly high for some resource, which has been requested while loading a page:
Content Download time for 1 KB is about 1 sec.
although there is no network issue: I've checked that with Wireshark trace + place my browser as close to Server as it was possible.
Ping shows about 0.3ms RTT.
I'm just wondering if the Network performance is the only reason according to the article by Jonathan Garbee
https://developers.google.com/web/tools/chrome-devtools/network-performance/understanding-resource-timing?hl=en
I've checked download time for that resource particularly (just putting its address in browser's address bar), and it took less than 100ms for the whole HTTP request (Content Download time was about 1ms) for that single resource.
I've checked that resource request time using Events in net-internals. And the results didn't fit to timings in DevTools.
for the same time and the same resource of 1 KB there was the following:
Events from net-internals showed 100 ms and Content Download in DevTools was 900 ms. See screenshots:
Content Download time
net-internals Event for the same HTTP request
Googling for a while I've found some discussions that Timings are recorded by Render process,
and if it is busy there can be significant time gap between actual point of time when responseEnd
(or responseFinish, I don't remember the exact event's name) event happened
and the point in time when Render process registered that events.
That can explain the long download time in DevTools Timings. But if that explanation is trustworthy?
Can someone confirm or deny that Timings recording depend on Render process workload,
and for fat applications Timings provided in DevTools could be distorted by Render process being loaded heavily...
If it is actually True, then what could be the source of truth for performance related statistics?
Sorry for not being familiar with Chromium source code structure so far.
It will take weeks to check the answer by myself. Unfortunately I've got no time for that.
PS is there any resource, which describes performance measurements in Chrome (I mean, how Chrome does it internally)?
"Understanding Resource Timing" is not enough any more.
Best regards,
Anton
These days I'm evaluating HTTP/2 (on Nginx), as a possible candidate for boosting performance of my application.
I was looking on this nice Akamai HTTP2 demo. From this demo I can see that the "http2" part loads much faster, apparently thanks to HTTP2 multiplexing feature.
So, I decided to look a bit closer. I opened Chrome (version 51) developer tools and examined the Network panel.
I expected to see one single network connection, handling all the requests (e.g. multiplexing).
However, I see multiple connections issued, one per image tile:
Moreover, I see that there is a delay ("stalled") for almost every reques:
I expected that (contrary to HTTP1) all requests will be issued in parallel without delays. Would someone help me to understand what is going on?
What you see are not multiple connections, one per image tile, but multiple requests, one per image tile, on a single TCP connection.
The fact that are multiplexed is evident because there is a large number of requests (tens or even hundreds) that are sent at the same time.
See how the requests are all aligned vertically.
Compare this with a HTTP/1.1 profile and you will see a ladder, ziggurat-style profile because only (typically) 6 requests can be sent at a time. See for example this presentation I gave at 39:54.
What you see is therefore the expected profile for a multiplexed protocol like HTTP/2.
The tiny "stalled" delay that you see for those requests may be due to internal implementation delays (such as queuing) as well as HTTP/2 protocol details such as flow control.
I am developing a Chrome App that needs to work off-line, i.e., I want it to use the App Cache, rather than sending a request to the server, as much as possible. However, should it be necessary to hit the server, then I would like to include a few bytes of data (so the server can collect and analyse some statistics about, for example, how many previous requests were served by the cache alone).
I can not send the data bytes in the URL query, because this defeats the cache (and is a well known technique for ensuring the cache is bypassed - exactly what I do NOT want to do).
I can't use a POST request, as that will also defeat the cache.
I have thought about including data in a header, but am unsure how, and unsure if this will do the trick as everything I have found about this idea recommends against it. I do not want to get in the trap of relying on something completely undocumented in case it stops working in the future (and I am not sure what will work today).
Can I include data in a GET request that will have absolutely no effect on the App Cache (in Chrome in particular), but is available to the server if and when the request makes it that far?
See comment above; this question isn't really about Chrome Apps. It's more about webapps that use App Cache.
It might be helpful to decouple normal web requests from the reporting feature. You are trying to piggyback the stats on the normal requests, but there doesn't seem to be a need to do so. Moreover, for the occasional client that caches perfectly, you'll never hear from that client because the reporting never occurs. So even in the best case the design would have been flaky.
Instead, you could increment a counter every time you make a request that might be cacheable, and keep it somewhere persistent like in localStorage. Then periodically report it to a noncached destination. You can then subtract the traffic you are receiving at the web server (which represents uncached requests) from that reported total (which represents all requests, cached or not). The difference is cached requests.
Whenever I send a GET-request to my webapp using chrome, according to my apache access log two identical requests (not always, but most of the times, I can't reproduce it - it's not for the favicon) get send to the sever, although only one is shown in the chrome dev tools. I deactivated all extensions and it's still happening.
Is this https://news.ycombinator.com/item?id=1872177 true and is it a chrome feature or should I dig deeper within my app to find the bug?
I think it's even worse than that. My experience here (developing with Google App Engine), is that Chrome is making all kinds of extra requests.
This is possibly due to the option that is in the Settings, checked by default:
Predict network actions to improve page load performance
Here is a really weird example: my website's page runs a notifications check every 15 seconds (done in javascript). Even after closing all tabs related to my website, I see requests coming from my IP, some random pages but also the notification check request. To me that means that Chrome has a page of my website running in the background and is even evaluating its javascript.
When I request a page, I pretty much always get another request for one of the links in that page. And it also requests resources of the extra pages (.css, .js, .png files). Lots of requests going on.
I have seen the same behavior with the development server that runs locally.
Happens also from another computer / network.
Doesn't happen with Firefox.
Also, see What to do with chrome sending extra requests?