Jetpack: Map Block: Add an option to render map as a static image

[dero]

Is your feature request related to a problem? Please describe.

Even a single Map block element loads relatively large amounts of assets on the front-end, uses a lot of CPU and spawns several worker threads. There is no "static" map block / option available.

Average desktop numbers for the stock twentytwenty theme installation and a single post page with and without the Jetpack Map Block on the page:

• Lighthouse score (without): ~60.
• Lighthouse score (with): ~11.
• Scripting time (without): ~330 ms
• Scripting time (with): ~1100 ms
• Worker threads (without): 0
• Worker threads (with): 8
• Network transfer (without): 0.8 MB
• Network transfer (with): 1.9 MB

Describe the solution you'd like

Assuming that not all users of the Map block _need_ an interactive map on their site, an option to render a map as an image using the Mapbox Static Image API could noticeably improve performance.

The static image could also serve as a placeholder while the interactive experience is being loaded (maybe the initialization can happen lazily based on viewport position; maybe the user can trigger the interactive experience by clicking / tapping the static image).

The API supports markers in static images. I'd suggest adding an option to the Block settings that would allow authors to not load the whole Mapbox runtime and only display a pre-generated map image instead. Something like Interactive: Yes; On click / tap; No.

Additional context / considerations / ideas

Pricing: Opportunity to provide more value. Mapbox's free tier allows for 50,000 map loads per month and also up to 50,000 Static Image API hits. By fetching and storing a static representation of the map, we would only consume the quota (Static API quota) when a static image is generated / regenerated or when the user opts for the interactive experience (map load quota).

Save-Data: Feels like not-initializing a full map experience when the Save-Data header is on could be a good idea.

Responsiveness: Currently the block changes its width on the front end to fit on the page. This may not be ideal for static images.

[dero]

Hey @kienstra, could you please take a look and let me know if you have any ideas related to this suggestion? Thanks!

[jeherve]

cc @Automattic/explorers who have been working on improvements to the Map block in the last few releases.

[kienstra]

Hi @dero,
This sounds like a good idea.

There doesn't look to be a concern for backwards-compatibility in the save function.

That function only saves a container in the post content, but the actual markup of the block isn't saved in the content.

As you found in, this could improve scripting time.

[dero]

@jeherve This issue has been stale for almost 3 weeks now. It's certainly nothing urgent, but I'm assigning it to you since I don't know who should be responsible for (any) next step. Feel free to reassign appropriately.

[andrewserong]

@apeatling I've added this to our backlog (proposing that we add it to the next sprint?) as adding in static image support will also help unblock https://github.com/Automattic/wp-calypso/issues/48883 in the short-term.

[creativecoder]

👍 @andrewserong -- I also want to note that as map block usage increases, this will likely be an important cost control measure for WP.com (which current provides a key for WP.com hosted sites).

Also related, see these comments about the Contact widget maps: pbAPfg-1d6-p2#comment-2431