Mapping exploration

[rjmackay]

• How do 5 maps on a page perform?
• How can we make it better?

Timebox: 1 day

[rowasc]

some thoughts about this while I get started Server side render/image creation

• not necessarily live data: ie: we could get a pre-created/cached image of that map deployment for the thumbnail with a max-age setting.
• Maybe only generate the map images when someone requests the deployment list. Since this would be prototype / early adopters in enterprise only , maybe it's not worth the extra complexity and we just generate the thumbnails once every X hours for everyone, which could be optimized if we want to be some smarter algo for the thumbnail updates

Client side: If we go for client side solutions we are basically killing the mobile users and users with slow connections I think, but at the same time it's probably not our target audience for deployment organizations .

[rowasc]

just some more notes to myself

Client side: If we go for client side solutions we are basically killing the mobile users and users with slow connections I think, but at the same time it's probably not our target audience for deployment organizations .

I need to run more tests and experiment some more, but from some quick tests I run today it looks like definitely mobile users will be negatively affected by a live version of ~5maps. I will be working on figuring this out today.

On the other hand, loading ~5 maps in desktop apparently is OK, fast even. It's a bit slow to render the new tiles on the map, which I'll test today to report back, but that is not really something specific to having multiple maps per view

[rowasc]

https://docs.google.com/a/ushahidi.com/document/d/1oNiYzKnAEBqMfASrWjZt8CvUfU_PYpPc83kK_AZs92g/edit?disco=AAAABdJ88Fs

Link to conversation here where we are trying to figure out the requirements a bit more

[rowasc]

This is the repo , for the curious https://github.com/ushahidi/meatloaf_experimental_maps Since the timebox is gone, here is what I found out

• First meaningful paint tends to be around 5 seconds if you are not using any optimizations beyond disabled interactions/clusters and other stuff that leaflet already has built in. It can be way higher but that's mostly for very slow devices or very slow network connections, or just a couple outlier runs.
• The first most common bottleneck I ran into is just getting and lightly processing the data that we get some servers. This is not going away.
• Rendering the maps themselves wasn't a big a problem especially if you disable scrolling and zooming, but getting the data and generally just improving page load times is where I'd focus right now.
• There's an inevitable bottleneck in the form of loading scripts, obviously, and stylesheets that cannot be deferred for the critical path (but those that can, we should defer)
• Anecdotal: My Note 5 didn't behave much worse than the desktop experience.

The real fun and improvement starts when we use a web worker to offload the server requests and send back a message to the main thread to render the map as we get each deployment. This makes for a much better user experience and has the result of lowering the first meaningful paint to sub 2s times. For browser compatibility there are some polyfills that make this usable beyond the modern browsers, so it should be OK for the target audience of the dashboard.
The one thing that would make a massive difference would be if we were ablet o do L.geojson in webworkers. This is not possible right now due to leaflet. I think there are big perf gains to be had with mapbox gl, but I didn't get to play with it yet.

TLDR: web workers are awesome and improve the user experience we can provide. MapboxGL would be a good 2hs timeboxed experiment to run and report back. If If I get some time during the weekend I will make a quick test with mapbox too

[rowasc]

Something else I discovered while doing the mapping experiments: we might need the bring the config for each deployment too, since that's where the map configurations live (mark cluster size being the most important I think)

[rowasc]

@jshorland @justinscherer We're wondering if for the use case of maps in the organization projects panel we have a specific target of browsers in mind. To make it as performant as possible, we need to use newer technologies, web workers and MapBoxGL JS (preferred). Both work best (or at all) in modern browsers, think evergreen browsers in general and relatively new iPhone/Android devices. As a reference: https://caniuse.com/#search=WebGL%20-%203D%20Canvas%20graphics https://caniuse.com/#feat=webworkers

I'm thinking that since this is mostly for enterprise users and not consumer oriented (right??) it would be possible to do this with new technologies like this, but we need your call on this.

[justinscherer]

Great question @rowasc

Is there an alternative that would have better low-end browser support with the same design?

How would those libraries behave on modern-ish browsers with a slow connection?

Is there a way to design the view to depricate for bad/old browsers? This could be a future enhancement, potentially.

[justinscherer]

Just a reminder. The map images only need to be thumbnails. They don't need to plan/zoom, etc.

[rowasc]

Is there an alternative that would have better low-end browser support with the same design?

• The alternative is using only web workers + leaflet only (plus mapbox tiles) with a backward compatible script (polyfill) which basically "fakes" the technology in older devices so the page works, but without actually making it faster.

• Mapboxgl: no decent alternative AFAIK.

How would those libraries behave on modern-ish browsers with a slow connection?

• This would not be a major concern with leaflet at least. Meaning the libraries themselves won't be a massive problem. The real problem would be the map tile loading (because you load one per map/deployment) and the data, which are both inevitable, basically.

• I don't have a map box GL prototype to compare against but there's nothing there that would make me go "oh this will totally drop the load speed " -vs leaflet/other libraries-

[rjmackay]

The map images only need to be thumbnails. They don't need to plan/zoom, etc.

@justinscherer the thing here is that either we still have to load a full mapping library (ie. leaflet/mapboxgl) to render the deployment data on the map, or we need to have a rendering pipeline that generates static 'thumbnail' style images. What I'm trying to get at: pan/zoom interactions aren't the costly things parts of load times. Its more getting the data onto the map.

While mapbox does have some tools for adding your own data, they're mostly targeted at static datasets not dynamic data ie. post in the platform. Carto has some more possibilities - rendering map tiles from tables of data, so we'd just have to figure out how to sync our data into Carto. But I don't that something we can do in the scope of this first build.

[justinscherer]

Ok, given all this, using WebGL and webworkers should be fine. We should do a few tests afterwards and reassess in a few months.

[rowasc]

@rjmackay not sure what to do with this ticket :| do I move it to review?

[rjmackay]

@rowasc write up conclusions on this ticket https://zube.io/ushahidi/platform/c/3945 so it can become the spec for how we build the map components.