HTTP/2 server push makes our sites considerably faster on first view. However, Firefox seems to have disabled server push since ca. v56.
Over at webpagetest.org, Patrick Meenan suggested that the developers had turned this off temporarily. Searching the web, I could not find any confirmation or info on this. But almost half a year later, our sites still load considerably slower in Firefox than in e.g. Chrome and this is clearly due to Firefox not accepting server push.
Does anyone know if and when server push will come back to Firefox?
Related
In the past, websockets were not supported by all browsers and networks.
We were required to provide fallback solutions like HTTP Long Polling.
This situation appeared to change.
At least the browsers support looks great now: https://caniuse.com/#feat=websockets
I could not find any statistics about networks blocking websockets.
Do we have any data proving that there is still a justification for websocket fallback solutions?
Last year, I had an issue using Trello at work. While the page was initially shown, some changes were not reflecting on the page. I investigated using the Chrome debugger and found out that WebSockets connection was blocked (at least for that website).
After a few exchanges with IT, and some firewall black magic on their side, the issue was resolved and now Trello works fine.
So, in a few corporate environments, some WebSockets scenarios still need a fallback IMHO.
When using Internet Explorer 11 to connect to a HTTPS site of my company, the first connection is very, very slow. Usually more than 30 seconds. After this first connection, I can browse the site with no problem. The problem just happens in Internet Explorer, it works fine in Chrome and Firefox.
If after the first visit, I clear the cache and cookies, the next page load is quick. I have to close the browser and reopen it to reproduce the problem. Even if I let the browser idle for a couple of hours, the next visit is still quick. The problem is just in the first visit of a browser to this site.
Below you can see the network view of the developer toolbar:
The first connection is a HTTP connection that redirects to a HTTPS connection. This connection is very slow. The two following connections are quick. If I close my browser and visit directly the third URL via HTTPS, it will also load slowly.
Here is the Timing in the Detail view (sorry, I can't change my company browser language to English):
What can it be? How do I debug it? With this problem, it is very hard to execute automated web tests.
I've had the same problem as well. It happens only when the HTTPS site is being accessed on a machine without internet access and only using IE.
A workaround that i've applied on LAN would be to update IE settings as described below:
Go to IE Options, advanced tab then locate security category and uncheck
“Check for publisher’s certificate revocation” and “Check for server certificate revocation”.
I've only found that workaround after seeing this post, so thanks for sharing :)
Since the problem happens only with HTTPS (right?) I guess that IE tries to check the revocation status of the site on the first visit. It probably caches the result, but only for the current browser session. There might be problems to reach the server responsible for the revocation (see OCSP/CRL settings inside the certificate) and thus the connection might time out. Chrome does not check revocation in most cases and Firefox might use a shorter timeout and ignore failures. You should see the attempts to get OCSP/CRL if you do a packet capture.
I need in autoresponder. I develop flash application and I need substitution flash file from server to my local debug flash.
I used Charles Proxy but in last week it became badly: internet connection very slow, some responses can't wait for request.
Is there a same solution for this micro task? May be little extension for browser? Or can anybody create this extension for chrome or safari?
Or Do you know why my Charles works slowly?
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
Recently, I came across an issue where a CGI application is not responding. Symptom is Firefox displaying:
Transferring data from localhost...
But the thing is I cannot see any traffic from Firebug's Net panel, and the browser just stays on the same stage forever.
I am thinking about the ways to debug this application but I cannot see the source code or any of its compiled Java/C++ components, therefore I reckon a HTTP network level of diagnostics is a good start.
I have little experience in Fiddler and Wireshark, just wondering will they get better feedback/statistics in the HTTP network level? I've heard Wireshark is advanced but could possibly introduce a large volume of traffic so system admins don't like it very much. At this time I think Firebug doesn't really show me enough information.
I need to collect information so that I can then forward to client as proof.
Wireshark, Firebug, Fiddler all do similar things - capture network traffic.
Wireshark captures any kind of network packet. It can capture packet details below TCP/IP (HTTP is at the top). It does have filters to reduce the noise it captures.
Firebug tracks each request the browser page makes and captures the associated headers and the time taken for each stage of the request (DNS, receiving, sending, ...).
Fiddler works as an HTTP/HTTPS proxy. It captures every HTTP request the computer makes and records everything associated with it. It does allow things like converting post variables to a table form and editing/replaying requests. It doesn't, by default, capture localhost traffic in IE, see the FAQ for the workaround.
The benefit of WireShark is that it could possibly show you errors in levels below the HTTP protocol. Fiddler will show you errors in the HTTP protocol.
If you think the problem is somewhere in the HTTP request issued by the browser, or you are just looking for more information in regards to what the server is responding with, or how long it is taking to respond, Fiddler should do.
If you suspect something may be wrong in the TCP/IP protocol used by your browser and the server (or in other layers below that), go with WireShark.
None of the above, if you are on a Mac. Use Charles Proxy. It's the best network/request information collecter that I have ever come across. You can view and edit all outgoing requests, and see the responses from those requests in several forms, depending on the type of the response. It costs 50 dollars for a license, but you can download the trial version and see what you think.
If your on Windows, then I would just stay with Fiddler.
Fiddler is the winner every time when comparing to Charles.
The "customize rules" feature of fiddler is unparalleled in any http debugger. The ability to write code to manipulate http requests and responses on-the-fly is invaluable to me and the work I do in web development.
There are so many features to fiddler that charles just does not have, and likely won't ever have. Fiddler is light-years ahead.
To complement the list, also be aware of http://mitmproxy.org/
I use both Charles Proxy and Fiddler for my HTTP/HTTPS level debugging.
Pros of Charles Proxy:
Handles HTTPS better (you get a Charles Certificate which you'd put in 'Trusted Authorities' list)
Has more features like Load/Save Session (esp. useful when debugging multiple pages), Mirror a website (useful in caching assets and hence faster debugging), etc.
As mentioned by jburgess, handles AMF.
Displays JSON, XML and other kind of responses in a tree structure, making it easier to read. Displays images in image responses instead of binary data.
Cons of Charles Proxy:
Cost :-)
If you're developing an application that transfers data using AMF (fairly common in a particular set of GIS web APIs I use regularly), Fiddler does not currently provide an AMF decoder that will allow you to easily view the binary data in an easily-readable format. Charles provides this functionality.
I’m using the Net panel in Firebug to evaluate the performance of web pages I’m writing.
Specifically, I’m wondering what the precise meaning is of the stages for each resource that’s downloaded (i.e. DNS lookup, Connecting, Blocking, Sending, Waiting, receiving).
But more generally, is there a Firebug guide where I can look this stuff up?
The various stages correspond to the various states of the connection being made for the resource. I don't know of any documents on them and a quick look around the Firebug network page doesn't show any explanations. There is some documentation in the resources area (wiki) of the Firebug site, though it looks like its subtly different than what is actually presented in the interface. They seem reasonably obvious to me, but I suppose I could be wrong, too.
DNS lookup - the name of the remote server is being resolved to an IP address
Connecting - a TCP/IP connection is being opened to the remote server
Blocking - the client is waiting for another request to complete (or a thread to become available) before sending the request
Sending - the client is sending data to the remote server
Waiting - the client is waiting on a response from the remote server
Receiving - the client is reading data from the remote server
You can read up on HTTP headers.
And for the whole firebug net panel you can read this.
Although it doesn’t include an answer to this question, Amy Hoy and Thomas Fuchs’s PDF ebook JavaScript Performance Rocks! has a lot of good information about measuring web page performance using Firebug