I'm not a googler or familiar with chrome or really that knowledgeable about fontconfig to be honest, (so I could be wrong! and I am curious what the answer would be from jungshik or someone who knows better than I do...) but it looks like a fontconfig issue to me.
Also seems like #36 which has an extensive discussion and some possible solutions.
I can give an in-depth explanation, from the best of my knowledge, if anyone is interested...
The page asks for Segoe UI Emoji (which we Linux users don't have installed) and so our systems look for any other font that can serve those glyphs. (Usually fontconfig is the subsystem that handles this -- fontconfig generally handles which fonts get used when on Linux).
(One can double-check that the font itself is fine by editing the page in the chrome dev-tools:)
By default, the CSS on the page requests "Segoe UI Emoji" which I don't have, so I get 4 different fallback fonts)
If averissimo repeats these steps and has the same result I have, I believe that helps confirm this is a fontconfig problem.
(Unless Chrome is somehow exacerbating the problem, or unless it is Chrome's responsibility to step in where fontconfig fails a user in this manner.) But I admit I am not an expert on this.
If so, we are basically asking fontconfig: "Hey fontconfig, give me anything that has a glyph at these codepoints" -- not specifically the user's shiny new color emoji font.
Unfortunately Ubuntu has lots of fonts that contain glyphs at various (especially older) emoji codepoints, all in black and white outline style.
And Ubuntu's developers haven't addressed this situation yet. Right now their fontconfig files do not mention any color emoji fonts, and so the color emoji fonts a user installs end up being "what's left" after the likes of Liberation Sans and Symbola have been exhausted, and as a consequence the user-installed fonts are usually searched last for glyphs. Really.
This is a perennial issue for emoji fonts under Linux. I think it may be solvable by having a fontconfig configuration that makes NotoColorEmoji get used first over other fonts, but there might be minor issues in different apps. For averissimo's YakYak app, which seems to use CSS, maybe the app needs a change to more specifically ask for Noto Color Emoji? For a peek into the emoji-on-Linux rabbit hole, and some possible solutions, to usage in the browser, see #36.