The vocabulary of Scrum has two aspects of finished work. First the team declares work done. Then the product owner accepts it. That is the optimal case of course. Many teams confuse the definition of done with acceptance criteria. The team defines what they mean when they say something is done. The product owner accepts work case by case and the criteria should be part of the story.
The definition of done is the common agreement made by the team of things that they will perform when applicable for every user story even and especially when there is no acceptance criteria specified.
Just like the team may try to stretch the amount of story points they take into a sprint, they may have a future vision of where they want to be eventually. The point of the definition of done is not to communicate an intent, rather it should describe an achievable level which is backed by a track record. Also, the list is not supposed to be conclusive.
There are levels to which it makes sense to commit to. For example performance testing is easily doable for new features when the hardware is in place. If it isn’t, the team does not have the power to make a promise. Whether or not that type of testing should be a part of the definition of done depends on the related risk.
The promise conveyed through the definition of done is a tool for the product owner. The items within the definition of done do not need to be implied in the user story. Unlike the the definition of done, acceptance criteria may be different for each story. It is also possible to omit some of the items in the team’s definition for a good reason.