Map tiles are the little square images which our web maps assemble into useful interactive maps. OpenStreet map describes tiles like this. In essence they are commonly used to serve up imagery or pre-rendered cartographic datasets inside a web mapping environment. Map tiles are also a very useful alternative to using vector data, when the amount of data becomes too dense. Map tiles are a base technology of modern web maps.

There are numerous “map renderers” on the market presently. Some are hugely expensive, some are free, some are open source. Most are complex, all need some element of tuning.

You can also plug into vendor tiles too, Google Maps is a common example of this, but also check out Mapbox and CartoDB if you are interested, they have excellent SAAS based alternatives.

There is a common assumption when dealing with map tiles: that the only thing differentiating them is how they look. Without a doubt, their appearance it enormously important, but its not the only measure of their quality. performance also matters. Over the last few months Maptiks has shown us that tile performance can be measured and documented. This has provided us with a unique insight into the performance of different vendors and different mapping solutions.

Let me show you an example. I built a node renderer using the wonderful mapnik to demonstrate how to overlay 70,000 polygons on a Google Map. Then we wrote another article on how to show the same polygons on LeafletJS too. This node-mapnik renderer only builds tiles on the fly, it doesn’t cache anything. For production purposes this would not be optimal (unless highly dynamic data was in question), but for a proof-of-concept it works well. Inadvertently, we found ourselves with a nice comparison of Google Maps and LeafletJS & Open-Street-Map (OSM).

The renderer produces a very simple result, like this:

Now, we can’t compare numbers of loads on each map, because of SEO differences in the articles themselves, and the timing of when we added Maptiks to each map. However, we can look at the performance differences over a fixed period of time, in this case the last week (April 21st – 28th 2015).

 

LeafletJS & OSM

Google Maps

The images above show the Maptiks tile performance graphs for each of the maps in question. Maptiks calculates a layer load as the amount of time its takes for a tile layer to complete loading all the tiles it needs to load per request. This means that the first request will always be the biggest (likely slowest too) because the browser will cache all loaded tiles. If the user was then to pan the browser will request only the necessary additional tiles to fill the blank space and pull the tiles already in the session from its cache, which is much faster. Some mapping platforms will request even more tiles at the beginning of a session to allow the user to subsequently not feel the effect of loading blank tiles.

Maptiks automatically detects any tile layers which are loaded (and you can see that someone briefly turned on the Google Maps Hybrid layer at the beginning of the week in question). The full URL is provided in the table under the graph to confirm the source as are the aggregated timings of each layer.

A single red line can be seen on each graph, thats is where maptiks has detected an error (a 404 or 500 response) in one of the tiles.

The first thing to notice is the scale on two the graphs. The average load time on the Google Maps graph goes to 4000ms where as the max on the leaflet Map goes to 2500ms. This alone indicates a general performance difference in the two platforms. Additionally, it can be seen that the minimums for the Leaflet map are significantly smaller indicating perhaps that Leaflet is doing abetter job of caching more tiles or that the OSM tiles are served more quickly than Google’s.

Another point to note is that there is a general difference between how Google Maps and LeafletJS consume the additional data source. We know the infrastructure rendering the “Sparkgeo Census Tiles” is exactly the same, so any difference is likely more to do with implementation. Undoubtably in both examples some extra effort could go into optimizing how the mapping libraries consume the additional map tiles, things can always be made to go faster (its just a matter of time and money!). But as it stands the “average load time” of the Sparkgeo tiles is quicker in Google Maps.

LeafletJS is loading base layers faster, but Google Maps is loading the Sparkgeo Census Tiles layer faster

A general comparison of these two maps indicates that LeafletJS is loading base layers faster, but Google Maps is loading the Sparkgeo Census Tiles layer faster. We should also note that the differences here are purely client side. Measuring the performance of your web server will not provide the comparative information we have discovered with Maptiks. Our web server simply says that tiles were requested and delivered.

Measuring the performance of your web server will not provide the comparative information we have discovered with Maptiks.

Maptiks has provided a very different and more enlightening perspective on how our census tiles are performing in the wild.