3 ms·

Nice work! My only suggestion is to optimise it, which we have :) (Lifting this from lower down in the thread). The following SVG fragment is a drop in replace

by tomxor 3y ago

Nice work! My only suggestion is to optimise it, which we have :) (Lifting this from lower down in the thread). The following SVG fragment is a drop in replacement for the <img> tag and produces the same result, albeit completely symmetrical as a side effect of quantising the coordinates: <svg width="18" height="18" viewBox="-32 -32 64 64" style="background: #f60; border: 1px white solid;"> <path fill="#fff" d="m0-5l-8-12h-7L-3 1v16h6V1l12-18H8z"/> </svg> This reduces the total payload from 1448 bytes to 172 bytes including whitespace (I ungolfed it slightly to make it less hacky). By comparing both the inline <img> tag, and the svg file and it's HTTP header (which disappears when you inline).

bambax 3y ago
Choosing a viewBox of size 64 as you have, is a much better choice than 100, because 64 is a power of 2. Symmetry is hard to achieve by hand with a path, and even harder if the origin is at the top left (0,0) instead of in the center (as you also have), because it's obvious that -3 is symmetrical to 3, and less immediately obvious that 47 is the opposite of 53 for example. That said, if working entirely by hand, using elementary shapes can be easier to write and understand (I think); here's an attempt with using one rectangle three times for the Y (and another rectangle to mask the edges at the top): <svg width="18" height="18" viewBox="-32 -32 64 64" style="background: #f60; border: 1px white solid;"> <rect x="-3" y="-2" width="6" height="24" fill="white" id="rc1"/> <use href="#rc1" y="-22" transform="rotate(-34) scale(1, 1.2)" id="rc2"/> <use href="#rc2" transform="scale(-1,1)"/> <rect x="-30" y="-30" width="60" height="12" fill="#f60"/> </svg>
- social_quotient 3y ago
  Cool! Here is a little smaller version of yours. Spaces and color abbreviation. That word “background” sure is big here. <svg width="18" height="18" viewBox="-32 -32 64 64" style="background:#f60;border:1px #fff solid;"><rect x="-3" y="-2" width="6" height="24" fill="#fff" id="rc1"/><use href="#rc1" y="-22" transform="rotate(-34) scale(1, 1.2)" id="rc2"/><use href="#rc2" transform="scale(-1,1)"/><rect x="-30" y="-30" width="60" height="12" fill="#f60"/></svg>
  - b112 3y ago
    Stop it! If you bastards optimize this any more, you'll hit the fractal limit, and drop into negative optimized space, renting local spacetime, killing us all! Is it really worth it? Is it?!?!
  - bambax 3y ago
    Ok, but my point was to be readable and easy to understand by using elementary shapes (rectangles), not to be as small as possible. (My version is much bigger than the comment it was replying to.)
