If you picked good habits from past scars, stick to them. Otherwise, concentrate on functionality, dogfooding on real devices that real people have as much as possible, and use profiling to find the bottlenecks that emerge when you find the time (since you’re focusing on functionality).
(Exceptions to this rule exist, like if your product is some cloud service then speed might be an actual functional requirement of whatever you’re building)
[1] Yeah yeah, CPUs & standard libraries are smarter than that, I know, I know. You get the point.
Using strings for identifiers is almost always a bad idea.
If you are interfacing with other APIs that use Strings, it may make sense to just pass those through. For example loading files from disk or pulling up UI classes from the OS library using some String identifier or something. It's hard to say without more context.
Working with dynamically allocated strings, like reading from files, rendering from data bytes, working with C strings or building formatted strings, might have worse performance characteristics.
It's easier to fix a design mistake just when you've made it than when you've got six months of development hinging on the poor design choice.
In many cases the time and code required to incorporate some aspect of a 3rd party lib to do something is similar to the amount of time and code in building what you need. In that case, the dependency only serves to make your code more complex (and slow).
This is not always the case, but surprisingly often.