Browser performance issues using query widget
Fortunately, we are rolling out chrome as a default browser, and this seems to be the best solution. I created a tiled service (which comes with its own set of issues) and performance was marginally better, the best response was 28 seconds, from 42 seconds to query records for Chrome, for Firefox it was 40 seconds, from 54 seconds. The best response from IE was 5 minutes and 3 seconds while edge took 2 min 35 seconds. So not all browsers are created equal! 
Note these were the best times...running the identical query several times I noticed in some instances there wasn't any improvement at all. Note we aren't necessarily interested in viewing the data, just pulling a simple query and saving to .csv.
Note that I've run the exact same query on the exact same data, but on a .gdb stored on locally networked drive using ArcMap and it took 1.5 seconds. I can completely understand and accept some latency in querying data across the web, but given the immense power of cloud computing that we have in 2017...I'm wondering why it's taking so long to run a simple, basic query. ESRI suggest not increasing the MaxRecordsCount beyond 2000, so they are well aware of the latency/performance issue. I hope they will direct resources to making it a lot faster, if not then at least make it more obvious to the end user that only 2000 records have been selected.
"Limiting the max record count to 2000 records does no prevent more than a total of 2000 records from being requested from the service, but does keep requests more concise for server performance. Check out this blog for more details on how ArcGIS Online makes requests to the data."
Yes, that is correct, but....If you run your query, you click on those dot thingies, and export to .csv, it will only export 2,000 records. To get all the records, you have to scroll, scroll, scroll and scroll down, down, down, right to the end of all the records that appear in the search pane, then export. This isn't obvious, and this is what I'm saying. I thought there was a problem with the map, and kept refreshing/adding layers/removing layers/rebuilding it to see if it would bring up all records for export.
I spent a lot of time troubleshooting why it would only bring up 2,000 records for export, even after I had increased the MaxRecordsCount to 20,000, and it was saying in small print '10,756 records found' (Hmmm, okay, so it has 'found' 10,756 records, so it knows that they're there, MaxRecordsCount = 20,000, correct layer is being queried, but why is it exporting only 2,000 to .csv?) It was purely by accident that I happened to start scrolling deep down through the records that more of them started magically appearing when I exported (Again I thought this was a problem with the map, or the way the all browsers were rendering things). If you don't scroll all the way down, you'll only get a few thousand extra, so you have to be careful and check the .csv against the no. of records found to make sure you're got them all. If the user sees that it has found 10,756 records, then it should grab all of them for export. There should be no scrolling required. The exact same problem applies to saving features to My Content. Moreover, this isn't a complicated query, it just runs a single query against a single Yes/No field in a table containing about 15 fields.
Again, performance wise, this is where we have found that Firefox and Chrome stand out way above IE and Edge because these last two browsers get completely bogged down and stopped responding trying to scroll down through the (tiled service) records.
