The discussion revolves around implementing lazy loading for emojis in Discourse. rrit initiated the conversation, pointing out that emojis are not lazy loaded like profile pictures and image elements. rrit submitted a pull request (https://github.com/discourse/discourse/pull/15830) to address this issue.
rrit explained that adding hardcoded width and height attributes to img elements, including emojis, is a good practice. This approach allows browsers to calculate the aspect-ratio before loading the image, reducing potential layout shifts. sam questioned the need for hardcoded attributes, but rrit clarified that it provides more flexibility with CSS and limits blocking around CSS. sam acknowledged the benefit, despite the resulting more verbose HTML.
The pull request was ultimately merged, as announced by pmusaraj, who thanked rrit for the contribution.
Profile pictures and image elements in posts get lazyloaded by having the attribute loading="lazy" set.
Emojis are missing out on this. 
<img src="https://emoji.discourse-cdn.com/twitter/sloth.png?v=12" title=":sloth:" class="emoji" alt=":sloth:">
I could not find the location in the sources where the emoji tags are generated.
Are emojis “baked” into the posts?
Can you expand on why you added hard coded width and height? Why is our CSS solution not good enough here?
Personally I think it is like a good manner to always add width and height attributes to img elements on point where the img-element is generated. That is the place where I might know for sure which exact image-file I’m putting in. CSS is far away from the actual image-file.
On top the browsers use this extra info about the image size to calculate aspect-ratio before loading the image file - and before CSS parsing.
For this case the emojis are used in many different places - and sometimes defining sizes via CSS will be skipped accidentally.
E.g. see crawler view of this very same topic on PageSpeed
I see, so the browser is using this to figure out aspect ratio and this allows people more flexibility with CSS (and limits blocking around CSS). Seems good to me, does make our html a bit more verbose though.
This PR has now been merged, thanks for the contribution @rrit!
