chore: improve LCP performance

[2color]

Description

This PR builds on #282 and improves the LCP performance.

Attempts to fix #281

What and Why

• Disable inlining of fonts into the css bundle. Reduces the build size significantly and results in only the needed fonts being loaded. As a result of this change, the font files are copied to the dist folder, but are not prefixed with ipfs-sw, so we may have trouble if the fonts need to be loaded once the SW is installed.
• Disable inlining of the sourcemaps for production builds. This one results in significant reduction in the build size. The source maps are also prefixed with ipfs-sw so there shouldn't be any major problems.

Notes & open questions

• how to prefix the downloaded/copied typefaces so that they can work with the service worker
• Should we just remove use of external fonts and use system-ui?
• We could also use the font-display css property to optional to ensure we only use fonts if fetching them takes less than 100ms. (https://web.dev/articles/font-best-practices#choose_an_appropriate_font-display_strategy)

Change checklist

• [x] I have performed a self-review of my own code
• [ ] I have made corresponding changes to the documentation if necessary (this includes comments as well)
• [ ] I have added tests that prove my fix is effective or that my feature works

[SgtPooki]

╰─ ✔ ❯ ls -lhatr dist                                                                                                                5.98   27.5G   65%   100%  ─╯
Alias tip: ll dist
total 14M
drwxr-xr-x  38 sgtpooki 1.2K Jun 12 11:34 ..
-rw-r--r--   1 sgtpooki 132K Jun 12 11:34 81862cd5e78843a135df.woff
-rw-r--r--   1 sgtpooki 139K Jun 12 11:34 e19bfcb1c7eac9952c86.woff
-rw-r--r--   1 sgtpooki 103K Jun 12 11:34 a41f98d0e72e4b39f67a.woff2
-rw-r--r--   1 sgtpooki 145K Jun 12 11:34 11788b15932bb4e5cae6.woff
-rw-r--r--   1 sgtpooki 244K Jun 12 11:34 a09fa2ba55dff7af7fc0.otf
# ...
-rw-r--r--   1 sgtpooki 110K Jun 12 11:34 551a291434a17555ee24.eot

looking at the dist folder, a few issues:

1. we're still including a lot of fonts that I don't think we need.
2. assets are not prefixed with ipfs-sw which may cause issues with re-requests or SW handling of them

---

addressing items in your notes section:

how to prefix the downloaded/copied typefaces so that they can work with the service worker

Just saw this. you were already aware.. I should have known ;)

Should we just remove use of external fonts and use system-ui?

If this doesn't require an update to ipfs-css, I am down. I like the idea of reducing dependencies

We could also use the font-display css property to optional to ensure we only use fonts if fetching them takes less than 100ms. (web.dev/articles/font-best-practices#choose_an_appropriate_font-display_strategy)

From that page:

The block period begins when the browser requests a web font. During the block period, if the web font is not available, the font is rendered in an invisible fallback font and thus the text will not be visible to the user. If the font is not available at the end of the block period, it will be rendered in the fallback font.

in other words, a flash of unrendered content(FOUC) for 100ms for any requested fonts. this could be undesirable if we aren't caching any font assets with SW.

I think I prefer a system-ui font

[2color]

+1. this may cause some issues with debugging, especially because of our currently convoluted build process (aegir/tsc->webpack) but will definitely reduce prod bundle size.

I'm curious, why do we use both aegir (which comes with esbuild) and webpack? Is that because of the code splitting?

[2color]

we're still including a lot of fonts that I don't think we need.

Fixed in the last build which does not copy any of the fonts from url functions in the css

I think I prefer a system-ui font

That's what I've defaulted to now by overriding the .sans-serif class that's defined in ipfs-css.

So no more external fonts.

[2color]

This PR is ready for another review.

This still doesn't change the fact that CSS files are getting chunked in a slightly weird way (multiple small files probably chunked based on the dynamic imports), and are not minified.

Compared to 947011e772f73d32b2380bb6d7521f61fc8d27bf there are some big savings:

Before

After

[SgtPooki]

+1. this may cause some issues with debugging, especially because of our currently convoluted build process (aegir/tsc->webpack) but will definitely reduce prod bundle size.

I'm curious, why do we use both aegir (which comes with esbuild) and webpack? Is that because of the code splitting?

Dynamic imports and benefits of asset loading and sw stuff I'm not as familiar with esbuild for. I attempted a migration fully to esbuild in the past but it didn't work great.