Make WordPress Core

Opened 6 weeks ago

Last modified 5 weeks ago

#60970 new defect (bug)

Remove importmap polyfill

Reported by: swissspidy's profile swissspidy Owned by:
Milestone: 6.6 Priority: normal
Severity: normal Version: 6.5
Component: Script Loader Keywords: dev-feedback
Focuses: Cc:

Description

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:

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.

Change History (6)

#1 follow-up: @luisherranz
6 weeks ago

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%.

#2 in reply to: ↑ 1 @swissspidy
6 weeks ago

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%

#3 @swissspidy
6 weeks ago

Quoting @gziolo:

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

#4 @gziolo
6 weeks ago

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?

#5 @luisherranz
5 weeks ago

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.

#6 @swissspidy
5 weeks ago

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.

Note: See TracTickets for help on using tickets.