How to versioning front-end projects?

Semantic versioning brings the following approaches: [...] but a frontend Artifact does not have APIs, making them do not break compatibility with those who use them.

That's right. Semantic versioning is used to normalize the behavior of dependencies. An end consumer is not a dependency, so the model does not apply - however several companies carry out married implementations, maintaining the versioning of the Lock in lockstep with the API version consumed.

How would it be better to increment the version numbers of a frontend?

If they occur at the same time, use the same API version tag. If not, it is up to you to create (or reuse) a versioning criteria definition.

If my frontend starts consuming a new third-party API, would it be a MAJOR change?

Is at the discretion of project, since SV does not apply. Version 2 of an app may well be using the same endpoints as the version 1 API.

I found a nice article that suggests some rules for versioning frontends, the article basically says the following:

Given the importance of an application's installation requirements for installer users, I propose that Semver be used for final version applications using the installation requirements as a public API with installer users as consumers of this API. In practice, Increment:

• MAJOR when you make incompatible API changes (for example, installer users must modify their infrastructure (phone / tablet / PC / web-server / firewall config / etc) in some way)
• MINOR when you add functionality in a backward-compatible manner (for example, passing additional data to an already provisioned API or adding any end-user functionality that does not affect installation requirements)
• PATCH when you make versioned bug fixes (for example, fixing any end-user error that does not affect installation requirements).