Performance Differences in Standalone player versus Web Browser?

Summary - I'm seeing performance differences in the Web Browser versus a standalone executable version of a Unity build. And I don't know why. :)

Situation: I've created the simplest scene I can - a 50-yard terrain, and a FPS controller at one end, plus a Frames-per-second guiText. I create both a standalone executable, and HTML file for testing. I have not changed any of the default Unity parameters.

In the standalone file, I run (via the FPS controller) from one end of the ramp to the other end - it takes 7-8 seconds to reach. Frames-per-second is showing in the thousands.

In a Web Browser (both Opera and IE) I do the same run down the ramp, and it takes 14-15 seconds to complete. The Frames-per-second generally shows 100+.

Why is there a time difference between these two?

At first, I was thinking that the difference in framerate would affect the run speed. But I looked over the FPSWalker script, and it uses FixedUpdate(), as well as Time.deltaTime applied to speed. So I would have thought that this compensated for the framerate difference.

I previously asked a question about Animation clips playing for different times, and it was suggested it might be a bug. But just moving the FPS controller around, in standalone versus a browser - it's too basic. I can't see how something that fundamental would be a bug. :)

Which means it's something in the configuration, in the scripts - or possibly in my assumptions. :) My first assumption is that they should perform the same - but I don't really know that. How should it work, given identical scenes, and no Unity configuration changes? And if they should work the same - what could cause it to not do so?

Update: mea culpa... I thought the code for reporting my Framerate was working, but maybe not. In any case, I tried setting the framerate to 30 frames-per-second, and both the standalone executable and Web browser then performed at the same speed. Sigh...

The frame rate is capped to a maximum when running in windowed mode in a web browser (i.e. not fullscreen).

This was implemented by UT so that the web browser doesn't end up eating up all the cpu power just because Unity is running (which, in turn, helps the Unity plug-in to not become known as a CPU hog). If you switch to full-screen mode you should see the frame rate cap lifted.

The difference in physics behaviour is a little strange though. (I thought I had spotted the reason for it, but my theory turned out incorrect so I have deleted that portion of the answer!)

the web player has other small diferences. the input code and some others are removed from the engine of web player and it uses javascript on the web to detect them.