The other browsers tend to be trying out more privacy ideas. So the session ID would be an area where the other browsers can differ.
Then we have https://caniuse.com/ where I look over the website codes to see if there is anything that is unsupported in the target browsers.
And I always let the W3C checker take a look. It's over at https://validator.w3.org/
We want to pass with no errors or warnings.
I am unable to connect to a particular website through the non-Microsoft browsers Chrome (Windows, Mac & Linux), Mozilla (Windows, Mac & Linux) and Safari (Mac) intermittently during office hours. The connection works only sometimes and gets stuck at "Establishing TLS connection..".
But accessing the same website through Edge or/and IE 11 works without any interruption 24/7. I thought there was some difference in the way the TCP and SSL were handled by the browsers and so took many sanitised dumps on both webserver side and client, to compare the non-Microsoft browsers vs Microsoft browsers. But to my amusement the only real difference between both were that the non-microsoft browsers used 'Session IDs' and the other didn't. I do not think this can cause connection issues.
The captures show that the non-microsoft browser connections time out after not recieving packets that follow and/or include "Server Hello".However, Microsoft-browsers don't have these issues
This issue has been plauging me for 6 months now. I have reached a dead end after trying out options and swapping network devices on client end and server end.
My webserver is Apache2 on Ubuntu 14 and the site is developed in php5.
Find capture dumps here : https://www.dropbox.com/sh/jiuh4k1b22... 4 capture files included : server end and client end for each Chrome and Edge.
(Edit : The below link has latest captures where Chrome and Edge uses same Cipher Suites and plus this will show that the above behavior is consistent and not a glitch.
Below is the packet timeline for "Client Side Capture.pcap" at https://www.dropbox.com/sh/ktz2b6nuvam4isk/AAB7n8SGcBmPyJNVbZfdKZqna?dl=0 :
First Connection using Chrome :
Url for website entered - Packet no. 1 to Packet no. 28
Kept Idle at Login Page - Packet no. 29 to Packet no. 30
Logged in to the website : Packet no. 31 to Packet no. 46
Closed browser : Packet no. 47 to Packet no. 48
CONNECTION TIME OUT
Second Connection using Edge :
Url for website entered : Packet 49 to Packet 102
Kept Idle at Login Page : No Keep Alives even after being IDLE for more than 45 seconds
Logged in to the website : Packet no. 103 to Packet no. 186
Idle: Packet no. 187 to Packet no. 203 instead of KeepAlives
Logged Out: Packet no. 204 to Packet no. 245
Closed browser : Packet no. 246 to Packet no. 247
SUCCESSFULLY CONNECTED
Third Connection using Edge :
Url for website entered : Packet 248 to Packet 299
Kept Idle at Login Page : No Keep Alives even after being IDLE for more than 45 seconds
Logged in to the website : Packet no. 300 to Packet no. 348
Logged Out: Packet no. 349 to Packet no. 390
Closed browser : Packet no. 391 to Packet no. 394
SUCCESSFULLY CONNECTED
Fourth Connection using Incognitto Chrome :
Url for website entered : Packet no. 395 to Packet no. 534
Kept Idle at Login Page : Packet no. 535 to Packet no. 563
Logged in to the website : Packet no. 564 to Packet no. 582
CONNECTION TIME OUT
The only things that stand out are Session IDs and a few additional Extensions used by Chrome.)
Maybe, there is a filtering device, but then how does Edge and IE 11 work!!!
If it is an application or coding error, how does the non-Microsoft browsers spring to life at around end of work hours and weekends!!!

Chowhound
Comic Vine
GameFAQs
GameSpot
Giant Bomb
TechRepublic