Optimize for high-usage label icons#449
Conversation
|
Measured against
Breakdown:
So the low-usage pruning is basically all of the win. Assuming the sprite is downloaded and not already cached:
|
|
Any somewhat normal website includes several images of hundreds of kilobytes each. I don't really understand why we need to save a few kilobytes here. The "search index" is so much larger, it's much easier to win milliseconds there by tweaking how or when that loads. Alternatively, the icons file is loaded completely regardless of what icons you're looking at right now. Instead, we could consider inlining the svg content into the markup instead of referencing elements in the larger file. That way you only load what you're rendering at that point. (random internet link about this approach): 
|
Agree.
I don't know that this is best. You save the cost of the unvisited icons, but you now load the SVG bytes every place it appears in the file. And you don't get to cache the bytes across different pages with the same icon (let alone between visits where the HTML updated but the icon doesn't). Can eleventy provide each icon as a file? You add the bytes of overhead for transferring each file, but you get to cache the files again. |
|
We don’t cache any of the other the words or bits markup either. You’re talking literally about bytes at that point.
They might even start out as individual files? Not sure what the build pipeline looks like for this. |
They also aren't included in the list of labels, so no reason to bloat the icons for insignificant labels. Additionally, this improves exclusions and aliases of icons. C, C# and C++ icons look very silly next to their names, so exclude those.
Keep build-label-icons focused on shipping the complete used-label icon set, then derive the low-usage subset during the Eleventy build. This lets the generated labels page, search index metadata, and copied SVG sprite agree with the current build dataset. Also keep the manual C-family exclusions and drop the unused mac to apple alias.
|
If this is just a fight between first load/most commonly used icons (as I read this), we just split the icons sprite into 2 (or n but that's really overdone then), and ship 100 icons on the front page and the rest by their first usage. (We actually ship on first usage anyway, but the homepage almost always has icons.) |
So usage > 2 seems like a better fit (or even 3), as we still had 93% of all packages covered by that first sprite file but only 35KiB download size.
|
ec6f794 to
be354ef
Compare
kaste
changed the title
Keep icons used by more than one package in the primary sprite, along with icons shown on the initial homepage and icons belonging to packages updated in the last year. Route less common icons to a second sprite so all labels retain their icons without burdening the initial page load. The current data puts 107 icons in the 41 KiB Brotli primary sprite and 30 icons in the 30 KiB fallback. The fallback is not needed until page 36 of Newest or page 47 of Recently Updated.
Require an icon to be used by more than two packages before including it in the primary sprite. Homepage icons and icons used by packages updated within the last year remain preferred regardless of usage. This reduces the primary sprite from 107 icons and 41.0 KiB Brotli to 90 icons and 35.8 KiB. The fallback still does not appear until page 32 of Newest or page 46 of Recently Updated in the current dataset.
be354ef to
ec1440a
Compare
3 participants
... but proper and dynamic.
Also, for neither "apple" nor "mac" we have icons. Remove, the c family because "Jon finds them awful".