Modules: Load the import map polyfill when needed

[gziolo]

What?

Explores whether there is a simple way to address the issue raised by @felixarntz in #55942 (comment):

For the import maps polyfill, it looks like that JS file is always loaded? I was using latest Chrome and it loaded for me, which it probably shouldn't (since Chrome supports import maps). Is there a way to perform a quick support check with inline JS instead so that the polyfill can only be loaded as needed? It's over 12kB, so if we can avoid that for most sites, that would be a good win.

Why?

It should be easier to handle in WordPress core, but as a quick experiment I replicated how we handle conditional polyfills in the past:

https://github.com/WordPress/wordpress-develop/blob/1bca32e30ede3f8731290b052b35c431d091e2f7/src/wp-includes/script-loader.php#L204-L214

How?

I used the conditional check for feature detection included on MDN:

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Modules#feature_detection

Testing Instructions

Testing Instructions for Keyboard

Screenshots or screencast

It works correctly with browsers that support import maps. I tested with Safari and Chrome:

import-map-polyfill.mov

[github-actions]

This pull request has changed or added PHP files. Please confirm whether these changes need to be synced to WordPress Core, and therefore featured in the next release of WordPress.

If so, it is recommended to create a new Trac ticket and submit a pull request to the WordPress Core Github repository soon after this pull request is merged.

If you're unsure, you can always ask for help in the #core-editor channel in WordPress Slack.

Thank you! ❤️

View changed files

❔ lib/experimental/modules/class-gutenberg-modules.php

[gziolo]

I only make it a normal pull request to be able to use Gutenberg PR Previewer powered by Playground. I'm not sure if that will help though.

[felixarntz]

Thanks @gziolo, this looks great! Two small concerns below.

[gziolo]

It works as expected with browsers that don't support import maps, like Firefox 107:

Screen.Recording.2023-12-20.at.22.56.48.mov

@felixarntz, I'll look tomorrow into how to optimize it based on your feedback.

[luisherranz]

Tested it in iOS, iPadOS and macOS versions with Safari 13, 14 and 15, and it works as expected.

I tested again the document.head.appendChild(importMapPolyfill) solution and that didn't work, so it seems like document.write is the key to making this work.

[felixarntz]

Thanks @gziolo, LGTM!

[Mamaduka]

I think this PR affected Largest Contentful Paint (classic) and LCP - TTFB (classic) stats - https://www.codevitals.run/project/gutenberg.

[luisherranz]

That's weird, because even though adding scripts with document.write is blocking and synchronous, it should not affect the latest versions of the browsers, which I guess is what the CWV is using to test.

We could try adding async, but if LCP is affected, it probably means the polyfill is being loaded when it shouldn't.

Previous related conversations:

• Interactivity API: Use modules instead of scripts in the frontend #56143 (comment)
• Load the import map polyfill only when there is an import map #56699 (comment)

[Mamaduka]

@luisherranz, this could be due to the WP hook changing from wp_footer to wp_head, but I've not tested this theory.

[luisherranz]

Yeah, but theoretically, in modern browsers, all it adds is a script tag with an if that resolves to false:

<script>
  if ( ! ( HTMLScriptElement.supports && HTMLScriptElement.supports( "importmap" ) ) ) {
    // Nothing else to do, because the if is always false in all the modern browsers.
  }
</script>

So that shouldn't affect the LCP even if it's in the head.

[luisherranz]

I'm not sure I'm looking in the correct place, but if I am, it seems like the performance tests are using the latest chromium version:

gutenberg/bin/plugin/commands/performance.js

Line 213 in 52ff927

`bash -c "source $HOME/.nvm/nvm.sh && nvm install && npm ci && npx playwright install chromium --with-deps && npm run build:packages"`,

Theoretically, that version should not load the polyfill.

[Mamaduka]

That's correct; perf tests use the latest browser versions provided for Playwright - https://github.com/microsoft/playwright/releases/tag/v1.39.0.

[luisherranz]

Tested Chromium 119 installed and run via playwright 1.3.9 locally in a arm Mac and confirmed that it does not load the polyfill.

[luisherranz]

Just to be sure, we are looking at these numbers, right?

https://github.com/WordPress/gutenberg/actions/runs/7409967406/job/20161251805?pr=57256

1. front-end-block-theme

(index)	f7afa64d69f90ac4494c3a0b49b73d7fe9f673ee	trunk
timeToFirstByte	'51.8 ms'	'51.3 ms'
largestContentfulPaint	'106.2 ms'	'104.4 ms'
lcpMinusTtfb	'52.8 ms'	'52.5 ms'

2. front-end-classic-theme

(index)	f7afa64d69f90ac4494c3a0b49b73d7fe9f673ee	trunk
timeToFirstByte	'39.15 ms'	'38.35 ms'
largestContentfulPaint	'113.8 ms'	'103.85 ms'
lcpMinusTtfb	'73.9 ms'	'64.3 ms'

---

Maybe we should run them a few more times to see if the numbers stay still?

Any other ideas about what might be going on here?

cc: @youknowriad, @gziolo

[gziolo]

That’s surprising results. It’s also unclear to me why it would impact negatively only the classic theme.

[gziolo]

We could try moving the polyfill to the footer as it seems to work in my basic testing, but as Luis pointed out it's a simple JS check for over 90% of users.

[luisherranz]

Maybe we should run them a few more times to see if the numbers stay still?

Now that we've got a few more PRs after this one, it's clear that it affected the LCP (https://www.codevitals.run/project/gutenberg):

---

As it still doesn't make sense that a single script with an if that evaluates to false is causing a performance issue, one test we could do to see if the browser that is used in the CI supports import maps or not is replacing the document.write() with a very expensive and blocking JS call. If that clearly increases the LCP, it means the if is not evaluating to false.