Library is 64Kb, minified

[NullVoxPopuli]

Posting from: https://bsky.app/profile/nullvoxpopuli.com/post/3l4g6z3holy27

After gzip, this library (+ dependencies) are 23kb.

This is quite hefty.

BundlePhobia: https://bundlephobia.com/package/baseline-status@1.0.4

Some of it is lit -- but a lot of it is just this component.

some questions:

• Does it need all of lit?
• is this library side-effect free?
  • this would allow tree-shaking of unused consts/functions/etc
  • BundlePhobia says:
    Exports analysis is available only for packages that export ES Modules and are side-effect free.
    This package [...] isn't marked side-effect free.

[stof]

the package is not side-effect free as it registers a custom element (well, 2 of them actually, as there is an internal one)

[niutech]

Whooping 64KB of minified code for a small Baseline Status widget is over the roof. It should fit in <20KB of minified code.

[stof]

I think a big part of it is the string containing CSS code. A JS minifier won't be able to reduce the size of that string, which takes half of the size of the file.
A custom minification that applies a CSS minifier on the content of that string would likely reduce the size (not sure of the actual size reduction after gzip though)

[captainbrosset]

I agree this is a big problem that we need to solve. We shouldn't be imposing this performance cost to the hosting webpages.
(Out of scope for this issue, but we probably shouldn't be imposing JS at all either, and think about what a server-side rendered HTML version could be).

Looking at the code, the SVG browser icons seem to be responsible for a large portion of the total size of the source file. I'm estimating around 60% of it.
On top of this, the built version embeds Lit, which adds even more.

[captainbrosset]

Regarding the SVG, we need to think about simplifying them substantially. The size at which they get rendered by default is very small and doesn't warrant that much details which most users will not see.

If I save the SVG string for the Safari logo (which is the longest) as a SVG file, it comes out at 20KB!
Saving the rendered image (at its default size) as a PNG file results in a 3KB file only.
But, I can further than that: if I save the biggest possible size that the logo can be displayed at (500% zoom) as a file, and run it by sqoosh to convert it to AVIF, I get a 3KB file.

So, there really doesn't seem to be any reason for embedding those large, very detailed, SVG code lines in the component.

[niutech]

@captainbrosset As for no-JS widget, Astro Embed <BaselineStatus> component is using Declarative Shadow DOM, but it can be done without DSD provided that the API optionally outputs HTML.

As for SVG optimization, there is an excellent tool SVGOMG.

[bramus]

Instead of trying to wrangle the SVGs, how well do base64-encoded small PNGs do?

[captainbrosset]

Instead of trying to wrangle the SVGs, how well do base64-encoded small PNGs do?

Agreed that the SVGs are unnecessarily complex. At most we're only going to be showing these icons somewhere between 30px to 200px. At these sizes, raster images seem to be perform a lot better. In my previous comment, I tested AVIF which (even for the largest page zoom) produced a 3KB file for the Safari logo.

Someone should try to embed base64-encoded versions of these images and see what the result feels like.

[niutech]

@captainbrosset As for AVIF, it's not widely supported, so I would stick with good old PNG.

For comparison, here is the optimized PNG version of Safari logo (40x40 px, 2119 B):

and here is the optimized SVG version of the same Safari logo (3360 B):

Base64 encoding of PNG in data URI adds an overhead of 33%. SVG does not need to be Base64-encoded.

[captainbrosset]

If we can live with the fact that, at max zoom level, the optimized SVG shows some incorrect details, then I really like the idea.

[bramus]

What about not including any images in the package itself? The data is fetched from an external endpoint anyways, so maybe the API server could also serve the logos?

(In that case, maybe also allow an option to set the baseURL for the logos, so that people can self-host the logos if they want to)

[jsnkuhn]

I know that the SVGs you are talking about above are the browser icons but it occurred to me that the baseline icons can probably also be reduced in file size by using stroke to create them instead of fill. Here's a proof of concept that cuts the baseline-newly-icon.svg icon code in half:

https://codepen.io/jsnkuhn/pen/OPLZddP?editors=1100

[jsnkuhn]

What about the possibility of using a sprite sheet for the browser icons?

Would reduce the number of HTTP requests the widget imposes on sites. Also usually the overall file size of a sprite sheet is smaller than the file sizes of the individual images added together.