A game redraws the screen dozens of times a second. Each redraw is a frame, and on every frame the game adds a number to a position:
x = x + speed
That is all "speed" means here. Speed 8 means the runner appears 8 pixels further along on every frame. Nothing is smoothly sliding: it is teleporting a small distance, very often.
Drop a dot everywhere the runner has been, once per frame, and you can read the speed straight off the screen. The gaps between the dots are the speed. Wide gaps mean fast; tight gaps mean slow. You never have to be told which runner is quicker.
Later this same trail will teach you something else. When the gaps start out tight and stretch as the runner falls, that is no longer speed. That is speed changing, which is what gravity does.
Once you know a trip is just "the same step, over and over", two questions have the same answer from different directions.
How long will this take? Count how many steps fit into the distance:
How fast must I go to arrive on time? Split the distance across the frames you are allowed:
It is the same fact as a road trip. 300 miles at 60 miles per hour takes 5 hours; if you only have 5 hours to cover 300 miles you need to average 60. Nobody memorises two rules for that, and you do not need two here either.
A door that is open for a moment, a platform that swings past, an elevator you have to catch: arriving at the right time is a different problem from arriving fast. Too early is just as dead as too late. Guessing works when the window is generous. When it is three frames wide, the division is the only way in.
In your toolkit these become two one-line functions, speedNeeded(distance, frames) and
framesToReach(distance, speed). In math class this idea is called a rate, and when
you meet slope later, it is this again with a new name.