Optimised stile-specific vector tile/sprite serving for static usecases

[CommanderStorm]

Currently, we trust our users to have optimised the tiles and styles themselves.
Thing is, I don't think they do that optimally and think that we could do better.

This is definitively dependent on

• Serve styles #1607
• feat: style serving #1711

To get performance benchmarks, likely also need

• draft: style rendering #1754

These optimiations only work if the style is static => a development mode is not something that would work with this model

There are optimisations, which we can do

• [ALWAYS]
• [SOMETIMES] (only for static data)
• [NEVER] (would impact rendering)

Optimising the styles

One potential optimization I thought of is "query-optimizing" styles, similar to how databases optimize queries.

Here are some possible optimizations that might be achievable with a reasonable effort:

• [ALWAYS] remove impossible or hidden sources
• [SOMETIMES] optimise the order of filter-selections in for example "any", "all", "match", "case" by selectivity
• [SOMETIMES] if certain that a predicate can never/ will always happen => replace with the literal
• [SOMETIMES] (unsure if benefitial) add ´{min,max}_zoom´ tags based on the actual data, filters and impossible styling conditions (think: oppacity=0), not just the part we export to tilejson

Opimising the tiles

This is likely a lot harder and much more of a risk.
Here is mapbox docs on a similar feature.

After discussion on slack, this blog post and this github repo came up doing the same thing

• [ALWAYS] make sure that martin only encodes the exact data that a style would actually look at.
  • => "pre-filter" before going over the network
• [SOMETIMES] cache the filtered output

optimised sprites

Some styles may permit to statically know which sprites are going to be used.
For others, we might need to do a "full table scan" to gather this statistic.

Optimised fonts

nothing that I can think of.
Maybe pre-warming a cache, but nothing major.

Discussion

Now to the fun part:

• How effective would these be?
• Would there be other optimisations are safely possible to do?
• What optimisations do maplibre-{native,gl} already do in this area?
• Are there tile servers/other projects (which I missed) that tired this in the past?

[springmeyer]

You may also be interested to check out https://github.com/mapbox/vtshaver. It is the library that powers the Mapbox "style-optimized" API which you reference above.

As context, there are a few ways to think about performance in regards to style optimization:

1. Style changes to optimize MapLibre rendering speed (to ensure the renderer needs to do the least work both in parsing the style and rendering the data as the style describes)
2. Vector tile changes to optimize tile size in order to allow tiles to be transferred over the network faster (e.g. compression, data sorting, and data reductions)
3. Vector tile changes to improve MapLibre tile decoding speed, filtering overhead, sprite parsing overhead, glyph fetching overhead, and rendering speed

The https://github.com/mapbox/vtshaver library is primarily designed to address #2 and #3 above, by helping remove data that is not needed for a given style (while doing it precisely in order to ensure the style renders visually identical). But you can also look at the vtshaver result, see what was optimized, and consider "upstreaming" the changes to the style (#1 above), to either a) further help vtshaver remove more unnecessary data, leading to more optimized tiles or b) avoid the need for vtshaver to do as much work in the first place.

Now, you smartly reference that if styles change then the tile optimization needs to be recomputed (or the style needs to be static and not change). Dynamical style changes can work: it requires some orchestration but can allow styles to be changed while still dynamically optimizing the tiles they reference. The big question however is whether a given usecase will support establishing a 1:1 relationship between style and tile source. Mapbox Vector Tiles are very useful, by design, such that a single tile source can often be used seamlessly with multiple different styles. So there can be great value in a 1:Many relationship of tiles to styles. But of course for top performance, 1:1, will be best. And therefore an ideal setup may be 1:Many tile source creation while allowing 1:1 on-the-fly dynamically, to have the best of both worlds.

Note: the latest release of https://github.com/mapbox/vtshaver currently uses Mapbox GL Native, not MapLibre Native (so it is not viable to use vtshaver with MapLibre-specific styles). But it would be feasible for a MapLibre Native specific version to be created.

[CommanderStorm]

Thanks a ton for this context. That helps me a ton ❤