i don’t disagree with the gist of your request, but i think you’re asking for something that is not a small thing. it’s like i would like every person on earth to have 3 healthy and satisfying meals each day, but that’s no small thing.
it may help to understand what the map actually is. there’s the map container itself, along with all the fancy code needed to display the map. there’s a basemap layer that contains map image tiles in 8-bit .png format from Google. there’s a observation marker (circles or pins, depending on zoom level) layer that contains image tiles in 32-bit .png format from iNat. paired with the observation marker layer, there’s an invisible layer created from UTFgrid .json files, which allows the user to “interact” with the markers. there are taxon checklist place layers and taxon range layers that may also show up, depending on existence of such data. and finally, there’s an optional GBIF observation layer that pops up only if the user selects it.
the tiles in the map are displayed at 256px x 256px (Google) or 512px x 512px (iNat), and the page will pull only the tiles needed to fill the map container. so an average desktop screen might need 6 to 12 tiles per layer, depending on what’s shown. each Google basemap tile is relatively small – in the neighborhood of 10-30KB. the UTFgrids (tiles) are bigger – up to maybe 250KB, depending on how many observations they attempt to represent. the observation marker tiles can be even bigger – maybe up to 600KB+, depending on number of observations. part of why the observation marker tiles are so big is that they are oversized – 1024px x 1024px – which allows for better display on very high-resolution screens. The other part is that they are 32-bit .pngs (as opposed to Google’s 8-bit files).
now, it definitely does seem to take iNat’s servers some time to create / deliver the UTFgrids and observation tiles. you will definitely note that tiles with lots of observation markers take much longer to come back vs tiles with fewer observation markers.
it probably is technically possible to save copies of the observation markers, and i suppose, the matching UTFgrids, but that would require a significant rewrite of the whole mapping architecture, i would think. no small task. and while you might save the server a few ad hoc requests, you would instead force it to pre-query every possible set of combinations of possible queries (or at least queries for a certain set of parameter combinations) and to save all those tiles somewhere. i would guess that the taxon map is not so heavily used that doing this would make sense.
but there might be a couple of things that make sense. i would guess most people aren’t clicking on the maps to open up observations most of the time. so you could save on resources by not loading the UTFgrids unless specifically requested by the user. and you could also configure iNat’s servers to deliver 512px x 512px observation marker tiles that are actually 512px x 512px, which would make those tiles 25% as large. or you could at least make that configurable so that people don’t have to get the oversized tiles if they don’t want them. smaller 256px x 256px tiles might also help reduce the size of files that need to be delivered. and reduced bit depth might further reduce the size. these might not be small changes, but they probably would provide the most bang for the buck.