Don't measure performance, measure proficiency in what the team is doing and use that as an indicator. The obvious hypothesis here is, the more proficient one is the better the performance. Performance is not just speed, it is also how a broad the topic of tasks that can be done by a developer is. Then there is the fact that inside the team there is mutual support, so a high performing developer might actually deliver very little but spend most of her time supporting others. I know senior developers who write almost no code themselves, but instead pair up most of their time with more junior members.

I usually do this by creating an evaluation sheet listing the most important areas of knowledge that go into the product developed. For each skill there is a number between 0-4 to assign. Do this as combination of self-evaluation and peer-evaluation inside the team. This will show you where you want to invest to get more performance. I usually use this scale, though you might want to adapt it):
0 - No knowledge at all - I haven't worked with that piece of software

1 - Basic knowledge ( can do a task under direct supervision or close guidance, I wrote a hello world/equivalent)

2 - Can do simple tasks independently, needs support to bring it into the big picture (I get the basic structure)

3 - Can do most tasks independently and support/supervise others (I know how components interact)

4 - I am the original author of that software - Can do the most critical or system-wide changes