This is a general question. We've noticed that scroll zooming in our ArcGIS JavaScript API 4x maps is a major pain point for performance. The problem is that zooming from a zoom level of say, 5 to 17 will go through all scales in between: 6,7,8,9,10... and so on.
Even though the user passes through the scale almost instantly, the fetch for the tile at each of these scales is queued up and the browser must wait for all these intermediate layers to be fetched from the server before it will load the data the user actually wants at scale 17.
This causes problems for both the browser and our servers. Most browsers limit concurrent network requests so our apps can become slowed because of a large backlog of queued requests that must be processed. It also causes undue strain on the server trying to serve many requests.
The behaviour I would like to see is to have the browser/API somehow be able to cancel fetches if they're no longer needed because the user is not at that scale or view extent and/or an ability to prioritize fetches for data at the scale view extent the user is currently at.
I read some forums that suggested the Google Earth API had some functionality that handled this as well as with Leaflet however I did not confirm or test.
I would like to know if the API has any tools or ability to improve such a use case and what the recommended approach would be from ESRI to handle such a scenario.
Unfortunately I cannot provide much in the way of samples as our site is not public. In order to reproduce, you would load an ArcGIS JS API map with cached tiled raster or vector data, look at the network pane in the developer tools and observe the network traffic as you zoom in or out via continual scrolling. Note how fetches are made at every zoom level in the network pane.
Update/correction: above behaviour tested extensively on API v. 4.15 but observed in 4.15-4.18. Correction: behaviour is also specific to ImageryTileLayers (see below)