miken123 3y ago
But is it an optimisation to send the SVG contents in every request, instead of just letter the browser cache the image?
- eagleseye 3y ago
  Since the svg is not inline but rather loaded externally it is being cached aswell. (source https://stackoverflow.com/questions/37832422/how-can-we-cache-inline-svg-in-browsers https://stackoverflow.com/questions/37832422/how-can-we-cach...)
- dieulot 3y ago
  Yes, retrieval from disk caching is not as fast as one would expect. Detailed article: https://simonhearne.com/2020/network-faster-than-cache/ https://simonhearne.com/2020/network-faster-than-cache/
  - rakoo 3y ago
    Speed is not the only criterion. Using network is a waste of energy and materials when the local cache was enough (even more when nobody sees the perf difference)
- aww_dang 3y ago
  When optimizing for lighthouse pagespeed metrics, yes.
- tomxor 3y ago
  That's a valid point, for subsequent loads in this case the inline svg is so small that when compared to the image tag it's replacing the difference is pretty small. But the other side of this is cache latency, this depends on the caching policy defined in the http header, for example some modes require validating caches with the server which incurs a round trip even if it doesn't require always reloading the resource. If it's fully offline caching then as a sibling comment pointed out, disk caching is not free either, under some threshold (which definitely applies here) inline is going to be the fastest way to get an svg rendering.
nailer 3y ago
What does “ungolfed” mean?
- mfkp 3y ago
  It's a reference to "code golf", where you try to make your code as compact and the least number of bytes possible. "Ungolfed" in this context means that it was cleaned up to make it more readable, at the expense of adding a few more bytes to the size.
  - JoshTriplett 3y ago
    And "code golf" got its name because better scores are a lower number of (key)strokes.
    - pelagicAustral 3y ago
      For completion: https://en.wikipedia.org/wiki/Kolmogorov_complexity https://en.wikipedia.org/wiki/Kolmogorov_complexity
  - nailer 3y ago
    Oh I use 'unminified' for that. Even though someone deliberately wrote minified code rather than automatically, so sometimes people disagree. Maybe 'ungolfed' is better.
    - zamnos 3y ago
      there's a difference. unminified refers to a program doing that, using single letter function names and such, but the underlying logic is unchanged. code golf is different from that because the human can make changes to the underlying logic if it saves some lines of code, so long as the output is the same. more advanced minifiers do that as well, but the point remains, as a historical artifact because until we have AGI, there's still a difference between if a person did it vs a human
      - 3y ago
javifu 3y ago
This one is based on yours, which is quite elegant, and the total payload is only 115B: <svg viewBox="-32-32 64 64"> <path fill="#f60" d="m-31-31H31V31H-31z M0-5l-8-12h-7L-3 1v16h6V1l12-18H8z"/> </svg>
- javifu 3y ago
  It assumes a white canvas, otherwise a background must be added at line 2 <path fill="white" d="M-32-32 h64 v64 h-64 z"/> Spaces can be deleted of course.

by tomxor 3y ago

bambax 3y ago

Choosing a viewBox of size 64 as you have, is a much better choice than 100, because 64 is a power of 2. Symmetry is hard to achieve by hand with a path, and even harder if the origin is at the top left (0,0) instead of in the center (as you also have), because it's obvious that -3 is symmetrical to 3, and less immediately obvious that 47 is the opposite of 53 for example. That said, if working entirely by hand, using elementary shapes can be easier to write and understand (I think); here's an attempt with using one rectangle three times for the Y (and another rectangle to mask the edges at the top): <svg width="18" height="18" viewBox="-32 -32 64 64" style="background: #f60; border: 1px white solid;"> <rect x="-3" y="-2" width="6" height="24" fill="white" id="rc1"/> <use href="#rc1" y="-22" transform="rotate(-34) scale(1, 1.2)" id="rc2"/> <use href="#rc2" transform="scale(-1,1)"/> <rect x="-30" y="-30" width="60" height="12" fill="#f60"/> </svg>

social_quotient 3y ago
Cool! Here is a little smaller version of yours. Spaces and color abbreviation. That word “background” sure is big here. <svg width="18" height="18" viewBox="-32 -32 64 64" style="background:#f60;border:1px #fff solid;"><rect x="-3" y="-2" width="6" height="24" fill="#fff" id="rc1"/><use href="#rc1" y="-22" transform="rotate(-34) scale(1, 1.2)" id="rc2"/><use href="#rc2" transform="scale(-1,1)"/><rect x="-30" y="-30" width="60" height="12" fill="#f60"/></svg>
- b112 3y ago
  Stop it! If you bastards optimize this any more, you'll hit the fractal limit, and drop into negative optimized space, renting local spacetime, killing us all! Is it really worth it? Is it?!?!
- bambax 3y ago
  Ok, but my point was to be readable and easy to understand by using elementary shapes (rectangles), not to be as small as possible. (My version is much bigger than the comment it was replying to.)

miken123 3y ago

But is it an optimisation to send the SVG contents in every request, instead of just letter the browser cache the image?

eagleseye 3y ago
Since the svg is not inline but rather loaded externally it is being cached aswell. (source https://stackoverflow.com/questions/37832422/how-can-we-cache-inline-svg-in-browsers https://stackoverflow.com/questions/37832422/how-can-we-cach...)
dieulot 3y ago
Yes, retrieval from disk caching is not as fast as one would expect. Detailed article: https://simonhearne.com/2020/network-faster-than-cache/ https://simonhearne.com/2020/network-faster-than-cache/
- rakoo 3y ago
  Speed is not the only criterion. Using network is a waste of energy and materials when the local cache was enough (even more when nobody sees the perf difference)
aww_dang 3y ago
When optimizing for lighthouse pagespeed metrics, yes.
tomxor 3y ago
That's a valid point, for subsequent loads in this case the inline svg is so small that when compared to the image tag it's replacing the difference is pretty small. But the other side of this is cache latency, this depends on the caching policy defined in the http header, for example some modes require validating caches with the server which incurs a round trip even if it doesn't require always reloading the resource. If it's fully offline caching then as a sibling comment pointed out, disk caching is not free either, under some threshold (which definitely applies here) inline is going to be the fastest way to get an svg rendering.

nailer 3y ago

What does “ungolfed” mean?

mfkp 3y ago
It's a reference to "code golf", where you try to make your code as compact and the least number of bytes possible. "Ungolfed" in this context means that it was cleaned up to make it more readable, at the expense of adding a few more bytes to the size.
- JoshTriplett 3y ago
  And "code golf" got its name because better scores are a lower number of (key)strokes.
  - pelagicAustral 3y ago
    For completion: https://en.wikipedia.org/wiki/Kolmogorov_complexity https://en.wikipedia.org/wiki/Kolmogorov_complexity
- nailer 3y ago
  Oh I use 'unminified' for that. Even though someone deliberately wrote minified code rather than automatically, so sometimes people disagree. Maybe 'ungolfed' is better.
  - zamnos 3y ago
    there's a difference. unminified refers to a program doing that, using single letter function names and such, but the underlying logic is unchanged. code golf is different from that because the human can make changes to the underlying logic if it saves some lines of code, so long as the output is the same. more advanced minifiers do that as well, but the point remains, as a historical artifact because until we have AGI, there's still a difference between if a person did it vs a human
    - 3y ago

javifu 3y ago

This one is based on yours, which is quite elegant, and the total payload is only 115B: <svg viewBox="-32-32 64 64"> <path fill="#f60" d="m-31-31H31V31H-31z M0-5l-8-12h-7L-3 1v16h6V1l12-18H8z"/> </svg>

javifu 3y ago
It assumes a white canvas, otherwise a background must be added at line 2 <path fill="white" d="M-32-32 h64 v64 h-64 z"/> Spaces can be deleted of course.