From a theoretical viewpoint, the answer is almost certainly that there's no speed difference that's truly intrinsic to the language. Either one can express any algorithm in a similar enough fashion that there's no good reason to believe one would necessarily be any faster than the other.
That doesn't have much to do with real life though. C typically compiles to native machine code. Its execution speed is more or less directly the speed of execution of the processor.
Forth is more often implemented as threaded code. There are two varieties: direct and indirect. Indirect threaded code, in particular, tends to be very compact, but has a reputation for being slow. Basically, executing a single "word" requires two indirections. Because of this, execution speed varies a lot more widely.
Threaded code is (usually) extremely compact, so it makes extremely good use of the processor caches. The inner interpreter will typically always be in the code cache, and in many cases much of the system dictionary will as well. Since the threaded code is so compact, a great deal of it will fit in the data cache. As a result, a lot of execution can run entirely inside the processor caches, without using memory at all.
As such, indirect threaded code will often be quite a bit slower than C on a smaller or older processor that doesn't have any kind of caching at all. On a newer processor with decent sized caches, threaded code is often much closer to the speed of native code, and can even be faster. Direct threaded code has roughly the same effects, but the degree of difference tends to be smaller (i.e., the code is larger so without caching it's not as slow, but the benefit when you do have caching isn't as large).
Those are basically characteristics of native and threaded code though, not of the source languages themselves. Forth compilers that produce native code aren't particularly rare, and the code they produce isn't all that much different from code C compilers produce. C compilers that produce threaded code have been written too, but they were mostly intended for fast development to be used in conjunction with a normal C compiler that produced native code for distribution. As such, they tended to emphasize fast compilation over producing particularly good code.