Future of icons

[matoululu]

Some merchants are commenting that icons are loading in slowly in our themes, recently we went ahead and decided to fetch our icons using JS instead of using a large snippet containing all of the icons.

While this offers some benefits it does have the disadvantage of a noticeable load time (specifically elements ‘above the fold’). I had a brief chat with @bertiful today and wanted to start a discussion on what we all think may be the best approach is here.

A couple of options I’ve brainstormed would be

• Since we know that header icons will always be present and above the fold we can hardcode those ones within their respective sections rather than fetching them with JS.
• Return to the idea of a large snippet containing all of our icons and reference it in the icon.liquid file so that we can choose whether we’re loading via snippet or fetch (for 3rd party libraries where a small load time would be expected)
• Finally, we can keep on course with our current method and try to make the load time less noticeable (ex: specify container width and heights to avoid a noticeable layout shift)

In any case it’s only been a handful of merchants bringing this up so there is no immediate urgency so we have the luxury of time to discuss what we think is the future of icons in our themes.

[t-kelly]

Love that you flagged this!

IMO our approach of requesting the icons should should be fine for non-critical path icons -- but your point makes sense (and maybe what merchants are referring to) with icons that are more critical.

Since we know that header icons will always be present and above the fold we can hardcode those ones within their respective sections rather than fetching them with JS.

The biggest dealbreaker for that is that we remove flexibility of changing out the contents of the icon from theme to theme

Return to the idea of a large snippet containing all of our icons and reference it in the icon.liquid file so that we can choose whether we’re loading via snippet or fetch (for 3rd party libraries where a small load time would be expected)

I think we're definitely onto something with our current approach. Not convinced that we need to backtrack back to snippets for SVGs yet.

specify container width and heights to avoid a noticeable layout shift

We should definitely minimizing layout shift regardless to our final approach

Spitballing a few ideas:

• I noticed we do have the icon component wrapped in a <is-land> component -- is that even needed here given the amount of JS?
• Could we inline the JS here and keep it to a minimum? That way we don't have JS to download before making the request?

Our approach is inspired by Shoelace's icon component -- what more can we learn from there?

Would be great to see some before/after experiments!

[bertiful]

I would not backtrack, otherwise we risk having two fragmented solutions to the same problem. I would go all-in with our current approach—it's solid given the amount of flexibility it provides.

@t-kelly the is-land component/JS is one of the first pieces of JS, at least within the theme, that's being loaded. In an icon's case, it ensures we're not fetching and loading in that icon until it's actually visible (much less relevant for above-the-fold icons).

Some questions worth exploring:

• Does preloading any of the assets help with this delay? A larger delay is caused by the fact that we're loading in JS for the icon component then making the request. If we can remove part of that sequence, is the perceived performance good enough?
• What can we learn from SVG sprite sheets and could we leverage this for above-the-fold (or all?) icons?

[matoululu]

Hey @t-kelly and @bertiful

I've been playing with the idea of preloading and inlining the JS (currently placed in the layout files) and got good results!

Now i'm no network timing expert but here are recordings using 'regular 3g' network throttling

Preloading and Inlining

Screen.Recording.2024-05-24.at.9.38.27.AM.mov

Current approach

Screen.Recording.2024-05-24.at.9.41.26.AM.mov

As you can see it's even faster than the font rendering and in our current approach the age verification will appear before the icons have a chance to load

Now if we do like these results we can certainly keep moving forward with it, i'm not 100% sold on placing the JS in the layout files so i'm open to some thoughts here but as for preloading icons we can keep it fairly controlled with conditionals

{%- if settings.search_enable -%}
    <link rel="preload" as="image" href="{{ 'icon-search.svg' | asset_url }}">
  {%- endif -%}

  {%- if shop.customer_accounts_enabled -%}
    <link rel="preload" as="image" href="{{ 'icon-user.svg' | asset_url }}">
  {%- endif -%}

  {%- if settings.cart_icon == 'bag-minimal' -%}
    <link rel="preload" as="image" href="{{ 'icon-bag-minimal.svg' | asset_url }}">
  {%- elsif settings.cart_icon == 'bag' -%}
    <link rel="preload" as="image" href="{{ 'icon-bag.svg' | asset_url }}">
  {%- else -%}
    <link rel="preload" as="image" href="{{ 'icon-cart.svg' | asset_url }}">
  {%- endif -%}

To add, I'm only preloading the icons we know for sure will appear above the fold

[t-kelly]

I did my own testing and found out our approach is not the bottle neck, just the wrapping <is-land on:idle> element.

Fixed it and wrote about it here!