I'm trying to debug difference between HTTP/1.1 and HTTP/2.
Is there any possibility for disabling HTTP/2 in chrome or chromium?
I couldn't find this option flag in chrome 56. I have tried chromium 58 with flag --disable-http2:
./Chromium.app/Contents/MacOS/Chromium --disable-http2
But content is still delivered with HTTP/2 protocol after using this flag:
For what it is worth, the flag works.
The issue is that you need to quit EVERYTHING Chrome for it to take effect. Including plugin shims and other chrome tabs and so on.
It is not enough just to add the command line switch.
An easier way to achieve something broadly equivalent is to use an HTTP Proxy, like https://www.telerik.com/fiddler. This adds negligible additional time to your requests, and (as far as I know) doesn't support http/2 at all (yet); even if it did, I'm pretty sure it would be much easier/practical to switch behavior in than restarting all your Chrome windows.
The advantage of this approach is that it takes effect immediately - disabling and reenabling HTTP/2 becomes as easy as starting and stopping the proxy, without messing with the (if you're anything like me) dozens of Chrome tabs you have open, to StackOverflow and elsewhere :)
What happens when you try doing the same thing in WebPageTest (select Chrome as the test agent and add the command line switch in the Chrome tab under advanced settings)
Here's a test I did for my personal site just now and the flag appears to work OK (if you look at the response headers you'll see HTTP/1.1)
https://www.webpagetest.org/result/170322_1B_ab8656afcfb8bcc4103e9872ff56c28b/1/details/#waterfall_view_step1
I have seen the same problem created by a firewall running in proxy mode vs flow mode.
The firewall would buffer the entire file so it could scan it then pass it along vs scanning the individual packets.
https://docs.fortinet.com/document/fortigate/6.4.4/administration-guide/721410/inspection-modes
The problem would only happen when using http2 and might have something to do with http request priority not being handled properly or it forced it single threaded.
We would have a video request start with a low priority that would stall then start causing other file downloads to be delayed. Then there was a api poler in the background coming in with high priority requests. After a few high priority requests were blocked chrome would cancel the low priority video.
It would happen in other cases but the video made it very reproduceable for us.
https://medium.com/dev-channel/javascript-loading-priorities-in-chrome-57c54cfa6672
https://blog.cloudflare.com/better-http-2-prioritization-for-a-faster-web/
https://blog.cloudflare.com/http-2-prioritization-with-nginx/
https://calendar.perfplanet.com/2018/http2-prioritization/
We set it back to flow mode on the firewall and the problem went away.
Afterwards the downloads all happened in parallel with no blocking or stalling in the chrome network waterfall.
Related
I'm using Chrome in headless mode via CDP (Chrome devtools protocol) to do HTML to PDF conversions. Works well but I do not trust Chrome to run forever and want to build a guardian service to monitor its responsiveness and if necessary kill the process and relaunch it.
What would be a good indicator of health? What I'm looking for is a low overhead test I can perform at fairly frequent intervals so that the restart latency is minimised.
I could try to perform some kind of CDP command if anyone has a suggestion and a reliable way to determine success.
I can't think of anything else, that's why I've thrown it open for suggestions.
My best suggestion for this case is to use the Target domain. Listening to some of the events that are fired from the target domain will give you some information regarding the state of your browser, such as TargetCrashed.
On top of that, you could use basic domains like Runtime (provides the evaluate method), SystemInfo or Browser to send the browser requests in order to check its health.
I have running a site serve both via https and http.
The issue only happen when access via https, steps are
open a chrome, first time to load the only single site in HTTPS, chrome stall this inital connection about 1second.
however any immediate subsequent refreshing the same page, only have zero to couples of milliseconds, can ignore.
put aside the page(don't interact with it, for a short while, may few minutes), then pick it up to refresh it, it will repeat from step #1(stall about 1 second, followed by any immediate refresh almost zero stalling)
This only happen when access the site by HTTPS, don't have this kind of issue when access by HTTP(always almost zero stalling).
Issue only seen in Chrome browser, but not safari and firefox(there is almost no stalled time), all tested in Mac OS
Would any one help to give some idea please? why the first loading introduce 1 second stalling? how to reduce that stalling time please
screenshot
sorry, this is really hard to explain the issue
I think i found the cause now, i was using a self-signed certificate for https connection, though i add it to browser exception list to trust it, it looks like chrome is being more strict on this(than others ), after switching to a trust CA signed cert. The chrome stalled time reduce to jus few millseconds for all request now, i am happy to close this question now
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.
I'm experiencing an issue that has only started occurring in the last month or so. The http request log in the network tab stops recording requests after the initial page load. I get how this behaviour might be desired in some circumstances, but in my case it's not very useful. I'm making several http requests after the initial page load, and unless I remember to hit record I won't see anything in the log.
Is this a problem others are having? Is there a setting buried away somewhere that can rectify this?
I had the same problem, make sure that the "Capture screenshots" feature (camera icon) is disabled in Chrome Developer Tools.
I had the same problem. There's a simple solution.
Go to Developer tools Settings > Preferences and then tap on Restore defaults and reload.
How can I tell chrome not to fetch any favicon.ico files from a webserver? For web development and debugging, I find this very annoying when I read server side logs. Loading the favicon is also bias when measuring and optimizing my page load times so I want to completely disabled it on the client side in chrome.
Look at this Chrome extension I hate your favicon, or build your own one, which utilizes webRequest module and trap all outgoing requests for favicons.
Also you could possibly set up one of ad blocking extensions to do the same job.
P.S. You can read discussion about whether to consider this as a bug, or feature in the issue 39402 at Chromium porject, I think it applies to Chrome as well. And it seems there will be no easy way to turn this behaviour off via options in the near future.