One piece of discipline that will save you from the opposite mistake, which is the one people make after reading threads like this: do not remove clones for performance without measuring.
What happens otherwise is a rewrite that threads lifetimes through six layers, makes the code substantially harder to read and change, and produces no measurable improvement because the program was waiting on the network the whole time. I have done this. It is a bad trade and it is very hard to undo.
So separate the two reasons cleanly:
For clarity and design - remove clones when doing so makes ownership obvious and the code simpler. That is always worth it and it is what the previous answer is about.
For performance, profile first, find out where the time actually goes, and only then look at allocations. If a clone is not in the hot path it does not matter how large it is.
And when a clone genuinely is hot and genuinely is needed, there are options between cloning and lifetimes: a reference-counted pointer for shared read-only data, a copy-on-write type for the read-mostly case, or an interned index instead of the value. Those are the tools for the real cases, and reaching for them before you have a real case is its own trap.
At six months, structure is the thing to be learning. The performance question can wait until something is actually slow.