There are a lot of factors at a lot of levels.
A completely interpreted language will be slower in general than a compiled language which in turn will be slower in common cases than a language that is compiled to an intermediate representation and utilizes runtime optimizations like JIT.
At the same time, a language that is too bare bones may be very fast, but if it takes a lot of effort to write anything in it there will be less time/work left over to optimize it. A language that is bare bones but has a lot of libraries will often accumulate inefficiencies when interfacing between these libraries due to having to transcribe data formats or incompatible locking schemes.
A language that is too abstract will have layers and layers of classes or constructs and eventually the compiler will find a reason not to optimize it, and the reasons will be buried too deep for mere mortals to fathom. Or, probably even more common, it will manage to bury locking mechanisms too deep inside the abstractions so the program will spend most of its time waiting for other parts of itself to do something.
A language with a garbage collector will be faster than a reference counting language, except for the 100ms every second or so where it takes a pit stop and does nothing at all. Which will require it to have special intricacies and workarounds to handle real-time tasks.
A functional or declarational language will usually stress immutability, and will burn through memory/cache if not coded with care of if the compiler is not up to snuff, and that will slow it down. An imperative/procedural language is more likely to encourage mutable objects, and then introduce more locking or copy-on-write mechanisms which will be more CPU intensive.
So, I'll give you a much simpler answer: Good documentation makes a language fast, because it tells you how to write fast code, gives you a clear idea how and why things work, gives you pointers to educational material that helps you write better algorithms or avoid mistakes, and lets you find wheels before reinventing them.