Actually this is where you can be flexible with a specification. If the ticket was initially specified as embedding the fonts, then technically it's an implementation defect since it was already specified. However, as a team you might decide it's not too bad to download fonts instead of embedding them. This is where you can be flexible with the solution. Instead ob being rigid with expectation when the reality is the bug can comfortably be re-classified.

If however the loading time with downloading the fonts is something the team is not as per the team's quality standards and they are not willing to live with it, then it should absolutely remain as a bug.

Now that the classification portion is out of the way, the team priority is to work on bugs first no matter what.

So I'm saying that "the actual definition of what a bug is" should be stated as a guideline and the team can decide on an ongoing basis. Some guidelines might be rigid, others not so much.