Okay, so let's get down to the nitty-gritty of map load times. First things first, we need to understand the magic behind the scenes that brings those colorful tiles to your screen.
Think of a Mango map like a towering stack of pancakes - each layer is a fluffy pancake, and the whole thing is topped with a generous serving of data syrup. Yum!
Now, each of those pancakes (I mean, layers) is sliced up into tiny 256px by 256px bits, like a really fancy chef's knife in action. And get this - each little slice is only 15KB in size. That's smaller than a picture of your cat you posted on Instagram!
But here's the catch: your browser needs to download around 24 of those slices (ahem, tiles) to cover your screen. So basically, your browser is chowing down on a whole stack of data pancakes, one bite (or tile) at a time. That's roughly 360KB of data per layer group, or as I like to call it, a mini feast for your browser.
Why can't we just pre-render every single tile for all zoom levels? It's not like we have anything better to do with our time, right?
Well, it turns out that the number of tiles required to make a global map at every zoom level is just a teensy bit mind-boggling. For example, at Zoom level 20, we're talking about generating over one trillion tiles. Yep, you heard that right - one trillion. That's like trying to count all the hairs on a woolly mammoth's back. And if we want to get even zoomier (technical term), things get even crazier. At Zoom level 22, we're talking about a whopping 17 trillion tiles. I don't even know what comes after trillion, but I'm pretty sure it's not good.
To put it in perspective, if every tile was a star, we'd need 43 Milky Way galaxies just to fit them all in. That's a whole lot of stars, my friend.
Now, I know what you're thinking - "But why can't we just store all one trillion, ninety-nine billion, five hundred eleven million, six hundred twenty-seven thousand, seven hundred and seventy-six of those tiles anyway? Who needs 264 petabytes of free space on their hard drive?" Well, as much as we love our data hosting providers, we can't exactly justify storing that much data (nor afford to). So instead, we only render and cache the tiles that you actually need. It's like a virtual concierge service - we're always ready to serve you the tiles you want, but we don't waste resources on the ones you don't need.
So there you have it - the secret behind our tile generation and storage strategy. Who knew maps could be so complicated?
"Service X is faster. Why isn't yours like theirs?"
When it comes to storage, we're happy to let you upload as many datasets as can fit in your quota. But when it comes to generating, storing, and caching tiles, well, we don't really factor that into our plans. It's like when you go to an all-you-can-eat buffet - you can pile as much food on your plate as you want, but you still have to pay for the drink and dessert.
Some of our competitors, on the other hand, charge you for every little thing. Need to generate some tiles? That'll cost you. Want to store those tiles? Better break out your wallet. Oh, and don't forget about caching those tiles in our global content delivery network - that'll be an arm and a leg, please.
So what does that mean for you, the customer? Well, for starters, it means that you can update your data to your heart's content without worrying about breaking the bank. It also means that you can rest easy knowing that we've got your back when it comes to tiles - we'll take care of generating, storing, and caching them for you so you don't have to. It's like having your own personal tile valet service.
In short, our pricing is all about keeping things simple and affordable for you. We don't believe in nickel-and-diming our customers - we're all about providing the best possible value for your money. And if that means giving you unlimited tile services without breaking the bank, well, we're happy to do it.
Maps are optimised for end users
When you view your maps as an administrator, they're objectively slower than when viewed by anyone you share the map with. So, what gives?
There are a couple of reasons for this. First, there's the data overhead required to load the administration panel and all associated account tools when you're signed in to your account. Second, every time you make changes to any map visualisation layer, we generate fresh map tiles, which 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.
The complexity of the layer group also affects how fast the regeneration process is. For instance, a layer group with a single layer regenerates faster than a layer group containing 7 complex layers since we regenerate the entire merged layer group.
End users 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 hasn't undergone recent style or feature updates will load faster for them than for the administrator who has just edited a feature.
But fear not, our worldwide content delivery network has endpoints across the globe, ensuring fast map load times for users no matter where they are.
If you're still seeing slow maps when viewing maps, there are several things that can be done to make things faster for end users:
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.
Minimise the number of layers per Group Layer
Group layers help you combine related visualisations into a single layer, reducing load time and helping the end user discover related features.
Group layers with a large number of layers within will take considerable time to process and generate tiles. A change to the layer style of any contained layer means a the tileset for the entire group must be regenerated and any cached tiles are cleared. This will result in a very slow map.
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.
Avoid using Clustered Pushpins or Mouse Highlight tools on layers with lots of features
Picture this: you've got a map with thousands of pushpins, and you want to make it look fancy by clustering them together or highlighting them on mouseover. But before you go all out, consider this: clustered pushpins and mouseover highlights are rendered client-side (in your browser), and your browser's performance can only take so much.
That's right, using these features can take a toll on your system's resources, and the user experience may vary depending on the device being used. We're not saying this to be a buzzkill, but to spare you the pain of a slow or, heaven forbid, crashed browser.
To avoid any mishaps, we suggest using these features only for layers with fewer than 10,000 features. The calculations and memory requirements to process and display clusters and highlights for larger layers can become very high and potentially turn your browser into a snail. So go easy on your device, and it'll go easy on you.