COVID-19
We've had a number of comments recently regarding map load performance, and server performance more broadly, and have found that this is primarily due to the change in network utilisation patterns as a result of the massive increase in video streaming, meeting and e-learning usage in the wake of the COVID-19 situation. We have worked with our upstream providers to maintain server response times, and we are currently operating within internal tolerances.
How maps work on Mango
To understand map load times, we first have to understand the underlying technology that is generating the map.
Mango maps are made up of as layers of continuously tiled images – one set of tiles for each Layer Group, at every zoom level, covering the full extents of your data.
Each tile is 256px x 256px, and around 15KB in size – regardless of how many layers each tile contains. A normal screen requires around 24 tiles to cover the browser – meaning around 360KB of data needs to be downloaded per layer group.
Why don't we just pre-render all tiles for all zoom levels?
The number of tiles required to generate a 'global' layer at each zoom level. By default, Mango will generate and display tiles down to Zoom level 20.
For complete global coverage at Zoom 20, we'd need to generate 1,099,511,627,776 tiles.
That's one trillion, ninety-nine billion, five hundred eleven million, six hundred twenty-seven thousand, seven hundred and seventy-six image tiles. 😰
Assuming a nominal file size per tile of 16 KB, that's 16 petabytes of data storage.
For customers than need tighter zooms, it's possible to extend the zoom range to Level 22. With these two extra zoom steps, the number of tiles required for global coverage jumps to 17,592,186,044,416 (seventeen trillion, five hundred ninety-two billion, one hundred eighty-six million, forty-four thousand, four hundred and sixteen ), using around 264 Petabytes of storage. 😱
Although our hosting providers would be very pleased if we started storing global coverages for every zoom level for every layer group in every map made by every customer, we do not pre-generate a tile set with global coverage for all zoom levels for each layer group.
While some mapping platforms charge for the compute cycles required to generate tiles, the storage of tiles, or the caching of tiles in our global content delivery network, our data quotas consider only the storage for the source datasets you upload to Mango.
But my maps don't cover the whole world, can't you load mine faster?
Mango loads only tiles currently visible, given the viewer's display size and resolution, with a small buffer for tiles around off-screen. As you pan and zoom around the map, the browser requests new tiles. Once a tiles is generated, it's cached in our CDN. The next time that tile is requested, it's sent immediately from the cache rather than being regenerated.
Maps are optimised for end users
When you view the map as the administrator, your maps are objectively slower than when they are viewed by anyone you share the map with.
There are two primary reasons for this: firstly, the data overhead required to load the administration panel and all associated account tools when you are signed in to your account; and secondly, because we generate fresh map tiles every time you make changes to any map visualisation layer. This requires clearing the caches for the updated layer group and then regenerating tiles for the layer group, along with any other instances of that data that exists in other layers in the same map.
For the layer you edit, the number of layers and the complexity of the data of each layer that share the same layer group determines how fast this process is. For example, a layer group with a single layer will regenerate faster than a layer group containing 7 complex layers, as we regenerate the entire merged layer group.
End users of the map who aren’t signed in to Mango see an interface that doesn’t have the extra data overhead of the administration panel, and all the tiles they see are retrieved from the cache, so a map that has not undergone recent style or feature updates will load faster for them than for the administrator who has just edited a feature.
The worldwide content delivery network used by Mango has endpoints across the globe, making map load time fast for users everywhere.
There are several things that can be done to make Mango run more quickly for end users:
How to speed up maps: warm up the tile cache
Mango's tile cache system means we will transform your data for any given zoom level and location into tiles every time you update the layer group. Once a tile is generated, we store the tile in our global Content Delivery Network (CDN) cache. Retrieving files from our global CDN is much faster than calculating and generating new tiles from our servers, so the next next time that zoom level and location is viewed, we simply retrieve the tile from our CDN.
So, the more your map is used, the faster it will become, as more of the tiles will be already stored in the cache rather than being generated for the first time.
If you are conscious of performance for your end users, we recommend 'warming up the cache' before you release the map to end users by generating and caching a range of tiles. To do this, simply take some time to use your map - zoom in and around key areas of interest that users would likely visit to pre-generate these tiles so that they are cached for the public users.
Minimise the number of Group Layers turned on by default
Web maps are made by stacking layers of data visualisations on top of each other. In Mango we have the concept of a group layers, with each group able to contain many layers, rendered as a single composite image layer of the layers within the group. Each Layer Group has a legend visibility control, so grouping layers by type or theme allows users to easily turn whole classes of data on and off in the legend.
Grouping layers reduces the overhead for loading maps. By putting your data layers into groups, you can minimise the overall size of your map. Each layer within a Layer Group is combined into a single layer and served to the map viewer. Learn more about Layer Groups.
For example, if we have a map with six layers all in one layer group, only one layer of tiles is rendered.
If, however, we have two layer groups and put three layers in each group layer, the system will now render two layers of tiles and stack them on top of each other so instead of downloading 360 KB of data, we now need to download about 720 KB.
This increases with each new group layer.
3 group layers means around 1 MB; 10 group layers, 3.6 MB.
As you can see, it’s quite easy to end up with a very ‘heavy’ map.
If your users have a slow internet connection, we don’t recommend having any more than three group layers turned on by default. If you do require more than three, then it’s best to set some layer groups to off by default in the Layers panel. This way the map loads the essential layers, and non-essential layers are only download when the user turns them on in the legend.
Data updates
Each time you update a dataset, we process new tiles for every map using that dataset. If your data is updating frequently, it's more likely that you will experience slower tile delivery as the cache is cleared after every update.
Lastly, avoid using Clustered Pushpins or Mouse Highlight tools on layers with lots of features
Unlike map tile layers that are rendered server-side, clustered pushpins are rendered client-side (in your browser). Browsers are able to utilise only your system resources, so the performance of clustered pushpins will vary for each user and each device.
Because of this, we don’t recommend using the clustered pushpin feature or the mouse over to highlight feature for any layers that have more than 10,000 features. The calculations to place these items and draw the highlights is complex and the memory requirements to process and display these overlays can become very high. Layers with more features than the above could cause the user's browser to become slow, and in some circumstances, crash.