Accessibility First DevRel. I focus on ensuring content created, events held and company assets are as accessible as possible, for as many people as possible.
Preword: this is a warning on the use of the library itself, not your article, despite the tongue-in-cheek title suggestion :-P
This should be titled "The one script that will kill your core web vitals".
If you used 10 different emojis on your page that is 10 extra network requests (plus one for the script itself), so your load speed will suffer!
Also I would imagine that your Cumulative Layout Shift would be horrendous due to the impact of inserting the images on the fly (and as such not allocating the correct space for them).
You would be much better manually inserting the SVG code for the emojis inline within the HTML if they are that important to your article.
If that much effort is not justified, then you know that is when you are using emojis the wrong way as they are simply not needed!
Additionally that alt text for the images will not behave well with screen readers as it appears to just be set to the emoji Unicode character, so from an accessibility perspective this is probably worse as you now have an image with a potentially useless alt description that will be announced instead of just an item that will get skipped (as screen readers have a notoriously bad time with emojis).
I would say avoid this at all costs for any site that needs traffic I am afraid (useful for personal blogs perhaps and the like, which I suppose are where emojis would be used anyway so perhaps I am just being stupid. hehe.)
I strongly agree, replacing a simple unicode emoji with a JS library that replaces the svg on the fly is a really, really bad idea.
If you do want to replace emojis with SVGs you should do it at a build step, automatically. Preferably all the SVGs would also be loaded as a single spirte-sheet to avoid multiple requests.
Personally I think that emojis are well supported enough to be used natively.
Accessibility First DevRel. I focus on ensuring content created, events held and company assets are as accessible as possible, for as many people as possible.
Not a problem, like I said (or should have said more clearly!) I enjoyed the article and it actually has made me think this is one step away from a good idea.
You could convert the code to server side code and replace all the emojis with inline SVGs before serving the page. The principal is sound just the implementation is bad, doing it on the server could actually be a useful solution.
Saved the library anyway and if at some point I get down my list of 50 "thats a great idea I will do that one day" items I may implement it as a server side library.
Accessibility First DevRel. I focus on ensuring content created, events held and company assets are as accessible as possible, for as many people as possible.
Preword: this is a warning on the use of the library itself, not your article, despite the tongue-in-cheek title suggestion :-P
This should be titled "The one script that will kill your core web vitals".
If you used 10 different emojis on your page that is 10 extra network requests (plus one for the script itself), so your load speed will suffer!
Also I would imagine that your Cumulative Layout Shift would be horrendous due to the impact of inserting the images on the fly (and as such not allocating the correct space for them).
You would be much better manually inserting the SVG code for the emojis inline within the HTML if they are that important to your article.
If that much effort is not justified, then you know that is when you are using emojis the wrong way as they are simply not needed!
Additionally that alt text for the images will not behave well with screen readers as it appears to just be set to the emoji Unicode character, so from an accessibility perspective this is probably worse as you now have an image with a potentially useless alt description that will be announced instead of just an item that will get skipped (as screen readers have a notoriously bad time with emojis).
I would say avoid this at all costs for any site that needs traffic I am afraid (useful for personal blogs perhaps and the like, which I suppose are where emojis would be used anyway so perhaps I am just being stupid. hehe.)
I strongly agree, replacing a simple unicode emoji with a JS library that replaces the svg on the fly is a really, really bad idea.
If you do want to replace emojis with SVGs you should do it at a build step, automatically. Preferably all the SVGs would also be loaded as a single spirte-sheet to avoid multiple requests.
Personally I think that emojis are well supported enough to be used natively.
Thanks for your comment 😁
Not a problem, like I said (or should have said more clearly!) I enjoyed the article and it actually has made me think this is one step away from a good idea.
You could convert the code to server side code and replace all the emojis with inline SVGs before serving the page. The principal is sound just the implementation is bad, doing it on the server could actually be a useful solution.
Saved the library anyway and if at some point I get down my list of 50 "thats a great idea I will do that one day" items I may implement it as a server side library.
Honestly I didn't think about the fact that, indeed, this creates many requests if you put several emojis! Thanks for your advice.
P.s. I guess what you're looking for is the rectangle "save" button, isn't it?
No I found it, the big heart icon on the left to give your article some love was what I was looking for! hehe.