Remove importmap polyfill

[swissspidy]

In #60348 / [57492] a polyfill was added for import maps (type="importmap").

From what I can see, all browsers supported by WordPress actually already do support import maps, so there isn't really a reason to include this polyfill.

For reference:

• ​caniuse.com data
• ​WordPress browser support policy

If you take the list of supported browsers from that page (also available ​in this browserslist config) and ​test it on the browserslist website, you'll only get browsers that already support import maps.

Thus, I propose removing this polyfill again by not printing it anymore in \WP_Script_Modules::print_import_map()

Note: actual performance impact is minimal as on all these browsers, no extra script is loaded. It's just a bit of unnecessary inline JS sent over the wire.

[luisherranz]

The usage of Safari < 16.3 on iOS is still 3.6%, and WordPress is meant to support any browser with usage bigger than 1%.

[swissspidy]

Replying to luisherranz:

The usage of Safari < 16.3 on iOS is still 3.6%, and WordPress is meant to support any browser with usage bigger than 1%.

My understanding is that means a single browser version bigger than 1%, not a range of versions added together being bigger than 1%. Otherwise our browserslist config is incorrect. And if you check the browserslist config above, you‘ll see those Safari versions not being liated.

Look at individual iOS Safari versions (I‘m only listing the ones without importmap support):

16.3 - 0.42% usage
16.2 - 0.24% usage
16.1 - 0.49% usage

All below 1%

[swissspidy]

Quoting @gziolo:

It looks like we don't need the polyfill for the import map, taking into account the list of currently supported browsers.

[gziolo]

I see the full context now. I'm not sure what's the correct way to interpret the browserslist settings vs the policy that WordPres has. However, realistically looking at where we are, we have been using these settings since WordPress 5.0 so I would say it's fair to say it should be the norm how @swissspidy has interpreted them.

@youknowriad and @desrosj, what do you think?

[luisherranz]

Look at individual iOS Safari versions (I‘m only listing the ones without importmap support):
16.3 - 0.42% usage
16.2 - 0.24% usage
16.1 - 0.49% usage
All below 1%

That doesn't make any sense to me. It's totally arbitrary. Browser vendors can release new versions each week or each year. Also, why minor and not major versions? The policy doesn't say anything about this. If we choose major versions, iOS 16 > 1%.

In my opinion, for the frontend, it would be better to use global usage. Something like global > 95%. For the admin is a different story.

[swissspidy]

Also, why minor and not major versions? The policy doesn't say anything about this.

FWIW I don't think Safari really treats those as minor versions, they don't follow semver.

In my opinion, for the frontend, it would be better to use global usage. Something like global > 95%. For the admin is a different story.

Just noting that this browserslist config and browser support policy page have been like this for years, ever since Gutenberg got introduced. My proposal is based on this existing documentation.

If we want to change the WP browser support policy I suggest writing a detailed make/core proposal, including a draft PR for the browserslist config so we can vet bundle size differences.